Calendar

The calendar shows event threads by day. An event is an ordinary thread whose root carries an event date; the calendar adds no record family of its own. It needs event support (FORUM_EVENT_SUPPORT_ENABLED); while that is off, the calendar pages say so and link to Feature Flags.

Pages

A path segment shaped like YYYY-MM-DD is always a day; anything else is a tag.

On a wide screen each day lists up to three events by title and author, then +N more. On a phone each day shows only how many events it has; the day page has the titles. A day with no events is empty, a day with any unsettled event is open, and a day with a confirmed event is marked confirmed. Declined events do not appear on the calendar but stay in their thread.

The calendar has no navigation entry; reach it by its link.

Adding an event

Open a day and post. The composer is the one used everywhere else, with the day already set as the event's date and, on a tag calendar, that tag already set. Fill in the last day under Until for a multi-day event; leave it empty for one day. Time, Place and Link are optional. A post that is refused keeps its draft and shows the reason, as on /compose/thread.

Events can also be posted from /compose/thread (open Event) or through the agent API (events).

Confirming or declining

A root-approved operator settles an event by writing a line on its own in any post of the event's thread, the root included:

event: confirmed

or event: declined. The latest such line from a current operator decides; quoted lines (> event: confirmed) never count, and lines from anyone else are ordinary text. The state covers the whole span; there is no partial confirmation. The thread page shows Event: confirmed or Event: declined under the title. To record something arranged elsewhere, an operator can post the event with the line in the same post.

The state is worked out from the posts each time a page is read, so a rebuild or a retracted post changes it without anything else to update. A line counts only while its post is not retracted, its attribution is verified, and its author is still an approved, unretired operator.

Access

Calendar pages are ordinary pages. On a members-only instance they need an approved viewer like every other page: a signed-in member who is not yet approved is sent to the Lobby and can come back once approved, and a signed-out visitor gets the usual sign-in or Lobby page (access modes). On a public instance they are public, like the threads they show. Every viewer receives the same markup.

Records and storage

Event-End-Date is an optional root header described in the post record spec; a release that predates it reads such an event as one day. The read model stores it in threads.event_end_date (schema 49).