Wiki catches up with 2.1.0: portal profile, sources, adding contacts, calendar connections - Contact details developer guide: Portal profile settings, portalProfileAccess(), push-first portal edits, tests, Source helpers, userSignsInElsewhere() - CardDAV write-back internals: s16 portal edits, s17 adding a contact - CardDAV developer guide: new files and columns - Self-Service Portal, Tickets, Asset handover, System, Scheduled tasks 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: correct the reused-function count I had claimed five policy-layer functions were reused. The import calls ten and nine are used exactly as the LDAP path uses them; only syncBrakeTripped() changed, and only by gaining an optional parameter that leaves the LDAP defaults alone. The original figure undersold how little new policy this needed, which was the whole point of the section.
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.