trackslash
TRACK-89 P2

Let private projects take issues from anyone signed in, like a help desk

0
All issues

Description

A project should be able to stay private and still accept issues from anyone with a trackslash account. It would work like a help desk. A reporter follows a link, files an issue, and afterwards sees their own issues: each one's status, the comments the project chooses to share with them, and their own replies. They never see anything else in the project. The form also works as a quiet advert for trackslash.

Today

  • Access is two booleans, is_public and public_issue_creation. The projects_public_issue_creation_requires_public CHECK in migration 0036 means the only way to take issues from outsiders is to publish the whole project.
  • Comments have no visibility. Anyone who can read an issue can read every comment on it.
  • Blocks (project_user_blocks) already exist and are managed by anyone who can manage members. A block removes every kind of access.

Access mode

Help desk is a new, explicit access mode, not a combination of the existing booleans. Replace is_public and public_issue_creation with one project access mode, migrating existing projects to the matching value. The modes are:

  • private;
  • public (read-only);
  • public, anyone signed in can file issues;
  • help desk.

It is set from the project's access settings in the UI, REST and MCP (track_get_project_access, track_update_project_access). Suggestion: keep returning is_public and public_issue_creation, derived from the mode, until clients have moved to the new field.

What a reporter gets

  • An account is required. Signed-out visitors are sent to sign in, then returned to the form.
  • A new-issue link for the project. The form shows only the project's name and key.
  • A list of their own issues in the project, reachable from the form and from each of their issues. For each issue it shows the ref, title, status and last update. It never includes anyone else's issues, and it gives no count of them.
  • Each of their issues, at its usual URL. The link works only when they are signed in as the reporter. It is not a capability URL, so passing it on grants nothing. On that page they see:
    • the title and description;
    • the status, shown as open, in progress or closed;
    • the created and updated times;
    • the comments marked as visible to them, each with its author's display name (never their email).
  • Replies. The reporter can comment on their own issues. Their replies are always visible to members and to them, and follow the same edit rules as other comment authors.
  • Everything else on the issue stays hidden: priority, assignee, tags, sprint, due date, close reason, links, sub-issues, the change history and members-only comments.

Promoting trackslash

At the bottom of the help-desk form, add one short line inviting the reporter to try trackslash, with a link to https://trackslash.com. For example: "This help desk runs on trackslash, the open issue tracker your coding agents can actually use. Take a look →".

Keep to the design principles in AGENTS.md: muted text, and an icon-and-text link at most. No banner, card or gradient. It should read as a footer note, not an ad, and must not distract from filing the issue.

Comment visibility

  • Members choose, for each of their comments, whether it is shared with the reporter or kept to project members. The default is members only, so nothing is shared by accident.
  • A members-only comment never reaches the reporter by any route: the page, the REST API, MCP, realtime events, push notifications, attachments on the comment or comment counts.
  • Members-only comments should mean the same thing in public projects too, hidden from public viewers, so there is only one rule.

Nothing else leaks

A reporter must not be able to see or infer anything about the project beyond their own issues. Check all three surfaces (UI, REST, MCP) and:

  • Lists: the project's issue list, search, other issue refs, members, sprints, tags, context, whiteboard, changelog, insights and stats.
  • Project listings: a help-desk project must not appear in project lists, Recents or Favorites for a non-member. That includes the "projects you can create issues in" query (IssueCreatableToUser in store/projects.go), since otherwise help-desk projects could be enumerated.
  • References in shared text: refs such as TRACK-12 and object-N in a shared comment or the description must not expand into another issue's title, status or attachment.
  • Realtime: a reporter's subscription carries events for their own issues only, and never members-only comments.
  • Errors: someone else's issue in the project returns the same not-found as an issue that does not exist.

Blocking

The owner, or anyone who can manage members, can block a user, using the existing block list. A blocked user gets a 403 for everything in the project through the UI, REST, MCP and realtime. That covers the form, their issue list, the issues they filed before the block, and replying.

Done when

  • Help-desk mode is a project access mode, and every existing project has been migrated to the matching mode.
  • Help-desk mode works through the UI, REST and MCP.
  • Comments carry a visibility that is enforced everywhere.
  • The form carries the trackslash footer line.
  • Every rule above is covered by integration tests written from the reporter's side. They try to read another reporter's issue, a members-only comment and each project listing, and a blocked user gets a 403 on each route.
  • The TRACK-88 security audit covers the new role.

GitHub

0

No branches or pull requests linked.

Comments

1
Bradley

Done in three PRs, one per sub-issue, merged in turn:

To turn it on, choose Help desk on a project's Members page (or send access_mode: helpdesk) and share the "Help desk link" from About (/{owner}/projects/{key}/issues/new). The TRACK-88 audit covers the new reporter role.