- Shipped
- August 10, 2026 at 6:03 PM UTC
- Author
- Kamo
- Commit
- 84b272e
UserCalendar and CalendarEvent hung off USER_ID alone and carried no organisation. A user is global and a member is that user inside one organisation, so an account belonging to several organisations had one pile of calendars visible from all of them. Both entities gain MEMBER_ID and ORGANIZATION_ID, and a calendar gains IS_ORG_CALENDAR — the one shared calendar an organisation has, readable by every member and writable only with the new right. USER_ID stays, populated and nullable: CalDAV and the external-sync jobs authenticate an account rather than a membership, so they legitimately read by user. It simply stops being the authorisation scope. Every new join column pins columnDefinition = "INT8", including the pre-existing user ones. Left unpinned, Hibernate copies the referenced key's INT8 DEFAULT unique_rowid() onto the FK; an insert that omits the column then invents an id belonging to nothing and fails the foreign key. That is not hypothetical — it is what stopped the first migration run from provisioning a single organisation calendar. New right CREATE_ORG_CALENDAR_EVENTS (196). Reading the calendar stays VIEW_CALENDAR; this governs only who may put something on the calendar the whole organisation sees. findByOrganizationMemberId is renamed findByUserId. It never scoped by member — the query is and was c.user.id = :userId — and the name is what invited this class of bug. findVisibleToMember and its event equivalent are the member-scoped reads.