Subsystem

subroutine user

The 9 commands under subroutine user, each with its arguments and options.

subroutine user [OPTIONS] COMMAND [ARGS]...

Add the people and agents this instance is for.

subroutine user create

subroutine user create [OPTIONS] {username}

Add somebody to this instance, and hand them the way in.

Examples:

subroutine user create thomas --name "Thomas Anderson"

subroutine user create thomas --terminal

subroutine user create thomas --browser --terminal --workspace acme

subroutine user create sam --superuser

One command rather than five. It makes the account, puts them in a workspace with a role, and — if you say how they will reach this instance — produces the sign-in link or the credential in the same breath. An account with no membership authenticates and can see nothing, which reads as a broken token rather than as a missing role.

'--role' is 'member' unless you say otherwise: enough to do the work, not to administer the place. '--workspace' can be left out when there is only one, and is asked for when there are several.

'--browser' and '--terminal' are not alternatives. Somebody who uses the web interface and has a colleague setting their machine up needs both, so both may be given. Naming neither is fine too — the account is real, and the two commands that hand it over are printed.

'--superuser' is what lets somebody create accounts and workspaces, and it is the only way to grant that — no role carries it. It joins no workspace: an instance owner needs no workspace role, and granting one quietly would be a permission taken by default.

There is no password. Subroutine authenticates with tokens, so what a new person needs next is one of those, or a link.

Arguments

Options

subroutine user list

subroutine user list [OPTIONS]

Show who is on this instance.

Examples:

subroutine user list

subroutine user list --workspace acme

Without --workspace this is every account, oldest first — the first one is whoever ran 'subroutine init'. With it, only that workspace's members, and what each may do there.

Options

subroutine user add

subroutine user add [OPTIONS] {username}

Let somebody work in a workspace.

Examples:

subroutine user add thomas --role member

subroutine user add thomas --role admin --workspace acme

The role is named rather than assumed. What somebody may do is the decision being taken here, and a default would be this command taking it quietly on your behalf.

Arguments

Options

subroutine user role

subroutine user role [OPTIONS] {username} {role}

Change what somebody who is already there may do.

Examples:

subroutine user role thomas admin

subroutine user role thomas viewer --workspace acme

The role is positional rather than an option, unlike 'user add': there it is one decision among several, and here it is the whole of what this command is for.

Somebody who is not there yet is turned down by name — 'user add' is what puts them in a workspace, and this is what moves them once they are.

Arguments

Options

subroutine user deactivate

subroutine user deactivate [OPTIONS] {username}

Mark somebody as having left, stopping the agents that answer to them.

Examples:

subroutine user deactivate thomas

Their account stays and so does everything they wrote, still attributed to them. What stops is their credentials and every agent answerable to them — because somebody gave those agents permission to work, and that permission was this person's to give.

The last person who can administer this instance cannot leave: an instance nobody can administer cannot be repaired from inside, and it would stop every agent at once.

Arguments

Options

subroutine user reactivate

subroutine user reactivate [OPTIONS] {username}

Bring somebody back, and with them the agents that answer to them.

Examples:

subroutine user reactivate thomas

The same operation as 'deactivate' in reverse, deliberately: two commands with their own rules would be two places for those rules to disagree.

Arguments

subroutine user timezone

subroutine user timezone [OPTIONS] [zone]

Say which timezone you are in, so your days are counted where you are.

Examples:

subroutine user timezone Europe/London

subroutine user timezone

Your own account and nobody else's — you know which zone you are in better than anybody else does, so there is no permission that lets somebody set it for you.

It decides which day a deadline counts as on every surface. It does not change how a date is written down: a day belongs to the item that has it, so 'due Fri 14 Aug' says Friday wherever it is read.

Arguments

Options

subroutine user transfer

subroutine user transfer [OPTIONS] {username}

Hand an agent to somebody else, who becomes answerable for what it does.

Examples:

subroutine user transfer deploy-bot --to jo

Agents stop when the person answerable for them leaves, so this is how one is kept when somebody goes. Only a person can take an agent on — being accountable is something somebody agrees to, and an agent cannot agree on anybody's behalf.

Arguments

Options

subroutine user remove

subroutine user remove [OPTIONS] {username}

Take somebody out of a workspace.

Examples:

subroutine user remove thomas

This removes their membership, not their account: what they wrote stays, and stays attributed to them. The last person able to administer a workspace cannot be removed from it, because a workspace nobody can administer cannot be repaired from inside.

Arguments

Options