phorge / src / docs / user / userguide / users.diviner

@title User Guide: Account Roles
@group userguide

Describes account roles like "Administrator", "Disabled", "Bot" and "Mailing
List".


Overview
========

When you create a user account, you can set roles like "Administrator",
"Disabled", "Bot" and "Mailing List". This document explains what these roles
mean.


Administrators
==============

**Administrators** are normal users with a few extra capabilities. Their
primary role is to keep things running smoothly, and they are not all-powerful.
In Phorge, administrators are more like //janitors//.

Administrators can create, delete, enable, disable, and approve user accounts.
Various applications have a few other capabilities which are reserved for
administrators by default, but these can be changed to provide access to more
or fewer users.

Administrators are **not** in complete control of the system. Administrators
**can not** login as other users or act on behalf of other users. They can not
destroy data or make changes without leaving an audit trail. Administrators also
can not bypass object privacy policies.

Limiting the power of administrators means that administrators can't abuse
their power (they have very little power to abuse), a malicious administrator
can't do much damage, and an attacker who compromises an administrator account
is limited in what they can accomplish.


Bot Accounts
============

**Bot** ("Robot") accounts are accounts for bots and scripts which need to
interface with the system, but are not regular users. Generally, when you write
scripts that use the Conduit API, you should create a bot account for them.

The **Bot** role for an account can not be changed after the account is
created. This prevents administrators form changing a normal user into a bot,
retrieving their Conduit certificate, and then changing them back (which
would allow administrators to gain other users' credentials).

**Bot** accounts differ from normal accounts in that:

  - they can not log in to the web UI;
  - administrators can access them, edit settings, and retrieve credentials;
  - they do not receive email;
  - they appear with lower precedence in the UI when selecting users, with
    a "Bot" note (because it usually does not make sense to, for example,
    assign a task to a bot).


Mailing Lists
=============

**Mailing List** accounts let you represent an existing external mailing list
(like a Google Group or a Mailman list) as a user. You can subscribe this user
to objects (like tasks) to send them mail.

Because these accounts are also user accounts, they can be added to projects
and affected by policies. The list won't receive mail about anything the
underlying user account can't see.

The **Mailing List** role for an account can not be changed after the account
is created.

Some options can be configured for mailing lists by browsing to the list user's
profile and clicking {nav Edit Settings}. You can change the address for a
list by editing "Email Addresses" here, choose the language and format for
email the list receives, and customize which actions the list is notified about.

**Mailing List** accounts differ from normal accounts in that they:

  - can not log in;
  - can not access the Conduit API;
  - administrators can access them and edit settings; and
  - they appear with lower precedence in the UI when selecting users, with
    a "Mailing List" note.


Disabled User Accounts
======================

**Disabled Accounts** are accounts that are no longer active. Generally, when
someone leaves a project (e.g., leaves your company, or their internship or
contract ends) you should disable their account to terminate their access to
the system. Disabled user accounts:

  - can not login;
  - can not access the Conduit API;
  - do not receive email; and
  - appear with lower precedence in the UI when selecting users, with a
    "Disabled" note (because it usually does not make sense to, for example,
    assign a task to a disabled user account).

While users can also be deleted, it is strongly recommended that you disable
them instead, particularly if they interacted with any objects in the system.
If you delete a user entirely, you won't be able to find things they used to
own or restore their data later if they rejoin the project.