Elixion

Permissions

How access control actually works in Elixion today

Permissions

Elixion's access model has two levels: Space and Project. There is no Organization level and no visibility settings (no "Public / Private / Restricted" project modes, no "Open / Closed / Secret" space modes). Access to a project or space is determined entirely by whether you've been added as a member, and at what role.

Not yet shipped: a real organization/tenant boundary is tracked as ELI-1284 and has not shipped. Today, every Space and Project on an Elixion instance is reachable by any authenticated user who is added as a member — there is no company/tenant wall preventing, say, Client A's admin from being added (deliberately or by mistake) to a Space that belongs to Client B. Do not describe Elixion as multi-tenant in its current state.

Hierarchy

Space
└── Project
    └── Issue

Issues do not have their own visibility rules independent of their project — if you can see the project, you can see its issues.

Space Roles

Space membership (SpaceMember.role) uses a fixed hierarchy:

| Role | Access | |------|--------| | OWNER | Full control of the space | | ADMIN | Manage space settings and membership | | MEMBER | Standard space access | | VIEWER | Read-only space access |

Superusers (platform admins) bypass this check entirely and are treated as OWNER on every space.

Project Roles

Project membership (ProjectMember.role) is a free-form role label used for both job function (DEVELOPER, QA_ENGINEER, DESIGNER, PROJECT_MANAGER, etc.) and coarse access tier (OWNER, ADMIN, VIEWER). A project's owner (Project.owner_id) always has full access regardless of their ProjectMember role.

Project-level permission checks (who can view/edit issues, manage sprints, etc.) are evaluated against ProjectMember rows and Project.owner_id directly. They do not consult Space membership or Space role — being an OWNER of a Space does not, by itself, grant access to every project inside that space; conversely, being a project member does not require also being a space member (the two are kept in sync on a best-effort basis when someone is added to a project, but they are separate checks).

What does not exist

The following are not implemented, regardless of what older mockups or marketing copy may say:

  • Organization-level roles or an "Org Admin"
  • Space or Project visibility settings (Public/Private/Restricted, Open/Closed/Secret)
  • Custom roles or a role builder
  • Groups, or group-based permission assignment
  • Field-level permissions (e.g. restricting a specific custom field to a subset of members)
  • A permission audit log UI

If you need one of these for a specific rollout, file it against ELI-1284 rather than assuming it already exists.

Next: Settings - Platform configuration