Roles and permissions
Access in Ngenaire is governed at two levels: your organization role and your project role. The two are independent — you might be an ordinary organization member but the owner of a particular project, or an organization admin who is only a viewer on a specific project.
Organization roles
| Role | Can do |
|---|---|
| Owner | Full control of the organization, including its settings and membership. |
| Admin | Manage members and invitations; administer the organization day-to-day. |
| Member | Belong to the organization and the projects they are added to. |
| Viewer | Read-only access at the organization level. |
Project roles
Your role on a project is set when you are added to it, and it determines what you can see and change there.
| Role | Can do |
|---|---|
| Owner | Everything an editor can do, plus manage project membership, change project settings, and delete the project. |
| Editor | Create, update, and delete project content — requirements, diagrams, tests, baselines, risks, schedule, and so on. By default, editors can also sign off on approvable items. |
| Approver | Review and approve approvable items. Most useful with strict approver mode (below). |
| Viewer | Read-only access to the project. Cannot create, edit, or delete. |
A project always keeps at least one owner — an owner cannot remove the last owner.
Strict approver mode
Each project has an optional setting, require explicit approvers, that owners can turn on in project settings. It introduces a separation of duties between editing content and approving it.
When strict approver mode is off (the default), editors who can change content can also approve it — the approve right is bundled into ordinary editing.
When strict approver mode is on, that bundle is broken:
- Approving becomes a distinct permission. Ordinary editors lose the implicit approve grant.
- An approver can approve but not necessarily edit, and an editor can edit but not necessarily approve.
- This lets you set up a clean review gate: drafters keep working while a designated approver signs off — for example, a customer review gate, a formal verification hand-off, or a compliance audit period.
Strict mode is a project-level policy. The exact mechanics of granting the approve permission to specific members are covered in Managing permissions.
When you don't have access
Roles are enforced everywhere, not just by hiding buttons:
- If you lack edit rights, edit and delete controls are hidden or disabled.
- If you are not a member of a project at all, attempting to reach it returns an access error (403 or 404). The same applies to objects in organizations you do not belong to.
Common scenarios
- Bring in a contractor for one project. Add them to that project only, as an editor; they see nothing outside it.
- Read-only stakeholder. Add them as a viewer so they can follow progress without changing anything.
- Hand off a project. Promote the new lead to owner, then step back to editor or viewer.
- Customer sign-off gate. Turn on require explicit approvers, then grant the customer reviewer the approve permission. Editors keep drafting; only approvers (and owners) can sign off.