Scopes
The whole organisation, a development project or a repository: where a member’s role applies and what happens where scopes overlap.
A permission is granted not “in general” but for a scope. The scope answers the question “where”: the whole organisation, one development project or one repository. The role answers the question “what”.
Three kinds of scope
| Scope | What it covers | When it fits |
|---|---|---|
| The whole organisation | All the organisation’s development projects and repositories — those that exist now and those that appear later. | Staff employees, the tech lead. |
| Development project | The project itself (its tasks, reviews, audits, conversations, research) and all its source repositories, including those added to the project later. A space is the same kind of scope: its conversations, research and entries. | A developer on one team, a contractor on one project; a product manager in their space. |
| Repository | One repository: questions about the code (“Ask”) and research on it. Tasks are run in projects, so a standalone repository gives no tasks. | An auditor or consultant who only needs the code. |
Outside their scopes a member sees nothing: no projects or repositories in the switcher, no tasks, no conversations. A direct link to someone else’s project opens “project not found”.
Several scopes
One member can have several grants — one per scope. This is how real situations are put together:
- Maintainer in the
shopproject and Contributor in the rest of the organisation; - Contributor in the
shopandbotprojects, but not ininternal; - Contributor in the whole organisation, plus the “Run audits” permission turned on individually only in the
botproject.
Two scopes of the same kind pointing at the same thing (for example, two grants on the shop project) are not allowed — the editor will not let you save them.
When scopes overlap
The narrowest scope covering the resource applies: a repository is narrower than a project, a project narrower than the organisation.
| Member’s grants | Task in the shop project | Task in the bot project |
|---|---|---|
| Contributor on the organisation | Contributor | Contributor |
Contributor on the organisation + Maintainer on shop | Maintainer | Contributor |
Maintainer on the organisation + Contributor on shop | Contributor (narrowing) | Maintainer |
A narrow scope can both widen and narrow permissions — this lets you give a person broad access and carve out one exception separately.
How scopes relate to repositories
Access to the organisation’s repositories is granted automatically from the grants: a member with a “project” scope gets access to the project and all its sources, with a “repository” scope — to that one repository, with an “organisation” scope — to all of them. When a new source repository is added to a project, members with a grant on that project get access to it on their own, without any action from the owner. There is no need to set up repository access separately.
What to do if a member sees the wrong things
- Does not see a project — check that their grants include the “whole organisation” scope or exactly this project (not just one of its repositories).
- Sees the project but cannot act — the scope is there but a permission is missing: open “Permissions” → “Advanced” and see which switch is off.
- Sees too much — they have a grant on the whole organisation; replace it with grants on the projects needed.