People, groups, guests and product access
Site administrators manage who is on the site and what they can open.
The people directory
Section titled “The people directory”The directory lists people with search and status. Everyone finds active people. Site administrators additionally see deactivated accounts, groups, and what each person may open. A list can be filtered by status (active, deactivated or all), by group, and by product.
Pickers in the product, for example for assignees, show the project’s members first and mark who can be assigned. They search the directory as you type instead of loading everyone.
Deactivate and reactivate
Section titled “Deactivate and reactivate”A site administrator deactivates a person, and a deactivated person can be reactivated. A deactivated person cannot sign in. Their authorship stays on work items, comments and history, and team references survive. Sessions of a deactivated account are refused.
Groups
Section titled “Groups”Groups collect people so that a role or an approval can be given once. A group can have a role in a project (administrator, member or viewer). A person’s effective role in a project is the strongest of their own role and the roles of their active groups. Removing a member removes their own role only. Retired groups can no longer be given roles.
Guests
Section titled “Guests”Guests see only the projects they are invited to, and only the people in those projects. They cannot create site-wide objects, such as projects, plans, teams or templates. A direct link to an object cannot take a guest outside their scope.
Teams have members and owners and are used for plans and capacity. A team survives the deactivation of a member.
Product access: Code / CI, Observability, Knowledge and Lumen
Section titled “Product access: Code / CI, Observability, Knowledge and Lumen”A site administrator chooses, per person, which of the other products they may open: Forge (Code / CI), Pulse (Observability), Folio (Knowledge) and Lumen. A person without a product is refused at the web proxy with a product_access_required error, even when they have a project role. Site administrators always have every product. A person with no explicit choice has every product.
The permission scheme and the permission helper
Section titled “The permission scheme and the permission helper”- Permission scheme. One scheme applies to every project. Everyone signed in can read it: site roles, project roles, the permissions and which roles hold them, work item security levels and project lifecycle states.
- Permission helper. Project and site administrators pick a person, and optionally a work item, and see each permission allowed or refused, with the reason. It also shows the person’s effective role and where it comes from (their own role or a group) and which products they may open. It is computed by the same rules the API enforces. The permissions it covers are browse, view work item, create work items, edit work items, manage sprints, administer project, work item security, delete project and project lifecycle.