[Feature] Per-issue and per-attachment visibility restricted to selected members

[MariposaJon]

Summary

Allow an issue (and by extension its attachments) to be scoped to a subset of workspace members, rather than every issue being visible workspace-wide by default.

Motivation

Teams uploading sensitive source material to issues — e.g. full call transcripts for an agent to analyze — currently have no way to keep that material from other human teammates in the same workspace. issue subscriber only controls notifications, not visibility; there'''s no member/access-list flag on issue create/update or project create/update; attachments inherit the issue'''s (workspace-wide) visibility. Related: #2697 asks for the same thing at project level.

Proposed scope

1. Optional member allow-list on issue create/update (--visible-to), defaulting to today'''s workspace-wide behavior.
2. Attachments inherit the parent issue's visibility list.
3. Same allow-list concept at the project level, closing 希望 更丰富一点的权限管理 #2697 too.

Who this helps

Teams handling sensitive source data (call transcripts, contracts, HR material) that shouldn'''t be workspace-wide by default.

[Souredfish]

Broader proposal: visibility and ACL rules for workspace objects

This comment expands the existing proposal to cover a coherent policy for tasks, projects, and squads. The related PR #9133 was closed by the project account for product reasons, with the response asking that visibility/ACL, inheritance, transfer, and migration rules be discussed before implementation (maintainer response). This proposal is for product discussion only; it does not assume that PR #9133's implementation should be adopted.

Options

• Keep workspace-wide visibility: simplest and preserves current collaboration behavior, but does not address sensitive work within a shared workspace.
• Infer access from roles and relationships such as assignee, creator, project lead, subscriber, or squad membership: avoids maintaining explicit ACLs, but transfers and membership changes can silently change historical access and make the rules hard to explain.
• Explicit object visibility and grants: mark an object workspace-wide or restricted, then grant access directly to members or defined groups. This is more predictable and auditable, but requires consistent enforcement across APIs, search, related content, notifications, live events, and agent context.

Suggested direction for evaluation: preserve workspace-wide as the default, and consider opt-in restricted visibility with explicit grants. Evaluate tasks and projects first; decide separately whether a squad itself needs restricted visibility. Treat agent execution access, object visibility, and edit/manage permission as separate controls. Do not infer a grant merely from being assignee, creator, subscriber, project lead, squad member, or having Agent Access.

Decisions needed

1. Which objects need restriction in the first phase: tasks, projects, squads, and/or attachments? Should attachments always inherit their parent object's visibility?
2. Which principals can receive grants: individual members, squads, agents, or combinations? If a squad is granted access, does membership apply dynamically, and what happens on join/leave?
3. How should project/task visibility interact? Should a task be allowed to be narrower than its project? What should happen when moving a task into or out of a restricted project?
4. Do creator, assignee, project lead, or subscribers receive access automatically, or only through an explicit grant? What recovery access do workspace owners/admins have, and must it be audited?
5. What should happen on reassignment, squad changes, archive/restore, and deletion? Should legacy objects remain workspace-wide unless explicitly restricted?
6. Must the same visible set govern list/detail/search/counts, comments, attachments, activity, exports, notifications, WebSocket events, CLI/API access, and agent execution context? What are the 403/404 and batch-operation semantics?
7. What migration, staged rollout, rollback, and admin recovery process is required before enabling restrictions?

A restricted-visibility design is only safe if all read and write paths enforce the same policy; client-side hiding alone is insufficient. Please first confirm the concrete privacy scenarios and whether workspace separation is adequate, then decide the object scope and rules before implementation is proposed.