Inviting your team

Nobody is put into a workspace without being asked.

Accounts are by invitation

Nobody can sign themselves up. /register says so rather than offering a form, and the landing page stops advertising it — see Configuration for the switch that opens it if you are running Félagi as a service rather than for one company.

Sending an invitation

Admin → Members → Invite person. An email address and a role, and that is the whole form.

The recipient gets an email naming who invited them, to what, and as what. Nothing happens to any account until they accept it themselves.

Why not simply create the account? Because creating one means choosing somebody's first password, which means knowing it. An invitation costs one extra click and removes that entirely.

The roles

Developer is the one worth explaining. Running the agent workforce and deciding who works here are different kinds of trust. A contractor can be given the machines without also being given the member list — and a team with no way to separate the two ends up giving everyone everything.

Management is not the bottom of that list. The other four are ordered — each does everything the one above it does, plus more — and Management is beside them rather than below. It gets the Timeline and the reports, no board, no inbox, no agents, and it is never offered as somebody to hand work to.

That last part is the point of it. A director in an assignee list ends up in the workload report as somebody carrying three issues they cannot open, and the report is then wrong for everybody who reads it. Invite a director as Management; invite somebody who will actually pick up an issue as a Member, whatever their title is.

The role is shown with its description in the invitation email, so the recipient knows what they are agreeing to before they click.

What the recipient sees

One page, whether or not they already have an account:

• No account yet — they choose a name and password and land in the workspace signed in. The email address is fixed by the invitation and cannot be edited.
• Account already — one click, and the workspace is added to the one they have.
• Signed in as somebody else — the page says so and offers to sign out. It will not accept on the wrong person's behalf, because a forwarded invitation must not put a stranger in your workspace.

Accepting marks the address verified. The link reached it; a second confirmation email would be ceremony.

Two-factor, if this is a production installation

A new colleague gets five days before a second factor is demanded, counted from the moment the account begins — whether they accepted an invitation or an administrator made the account for them. They can read issues, comment and find their way around first; being marched through an authenticator app in the first thirty seconds is how the secret ends up on a sticky note.

Settings tells them how many days are left, next to the button that ends the countdown. Nothing else is needed from you.

See Two-factor authentication.

While you wait

Pending invitations are listed under the member list with who sent them and when they expire.

• Resend issues a fresh link and invalidates the old one
• Revoke removes the invitation entirely

Invitations last 14 days. Re-inviting the same address replaces the open invitation rather than adding a second, so an inbox never holds two working links.

Changing your mind later

Roles are changed from the member list at any time, and take effect on the next page load.

Two rules the interface enforces:

• A workspace cannot lose its last owner, by demotion or removal
• Nobody can remove themselves, which would lock them out of their own workspace

Removing somebody deletes the membership, never the account, and never anything they wrote. Their comments and the issues they opened stay exactly where they are.

Maintaining an account

A platform administrator — is_admin, the widest privilege in the product — can give somebody a new password, or create an account outright instead of waiting for an invitation to be accepted.

Not a workspace owner. A person can be in three workspaces, and owning one of them says nothing about the right to change the password on their account. Removing somebody from this workspace is workspace-scoped and stays with the owner; a password is not.

Name and address

The pencil beside somebody's row edits their name and their email.

A name is cosmetic. An address is not — and the reason is worth being precise about: a password on an account with an authenticator confirmed gets nobody in, but changing the address moves where a password-reset link goes. That is a step towards a takeover rather than a takeover, and it gets the loudest control here.

An address another account already uses is refused: two accounts for one address is a person who cannot be told apart from themselves.

Everybody can change their own name and address at Settings, which needs no administrator at all.

What it deliberately cannot do

It never touches two-factor authentication. A new password on an account with an authenticator confirmed does not get anybody in — and that is the point. If it cleared the secret as well, one account could take over any other in two clicks and every other control in the product would be decoration.

Somebody who has lost both their password and their authenticator has a different problem, and recovery codes are the answer to it.

It also does not verify an address that was unverified, and does not make anybody an administrator. The list of columns it writes is three lines long for exactly that reason.

What happens

The password is not emailed. A working credential sitting in a mailbox is worse than one read off a screen.

An administrator cannot reset their own: the settings page does it properly, asking for the current password first, which is the check that makes a password change a password change rather than a session hijack.

Creating an account outright

Create account makes the user, adds them to the workspace at a role you pick, and gives you a one-time password to pass on. No link to accept.

The honest case for it is an internal deployment where an operator adds colleagues who never asked to be invited. It creates an account without their involvement, which is why it is the platform administrator's and nobody else's.

The address is treated as verified, on the same argument the felagi:admin command makes: there is no inbox to confirm from yet, and an administrator who typed a colleague's work address has asserted more than a click in an email would. They still set up two-factor authentication themselves. See Permissions for what is_admin reaches.

An address that already has an account is refused — two accounts for one address is a person who cannot be told apart from themselves. Reset the existing one instead.

Not there yet

• No way for an administrator to clear somebody's two-factor authentication, and that is deliberate rather than pending. It would turn a password reset into an account takeover primitive. Recovery codes exist for the person who has lost their authenticator.
• No bulk import of people. One at a time, or an invitation each.
• Nothing over the API. Account maintenance is the interface's.

Departments

Administration → Departments holds a list of names for the current workspace. Add one and it becomes available in three places: the member list, the invitation form, and an account created by hand.

The picker is searchable, because a company with forty departments has a list nobody scrolls.

Two things worth knowing:

• Engineering and engineering are the same department. A list holding both is a list nobody trusts, and people stop using the field rather than risk picking the wrong one. The first spelling wins, because somebody chose it.
• Dissolving a department removes nobody. The people in it stay in the workspace and lose their department. The confirmation says how many that is before you do it.

A department set on an invitation is applied when the invitation is accepted, not when it is sent — so it is not something to remember afterwards. If the department is dissolved while the invitation is still open, the invitation still works; the person simply joins without one.

Phone numbers

A phone number sits on the person, beside their name and address, and is edited in the same place. It follows them into every workspace they are a member of.

Nothing parses it. A number is written a dozen ways and a validator that insists on one of them is a field people leave empty.

Tip: A department is a per-workspace fact and a phone number is a personal one. That is why the department picker is a column in the member list and the phone field is in the person's own panel.

Not there yet

• No department hierarchy, and none planned.
• Reports do not group by department yet.
• A department cannot be set over the API.