feat: editable event attendees with contact picker #29

Merged
makiolaj merged 6 commits from feat/attendee-editing into release/v2.8.0 2026-06-23 07:12:29 +00:00
Showing only changes of commit ac17343747 - Show all commits

View File

@@ -480,16 +480,25 @@ detail screen (since v0.6) but the form can't write them. Make guests editable.
enums, `queryAttendees` + `EventDetailMapper.toAttendee` (with tests), and the enums, `queryAttendees` + `EventDetailMapper.toAttendee` (with tests), and the
attendees `DetailCard` + `AttendeeRow` in `EventDetailScreen`. Nothing to add attendees `DetailCard` + `AttendeeRow` in `EventDetailScreen`. Nothing to add
there. there.
- **Write side (new):** add `attendees` to `EventForm` and an attendees section - **Write side — SHIPPED (`feat/attendee-editing`, commit b0f34ff, 2026-06-22):**
to `EventEditScreen` — add a guest by typed email (+ optional display name), `attendees` on `EventForm`; a Guests section in `EventEditScreen` rendered as an
remove rows, set role (required / optional). Persist by diffing against the inline grouped list — each guest a tonal card (avatar, name/email, tappable
provider's `CalendarContract.Attendees` rows on insert + dirty-checked update, Required/Optional role chip, remove), the trailing card an inline email field
mirroring the reminders-diff (kept rows keep their fields). Organizer/self rows (type → Done commits). Persisted by `reconcileAttendees` diffing the provider's
are not user-editable. `CalendarContract.Attendees` rows on insert + dirty-checked update (new guests =
- **No new permission for the typed-email path** — writing `Attendees` needs only `RELATIONSHIP_ATTENDEE` / `STATUS_INVITED`; kept rows keep their status, only the
the existing `WRITE_CALENDAR`. A contact-picker entry (`ACTION_PICK` on emails, required/optional type updates; organizer/resource/no-email rows untouched).
one-shot, no READ_CONTACTS) can follow as a convenience, reusing the address- Reminders restyled to the same grouped-list pattern in passing. Needs only the
picker mechanism above. existing `WRITE_CALENDAR` — no new permission.
- **Name on manual add — solved next via a contact picker.** The inline field is
email-only (the quick path); names otherwise come from sync. The planned fix is
a **"from contacts" entry**: `ACTION_PICK` on
`ContactsContract.CommonDataKinds.Email.CONTENT_URI` → the system Contacts app
returns a URI to the picked email row, queried for `Email.ADDRESS` **and** the
contact `DISPLAY_NAME`, so a picked guest gets both email and name directly. The
result Intent grants temporary read access, so **no `READ_CONTACTS` permission**
— one-shot and user-driven, same no-permission mechanism as the location address
picker above. Self/organizer rows stay non-editable.
- **Invitation behavior — DECIDED 2026-06-22: record-only, all writable - **Invitation behavior — DECIDED 2026-06-22: record-only, all writable
calendars.** Calendula has no INTERNET and never sends an invitation itself; it calendars.** Calendula has no INTERNET and never sends an invitation itself; it
only writes `Attendees` rows. Whether a guest is notified is decided downstream: only writes `Attendees` rows. Whether a guest is notified is decided downstream: