Scope notes to a membership instead of an account

Fixkamo-shared-library
Shipped
August 14, 2026 at 11:06 PM UTC
Author
Kamo
Commit
411f0e0

A note hung off USER_ID alone and carried no organisation at all. A user is global and a member is that user inside one organisation, so an account belonging to several organisations had one pile of notes visible from every one of them — open a different org and the first org's notes came along, onto /notes, the home page and the floating stickies alike. Note gains MEMBER_ID and every finder filters on it. There is deliberately no by-user variant left to reach for: that is what made the scope wrong in the first place. USER_ID stays, and stays populated. A note's content is encrypted under a key derived from the user id, so the account has to remain on the row for an account's own notes to decrypt from any of its memberships; it just stops being the read scope. The join column pins INT8 so it cannot inherit DEFAULT unique_rowid() from Member.id and stamp every existing note with a member id matching no row. note_tags needs no column of its own — a tag hangs off its note, so the tag listing reaches the membership through it. Going via NoteTag.user would have listed the tags of every organisation the account belongs to. Deleted notes are excluded there now too; their tags used to keep haunting the filter bar.

All changes

Like what you see shipping?

Every one of these updates lands in your workspace automatically. Start free and watch it grow week after week.

Start Free ForeverView Pricing