Honor per-project access on private-visibility projects (fixes #94) #95

Closed
qwc wants to merge 91 commits from fix/private-project-access into main
Owner

Summary

  • canViewProject and filterAccessibleProjects now treat private visibility as "global access grant or per-project grant", instead of global-only.
  • Adds a regression test (TestEditorSeesPrivateProjectViaProjectAccess).
  • Updates the docs for the new semantics (manage-global-access, first-project tutorial, roles-permissions reference).

Why

PR #92 (auto-create-projects) creates projects as private and grants the creator a ProjectAccess editor row. But the old view-check code required a global access grant for private projects and ignored per-project rows, so an editor without global access couldn't see a project they had just created — issue #94.

This also fixes the latent inconsistency where canUpload already honored per-project grants regardless of visibility, but canViewProject was stricter — meaning a user could end up with upload rights but no view rights.

Test plan

  • go test ./... passes
  • New test TestEditorSeesPrivateProjectViaProjectAccess covers: editor with no grant cannot see a private project; editor with a ProjectAccess row can see it.
  • Manual: editor logs in, creates a project via Admin > Projects (default visibility now private), confirms the project appears in their list and /admin/projects.
  • Manual: editor with no grants on an unrelated private project still cannot see it.

🤖 Generated with Claude Code

## Summary - `canViewProject` and `filterAccessibleProjects` now treat private visibility as "global access grant **or** per-project grant", instead of global-only. - Adds a regression test (`TestEditorSeesPrivateProjectViaProjectAccess`). - Updates the docs for the new semantics (manage-global-access, first-project tutorial, roles-permissions reference). ## Why PR #92 (auto-create-projects) creates projects as `private` and grants the creator a `ProjectAccess` editor row. But the old view-check code required a **global** access grant for private projects and ignored per-project rows, so an editor without global access couldn't see a project they had just created — issue #94. This also fixes the latent inconsistency where `canUpload` already honored per-project grants regardless of visibility, but `canViewProject` was stricter — meaning a user could end up with upload rights but no view rights. ## Test plan - [x] `go test ./...` passes - [x] New test `TestEditorSeesPrivateProjectViaProjectAccess` covers: editor with no grant cannot see a private project; editor with a `ProjectAccess` row can see it. - [ ] Manual: editor logs in, creates a project via Admin > Projects (default visibility now `private`), confirms the project appears in their list and `/admin/projects`. - [ ] Manual: editor with no grants on an unrelated private project still cannot see it. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Honor per-project access on private-visibility projects
All checks were successful
CI / test (pull_request) Successful in 1m30s
CI / build (pull_request) Successful in 57s
CI / docker (pull_request) Has been skipped
f3e7965b5d
Per-project ProjectAccess rows were silently useless for view checks on
private-visibility projects: canViewProject and filterAccessibleProjects
required a global access grant for private and ignored any per-project
row. The auto-create flow (PR #92) creates projects as private and
grants the creator a ProjectAccess row, so editors without global access
couldn't see projects they had just created.

Treat private as "global access grant OR per-project grant" — aligning
canViewProject with the already-lenient canUpload. Per-project grants on
private projects act as targeted exceptions, e.g. for the creator.

Fixes #94.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
qwc referenced this pull request from a commit 2026-05-18 19:53:37 +02:00
qwc closed this pull request 2026-05-19 07:05:46 +02:00
qwc referenced this pull request from a commit 2026-07-13 13:19:10 +02:00
All checks were successful
CI / test (pull_request) Successful in 1m30s
CI / build (pull_request) Successful in 57s
CI / docker (pull_request) Has been skipped

Pull request closed

Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
qwc-open/asiakirjat!95
No description provided.