@acms-subir/core 0.3.55 → 0.3.57

package/CHANGELOG.md

@@ -1,5 +1,34 @@
 # @acms-subir/core
 
+## 0.3.57
+
+### Patch Changes
+
+- b9eed5e: Change a repeating event from one of its dates on, and keep the dates before it as they were.
+
+  - **One event.** When a class moves for good, from Thursdays 6 PM to Wednesdays 5 PM, the dates before the change stay exactly as they were, and it stays one event: the same page, slug, hosts, RSVPs and My events entry. Each change is a segment on the events row (`CalEvent.segments`, migration 70), with its own first date, repeat, rooms and place.
+  - **Where.** Change it from the event editor's Single dates (**From here on…**, with **Undo**), or drag a date on the Schedule and choose **This and following dates**. Hosts can ask with **Change from this date on…** on My events, and staff apply it from Requests.
+  - **What follows.** Sign-ups move to the new date nearest them within half a week, and each person is emailed the new time with your note. Cancelled, skipped and moved dates follow the same way. Sign-ups with no new date near them are cancelled, with the email. `npx acms docs calendar` has the rule.
+  - **Every output.** `/calendar`, the event page ("Weekly on Thursday · From Wed, Jan 9: Weekly on Wednesday"), cards, the TV display, room holds and the app API show the new dates. `calendar.ics` writes one VEVENT per part, as Google does for "this and following". The "When an event changes" rule sends one notice: "From Wed, Jan 9: Weekly on Wednesday, 5:00 PM".
+  - **API.** Events carry `segments` (`from`, `start`, `end`, `rrule`, `repeats`, `cancelled`, `note`, `location`, `rooms`). `repeats` is the rule in effect now, and each occurrence has its own `location`. Push data gains `change: 'fromDate' | 'cancelledFrom'`.
+  - **Server API.** `@acms-subir/core/server` adds `changeFromDate`, `cancelFromDate`, `restoreFromDate`, `revertFromDate` (staff and `GOOGLE_SYNC`, all idempotent, `quiet` for a sync) and `requestFromDate` for hosts.
+
+## 0.3.56
+
+### Patch Changes
+
+- 191830f: Anyone can now ask for an event, or for a change to one, without an account. Turn it on with `acms({ requests: true })`; it needs the calendar.
+
+  - **On the website**, a form at `/request` (and `/es/request` and so on), in the visitor's language and themed through the site's tokens. It asks what they're planning, the kind, date and times, how it repeats, rooms (or "Not sure"), how many people, and anything else. "Change to an event" asks which event, optionally which date, and what should change. A live line says whether the chosen rooms look free then (free or busy only). `requests: { path: '/ask' }` moves it; `requests: { page: false }` drops it but keeps the rest, and a site file at the path replaces it.
+  - **In apps**, `GET /api/v1/requests/options` (open or closed, the kinds and requestable rooms, the reply time, notice and office phone, in the asked language) and `POST /api/v1/requests` (Idempotency-Key; returns `{ id }`; refusals carry a code such as `title`, `past`, `room`, `closed` or `busy`). `site.features.requests` says the site has it. 10 requests a minute and 20 a day per address, 5 a day per email address, plus the site's daily cap.
+  - **Calendar → Requests** lists requests from the app, the website and hosts on My events (new events, suggested changes and date moves, each answered there) in one place, with Pending, Approved and Declined tabs and, on each new request, what takes its rooms then (12 weeks for weekly ones). **Approve** makes a draft that's already filled in: title, times, weekly when asked, the kind's tag and calendar, and the rooms held while it's a draft. The person's details stay on the request, never on the event. Approving a change opens the event, or that date's Move… form. **Reply** and **Decline** (with an optional reason) email the person in the language they asked in. **Delete as spam** removes one without an email. The list shows 50 at a time. Reading the list needs "Create and edit content"; answering needs "Publish content".
+  - **Settings** on that page (needs "Manage rooms and calendars"): open or closed (closed forms and apps say so and show the office phone, and never disappear), the kinds with their label in each language, tag and calendar, the reply time and opening notice in each language, the office phone, who hears about new requests (else `members.notify`, else the owners), an optional push to their linked phones, the daily cap (100) and how long requests are kept (180 days after the answer, or after they arrive if nobody answers). Rooms marked **Anyone can check if it's free** are the ones people can choose.
+  - **Emails:** the person gets "We got your request" in their language. It never repeats what they typed, so the form can't be used to send someone else a message, and each address gets at most 3 a day. Staff get every detail, with Reply-To set to the person, and only while the request still waits.
+  - **Privacy:** the generated privacy notice gets an "Event requests" section (what's kept, why, and when it's deleted), and the app store answers list event requests under contact info and user content. Requests are in backups.
+  - **Server API** (`@acms-subir/core/server`): `requestOptions`, `submitRequest` (for a site's own form), `listRequests`, `approveRequest`, `declineRequest` and `replyToRequest`. See `npx acms docs calendar` and `npx acms docs server`.
+
+  Requests use the `event_requests` table that came with hosts' date moves (migration 68); this release adds no migration. After updating, a site that wants requests adds `requests: true`, marks the rooms people may ask for as **Anyone can check if it's free**, and sets the kinds, reply time and office phone in Calendar → Requests → Settings. Update the privacy notice and the app's store answers, which now include requests.
+
 ## 0.3.55
 
 ### Patch Changes

package/cli/migrations.generated.mjs

@@ -283,8 +283,8 @@ var V65_COLUMNS = [
   "start_at",
   "end_at"
 ];
-var EVENT_CHANGE_SNAPSHOT = [...V65_SNAPSHOT, "moved_dates"];
-var EVENT_CHANGE_COLUMNS = [...V65_COLUMNS, "moved_dates"];
+var EVENT_CHANGE_SNAPSHOT = [...V65_SNAPSHOT, "moved_dates", "segments"];
+var EVENT_CHANGE_COLUMNS = [...V65_COLUMNS, "moved_dates", "segments"];
 var snapshotOf = (cols, row) => `json_object(${cols.map((c) => `'${c}',${row}.${c}`).join(",")})`;
 var live = "(SELECT suppressed FROM webhook_control WHERE id=1)=0";
 var quiet = "COALESCE((SELECT quiet FROM push_control WHERE id=1),0)";
@@ -331,6 +331,15 @@ var MOVED_DATES_MIGRATION = (contentVersionUpdate) => ({ version: 66, statements
   `DROP TRIGGER event_changes_delete`,
   ...eventChangeTriggers([...V65_SNAPSHOT, "moved_dates"], [...V65_COLUMNS, "moved_dates"])
 ] });
