master
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  pastilhasandClaude Opus 5
|
b578c2aa3b |
2026.08.27.03 — a filter on both screens
a calendar of a few hundred events and an address book of a few hundred cards are both lists you scroll until you give up. one box on each header narrows them. CLIENT SIDE, because the data is already here: both screens fetch a whole collection in one request and hold it, so filtering is a string comparison over what is in hand. a round trip per keystroke would be slower, would need a search endpoint on the sidecar, and would put a spinner where a person expects a list to narrow as they type. ACCENT-INSENSITIVE, and that is the half that decides whether this is usable here: these contacts are portuguese, and a box where "jose" does not find "José" is a box nobody uses twice. NFD splits the letter from its accent and the range strips what is left, so it matches in both directions — "josé" finds "Jose" too. every term must match somewhere, not all in one field, so "ana lisboa" finds the ana whose address is in lisbon. events match on their start as well, which is an ISO string, so "2026-08-29" narrows to a day without anything having to parse it. the count in the header becomes "12 of 340" while filtering, and a filter that matches nothing says so by name — otherwise it reads as a calendar that lost its events. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
43cb531dc2 |
one CRUD, three callers — the browser and the agent stop writing iCalendar
the skill told an agent how to hand-write a .ics: escape the commas, fold at 75 octets, CRLF, DTSTAMP is required, and DTEND is the day after. all true, all silent when wrong, and the browser had learned the same lesson separately in its own copy of the code. this makes the sidecar the only thing that knows the format, and gives everyone else fields. WHAT WAS MISSING BEFORE THE SKILL COULD CHANGE. reading was already JSON, and create-event landed this morning. this adds PATCH /_officer/item — change some fields of an event or a card — and POST /_officer/contact. delete already worked. with those the skill has no reason left to mention iCalendar, so it does not. PATCH IS READ-PATCH-PUT, SERVER SIDE. it reads the stored text, replaces only the lines it owns, and puts the whole thing back, so alarms, attendees, RRULEs and every X- property a phone invented survive an edit made from a form that cannot show them. that logic came out of the browser, where it had needed a duplicate of the escaping and folding rules to live; the agent would have been a third copy in bash. the web bundle now contains no iCalendar literals at all. AND LIVE TESTING FOUND THE BUG THAT MATTERS. an event with a TZID is stored with a VTIMEZONE block beside it, and that block has DTSTART lines of its own — the rule for when summer time starts. taking the first DTSTART in the file rewrote the TIMEZONE DEFINITION, left the event where it was, and answered ok. the calendar showed the old time and the file was quietly corrupt. every write is now confined to the first VEVENT or VCARD, and the file that caught it is a test. three more traps handled rather than documented: a patch that reuses an all-day event's stored DTEND must subtract the exclusive day first or the holiday drifts every time the title is edited; moving a timed event must DROP a stale TZID rather than preserve it, because a TZID and a Z together are a contradiction clients resolve by moving the event; and a move bumps SEQUENCE, which is how a phone tells an update from a duplicate. contacts got the create form the calendar had, so both screens now do all four. editing a card sends the other emails and phones back untouched — the form shows the first of each, and sending only that would delete the rest. 47 tests across the writer and the patcher. verified live against a real event carrying an alarm, an attendee, an RRULE and an X- property: all four intact after a rename, a relocation and a move to a different day. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
785e5f9eed |
edit and delete, on both screens
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
|
dcbc9b102c |
calendar and contacts, extracted from the officer platform
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 |