EventService: household-wide event visibility and self-add #188

New issue

Closed

opened 2026-08-23 22:54:05 +00:00 by nalum · 0 comments

nalum commented

2026-08-23 22:54:05 +00:00

Owner

Implements option A of #187, and lands only if that decision goes A.

Two changes, both in internal/services/event/:

Read — relax svc.RequireEventMember (read.go:32) to household membership, so a member may open any event on the shared calendar. The grid already shows them; today tapping one and reading it is refused, which is the inconsistency #187 is about.
AddUser — allow a household member to add themselves (adduser.go:36). Adding anyone else stays member-only. Without this nobody but an admin can join an event, so "I'm going" is unbuildable and a parent cannot put themselves on the school run.

Everything else stays as it is: Update, Delete, RemoveUser, SplitOccurrence and CancelOccurrence remain member-only, and ListEvents keeps filtering to your own.

Needs the ADR from #187, integration coverage for the auth-critical paths (the repo rule for auth flows), and a note in the permission matrix commentary so the guard's new shape is discoverable.

Update — #187 is closed, and this is what it decided

Everyone can read the calendar and the events on the calendar. Joining an event
is open to all (except guest) as well.

So, concretely:

Read — drop svc.RequireEventMember (internal/services/event/read.go:32).
The permission matrix already admits Admin, Member, Child and Guest, and that
role gate becomes the whole check. The grid has always returned every event;
this makes opening one agree with seeing it.
AddUser — allow a caller to add themselves to any event
(adduser.go:36). Adding anyone else stays member-only. The matrix admits
Admin, Member and Child for AddUser and not Guest, so "open to all except
guest" needs no matrix change — only the resource guard moves.

Everything else keeps its member guard: Update, Delete, RemoveUser,
SplitOccurrence, CancelOccurrence, and ListEvents keeps filtering to your
own.

This is an authorization change, so it needs an ADR and integration coverage —
including the negative cases: a Guest may read but may not join, and a member may
add themselves but not a third person.

Update — implemented in PR #205 (2026-08-25)

feat/household-visible-calendar delivers this, and ADR-0036 records it. The guard went one step further than the sketch above: attendance and authority split. AddUser/RemoveUser gate on RequireEventJoiner/RequireEventLeaver (self-add and self-remove open to every role the matrix admits), and a self-add writes an ATTENDEE ref — presence with no authority — while Update, Delete and the occurrence verbs gate on RequireEventOwner (an OWNER ref, or admin). Read dropped its membership guard entirely. Every ref written before the change is an OWNER ref, so no stored event changes meaning.

Closes when the PR merges. The updated handoff's newer requirement — an event with no attendees is household-owned — is not part of this change and has its own issue, #257.

Implements option A of #187, and lands only if that decision goes A. Two changes, both in `internal/services/event/`: 1. **`Read`** — relax `svc.RequireEventMember` (`read.go:32`) to household membership, so a member may open any event on the shared calendar. The grid already shows them; today tapping one and reading it is refused, which is the inconsistency #187 is about. 2. **`AddUser`** — allow a household member to add **themselves** (`adduser.go:36`). Adding anyone else stays member-only. Without this nobody but an admin can join an event, so "I'm going" is unbuildable and a parent cannot put themselves on the school run. Everything else stays as it is: `Update`, `Delete`, `RemoveUser`, `SplitOccurrence` and `CancelOccurrence` remain member-only, and `ListEvents` keeps filtering to your own. Needs the ADR from #187, integration coverage for the auth-critical paths (the repo rule for auth flows), and a note in the permission matrix commentary so the guard's new shape is discoverable. --- ## Update — #187 is closed, and this is what it decided > Everyone can read the calendar and the events on the calendar. Joining an event > is open to all (except guest) as well. So, concretely: 1. **`Read`** — drop `svc.RequireEventMember` (`internal/services/event/read.go:32`). The permission matrix already admits Admin, Member, Child and Guest, and that role gate becomes the whole check. The grid has always returned every event; this makes opening one agree with seeing it. 2. **`AddUser`** — allow a caller to add **themselves** to any event (`adduser.go:36`). Adding anyone else stays member-only. The matrix admits Admin, Member and Child for `AddUser` and not Guest, so "open to all except guest" needs no matrix change — only the resource guard moves. Everything else keeps its member guard: `Update`, `Delete`, `RemoveUser`, `SplitOccurrence`, `CancelOccurrence`, and `ListEvents` keeps filtering to your own. This is an authorization change, so it needs an ADR and integration coverage — including the negative cases: a Guest may read but may not join, and a member may add themselves but not a third person. --- ## Update — implemented in PR #205 (2026-08-25) `feat/household-visible-calendar` delivers this, and ADR-0036 records it. The guard went one step further than the sketch above: **attendance and authority split**. `AddUser`/`RemoveUser` gate on `RequireEventJoiner`/`RequireEventLeaver` (self-add and self-remove open to every role the matrix admits), and a self-add writes an **ATTENDEE** ref — presence with no authority — while `Update`, `Delete` and the occurrence verbs gate on `RequireEventOwner` (an OWNER ref, or admin). `Read` dropped its membership guard entirely. Every ref written before the change is an OWNER ref, so no stored event changes meaning. Closes when the PR merges. The updated handoff's newer requirement — an event with **no** attendees is household-owned — is not part of this change and has its own issue, #257.

nalum added the

enhancement

adr

labels

2026-08-23 22:54:05 +00:00

nalum referenced this issue

2026-08-23 22:54:05 +00:00

Decide: who may see a household event — ListOccurrences and Read disagree #187

nalum referenced this issue

2026-08-23 22:54:30 +00:00

Order of work for the calendar redesign (#187-#198) #199

nalum added the