Subsystem Search

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 keanu --name "Keanu Reeves"

subroutine user create keanu --terminal

subroutine user create keanu --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 keanu --role member

subroutine user add keanu --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 keanu admin

subroutine user role keanu 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 keanu

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. A workspace with nobody left to administer it is named before and after, with the command that makes somebody its administrator again.

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 keanu

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. An agent that has said none reads days in its account parent's zone, so whoever made one has nothing to set for it.

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 hand an agent over. It can go to a person, or to an agent whose own chain ends at one.

Arguments

Options

subroutine user remove

subroutine user remove [OPTIONS] {username}

Take somebody out of a workspace.

Examples:

subroutine user remove keanu

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