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
the screens could show a calendar and an address book and change neither. this
adds a pencil and a bin to every event and every card, with a confirm on the bin.
three things worth defending.
THE HREF IS THE ADDRESS, and the listing now carries it. it used to return only
the object's data, which is enough to show something and not enough to change
it. deriving `<uid>.ics` was the obvious shortcut and is wrong: a .ics filename
only conventionally matches the uid — radicale stores what the writing client
chose — so it works for everything officer wrote and misses everything a phone
did. proved immediately: this machine's own calendar holds
62970EC7-47B1-4214-858E-85C32C2476A5.ics, written by an iphone.
READ, PATCH, PUT — NEVER REBUILD. an event is a file with far more in it than
these screens show: alarms, attendees, RRULEs, every X- property. rebuilding it
from the fields on screen would silently drop all of that, and an edit that
quietly deletes half an event is worse than no editing. so a save reads the
original text, replaces only the lines it owns, and puts the whole file back.
verified on a real event: 22 lines before, 22 after, one changed.
THE EDITOR IS DELIBERATELY SMALL. title and place for an event, name/email/phone
for a card. times and recurrence are where an editor does damage, and a
half-editor that rewrites an RRULE it does not understand is the thing this
avoids. `setProperty` also escapes commas, semicolons and newlines, because a
raw comma silently splits an iCalendar TEXT value into parts.
the sidecar grew GET/PUT/DELETE on /_officer/item, above the `collection is
required` guard — they take an href rather than a collection, and sitting below
it they answered 400 forever. both check the href is inside this user's own tree
even though X-Remote-User already scopes radicale: an href from a request body
is attacker-shaped input either way.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
pastilhasandClaude Opus 5