Permissions and Public Sharing

Pomavo now gives you explicit control over who can do what, where they can do it, and how public access is handled. Permissions and Public Sharing replaces broad assumptions with fine-grained grants that apply consistently across the UI, API, search, automation, and AI entry points.

Subject, action, resource is the core model

Pomavo permissions are expressed as Subject-Action-Resource tuples. The subject is the identity receiving access, the action is the capability being allowed, and the resource is the scope where that capability applies.

This model is simple enough to inspect but precise enough for multi-tenant work. A user can view one project without viewing every project. An integration can download attachments only where it has access. Anonymous visitors can receive read-only access to a public project without becoming organization members.

This is the same permission language described in Permissions and reinforced by the Security Model.

URN scopes make grants precise

Resource scopes use URNs so grants can target an organization, all resources of a type, or one specific resource. Wildcards make broad access possible when it is intentional, while specific IDs keep everyday grants narrow.

Wildcard scope is powerful. Use it for administrators, broad automation, or shared read access only when the subject truly needs every resource of that type.

Specific scopes are better for project contributors, one-off integrations, public issue trackers, and guests who need access to one area but not the whole workspace.

55 permissions across 16 categories

This release documents and manages 55 permissions across 16 categories. The categories map to the product areas your team already uses, including organizations, projects, templates, workflows, integrations, agents, tickets, attachments, links, comments, users, automations, plugins, shared fields, and locks.

The catalog matters because every product area can be granted independently. A user who manages templates does not automatically receive attachment deletion. An integration that comments on bugs does not automatically create projects.

Permission-gated UI actions reduce dead ends

The UI now uses permissions to decide which actions and sections you can see or use. If you do not have the required permission, Pomavo can hide or disable the action instead of letting you click into an operation that the API will reject.

This improves both clarity and security. Users spend less time discovering forbidden operations through errors, while the API remains the final authority for every sensitive action.

Permission-gated UI is a guide, not the only protection. Direct API calls, MCP tools, query mutations, and automation all still pass through the same permission checks.

The quick grant dialog speeds project setup

The quick grant dialog helps administrators grant project permissions without building every tuple manually. It is designed for common project access tasks where you need to give a user the right set of project-scoped abilities quickly.

This is especially useful when onboarding a teammate to one project, giving a guest read access, or granting an integration the exact permissions it needs for a project-level workflow.

Quick grants still produce normal permission grants. You can inspect and revoke them from the Permissions page.

Permissions page overhaul improves visibility and validation

The Permissions page in Organization Settings now serves as the central management surface for grants. Administrators can view grants, add permissions to specific subjects, revoke existing grants, inspect effective permissions, and configure anonymous access.

Scope validation helps keep grants well-formed. When a permission expects a project or template scope, the page can validate that the URN matches the action instead of saving an ambiguous grant.

This is the admin workflow counterpart to the SAR model. You do not need to memorize every tuple to manage access safely, but the tuple remains visible enough to audit.

Anonymous and guest access use the same permission system

Public sharing is built on the same permission model as member access. Pomavo can grant read permissions to a special anonymous identity, sometimes called a sentinel user, so unauthenticated visitors can view approved resources without receiving a real account.

Guest access also fits into the same model. A guest can be represented as an authenticated subject with limited grants, while anonymous access represents unauthenticated visitors.

Because anonymous access is a permission grant, it can be scoped. You can make one project public without making every project public.

Middleware distinguishes 401 from 403

Public and guest access depend on clear authentication behavior. Pomavo middleware now distinguishes between unauthenticated requests and authenticated requests that lack permission.

A 401 response means the caller is not authenticated and authentication is required. A 403 response means the caller is known, or treated as the anonymous subject, but does not have permission for the requested action.

This distinction prevents public links from behaving like broken sessions and prevents authenticated users from being sent through unnecessary sign-in loops when the real problem is missing permission.

Search, automation, API, and MCP all respect grants

Pomavo's security model is uniform. UI actions, API requests, query mutations, automations, and MCP tools all run through permission checks instead of relying on separate back doors.

That is especially important for the Query Language, because queries can find many tickets and mutations can affect many tickets. Permissions decide what the caller may read or change.

1
2
3

template = "Bug" and status not in ("Done", "Closed")
order by updated_at desc
limit 50

A user or integration running this query still needs permission to view the matching tickets. If the query later becomes a mutation, the caller also needs the relevant edit, transition, link, comment, or attachment permission.

Multi-tenant isolation remains the boundary

Every permission check happens inside an organization context. Pomavo establishes tenant context at the edge of the request and threads it through the API, search index, worker jobs, and automation engine.

This means a grant is not just about action and resource. It is also bound to the organization where it was issued. A user, guest, anonymous visitor, or integration cannot use a grant from one tenant to read or write another tenant's data.