feat(tracker): issue access management — grants panel, access groups, level-aware enforcement (stacked on #10895)

[MichaelUray]

Issue Access Management

Fine-grained, fail-closed access management for Tracker issues on top of the
mention-grants mechanism from #10895: explicit per-issue grants with access
levels, reusable access groups, and a full management UI.

Stacked on #10895 — the leading commits in this PR belong to #10895
(mention grants) and are reviewed there. Please review only the commits
after 93c13b4873 (the current head of feat/huly-mention-grants). I
will rebase this PR the moment #10895 lands, which shrinks the diff to the
feature commits automatically.

What it does

• P1 — Collaborator provenance + guard: Collaborator records gain
  provenance (who granted, and why) and an access-level field; a new
  fail-closed CollaboratorGuardMiddleware (registered after
  GuestPermissions) vetoes every access-granting Collaborator write the
  actor is not entitled to make. Includes an ordinal access-level helper as
  the evolution seam towards role mapping.
• P2 — Level-aware enforcement: per-document collaborator visibility for
  all non-admin roles, and level-aware field-write enforcement
  (read < write < admin) in the security middleware.
• P3 — Issue Access panel: a panel on the issue showing every grant with
  provenance and level, with grant/revoke management and a confirm dialog
  (fully i18n-ized).
• P4 — Access groups: AccessGroup + GroupGrant classes with guarded
  writes, server-side grant materialization with reconcile triggers, and a
  management UI under Settings. Deleting a group tears down its materialized
  group collaborators.
• P5 — Mention grants as Grant v2: mention-based grants become a special
  case of the same grant pipeline, with a fail-closed mention-consent UI and
  a pure reconcile helper covered by unit tests.

Security model

• Fail-closed everywhere: unknown class, missing space, or missing grant
  always denies; the guard vetoes rather than filters.
• Access levels: read / write / admin with ordinal comparison —
  field writes require write, grant management requires admin.
• Provenance: every Collaborator row records how it came to exist
  (direct grant, group materialization, mention), so grants stay auditable
  and reconcilable.
• Review remediation is included: C-01 (cross-space privilege escalation in
  the collaborator guard), M-01 (collab-read widening scoped to grant classes
  only), M-02 (group-collaborator teardown on AccessGroup delete), H-02
  (jest wiring so the client test runs in CI), L-02 (grant hint externalized
  to IntlString, EN + DE).

Known follow-ups (deliberately out of scope)

• Performance: a composite index on (workspaceId, collaborator, attachedTo)
  for the collaborator lookup path — planned as a separate migration PR.
• M-03 residual risk (documented during review): one server-trigger edge path
  attributes grants to the system actor instead of the originating user;
  tracked for a follow-up hardening pass.
• Live end-to-end runs for the panel flows (P3.4/P4.4, Playwright) are still
  pending on an isolated staging stack; unit and integration coverage of the
  security paths is complete (RED→GREEN).

All feature commits are signed off (DCO). Fork-internal full CI (build,
svelte-check, unit tests, UI tests) is green for this exact head.

[huly-github-staging]

Connected to Huly®: UBERF-16641

[ArtyomSavchenko]

Hi @MichaelUray
I think we don't need a separate access management mechanism for issues only. My worry is that we'll then resolve the same problem for every other entity and end up with several inconsistent permission mechanisms. I'd rather build one unified permission system and make issues its first consumer.

Roughly:

1. Permissions are assigned to user groups, not individual users. Effective permissions are the union of a user's groups.
2. Permission sets declare application-level access — which apps a group can reach and which it can't. Cheap first gate, and one obvious place to answer "what can this team see?"
3. Access is also scoped to spaces within an application. A group shouldn't just have "access to the issue tracker" — it should have access to a specific set of spaces inside it. So a grant is really a triple: group → application → spaces, plus the permissions within them.
4. Each application declares its permission model in its data model — which objects it exposes and what permission groups exist for them (e.g. issue: read, comment, transition, delete). The core system knows nothing about issues specifically; it just reads the declaration. That's what makes it extensible.
5. Admin flow becomes: pick a group → pick an application → pick spaces → check off the permissions that app declared. No custom code per app.

[MichaelUray]

Thanks @ArtyomSavchenko — I agree with the direction. One correction to my own earlier framing first: I no longer think this should land as an issue-specific permission mechanism. Issues should be the first consumer of a generic object-permission layer, and I'd rather build toward that than ship an issue-only feature.

What helped me get there is how much of it already exists upstream. Permission already carries txMatch, objectClass, scope and forbid; Role.permissions bundles them; and SpaceTypeDescriptor.availablePermissions + ModulePermissionGroup already let an app declare its own permission model — which is exactly your point 4. On the data side, Collaborator is already shaped like a relationship tuple (object, subject), and addSecurity() already has a Collaborator branch that grants per-document visibility — today gated to guests and to classes with provideSecurity. So I read your proposal less as "build a new system" and more as "consolidate and generalize what's already implicit in the code."

The one hard constraint that shapes everything: read security is compiled into SQL. addSecurity() appends the visibility predicate before ORDER BY/LIMIT (and to the COUNT), so pagination and totals run over the filtered set. Any model has to keep the visible set expressible as a SQL predicate. The invariant I'd propose: read is a SQL-compilable existence check; all per-action granularity lives on the write path. A grant's existence makes the object visible; whether the subject may edit vs comment vs transition would be decided per-transaction in the guard — Permission.txMatch plus a small anchor resolver, so a comment on an issue authorizes against the parent issue's grant.

Two concrete requirements from my use case: access to a single issue and nothing else in the project (my branch extends the existing addSecurity() Collaborator branch to issues and to all roles, which I think proves the read-side shape works); and different actions per user on the same issue — some may edit, others only comment. The ordinal level I used in my draft can't express that; declared per-action permissions can, which is another argument for your model.

On the grant shape, I'd evolve Collaborator with role?: Ref<ObjectRole> (a named, app-declared permission set) rather than introduce a parallel grant document up front — every hot path already keys on Collaborator. A canonical grant doc can come later if audit/expiry needs outgrow it. And I'd keep authorization in-process rather than introduce an external authz runtime, precisely because of the in-SQL read path — an external checker can't inject that predicate.

One lesson from validating my branch: I found and fixed locally two write-path inconsistencies in my own draft implementation, both caused by authorization logic being spread across middlewares with role-specific early exits. That reinforced your consolidation point — this belongs in one engine.

For sequencing I'd suggest starting small: a PR that only declares the model primitives (Permission.scope: 'object', ObjectRole, Collaborator.role, Tracker's issue permissions) with no behavior change, then wire enforcement behind the existing middlewares incrementally. Would you review a "model primitives" PR as the starting point — and does an object-level exception layer fit how you're picturing the space-scoped model?