mirror of
https://we.phorge.it/source/phorge.git
synced 2025-02-02 01:48:23 +01:00
69ee51dc53
Summary: Ref T8387. Just mention this stuff since it's moderately useful. Test Plan: Read. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8387 Differential Revision: https://secure.phabricator.com/D13139
107 lines
4.1 KiB
Text
107 lines
4.1 KiB
Text
@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 Phabricator, 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 addresss 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 Users
|
|
==============
|
|
|
|
**Disabled Users** 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 users:
|
|
|
|
- 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).
|
|
|
|
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.
|