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 invite to the address the person actually uses. Invites 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.

Invites expire after 12 hours

An invite link stops working 12 hours after it is sent. This is short on purpose: an invite link is a credential, and a credential sitting in an inbox for a week is a liability.

The practical consequence is to send invites when the person is likely to act on them. An invite sent late on a Friday will almost certainly need reissuing. If someone tells you their link no longer works, simply send a new one — expiry is the normal outcome, not a fault.

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.

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.