Move calendars onto memberships and give each org a shared one

FeatureInitializerService
Ya
10 Agosti 2026, 18:04 UTC
Mwandishi
Kamo
Ahadi ya
d5546e5

Calendars and events were owned by an account and carried no organisation. This attaches each to its owner's earliest membership — the organisation the account has belonged to longest, which in practice is where the calendar was made — so a calendar lands in exactly one organisation rather than being duplicated across all of them. Accounts where that choice was material are counted in the log, because for them the calendar stops being visible from their other organisations. Events follow the calendar they live on rather than their own user, so an event can never end up in a different organisation from the calendar displaying it. The DROP DEFAULT on user_id is the load-bearing statement. That column predates this change and had carried DEFAULT unique_rowid() from User.id all along, harmlessly, because it was NOT NULL and always written explicitly. Making it nullable so the shared calendar could exist without an owner turned it lethal: an INSERT that omits user_id fires the default, invents a user id belonging to nobody, and fails the foreign key to users. That is exactly how the first run provisioned zero organisation calendars. The entities now pin the column type so ddl-auto cannot reinstate it. Idempotent throughout: the backfills only touch rows with no member yet, and the shared calendar is inserted only where an organisation has none.

Mabadiliko yote

Je, unaona nini kuhusu usafiri?

Kila moja ya hizi updates ardhi katika nafasi yako ya kazi moja kwa moja. Kuanza bure na kuangalia kukua wiki baada ya wiki.

Kuwa Huru MileleMtazamo wa bei