Permissions
What each permission level allows, what only the web app can do, what an agent can never do, and how your tokens inherit your rights.
Every project has four permission levels — Viewer, Member, Admin, Owner — and one rule book, checked in one place and the same way whether the actor is a person in the app, a token over the API, an assistant over MCP, or a project agent on a runner. This page is that rule book in reading order. How people get a level is on Invite your team.
What each level allows
| Action | Viewer | Member | Admin | Owner |
|---|---|---|---|---|
| Read the project’s content — tasks, documents, test cases, comments, sprints, releases; watch; comment; personal saved filters and pins; read the Audit page and export it | ✓ | ✓ | ✓ | ✓ |
| Create and edit tasks, documents and test cases; move statuses; upload files | ✓ | ✓ | ✓ | |
| Sprints and releases; record test runs; start and complete review passes | ✓ | ✓ | ✓ | |
| Approve or reject drafts; revert content; @mention an agent so that it starts a job | ✓ | ✓ | ✓ | |
| Edit the Guidance page, a Role’s instructions and skills; publish the project’s pack; shared saved filters | ✓ | ✓ | ||
| Configure the project: workflow, types, fields, components, Git, embedding, agents, pools, packs, work Roles | ✓ | ✓ | ||
| Add members, change their permission, invite by e-mail, remove | ✓ | ✓ | ||
| Delete tasks, documents and test cases to the Trash; open the Trash; restore | ✓ | ✓ | ||
| Archive and unarchive the project; offer ownership; delete the project; export the project | ✓ |
Two acts belong to the person rather than the level: anyone but the Owner can Leave project, and anyone can decline an ownership offer made to them — and accept it once their account passes the acceptance checks (a verified address, room under their active-project and storage limits).
A Viewer who @mentions an agent is heard as text: the comment lands, no job starts.
Only in the web app
Some acts are refused to every token, assistant and agent, however high the level behind them: deleting tasks, documents, test cases and comments, opening the Trash and restoring from it, deleting the project, removing a member, leaving, offering ownership and accepting or declining it, accepting an invitation, and exporting the project or its audit log. They are done by a person, signed in, in the app. Removing a piece of configuration — a status, a field, a component, an agent, a connection — is a configuration act instead, open to an Admin’s unscoped token. Deleting content is never an agent’s act, on any channel.
Project agents
A project agent — one that runs on a runner — acts at Member and never more, with five things removed for good: it never approves or rejects a draft, never reverts, never deletes, never touches configuration, and it does not start other agents. Its edits to existing content always wait as drafts. An Admin can narrow an agent further on Settings → Agents with Edit scope… — presets Triage, Tester, Reviewer and Editor — and every runner token the agent holds inherits that scope.
Your tokens and connected apps
A personal access token or a connected app acts as you: your level in each project, read live at every call, so a change to your permission reaches it the moment it is made. It can be narrowed and never widened — a Read-only token changes nothing; a scoped token holds the capabilities you picked, intersected with your level; a connected app holds Read only or Read and write, and Read and write never includes settings or deletion. See Your account.
The Owner
A project has exactly one Owner — the person who created it until ownership moves. The Owner cannot leave and cannot be removed or demoted. Ownership moves by offer: the Owner chooses Transfer ownership… on a member’s row under Settings → Members, confirms with their password or an emailed code, and the member accepts under their own account. On acceptance the previous Owner becomes an Admin, and the project’s plan and billing follow the new Owner. When an Owner’s account is locked or closed, the project is offered to its members in turn, or handed over by the operator, the same way.
Admin for guidance
Approving a draft to the project’s Guidance page, a work Role’s instructions or a skill — or reverting one — takes an Admin, not a Member: those pages steer the agents that read them, so they are configuration in substance.
When the project’s state overrides the level
- Archived — read-only for everyone, agents and assistants included. Still open: unarchiving, deleting the project, leaving, ownership offers and the export.
- Suspended by the operator — read-only; leaving, the ownership acts and the Owner’s export remain.
- Limited — while the Owner’s account is locked or closing: no new members and no new agent jobs (jobs already queued or running carry on); everything else works.
The operator
The people who run app.rindo.io hold an instance-level flag. It never shows them a project’s content — that is visible to its members only. It does let them suspend, take down or restore a project, set its storage limit, see its member list, and offer it to a member when it has no active Owner.
There are no custom permission levels. The Roles under Settings are work Roles — who does what, and how — and grant nothing; this page is what decides who may.