Sidai team: how it manages users

We really mean `user accounts', not `users'.

Our initial goal is to be able to reconstruct a password file, and to specify aliases and mailing lists that a user should be on.

A user's status field

• pending: User account is not yet fully active, but will be soon.

• active: User account is `live' and in a state in which the ARK machinery can be used to invoke methods on it.

• deprecated: User account was once active, and is still valid, but it's on its way out. (It's a zombie.)

• external: User account is not in the ARK system at all (no methods to run). We keep a little information about it in ARK land, and can access that if we try hard.

• historical: User account is not in use at all. We may be retaining its records for historical purposes.

• non-existent: User account does not, cannot, and should not exist on the system; used as a default in (effectively) `case' statements...

A user's acct-type field

• person: Associated with a living human being.

• application: Associated with an add-on application, e.g. Web service, backups manager, etc.

• system: Associated with the system as supplied by the vendor.

A user's email-type field

• null: E-mail to <name>@local.domain will be silently dropped on the floor.

• local: E-mail to <name>@local.domain will get to them.

• local-stopped: E-mail to <name>@local.domain will get some reply (e.g. .vacation.msg) and will not be forwarded.

• local-dropped: E-mail to <name>@local.domain will go to /dev/null.

• global: E-mail to <name>@local.domain will be forwarded to their <global-email-address>.

• global-notified: E-mail to <name>@local.domain will be forwarded to their <global-email-address>, and a notice will be sent back of the correct address to use.