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 full troubleshooting page, and correct what the work made wrong
The four operational additions - failure reporting, the write log, D015 and
D016 - were compressed into two sections of the internals page. That page is
written for somebody changing the code; the reader who needs this is somebody
whose write-back is not working. Ed asked for them in proper depth, and he was
right that they had not had it.
New: CardDAV write-back - when it goes wrong
- the guarantee first: an analyst's edit is never lost, which is why every
message opens with "Saved here, but..."
- the asymmetry that shapes the whole design, stated as a table: a bad import
damages our copy and is recoverable, a bad write-back damages the operator's
address book and is not
- all four results, what each means, and what to do - including why Refused is
the safety net working and not a fault to be cleared
- the Digest trap on its own, with the measured numbers, because a stock Baikal
answers Basic with a 401 that looks exactly like a wrong password
- reading the log, including why the server's raw response is kept verbatim and
is the thing to forward to whoever runs the server
- D015 rung by rung, with what a failure at each rung actually implies
- D016 section by section, why there is no "fix it" button, and the trap it
reveals: drift is what makes a later write-back get refused
- a symptom-to-where-to-look table
- what is deliberately not automatic, since each is a thing people ask for
Corrected where the build had made a page wrong from a distance:
- Contact-Details still said all seven fields lock on any managed record. Now a
table of three cases, including that write-back unlocks them entirely, with
the permanently-unfillable-fields bug named rather than quietly fixed.
- System.md promised a fixed 4s toast dismiss, and its debug tools list stops at
D004 - ten tools never written up. D015 and D016 added; the gap is not
backfilled but the page now says so and names the registry as the only source
of truth. A list that looks complete and is not is worse than one that admits
it.
CardDAV write-back: what happens when it fails, and the two diagnostics
Three sections that were missing because the operational half of write-back
did not exist yet:
- What happens when it fails - the analyst is always told, a dead server costs
seconds rather than the form, and every attempt is logged with the server's
own response verbatim. Plus why "refused" is coloured as a warning and not a
fault: it is the safety net working.
- The two Debug Tools, and which question each answers. D015 walks the
connection one rung at a time and names the write-back-on-with-no-permission
mismatch; D016 is the top-to-bottom compare, and is also how to answer the
"which details actually drift" question the reporter never did.
- A note that the write log is deleted explicitly rather than by the foreign
key, because Database Verify creates tables without constraints.
The user-facing page gets the same in plain language, including a table of what
each outcome in the log means.
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.