Roles, permissions and scopes

Mode: reference.

Tollgate access is governed at two altitudes: per-project gates (who can see and edit a single project’s governance data) and a portfolio gate (who can see the Tollgate Portfolio and use the agent across projects). Underneath both sit the Forge OAuth scopes declared in manifest.yml.

Access gates

Per-project

Role	Capability
Any user who can browse the Jira project	View the project’s Tollgate surfaces read-only.
Jira Project Lead	Edit all governance data by default.
Nominated editors	Jira users the Project Lead adds (stored in per-project app config) who also gain edit rights.
Steering-committee members	Recorded per project; count toward `canView` where a governance group restricts visibility.

Rules:

Edit is Project Lead only by default. Holding Administer Projects does not confer edit rights unless the Project Lead explicitly nominates the user.
Without edit rights the header and registers are read-only; Add / Edit / Delete / Link-issue actions are hidden or disabled. Row click still opens the read-only detail view so governance data stays visible.
The per-project group gate (enforceGroupGate) is a no-op until a governance group is set — with no group configured it does not restrict visibility.

Portfolio and agent

An app-level governance group is configurable from the Tollgate Portfolio settings. When set, it gates visibility across the Portfolio and the Rovo agent.
The portfolio/agent gate (enforceAgentAccess) defaults to admins-only when no group is configured; once a governance group is set, that group gates everything (per-project surfaces, Portfolio, and agent alike).
Every Rovo agent action runs behind this gate plus the per-project access gatekeeper (see Rovo agent actions).

Forge scopes

Declared in manifest.yml under permissions.scopes. Adding or removing a scope requires forge install --upgrade on every installed site before the change takes effect.

Jira

Scope	Why it exists
`read:jira-work`	Read project and issue data (project context, issue search for linking work packages).
`read:jira-user`	Resolve `accountId` references to display names in the UI.
`write:jira-work`	Write the “Work Package” reference back onto linked Jira issues.
`manage:jira-configuration`	Create and maintain the per-project custom “Work Package” field used for issue write-back.
`storage:app`	Read/write app data in Forge storage (KVS and the Custom Entity Store).

Confluence

Confluence scopes support the Investment Thesis “Supporting documents” picker and the “Create from template” flow. The manifest deliberately mixes classic and granular scopes (accepted by forge lint); the v1 space/content endpoints are retired on the Forge gateway, so writes use the Confluence v2 API.

Scope	Why it exists
`search:confluence`	CQL search for the supporting-documents page picker (v1 search endpoint).
`read:confluence-content.summary`	Read title/space summaries on search results.
`write:confluence-content`	Create pages via the classic content endpoint (template flow).
`read:confluence-space.summary`	Space selector and space-by-key lookup.
`read:page:confluence`	v2 page-exists check (`GET /wiki/api/v2/pages/{id}`).
`write:page:confluence`	v2 page create (`POST /wiki/api/v2/pages`).
`write:space:confluence`	v2 space create (`POST /wiki/api/v2/spaces`).
`read:space:confluence`	Resolve a space key to a numeric `spaceId` for v2 page create (`GET /wiki/api/v2/spaces?keys=`).
`write:comment:confluence`	Best-effort approval nudge — @mention an approver via a footer comment (`POST /wiki/api/v2/footer-comments`).
`write:confluence-space`	Classic space create for the one-time “clean space” setup step.
`write:confluence-props`	Apply the canonical `sapper-pmo` / `sapper-canonical` labels to pages Tollgate creates.

Content security

permissions.content.styles permits unsafe-inline for the app’s inline styles.