Enter events by hand

Manual entry is a collection method. An event typed into the admin is governed exactly like one fetched from a provider: the feed's published contract decides which fields exist, the same validation runs, and QuickLookup writes the same row to the same place. Nothing about the event says it was typed.

Use it for the events only a person knows — an internal calendar, a venue's programme, a correction a provider has not published yet.

Who may write

• The feed's own editors — anyone holding editor or above on the account that owns it.
• Every @snjallgogn.is identity, for any account, as an internal catalogue manager.

A viewer sees the feed and its events and cannot open the form.

Which feeds accept written events

A feed takes hand-written events once it has an active published revision and a source binding with mode stored. An externally sourced feed does not: its provider would overwrite the event on the next fetch, so the page says so instead of letting you lose work.

Open the form

From the feed: Event feeds → the feed → Manage events. From a query: run the feed in the console and use Edit or Duplicate on any result.

The page lists the feed's events, newest start first, with a search over name, venue and description.

What the form shows

Exactly what the feed publishes, and nothing else:

• every canonical event field the collection declares, plus the fields every event has — name, type, start, end, all-day; the venue, address and coordinates are the event's first place (its epicenter), and More places below them holds every other place a happening takes place at — a promotion in seven stores is one event with seven places, each with a role, a name, a town, coordinates and, when known, the id the source knows it by;
• its declared metrics and dimensions, with required ones marked;
• the flags the feed already uses, as a row of toggle chips rather than a list of checkboxes, named readably (is_free_event reads as "Free event"; the exact key is in the chip's tooltip).

What the collection owns is never shown and never editable: the feed identity, the catalog revision, the access classification, the owning account and the row version. Those are what make the row part of this feed, and the server writes them. If the feed publishes a single event type, the type is not asked either — it is already decided.

What the form already knows

A new event does not start empty. It opens with the values this feed is actually consistent about — a value is only offered when it covers at least half the feed's events, so a prefilled box is one you would have filled the same way. Whatever you last entered in this feed wins over the feed's average. What happened is never guessed: the name is always yours to write.

The end time is offered as a length rather than a second clock reading — 30 min, 1 h, 90 min, 2 h, 3 h, with this feed's own usual length marked. Move the start and the end follows.

The cursor starts in the name, and ⌘/Ctrl + Enter saves.

Repeating an event

Most events in a real feed are a repeat of one already there, usually a day or a week later. Every row offers Repeat — next day, next week, +14 days, +28 days — which copies the event forward and keeps its length. The copy is its own event with its own identity, so correcting one never touches the other. Use Duplicate instead when you want to edit the copy before saving it.

Lookups

The form offers what the feed already holds, most-used first: venue, sub-type, tags, town, country, timezone, and every declared text dimension. Picking a known venue fills in its address, town, postal code, coordinates and timezone — only the boxes you left empty, never anything you typed.

For a venue the feed has never seen, Look up address resolves it through the CTX geocode source (Nominatim) and fills in the same fields. Its coverage is whatever OSM data the cluster holds, which today is Iceland.

Correct, cancel, remove

Action	What happens
Save changes	The event is replaced. Same identity, newer version — a correction never leaves a second event behind.
Cancel	status becomes cancelled. The event stays in the feed and consumers see it was called off. This is what "it is not happening" means.
Delete	The event is removed outright, for every consumer, and cannot be undone. It stops being served within about a minute — ClickHouse applies the removal in the background, so the page does not wait for it. This is for a mistake, not for a cancellation.

Cancel is offered only when the feed publishes a status field — without one, a feed has no way to say an event was called off.

Save and add another keeps the venue, type and times of the event you just saved, so a run of similar events is a name and a time each.

Recurring events

Occurrences are stored one by one, and this form writes one occurrence. Where a feed publishes them, the recurrence fields (eventSeriesGid, recurrenceId, recurrenceRule, recurring) are yours to fill in and are preserved, but nothing expands a rule into occurrences and there is no series-level edit. Use Duplicate for the next one.

The same thing over the API

The page posts to the admin, but it writes through the same contract and the same writer as these endpoints, so anything done here can be done — and automated — over the API:

Action	Request
Add or correct	POST /v1/event-collections/{collectionGid}/events
Read one	GET /v1/event-collections/{collectionGid}/events/{eventGid}
Remove one	DELETE /v1/event-collections/{collectionGid}/events/{eventGid}
Lookup values	GET /v1/event-collections/{collectionGid}/events/values?field=venue

values answers with the values the feed already uses and how often — field is a canonical event field or dimension:<key>. Cancelling is not its own call: write the event back with "status": "cancelled".