[Feature][Calendar] Create-for-child from the parent calendar — owner selector in the event modal (follow-up to #788) #790

New Issue

2026-07-22T05:36:22Z

spikerj commented

2026-07-22 05:36:22 +00:00

Phase 3 of the family-calendar overlay (#788): let a parent CREATE an event directly on a child's calendar from the parent view.

Backend is nearly free: POST api/calendar/children/{childUserId}/events → CalendarParentalAccess.EnsureOwnerOrParentAsync, build the event with CreatedBy = childUserId (UpdatedBy = the parent), reuse CreateCalendarEventCommand — its UserId => CreatedBy already invalidates the child's cache correctly, and the reminder should schedule for the child.

The real scope is UI: an owner mat-select ("Me" + linked children, colored dots per the #788 palette) in EventModalComponent's create mode, plumbing children into the modal data, and routing save to a new CalendarApiService.createChildEvent. Also decide whether handleDateSelect defaults the owner to "Me" always or remembers the last choice.

Deliberately split out of #788 so the overlay could ship without modal surgery.

Phase 3 of the family-calendar overlay (#788): let a parent CREATE an event directly on a child's calendar from the parent view. Backend is nearly free: `POST api/calendar/children/{childUserId}/events` → `CalendarParentalAccess.EnsureOwnerOrParentAsync`, build the event with `CreatedBy = childUserId` (`UpdatedBy` = the parent), reuse `CreateCalendarEventCommand` — its `UserId => CreatedBy` already invalidates the child's cache correctly, and the reminder should schedule for the child. The real scope is UI: an owner `mat-select` ("Me" + linked children, colored dots per the #788 palette) in `EventModalComponent`'s create mode, plumbing `children` into the modal data, and routing save to a new `CalendarApiService.createChildEvent`. Also decide whether `handleDateSelect` defaults the owner to "Me" always or remembers the last choice. Deliberately split out of #788 so the overlay could ship without modal surgery.

spikerj referenced this issue

2026-07-22 05:45:19 +00:00

[Feature][Calendar] Family calendar overlay — parents see + manage children's events with per-child toggles (epic #781 adjacent) #788

spikerj commented

2026-07-29 16:56:19 +00:00

Audited at file level against origin/master — NOT DONE. Neither half landed.

Backend: enumerating every route in SpikerSoft.Api/Domain/Calendar/CalendarController.cs shows [HttpGet("children/{childUserId}/events")] at :326 — the #788 read-side family overlay — and [HttpPost("events")] at :431. There is no POST children/{childUserId}/events. No create-for-child endpoint exists.
Angular: git grep -n "createChildEvent" origin/master → zero hits repo-wide.

Worth noting this is not the usual half-shipped cross-repo pattern I've been finding elsewhere in this audit (#894, #663, #645). Both halves are simply absent — the follow-up was filed after #788 shipped and never started.

One thing I did not open: the owner mat-select in EventModalComponent create mode. Since createChildEvent doesn't exist anywhere for a selector to call, there'd be nothing to route to — but treating that as inferred rather than verified.

Remaining: the whole ticket. The read-side overlay from #788 is in place, so the shape is established; this is the write-side counterpart — endpoint with the same household-authorization check :326 uses, service method, and the owner selector gated to a parent's own children.

Related open work worth sequencing against: #876 (ApproveParentalLinkCommandHandler silently resets unlisted FeaturePermissions to false) touches the same parental-permission surface. If create-for-child gains its own permission gate, it should be added after #876 is fixed, or it'll be silently zeroed by the same wholesale-replacement bug.

Audited at file level against `origin/master` — **NOT DONE. Neither half landed.** - **Backend:** enumerating every route in `SpikerSoft.Api/Domain/Calendar/CalendarController.cs` shows `[HttpGet("children/{childUserId}/events")]` at `:326` — the #788 read-side family overlay — and `[HttpPost("events")]` at `:431`. There is **no** `POST children/{childUserId}/events`. No create-for-child endpoint exists. - **Angular:** `git grep -n "createChildEvent" origin/master` → **zero hits** repo-wide. Worth noting this is *not* the usual half-shipped cross-repo pattern I've been finding elsewhere in this audit (#894, #663, #645). Both halves are simply absent — the follow-up was filed after #788 shipped and never started. One thing I did not open: the owner `mat-select` in `EventModalComponent` create mode. Since `createChildEvent` doesn't exist anywhere for a selector to call, there'd be nothing to route to — but treating that as inferred rather than verified. **Remaining:** the whole ticket. The read-side overlay from #788 is in place, so the shape is established; this is the write-side counterpart — endpoint with the same household-authorization check `:326` uses, service method, and the owner selector gated to a parent's own children. Related open work worth sequencing against: **#876** (`ApproveParentalLinkCommandHandler` silently resets unlisted `FeaturePermissions` to false) touches the same parental-permission surface. If create-for-child gains its own permission gate, it should be added after #876 is fixed, or it'll be silently zeroed by the same wholesale-replacement bug.

spikerj referenced this issue

2026-07-29 17:01:25 +00:00

Epic: Unified scheduling — recurrence engine + availability (calendar + iCal) #781

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#790