trackslash
TRACK-95 P2

List only projects the user belongs to; public projects are link-only

0
All issues

Description

A public project (access_mode public or public_issues) currently shows up in every signed-in user's Projects list. Public should mean link-only. Anyone with the link can open the project, and can file issues if it's public_issues, but people who aren't in it never see it advertised. The Projects list should hold only the projects the user owns or is a member of (project_members, any role).

Why it happens store.ListProjects with VisibleToUser includes access_mode IN ('public', 'public_issues') alongside owner/member. The Projects panel (uiBuildProjectsPanel) lists everything that query returns.

Careful: don't just narrow that query uiVisibleProjects / VisibleToUser is used in about 20 places (ui_home_pages.go, ui_issue_pages.go, ui_tag_pages.go, context/whiteboard/help-desk pages, …). Some of those resolve the project you are on. Narrowing the query would break opening a public project by its link. Instead, add a membership-only listing for surfaces that advertise projects, and leave access checks alone. Read SECURITY_MODEL.md first; its "Public viewer" row should keep holding.

Surfaces that should use the membership list

  • The Projects panel (/projects).
  • The / redirect. uiHome sends you to the first visible project, so a new user with no projects of their own can land on someone else's public project today.
  • The shell's Projects data, used by the sidebar, search and project pickers. Check what each consumer needs. For example, the new-issue picker should offer only projects the user can file into, and a link-only project isn't one they should be browsing to.
  • Probably also GET /api/projects and MCP track_list_projects, which currently list "projects visible to current user".

Open questions (decide when picking it up)

  • Owner pages (@owner projects, uiBuildOwnerProjectsPanel): should non-members see an owner's public projects there? "Link-only" suggests no.
  • Admins: visibleProjectUser returns nil for admins, so they currently list everything. Should that stay, or should admins also get membership only?
  • A public project you opened by link should probably still appear in your own Recents and Favorites, since those record your own history.

Done when

  • A signed-in non-member doesn't see a public project in Projects, isn't redirected to it from /, and isn't offered it in pickers or search.
  • That same user can still open it by URL, read it, and (for public_issues) file issues.
  • Owners and members see it exactly as before.
  • Integration tests cover the list exclusion and the link access.

Sub-issues

0

Linked issues

0

GitHub

0

No branches or pull requests linked.

Comments

1
Bradley

Fixed in https://github.com/badbundle/track-slash-app/pull/192 (merged as 4a77eee).

Public projects are now link-only. Anyone with the link can still open, read and (for public_issues) file into one. Lists name a project only to its owner and members, in any role. Those lists are:

  • Projects and owner pages
  • the / redirect
  • Me (its count and the assigned-issue scan)
  • the new-issue picker
  • GET /api/v1/projects and track_list_projects

What I found: all ~20 uiVisibleProjects callers only fed uiShellData.Projects, which no template rendered. So that field and its per-page queries are gone, and access checks are untouched. ListProjectsParams.VisibleToUser is now MemberUser. IssueCreatableToUser folded into WritableToUser once its public-issues clause went.

Decisions on the open questions:

  • Owner pages list only the viewer's projects, and nothing when signed out.
  • Admins get the same membership lists, and their wider access works by link.
  • Recents and Favorites are unchanged, since they record your own history.
  • The new-issue picker offers only projects you own or can write to. Outsiders file from the project's own page.

SECURITY_MODEL.md has a new "Public projects are link-only" rule. Tests: TestLinkOnlyPublicProjects, plus the store list checks.