Administration

This page is for Admins and Super Admins. Everyone else can skip it, other than to understand who to ask when access needs changing.

Inviting users

There is no self-service sign-up. New people join only when an Admin or Super Admin invites them by email address, and the invitation is what creates the account.

Before inviting someone, decide two things: which organisation they belong to, and what role they need. Both are your decision, not theirs, and the role should be the least that lets them do their job — see Roles and permissions.

Send the invitation to the address the person actually uses. Invitations sent to shared or role-based inboxes tend to expire unread, and they make the timeline harder to read afterwards, because notes attributed to a shared account do not tell you who wrote them.

What the recipient sees is one screen: their name, a password, done. There is no verification email to chase and nothing for them to install, so "it did not work" almost always means the email did not arrive rather than that they got stuck part-way through.

Invitations last two days

An invitation link stops working 48 hours after it is sent. An invitation link is a credential, and one sitting unread in an inbox for a week is a liability — but two days is long enough that an invitation sent on a Friday afternoon still works on Monday morning.

If someone tells you their link no longer works, reissue it. Expiry is a normal outcome, not a fault.

Resending and withdrawing an invitation

Every outstanding invitation on the Users and invitations screen carries two actions:

• Resend issues a fresh link, valid for another two days, and emails it again. Use it when the original went to junk or lapsed over a weekend. The previous link stops working immediately, so there is never more than one live link per invitation.
• Withdraw cancels the invitation. Use it when you sent one to the wrong address — until you do, that link remains a working credential in a stranger's inbox.

Both are available for expired invitations as well as pending ones, which is usually the case you want: reviving a lapsed invitation is a single click rather than typing the address in again.

Assigning a role and an organisation type

Each user carries two classifications that you set:

• Organisation Type — Council, Consultant, Contractor or Other. This describes who they work for and gives their contributions context on the timeline.
• Role — Super Admin, Admin, Editor, Commenter or View only. This is what actually determines what they can do.

Both can be changed later. When someone's involvement in the programme changes, change their role rather than leaving broad access in place because it is convenient — and remove access when people leave.

Be deliberate about who gets Editor. Editors can change stored facts about an issue: its address, its type, its recorded date, its status. Anyone whose job is to comment on or review issues rather than to record them is better served by Commenter, which lets them contribute to the timeline without altering the record.

Who has to use two-factor authentication

Admins and Super Admins must. They will be asked to enrol the first time they sign in and cannot use the register until they have. That is because those roles can invite people, change anyone's role, clear anyone's second factor and read the access log — a stolen Admin password costs far more than a stolen Editor one.

Everyone else may, and is encouraged to. They will find it on their account page, with a reminder there until they turn it on. Promoting someone to Admin takes effect immediately: the next page they load asks them to enrol.

If someone loses their phone and their recovery codes, an Admin can clear their second factor from the Users screen, which sends them back through enrolment at their next sign-in. Nobody can clear their own — including you, which is why a programme should have more than one Admin.

What Super Admins can see

Super Admins are the only role with visibility across the whole deployment: all organisations, all projects and all issue data. Every other role, Admin included, works within its own scope.

That breadth is what makes Super Admin the account to hand out most sparingly, and the one to keep an eye on. It is intended for the small number of people responsible for running the portal.

Good administrative practice

• Grant the narrowest role that lets someone do their work; widen it if they hit a limit.
• Review the user list periodically against who is actually still on the programme.
• Remember that all changes are captured in the append-only audit trail, including changes made by administrators. That is a feature, not a risk: it means questions about who altered something have an answer.
• If you are unsure whether someone should have access at all, they probably should not yet. An invite is easy to send later.