three small things, one of which turned out to be a bug in what shipped an hour
ago.
CREATE. a POST to /_officer/event, and the SIDECAR builds the file — the browser
sends title, when and where. a UID, a DTSTAMP and a UTC timestamp each have
exactly one correct form, and that belongs next to the parser that reads them
back, not in a react component. it writes the minimum a VEVENT can legally be:
no recurrence, no alarms, no attendees. this app cannot show those, and a field
the list cannot display is a field that silently disappears on the next edit.
times go in as UTC. the alternative is DTSTART;TZID plus a VTIMEZONE block
defining that zone's rules, and a subtly wrong VTIMEZONE moves an event by an
hour twice a year. UTC needs no definition and every client renders it local.
all-day is the other trap: RFC 5545 makes DTEND EXCLUSIVE, so a one-day event on
the 29th ends on the 30th — write the 29th and some clients draw nothing at all.
the form takes the last day a person means and the builder adds the day.
NEWEST DAY ON TOP. a calendar accumulates years, so ascending opened on whatever
was imported first and this week was a scroll away. within a day the order stays
chronological, because that is what a day is.
?collection=ra-guide, NOT ?collection=%2Fdav%2F1%2Fra-guide%2F. the path is
/dav/<userId>/<name>/, so the escaped form spent six characters on slashes to
say `ra-guide` and put the owner's user id in a URL people paste at each other.
the name is unique within a user, which is all a selector needs, and the full
path is recovered from the collections list the screen already loaded. a full
path in the param still resolves, because somebody's bookmark has one.
AND THE BUG. setProperty replaced a property's first line and left its
continuation lines behind. a value over 75 octets is FOLDED onto lines starting
with a space — so editing a long summary left the old tail folded onto the new
value, and each edit inherited the last one's ending. it only bites on long
values, which is why the first round of testing missed it. the fix consumes the
whole folded run and folds what it writes; both are now under test, including
the accent-near-the-boundary case that a naive slice(0,75) cuts in half.
verified live: both event shapes written and read back, escaping round-tripped,
and a long summary edited twice with no accumulation.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
one sidecar, one permission, one install — and two screens, because Calendar and
Contacts are two places you go rather than two sections of one page. the first
plugin to declare `screens`, which the platform gained for this.
what moved: the radicale sidecar, the four routers, the panel apps, the
app-password table and the settings form. the form became a modal on the
calendar screen — a plugin ships panels and cannot contribute a settings
section, which is the same wall the email plugin hit and the same answer.
the routes are /calendar and /contacts, not /caldav/calendar. they were core
routes and keeping them is not cosmetic: a bookmark, a dock tile someone
arranged, and a persisted layout all address them. only a first-party plugin may
choose its own segment; a third-party one is confined to /p/<publisher>/.
four paths outside /api come with it, above the account gate, because phones are
not browsers: DAVx5, iOS and thunderbird send HTTP basic on every request and
have nowhere to put a JWT. that is not "open" — the sync door demands a scoped
app password and resolves it to one user before radicale sees anything.
two things deliberately unchanged. the table is still dav_app_passwords, not
caldav_app_passwords: installs hold real rows and a naming convention is not
worth a data migration on a live machine. and the panel names still resolve
through the platform's catalogs, so the six locales they had as core screens
survive rather than dropping to english to make the refactor tidier.
per-user was already true and is worth writing down because the config said
otherwise: the sync door resolves an app password to an account, tells radicale
that id is the principal, and owner_only does the rest. the comment claiming
"the owner is the only principal that exists" had been stale since multi-user
landed on 2026-08-07.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
pastilhasandClaude Opus 5