Personal Notes - notes only seen by the user that created them, unless shared/pinned

[adambomb1011]

I would like to use yuvomi as a note app as well. Is there any way to allow personal notes, not seen by other users, unless shared or pinned?

[ulsklyc]

Confirmed, and this is less a new feature than a missing alignment.

notes carries created_by but no visibility column, so every note is household-visible. Three neighbouring tables in the same schema already have the exact vocabulary for what you are asking: medications, health_lab_reports and budget_entries all carry visibility TEXT CHECK(visibility IN ('private','family')). The notes module simply never got it.

So the answer to "is there any way" is no, and the answer to "could there be" is yes, using a pattern that is already in the database three times over rather than inventing a fourth one.

One decision is worth stating up front, because it is the part that can go wrong irreversibly: the default has to stay family. Defaulting existing notes to private would hide every note already written from everyone except its author, on update, without anyone asking for that. #584 walked into exactly that trap with health data and it took a migration to walk back out. New notes could reasonably default either way, and I lean towards family there too, so that the sharing model of a family planner does not silently invert.

Your "unless shared or pinned" clause needs one correction: pinning cannot double as sharing. A pinned note is on the dashboard, which is shared ground, so a private note that is pinned would leak itself through the pin. Private and pinned has to mean pinned for the author only, or be refused. Sharing stays an explicit act.

Accepted, no date.

[ulsklyc]

A correction to my answer above, from re-checking it against the schema rather than from memory.

I wrote that medications, health_lab_reports and budget_entries "all carry visibility TEXT CHECK(visibility IN ('private','family'))". That is right for the two health tables and wrong for the third:

• medications and health_lab_reports: CHECK(visibility IN ('private','family')), default private.
• budget_entries: CHECK (visibility IN ('private','shared','shared_amount')), default shared. It has never used family - migration v88 introduced it as ('private','shared'), and Support including private budget entries in account balance computation #659 added the third step later.

So there are not three copies of one pattern in the database. There are two different patterns, and they disagree with each other in both directions: health data is private by default and calls the shared state family; budget data is shared by default and calls it shared.

That matters here more than it looks, because my own answer then picked one of them without saying so. I wrote that "the default has to stay family" - which silently adopted the health vocabulary and the opposite of the health default. The reasoning behind it still holds and I would still argue for it: flipping existing notes to private on an update would hide what people already wrote, and that is the #584 trap. But the choice between the two vocabularies was a real fork, and I presented it as if the schema had already made it.

Nothing else in that answer changes. notes still carries created_by and no visibility column, so every note is household-visible today, and pinning still cannot double as sharing for the reason given above.

[ulsklyc]

A correction to something I wrote here on 12 August and leaned on again on 2 September: #584 did not walk into that trap, and no migration walked anything back.

The caregiver grant in v1.83.0 landed as a per-person setting from the start (migration 130), and until an admin sets one, nothing changes for anybody; that was the point of the design there, and the release note says so. The trap I meant is the one #584 deliberately avoided: a default derived from the family role that changes what existing members see on update. It is now written down as the first entry in docs/DECISIONS.md, with #584 as the case where the trap was avoided, not the case where it happened.

The argument in this thread stands: existing notes stay visible on update, whatever the default for new ones turns out to be. Its example was wrong, and I would rather say so here than leave the register and this thread contradicting each other.