Honor per-project access on private-visibility projects (fixes #94) #95
No reviewers
Labels
No labels
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
qwc-open/asiakirjat!95
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/private-project-access"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
canViewProjectandfilterAccessibleProjectsnow treat private visibility as "global access grant or per-project grant", instead of global-only.TestEditorSeesPrivateProjectViaProjectAccess).Why
PR #92 (auto-create-projects) creates projects as
privateand grants the creator aProjectAccesseditor 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
canUploadalready honored per-project grants regardless of visibility, butcanViewProjectwas stricter — meaning a user could end up with upload rights but no view rights.Test plan
go test ./...passesTestEditorSeesPrivateProjectViaProjectAccesscovers: editor with no grant cannot see a private project; editor with aProjectAccessrow can see it.private), confirms the project appears in their list and/admin/projects.🤖 Generated with Claude Code
Pull request closed