+var SEGMENTS_MIGRATION = (contentVersionUpdate) => ({ version: 70, statements: [
+  `ALTER TABLE events ADD COLUMN segments TEXT NOT NULL DEFAULT '[]'`,
+  `DROP TRIGGER content_version_events_update`,
+  contentVersionUpdate,
+  `DROP TRIGGER event_changes_insert`,
+  `DROP TRIGGER event_changes_update`,
+  `DROP TRIGGER event_changes_delete`,
+  ...eventChangeTriggers([...V65_SNAPSHOT, "moved_dates", "segments"], [...V65_COLUMNS, "moved_dates", "segments"])
+] });
 
 // src/lib/maps/migration.ts
 var PLACES_MIGRATION = { version: 43, statements: [
@@ -1351,12 +1360,15 @@ var MIGRATIONS = [
   { version: 68, statements: REQUEST_TABLE },
   // two-way Google Calendar sync: the account, links, pairs, outgoing queue
   // (triggers on events) and Recent changes. Not public, so no cache trigger.
-  GCAL_MIGRATION
+  GCAL_MIGRATION,
+  // a series changed from one date on (CalEvent.segments): a column on the
+  // row, so the triggers on events see it, like moved_dates
+  SEGMENTS_MIGRATION(contentVersionTriggers("events", [...CONTENT_VERSION_COLUMNS.events, "cancelled_dates", "moved_dates", "segments"])[2])
 ];
 var CURRENT_CONTENT_VERSION_COLUMNS = {
   ...CONTENT_VERSION_COLUMNS,
   settings: [...CONTENT_VERSION_COLUMNS.settings, "links_verified", "links_avatar_shape", "links_avatar_fit", "links_avatar_scale", "legal"],
-  events: [...CONTENT_VERSION_COLUMNS.events, "cancelled_dates", "moved_dates"],
+  events: [...CONTENT_VERSION_COLUMNS.events, "cancelled_dates", "moved_dates", "segments"],
   resources: [...CONTENT_VERSION_COLUMNS.resources, "color", "show_on_events"],
   announcements: ANNOUNCEMENT_VISIBLE_COLUMNS
 };

package/docs/calendar.md

@@ -1,6 +1,7 @@
-# Calendar: repeats, single dates, rooms and clashes
+# Calendar: repeats, single dates, rooms, clashes and requests
 
-How events repeat, how one date of a series is changed, and how events hold rooms.
+How events repeat, how one date of a series is changed, how a series changes from a
+date on, how events hold rooms, and how people ask for events.
 Read it with `npx acms docs calendar`. The functions named here come from
 `@acms-subir/core/server` (`npx acms docs server` has their signatures), and the app
 API is in `docs/mobile-api-v1.md` in the framework repository.
@@ -147,6 +148,120 @@ Errors carry a `status`, a message safe to show people, and a `code`:
 | 403 | `room-not-allowed` | a host picking a room the event doesn't use and nobody may request |
 | 401, 404 | | who is acting |
 
+## From this date on
+
+When a class moves for good, say from Thursdays 6 PM to Wednesdays 5 PM, change the
+series **from one of its dates on**. The dates before it stay exactly as they were. It
+stays one event: the same page, slug, hosts, RSVPs and My events entry.
+
+Ways to do it:
+
+- the event editor's **Single dates** list: **From here on…** on a date (the new first
+  date, its times, how it repeats, its rooms and a note);
+- dragging a date of a repeating event on the Schedule, then **This and following
+  dates**. **Undo** puts it back;
+- a host's **Change from this date on…** on My events, which is a request staff apply
+  from Schedule → List → Requests;
+- `changeFromDate` from site code or a calendar sync.
+
+The new first date may come before the date you change from (from Thursday Jan 10 to
+Wednesday Jan 9), but it has to come after the date before it. Leave the repeat as it
+is and it carries on from the new day: "weekly on Thursday" moved to a Wednesday becomes
+"weekly on Wednesday", a COUNT becomes what's left of it, and an end date stays.
+
+### What follows the change
+
+Each date from the change point on is matched to the new date nearest it, within half
+a week (3½ days). Each new date takes at most one old date, closest pairs first. Then:
+
+- its RSVPs move to that date, and each person gets the "new time" email in their own
+  language, with your note. Places in line move quietly;
+- a cancelled date stays cancelled on its match, and a skipped one stays skipped;
+- a moved date keeps its new time, as its match's date;
+- a date with no match has its RSVPs cancelled (with the "cancelled" email). Its
+  cancellation, skip or move is dropped, and `changeFromDate` lists it in `dropped`.
+
+So Thursday → Wednesday moves each week's sign-ups to that week's Wednesday, and twice
+a week → once a week keeps the day that matches and cancels the other.
+
+Changing again from a later date replaces every change after it, the way Google's
+"this and following" works. Changing from the first date of an earlier change replaces
+that change. A change that gives exactly the dates the rule before it gives is no
+change at all: it's removed. **Undo** in the editor (`revertFromDate`) removes a change
+the same way, with RSVPs following back.
+
+### How it shows
+
+- `/calendar`, the event page, cards, the TV display, the app API and room holds show
+  the new dates like any other date of the series. Its rooms and place hold from then.
+- The event page's repeat line says the rule in effect and the change still to come:
+  "Weekly on Thursday · From Wed, Jan 9: Weekly on Wednesday". Once it has taken over,
+  just "Weekly on Wednesday".
+- `calendar.ics` has one VEVENT per part, the way Google writes "this and following":
+  the event's own rule keeps its UID and stops with an UNTIL at the end of the day
+  before the change,
+  and each change is a recurring event of its own with UID `<id>-<from>@<host>` (`from`
+  as `YYYYMMDDTHHmm`), with its own cancelled and moved dates. Calendar apps that
+  subscribed show both parts.
+- The "When an event changes" rule sends one notice: "Music class · From Wed, Jan 9:
+  Weekly on Wednesday, 5:00 PM" (`data.change: 'fromDate'`), or "Cancelled: every date
+  from …" (`'cancelledFrom'`).
+- `/api/v1/events` and `/api/calendar/events` carry `segments: [{ from, start, end,
+  rrule, repeats, cancelled, note, location, rooms }]` on each event, and `repeats` is
+  the rule in effect now. Each occurrence has `location`: its own place (a moved
+  date's, or its segment's), `null` for the event's.
+
+### Stored on the event row
+
+Changes are `CalEvent.segments`, sorted by `from`, on the events row (so its triggers,
+the event_changes outbox and the content version see them):
+
+`{ from, start, end, rrule, roomIds?, location?, cancelled, note, by, at }`
+
+- `from` is an occurrence key of the rule before it: that rule's dates from that day on
+  are gone (so retiming the earlier rule never leaves a second date that day);
+- `start`/`end` are the new part's first date, wall-clock like the event's own;
+- `rrule` is its rule (`''` = just that date);
+- `roomIds`/`location` are its rooms and place (unset = the event's);
+- `cancelled: true` cancels every date of it.
+
+Its dates have their own keys, so `cancelledDates`, `movedDates` and `exdates` work on
+them, and so do `moveOccurrence` and `cancelOccurrence`. `seriesParts(event)` splits a
+series into its parts. Dragging the whole series on the Schedule moves every part.
+
+Why one event with segments, and not a second event for the later part: hosts, RSVPs,
+the page and slug, My events and the Classes card all stay with the one event, every
+event write path already goes through the row's triggers, and calendar feeds can still
+show the parts as separate series.
+
+### Server API
+
+```ts
+changeFromDate(repo, who, eventId, fromKey, { start, end?, rrule?, roomIds?, location?, note? }, ctx, { quiet? })
+  → { event, clashes, changed, rsvps: { moved, cancelled }, dropped }
+cancelFromDate(repo, who, eventId, fromKey, ctx, { quiet? })   // every date from it on, struck through
+restoreFromDate(repo, who, eventId, fromKey, ctx, { quiet? })  // undo that; RSVPs stay cancelled
+revertFromDate(repo, who, eventId, from, ctx, { quiet? })      // remove a change: the rule before it carries on
+```
+
+`who` is staff ("Create and edit content") or `GOOGLE_SYNC`. Room clashes at the new
+times (180 days ahead) come back in `clashes` as warnings. Hosts get 403
+`host-request`: they send `requestFromDate` instead (`npx acms docs server`). All are
+idempotent (`changed: false`). `quiet` skips the member push; the RSVP emails still go.
+A `fromKey` that a change took over from (no longer a date itself) means that change,
+so a sync can retry safely: the same change again is `changed: false`, whoever sends it
+and whenever. A change whose first date has started can't be replaced or undone
+(`started`), and neither can a cancelled part be restored once its dates have started.
+
+| status | code | when |
+|---|---|---|
+| 400 | `one-off`, `not-a-date`, `started`, `past`, `bad-time` | as for moves |
+| 400 | `first-date` | changing from the series' very first date (edit the event instead) |
+| 400 | `previous-date` | the new first date isn't after the date before the change |
+| 400 | `bad-rule` | a rule the calendar can't read, or a first date that isn't one of its dates |
+| 403 | `host-request` | a host: send it as a request |
+| 409 | `cancelled-event` | the whole event is cancelled |
+
 ## Rooms
 
 Rooms, people and equipment are **Resources** (Admin → Calendar → Rooms; they need
@@ -315,3 +430,75 @@ calendars in step, both ways, within a few minutes. The full guide is
   until "from this date on" exists.
 - Site code can read an event's Google copies with `googleCopies(repo, eventId)`, and
   Recent changes with `googleSyncHistory(repo)`.
+
+## Requests without an account
+
+`acms({ requests: true })` lets anyone ask for a new event, or for a change to one,
+without an account:
+
+- from the website's form at `/request` (and `/es/request` and so on);
+- from an app (`GET /api/v1/requests/options`, `POST /api/v1/requests`);
+- from the site's own form, through `submitRequest`.
+
+Staff answer them on **Calendar → Requests**. That one list also shows hosts'
+requests from My events. `requests: { path: '/ask' }` moves the form, and
+`requests: { page: false }` drops it but keeps the API and the admin. A site file at
+the form's path replaces it.
+
+Each request is a row of its own (`RequestRecord`), not an event:
+
+- `kind`:
+  - `'new'`: `data` has `type`, `title`, `start`, `end`, `repeat` (`once`, `weekly`
+    or `other` with `repeatText`), `roomIds`, `roomsUnsure` and `people`;
+  - `'change'`: `eventId`, plus `key` for one date (`''` = every date).
+- `state`: `pending`, `approved`, `declined` or `withdrawn`.
+- `source`: `app`, `web` or `member`.
+- `requester`: `{ name, email, phone, locale }`, for a person without an account.
+- `note`: their own words to staff.
+- `reply`: staff's last answer.
+
+Hosts' date moves (C3/C4) use the same table with kinds `move` and `from-date`.
+
+**Settings** (Calendar → Requests → Settings, in `settings.calendar.requests`):
+
+- **Open or closed.** Closed forms and apps say so and show the office phone; they never
+  disappear.
+- **Kinds.** Each has a label per language, plus the tag and calendar an approved
+  draft gets.
+- **Reply time and notice**, per language.
+- **Office phone.**
+- **Who hears about new requests.** Their email, else `members.notify`, else the owners.
+  Optionally a push to their linked phones, without names.
+- **A daily cap** on new requests (100), on top of 10 a minute and 20 a day per
+  address and 5 a day per email address.
+- **How long requests are kept** (180 days) after their answer, or after they
+  arrived if nobody answered. The scheduler deletes them then.
+
+**Rooms** people can choose are the ones marked **Anyone can check if it’s free**
+(`requestable`). The form's live "free then" line uses `GET /api/v1/rooms/free`, which
+says free or busy, never what or who.
+
+**Answering** (needs **Publish content**; reading the list needs **Create and edit
+content**):
+
+- **Approve** a new request: makes a draft that's already filled in. It has the
+  title and times, `FREQ=WEEKLY` when asked, the kind's tag and calendar (else the
+  default calendar), and the rooms held while it's a draft. The draft opens in the
+  editor. The person's details stay on the request, never on the event.
+- **Approve** a change: opens the event, or that date's Move… form
+  (`/admin/calendar/events/<id>?move=<key>`).
+- Both email the person, with an optional message, unless you untick it.
+- **Decline**, with an optional reason, and **Reply** email the person in the
+  language they asked in. A reply leaves the request as it is. **Delete as spam**
+  removes a request from the app or the website without emailing anyone.
+- Each row shows what takes its rooms then. Weekly requests are checked for 12
+  weeks.
+
+**Emails.** The person gets "We got your request" in their language. It never
+repeats what they typed (the title or message), so the form can't be used to send
+someone else a message, and each address gets at most 3 a day. Staff get every
+detail in the site's main language, with Reply-To set to the person.
+
+**Privacy.** The generated privacy notice gets an "Event requests" section, and
+the store answers list event requests under contact info and user content.
+Requests are in backups.

package/docs/mobile.md

@@ -114,7 +114,7 @@ Read the app's `AGENTS.md` too: it holds the same rules, next to the code.
 
 | Hook | For |
 | --- | --- |
-| `useSite()` | name, menu, languages, features (`calendar`, `bookings`, `rsvp`, `blog`, `search`, `bookingChanges`, `guestSignIn`, `forms`, `links`, `live`) |
+| `useSite()` | name, menu, languages, features (`calendar`, `bookings`, `rsvp`, `blog`, `search`, `bookingChanges`, `guestSignIn`, `forms`, `links`, `live`, `announcements`, `requests`) |
 | `usePage(slug)` | a published page: `mode` (`sections`/`content`), `sections`, `body.html`; 404 when missing |
 | `usePosts({ collection, limit, q })` / `usePost(slug)` | posts (infinite: `items`, `fetchNextPage`); `q` gives ranked search matches |
 | `useSearch(text, { types, collection, limit })` | site-wide search: `data.posts`, `data.pages`, `data.events` (each with `snippet.text` + `snippet.highlights`), `data.more`; debounced, blank text fetches nothing |
@@ -128,6 +128,7 @@ Read the app's `AGENTS.md` too: it holds the same rules, next to the code.
 | `useLive()` | live video: `snapshot`, `status` (`live`/`upcoming`/`offline`), `isLive`, localized `view` text, the owner's `display` choices (`style`, `bar`, `header`, `dock`). Polls every 30 s only in the foreground, rechecks on resume, drops an expired "live" even offline; idle while `features.live` is false. Render `<LiveCard>` / `<LiveTag>` |
 | `useResources()` / `useAvailability({ resource, link })` / `useBooking()` | bookings |
 | `useRoomFree({ room, start, end })` | bookings: is a requestable room free (no names) |
+| `useRequestOptions()` / `useSubmitRequest()` | event requests without an account (`features.requests`): the form's kinds, rooms, words and office phone (`open: false` = say so and show the phone, never hide the screen), and sending one with its own Idempotency-Key; `problem` and `field` say what to fix |
 | `useLocale()`, `useTheme()`, `useLayout()`, `useRefresh()`, `useOpenLink()` | language, tokens, layout, refresh, links |
 | `usePushRegistration({ topics })` / `usePushTopics()` / `useNewPushTopics()` / `useNotificationTaps()` | push notifications (see Push notifications); topic names come in the app's language |
 | `useAnnouncements({ kind, pinned })` / `useAnnouncement(id)` / `useAnnouncementState()` | announcements up right now; unread and closed banners kept on the phone (a dot, never a number); idle while `features.announcements` is false |
@@ -150,6 +151,7 @@ npx acms mobile recipe add news      # posts list, article
 npx acms mobile recipe add booking   # resources → slots → form → confirmation  (expo-crypto)
 npx acms mobile recipe add push      # notifications: turn on, topic toggles, taps open the page  (expo-notifications, expo-device)
 npx acms mobile recipe add announcements  # list with kind tabs and unread dots, detail, home banners (site needs announcements on)
+npx acms mobile recipe add event-request  # "Request an event" screen, a More row and an events-list link, no account (site needs requests on; expo-crypto, expo-secure-store)
 ```
 
 Each prints the `npx expo install …` line for its packages: run it (doctor

package/docs/server.md

@@ -18,6 +18,7 @@ import {
   withdrawEventRequest, approveEventRequest, declineEventRequest, setHostedOccurrence,
   moveHostedDate, moveHostedDateBack, requestDateMove, listMyDateRequests, withdrawDateRequest,
   approveDateRequest, declineDateRequest,
+  changeFromDate, cancelFromDate, restoreFromDate, revertFromDate, requestFromDate,
 } from '@acms-subir/core/server';
 ```
 
@@ -38,6 +39,10 @@ cancelOccurrence(repo: Repo, eventId: string, occurrenceKey: string, ctx: WriteC
 restoreOccurrence(repo: Repo, eventId: string, occurrenceKey: string, ctx: WriteContext): Promise<CalEvent>
 moveOccurrence(repo: Repo, who: ServerUser | null | typeof GOOGLE_SYNC, eventId: string, occurrenceKey: string, input: MoveInput, ctx: WriteContext, opts?: { quiet?: boolean }): Promise<MoveResult>
 moveOccurrenceBack(repo: Repo, who: ServerUser | null | typeof GOOGLE_SYNC, eventId: string, occurrenceKey: string, ctx: WriteContext, opts?: { quiet?: boolean }): Promise<MoveResult>
+changeFromDate(repo: Repo, who: ServerUser | null | typeof GOOGLE_SYNC, eventId: string, fromKey: string, input: ChangeFromInput, ctx: WriteContext, opts?: { quiet?: boolean }): Promise<ChangeFromResult>
+cancelFromDate(repo: Repo, who: ServerUser | null | typeof GOOGLE_SYNC, eventId: string, fromKey: string, ctx: WriteContext, opts?: { quiet?: boolean }): Promise<ChangeFromResult>
+restoreFromDate(repo: Repo, who: ServerUser | null | typeof GOOGLE_SYNC, eventId: string, fromKey: string, ctx: WriteContext, opts?: { quiet?: boolean }): Promise<ChangeFromResult>
+revertFromDate(repo: Repo, who: ServerUser | null | typeof GOOGLE_SYNC, eventId: string, from: string, ctx: WriteContext, opts?: { quiet?: boolean }): Promise<ChangeFromResult>
 eventRoomClashes(repo: Repo, event: string | CalEvent, opts?: { horizonDays?: number; now?: Date | number }): Promise<EventClash[]>
 roomBusy(repo: Repo, q: { roomIds: string[]; from: Date | number; to: Date | number; ignore?: { eventId: string; key?: string } }): Promise<BusySlot[]>
 
@@ -61,11 +66,22 @@ setHostedOccurrence(repo: Repo, who: ServerUser | null, eventId: string, occurre
 moveHostedDate(repo: Repo, who: ServerUser | null, eventId: string, occurrenceKey: string, input: MoveInput, ctx: WriteContext): Promise<HostMoveResult>
 moveHostedDateBack(repo: Repo, who: ServerUser | null, eventId: string, occurrenceKey: string, ctx: WriteContext): Promise<HostMoveResult>
 requestDateMove(repo: Repo, who: ServerUser | null, eventId: string, occurrenceKey: string, input: MoveInput | null, message: string, ctx: WriteContext): Promise<RequestRecord>
+requestFromDate(repo: Repo, who: ServerUser | null, eventId: string, fromKey: string, input: Omit<ChangeFromInput, 'location'>, message: string, ctx: WriteContext): Promise<RequestRecord>
 listMyDateRequests(repo: Repo, who: ServerUser | null, eventId?: string): Promise<RequestRecord[]>
 withdrawDateRequest(repo: Repo, who: ServerUser | null, requestId: string): Promise<void>
-approveDateRequest(repo: Repo, who: ServerUser | null, requestId: string, ctx: WriteContext, seen?: number): Promise<{ request: RequestRecord; moved: MoveResult }>
+approveDateRequest(repo: Repo, who: ServerUser | null, requestId: string, ctx: WriteContext, seen?: number): Promise<{ request: RequestRecord; moved?: MoveResult; changed?: ChangeFromResult }>
 declineDateRequest(repo: Repo, who: ServerUser | null, requestId: string, reply: string, ctx: WriteContext, seen?: number): Promise<RequestRecord>
 
+// requests without an account (acms({ requests })): asking needs no account; listing needs
+// content.edit, answering content.publish
+requestOptions(repo: Repo, locale?: string): Promise<{ open: boolean; types: { id: string; label: string }[]; rooms: { slug: string; name: string; color: string }[]; replyTime: string; notice: string; phone: string; timezone: string; events: { slug: string; title: string; dates: string[] }[] }>
+submitRequest(repo: Repo, input: RequestInput, opts: { key: string; address: string; context: WriteContext }): Promise<{ id: string; created: boolean }>
+listRequests(repo: Repo, who: ServerUser | null, q?: { states?: RequestState[]; kinds?: RequestKind[]; sources?: RequestSource[]; eventId?: string; userId?: string; order?: 'oldest' | 'newest' | 'decided'; limit?: number; offset?: number }): Promise<RequestRecord[]>
+approveRequest(repo: Repo, who: ServerUser | null, id: string, ctx: WriteContext, seen?: number, opts?: { message?: string; email?: boolean }): Promise<{ request: RequestRecord; event: CalEvent | null; next: string }>
+declineRequest(repo: Repo, who: ServerUser | null, id: string, reason: string, ctx: WriteContext, seen?: number, opts?: { email?: boolean }): Promise<RequestRecord>
+deleteRequest(repo: Repo, who: ServerUser | null, id: string): Promise<void>
+replyToRequest(repo: Repo, who: ServerUser | null, id: string, message: string, ctx: WriteContext): Promise<RequestRecord>
+
 type Role = 'owner' | 'administrator' | 'editor' | 'author' | 'contributor' | (string & {})
 interface ServerUser { id: string; email: string; name: string; role: Role; staff: boolean; can(permission: string): boolean }
 interface Occurrence { event: CalEvent; start: number; end: number; allDay: boolean; days: number; key: string; cancelled: boolean; roomIds: string[]; moved?: { from: { start: number; end: number }; note: string; location?: EventLocation } }
@@ -74,6 +90,9 @@ interface MoveResult { event: CalEvent; clashes: BusySlot[]; changed: boolean }
 type HostMoveResult = { moved: MoveResult } | { request: RequestRecord }
 interface RequestRecord { id: string; kind: 'new' | 'change' | 'move' | 'from-date'; state: 'pending' | 'approved' | 'declined' | 'withdrawn'; source: 'member' | 'web' | 'app'; userId: string; requester: { name: string; email: string; phone: string; locale: string } | null; eventId: string; key: string; data: Record<string, unknown>; note: string; reply: string; reviewedBy: string; reviewedAt: number; createdAt: number; updatedAt: number }
 interface MoveRequestData { start: string; end: string; roomIds?: string[]; note: string; back?: boolean }
+interface FromDateRequestData { start: string; end: string; rrule: string; roomIds?: string[]; note: string }
+interface ChangeFromInput { start: string; end?: string; rrule?: string; roomIds?: string[]; location?: Partial<EventLocation> | null; note?: string }
+interface ChangeFromResult { event: CalEvent; clashes: BusySlot[]; changed: boolean; rsvps: { moved: number; cancelled: number }; dropped: string[] }
 interface Hold { resourceId: string; eventId: string; key: string; title: string; start: number; end: number; eventStart: number; eventEnd: number }
 interface EventClash { hold: Hold; other: Hold }
 interface BusySlot { resourceId: string; start: number; end: number; kind: 'event' | 'booking' | 'block' | 'calendar'; title: string; eventId?: string; key?: string; bookingId?: string }
@@ -177,6 +196,29 @@ full table is in `npx acms docs calendar`).
 `npx acms docs calendar` has the details: what follows a moved date, how it shows,
 and the error statuses.
 
+## From this date on
+
+- **`changeFromDate(repo, who, eventId, fromKey, input, ctx, opts?)`**: changes a repeating
+  event from one of its dates (`fromKey`, an occurrence key) on. `input.start` is the new
+  first date, wall-clock in the event's timezone. It may come before `fromKey` but has to
+  come after the date before it. `end` defaults to the dates' length, `rrule` to the rule
+  in effect on the new weekday (`''` = just that date), and `roomIds` / `location` to
+  what's in effect there. Dates before it stay exactly as they were. RSVPs, cancelled,
+  skipped and moved dates follow to the new date nearest them within half a week. RSVPs
+  with no new date are cancelled, and `dropped` lists the other dates that had none.
+  `clashes` lists what else holds the new rooms over the next 180 days.
+- **`cancelFromDate(...)`** / **`restoreFromDate(...)`**: cancel every date from one on
+  (they stay listed, struck through) and undo that.
+- **`revertFromDate(repo, who, eventId, from, ctx)`**: removes the change that took over
+  at `from`.
+
+All four check `who`: staff ("Create and edit content") or `GOOGLE_SYNC`. A host gets 403
+with code `host-request` and sends **`requestFromDate`** instead (rooms among the event's
+own and the requestable ones). Staff answer it with `approveDateRequest` /
+`declineDateRequest`. All of these are idempotent (`changed: false`), and a `fromKey` that a
+change took over from means that change. The changes are stored on the event as
+`segments`. `npx acms docs calendar` has the rules and the error codes.
+
 ## Rooms
 
 Events hold rooms (`event.roomHold.resourceIds`, the Rooms box in the event editor)
@@ -460,3 +502,44 @@ if (Astro.request.method === 'POST') {
 
 `/classes/mine` would list `listMyEvents(repo, me)` and show `e.request?.state`
 (`'pending'`, `'declined'` with `e.request.reply`, or no request once approved).
+
+## Requests without an account
+
+With `acms({ requests })`, anyone can ask for an event or a change to one (see `npx
+acms docs calendar`). The built-in form at `/request` and `POST /api/v1/requests` use
+these functions, and so can a site's own form:
+
+- **`requestOptions(repo, locale)`**: whether requests are open, the kinds, requestable
+  rooms and the events a change can be about (with their next dates), and the site's
+  reply time, notice and phone, in that language.
+- **`submitRequest(repo, input, { key, address, context })`**: `input` is the same as
+  the API body (`kind: 'new'` or `'change'`, `name`, `email`…). `key` is a random UUID v4
+  your page keeps for this form, so a double submit stores one request. `address` is
+  `Astro.clientAddress`, for the 10-a-minute limit. Refusals throw with a `status` and a
+  `code` (`RequestRefusal`: `title`, `start`, `past`, `room`, `email`, `closed`,
+  `busy`…). Show your own words for each code.
+- **`listRequests(repo, who, q)`**: for staff (`content.edit`). `states: ['pending']`
+  comes oldest first.
+- **`approveRequest`**, **`declineRequest`** and **`replyToRequest`** answer one (`content.publish`) and
+  email the person in their language (approve and decline take `email: false` to stay quiet).
+  **`deleteRequest`** removes spam from the app or the website without an email. Pass `seen` (the `updatedAt` you showed) and an
+  edited request answers 409 instead.
+
+```astro
+---
+// src/pages/ask.astro: the site's own request form
+import { getRepo, submitRequest } from '@acms-subir/core/server';
+const repo = await getRepo(Astro.locals);
+let done = false, problem = '';
+if (Astro.request.method === 'POST') {
+  const f = await Astro.request.formData();
+  try {
+    await submitRequest(repo, {
+      kind: 'new', title: String(f.get('title')), start: `${f.get('date')}T${f.get('from')}`, end: String(f.get('to')),
+      name: String(f.get('name')), email: String(f.get('email')),
+    }, { key: String(f.get('key')), address: Astro.clientAddress, context: { url: Astro.url, locals: Astro.locals } });
+    done = true;
+  } catch (e) { problem = (e as { code?: string }).code ?? 'failed'; }
+}
+---
+```

package/integration.mjs

@@ -448,6 +448,20 @@ function resolveMembers(members, calendar) {
   // the built-in pages are "My events": they need the calendar
   return { enabled: calendar.enabled, base, notify: notify.map((e) => e.trim().toLowerCase()), hostMoves };
 }
+function resolveRequests(requests, calendar, reserved) {
+  if (requests === undefined || requests === false) return { enabled: false, path: '/request', page: true };
+  if (requests === true) requests = {};
+  if (!requests || typeof requests !== 'object' || Array.isArray(requests)) throw new Error('acms: requests must be true, false or an object');
+  unknownKeys('requests', requests, ['path', 'page']);
+  const path = requests.path ?? '/request';
+  if (typeof path !== 'string' || !/^\/[a-z0-9-]+(\/[a-z0-9-]+)*$/.test(path)) {
+    throw new Error(`acms: requests.path must start with "/" and use lowercase letters, digits, and hyphens (no trailing slash) — got "${path}"`);
+  }
+  if (RESERVED_BASES.has(path) || reserved.includes(path)) throw new Error(`acms: requests.path "${path}" collides with another route — pick another path`);
+  if (requests.page !== undefined && typeof requests.page !== 'boolean') throw new Error('acms: requests.page must be true or false');
+  // requests become calendar events: they need the calendar
+  return { enabled: calendar.enabled, path, page: requests.page ?? true };
+}
 function resolveAnnouncements(announcements, reserved) {
   if (announcements === undefined || announcements === false) return { enabled: false, base: '/announcements', pages: true, topics: {} };
   if (announcements === true) announcements = {};
@@ -713,6 +727,14 @@ function acmsVitePlugin(userConfig) {
  *   `topics` picks the push topic each kind starts with in the composer, e.g.
  *   `{ registration: 'registrations', help: 'help' }` (otherwise a topic named
  *   after the kind, such as `events` or `help`, else everyone).
+ * @param {boolean | {path?: string, page?: boolean}} [options.requests]
+ *   Event requests without an account (off by default; needs the calendar):
+ *   anyone asks for a new event or a change to one from the app
+ *   (GET /api/v1/requests/options, POST /api/v1/requests) or the website's
+ *   form (default path '/request', also under each language's prefix). Staff
+ *   answer them on Calendar → Requests, where approving makes a filled-in
+ *   draft event. `page: false` keeps the API and the admin but drops the
+ *   built-in form, so a site can build its own on the same server API.
  * @param {string[]} [options.signedRoutes]
  *   The site's own routes that receive posts from another server and check
  *   its signature themselves (an SMS or payment provider's webhook), as route
@@ -741,6 +763,7 @@ export default function acms(options = {}) {
     if (clash) throw new Error(`acms: members.base "${members.base}" collides with another configured path — pick another`);
   }
   const announcements = resolveAnnouncements(options.announcements, [...contentBases.keys(), ...(calendar.enabled ? [calendar.base, calendar.eventsBase, calendar.bookBase] : []), ...(members.enabled ? [members.base] : [])]);
+  const requests = resolveRequests(options.requests, calendar, [...contentBases.keys(), ...(calendar.enabled ? [calendar.base, calendar.eventsBase, calendar.bookBase] : []), ...(members.enabled ? [members.base] : []), ...(announcements.enabled ? [announcements.base] : [])]);
   const roles = resolveRoles(options.roles, members);
   const permissions = resolvePermissions(options.permissions, roles);
   const maps = resolveMaps(options.maps);
@@ -771,6 +794,7 @@ export default function acms(options = {}) {
     permissions,
     members,
     announcements,
+    requests,
   };
   const routes = [...ROUTES,
     ['/api/v1/site', 'api/v1/site.ts'],
@@ -942,6 +966,16 @@ export default function acms(options = {}) {
     );
     if (announcements.pages) routes.push([announcements.base, 'announcements/index.astro'], [`${announcements.base}/[id]`, 'announcements/[id].astro']);
   }
+  // event requests from people without an account (acms({ requests })): the
+  // app API, Calendar → Requests and, unless page: false, the public form
+  if (requests.enabled) {
+    routes.push(
+      ['/admin/calendar/requests', 'admin/calendar/requests.astro'],
+      ['/api/v1/requests', 'api/v1/requests/index.ts'],
+      ['/api/v1/requests/options', 'api/v1/requests/options.ts'],
+    );
+    if (requests.page) routes.push([requests.path, 'request/index.astro']);
+  }
   // "My events" for signed-in members (acms({ members })): thin pages over
   // lib/calendar/requests.ts. A site file at any of these paths replaces that
   // page; `members: false` drops them all (members.enabled needs the calendar).

package/mobile-template/client/AGENTS.md

@@ -78,6 +78,7 @@ npx acms mobile recipe add news      # posts list and article
 npx acms mobile recipe add booking   # resources → slots → form → confirmation
 npx acms mobile recipe add push      # notifications: turn on, topics, taps (site needs push on)
 npx acms mobile recipe add announcements  # list, detail, home banners (site needs announcements on)
+npx acms mobile recipe add event-request  # Request an event: screen, More row, events-list link (site needs requests on)
 ```
 
 Each recipe prints the extra Expo packages to install (`npx expo install ...`).

package/mobile-template/client/README.md

@@ -28,7 +28,7 @@ site) and `.env.local` (written by `acms mobile dev`, not committed).
 ## Add screens
 
 ```sh
-npx acms mobile recipe add events   # also: news, booking, push, rsvp, announcements
+npx acms mobile recipe add events   # also: news, booking, push, rsvp, announcements, event-request
 ```
 
 Build your own with the hooks from `@acms-subir/native`. `AGENTS.md` has the