Permissions

Access in Elixion, the platform for Engineering Intelligence™, is decided in layers. This page describes each one and the exact tiers a project role maps onto.

Hierarchy

Organization
└── Workspace
    └── Project
        └── Issue

An issue has no visibility of its own. If you can see the project, you can see its issues.

A workspace belongs to exactly one organization, and it cannot exist without one.

Project-level access control is in place today. Organisation-level tenancy is on the roadmap.

Organization

An organization is created for you the first time you create a workspace; it is not something you make by hand. Its roster has two roles, Owner and Member, managed in Settings > Organization.

Only an owner or an administrator of the organization can see the roster or change its security policy. Everyone else sees an access-denied state on that page, decided by the server rather than guessed in the browser.

An organization also carries:

• A multi-factor authentication policy, off until an administrator turns it on.
• Single sign-on configuration.
• Directory sync credentials.

See Security.

Workspace roles

Workspace membership has four ranked roles: VIEWER, MEMBER, ADMIN, OWNER. A role satisfies any check at or below its rank.

Workspace membership answers which workspaces you belong to. It is not what is checked when you open a project's issues, board or sprints. That is project membership.

Project permission tiers

A project member's role is matched against a fixed set of tiers. Every action in the product asks for one of them.

| Tier | Roles that pass | |------|-----------------| | view | Viewer, Member, Designer, QA engineer, Developer, Backend engineer, UI/UX engineer, Tester, Agent, Scrum master, Product manager, Project manager, Project owner | | member | The same, without Viewer | | create, update, edit | Developer, Backend engineer, Scrum master, Product manager, Project manager, Project owner | | delete | Scrum master, Product manager, Project manager, Project owner | | admin | Project owner |

Two consequences worth reading twice:

• A Viewer can see a project but is not a member for anything else.
• Designer, QA engineer, UI/UX engineer and Tester can view a project and count as members, but they are not in the create, update or edit tiers.

Saving Project Settings requires the admin tier.

The project owner

The project's owner passes every tier, whatever their membership row says. If an owner also holds a member row with a weaker role, ownership wins.

Public projects

A project can be marked public. Public means any member of the project's organization may view it, even without being a project member. It grants view only, it never reaches outside the organization, and it fails closed when the project's organization cannot be determined.

Platform roles

Two account-level facts sit above the project model:

• A superuser has an unconditional, platform-wide bypass.
• An account whose platform role is ADMIN has a bypass scoped to their own organizations. An administrator from another organization gets no bypass and is checked like anyone else.

The platform role is set from a person's dossier. See Team Management.

Agents

An agent joins a project with the AGENT role, which sits in the view and member tiers. An agent is never granted the admin tier, and it cannot move an issue past In review.

Not configurable today

• Custom roles or a role builder.
• Groups, or group-based permission assignment.
• Per-field permissions.
• Visibility modes beyond the single public switch on a project.

Next: Settings.