Remember an added address book when the server will not #103

New Issue

Closed

opened 2026-08-27 19:06:32 +00:00 by jcoffey-dev · 0 comments

jcoffey-dev commented

2026-08-27 19:06:32 +00:00

Owner

You are not allowed to modify this address book.

That's Stalwart's answer to a sharee subscribing to a book shared read-only, and it's a fair one: isSubscribed lives on the collection rather than on the reader, so adding one is a write to the owner's account. The identical write on a shared calendar is accepted. The difference is the server's, not ours.

The arrangement

The flag is still asked for first — a preference the server holds is one every client agrees about. When it's refused, the answer goes into the reader's own synced settings instead, as addedShares, keyed by account and collection. Either record counts as added.

That rule has a test of its own, because three components ask the question and they must not drift apart.

Two things about how this hid

The refusal arrives as a successful response, with the id in notUpdated. The version that ignored it saw nothing wrong, so the button simply did nothing. Fixed in #102, and that's what turned "the + does nothing in Firefox" into a sentence from the server.

It cannot be seen from the owner's account at all, where the write succeeds and everything looks right. It took two browsers signed in as two accounts to find — which is why it survived every check made from one, including all of mine.

The mock now refuses the same write for the same reason. One that accepted it would have gone on agreeing with the belief that shipped.

Verified

Against the mock: adding the shared book is refused by the server, recorded in settings, and the book moves to Shared with me with its contacts reaching the To field (suggest("katherine") goes from 0 to 1). Removing undoes all three. It survives a full page reload — the point of putting it where the settings live rather than in this tab, since those follow the account between devices.

333 web and 77 server tests pass, five new. npm run typecheck clean.

KNOWN-ISSUES records the asymmetry, including that it's invisible from the owner's side.

🤖 Generated with Claude Code

Merged 2026-08-27 as coffey-labs/ihasmail@8a3e0b9954

_{Rebuilt from: git history, session transcript.}

> You are not allowed to modify this address book. That's Stalwart's answer to a sharee subscribing to a book shared read-only, and it's a fair one: `isSubscribed` lives on the collection rather than on the reader, so adding one is a write to the **owner's** account. The identical write on a shared **calendar** is accepted. The difference is the server's, not ours. ### The arrangement The flag is still asked for first — a preference the server holds is one every client agrees about. When it's refused, the answer goes into the reader's own synced settings instead, as `addedShares`, keyed by account and collection. Either record counts as added. That rule has a test of its own, because three components ask the question and they must not drift apart. ### Two things about how this hid **The refusal arrives as a _successful_ response**, with the id in `notUpdated`. The version that ignored it saw nothing wrong, so the button simply did nothing. Fixed in #102, and that's what turned "the + does nothing in Firefox" into a sentence from the server. **It cannot be seen from the owner's account at all**, where the write succeeds and everything looks right. It took two browsers signed in as two accounts to find — which is why it survived every check made from one, including all of mine. The mock now refuses the same write for the same reason. One that accepted it would have gone on agreeing with the belief that shipped. ### Verified Against the mock: adding the shared book is refused by the server, recorded in settings, and the book moves to Shared with me with its contacts reaching the To field (`suggest("katherine")` goes from 0 to 1). Removing undoes all three. It survives a full page reload — the point of putting it where the settings live rather than in this tab, since those follow the account between devices. 333 web and 77 server tests pass, five new. `npm run typecheck` clean. KNOWN-ISSUES records the asymmetry, including that it's invisible from the owner's side. 🤖 Generated with [Claude Code](https://claude.com/claude-code) **Merged** 2026-08-27 as coffey-labs/ihasmail@8a3e0b9954ae <sub>Rebuilt from: git history, session transcript.</sub>

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coffey-labs/ihasmail-github-archive#103