mirror of
https://github.com/go-vikunja/vikunja.git
synced 2026-08-15 08:26:14 -05:00
kolaenteandkolaente
0638200ac0
Notification rows outlived access. A subscription survives a project being unshared, so every notification already written for a revoked user stayed readable — comment bodies, task titles, project names, deletion notices. The read paths filtered on notifiable_id alone, with no permission check anywhere. #3325 stopped the sender writing new ones; this is the other half. The project a notification is about is persisted on the row when it is written and the read paths filter on it in SQL, so LIMIT, OFFSET and total are all computed on the filtered set. Notification types declare their project through a capability interface in pkg/notifications, the same way they already declare SubjectID, ThreadID and ToTitle — which is what lets the package below pkg/models stay ignorant of what a project is. project_id 0 means account-scoped and always visible, a positive value is checked against the projects the caller can read, and -1 marks a project-scoped row whose project could not be determined, so it is visible to nobody. Filtering reuses the existing accessibleProjectIDsSubquery, so the page query and the count cannot drift apart. A migration backfills existing rows from their stored payloads, resolving through soft-deleted tasks so task.deleted rows still land on their project. Covers every read path: the v1 and v2 list endpoints, mark-as-read (which echoes the payload back), the Atom feed, and the websocket push — the last of which is load-bearing, since a row is still written for a revoked subscriber. Deliberately no instance-admin bypass: notifications are always the caller's own, and being an admin says nothing about whether they should still read a comment out of a project they were removed from.