#133: adding a CardDAV address book failed on Save Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
CardDAV write-back: a new internals page, and correct the pages it made wrong The write half carries as much detail as the read half - surgical vCard editing, the escaping trap, UTF-8-aware folding, the three-way merge, the permission probe - and appending it to the developer guide would have buried the transport that guide exists to explain. So: CardDAV-Write-Back-Internals, linked from the five related pages and the sidebar. Corrected where the build made an existing page wrong: - CardDAV-Contact-Sync: "What this does not do / It does not write back" was the headline claim and is now false. Replaced with what write-back changes, what it never touches, and what happens when two people edit the same detail. - CalDAV-and-CardDAV: step 5 is done. Predictions kept rather than deleted and marked against the outcome - the conflict rules were the real cost as called, "precedence" was the wrong frame, and the feedback S10 named as most likely to move it is not what moved it. - Contact-Details: the Article 16 argument is now only PARTLY answered, and says which part. Write-back sends an analyst's edit; a customer's own portal correction is still refused on an imported contact. - CardDAV-Import-Internals: warns that the import records source_ref and source_etag for the write-back.
CardDAV contact sync: user page and two developer guides New: CardDAV-Contact-Sync (the administrator's view), and the developer guide split in two because there was too much for one page - the transport half covers auth, PROPFIND/REPORT and vCard parsing; the internals half covers scope resolution, the run lifecycle, the counts bug, the exit-code bug and the Docker test rig. Updates what the work made wrong rather than only adding pages: - CalDAV-and-CardDAV said the protocol work was parked. The transport is built; the write-back and CalDAV are what remain. Sections 8, 9 and 10 rewritten to match, including the honest note that the demand argument never changed - only the cost estimate did, and only because reading the policy layer showed it had no LDAP in it. - Contact-Details said there were three ways a person's details get filled in, and that the fields were worth having "whether or not FreeITSM ever speaks CardDAV". There are four ways, and it does. - _Sidebar gains the three pages, alongside LDAP as a people source. Also corrects two citations I got wrong: both the estimate and the test-fixture prediction are CalDAV-and-CardDAV section 5, not Extending-Directory-Sync section 2.