Stop offering to share mail folders, and let a share be removed #97

New Issue

Closed

opened 2026-08-27 17:28:18 +00:00 by jcoffey-dev · 0 comments

jcoffey-dev commented

2026-08-27 17:28:18 +00:00

Owner

Based on main, so it can merge independently of #95 and #96.

Sharing a mail folder does nothing

Mailbox/set takes the shareWith map, Mailbox/get reads it back, and the folder never appears for the account it was shared with. Confirmed on live 0.16.19 with LEsite shared read-only to another account on the same server, which never saw it. Stalwart's sharing docs list calendars, address books and file storage — mail folders are not among them.

Nothing reports a failure anywhere, so a client that trusts what it reads back shows the share as live forever. Which is exactly what happened.

The entry point is withdrawn. Address book sharing goes with it on a report that it behaved the same way — not reproduced, and contradicted by Stalwart's own docs, so that one is expected back. It's out because offering a share nobody can verify was worse than the gap. Files and calendars are untouched.

Why the share couldn't be removed

The dialog rendered the list of who a thing is shared with inside the branch that runs when the directory has principals to offer. A server with allowDirectoryQueries off returns none — that's the default, and it's how these shares came to be made in the first place — so the dialog showed one line of hint and nothing else.

The share was there. There was no way to see it, let alone remove it.

The list now renders whatever the directory says; only the add control depends on having someone to add. So the withdrawn entry points don't strand what they created: a folder or book already shared still offers Stop sharing, which is the one thing you want when the share is invisible everywhere else.

The API was never the problem

Worth recording, since it was my first guess: shareWith: null is accepted and clears the map. Tested against the live server on the stuck folder — LEsite is now unshared.

Documented

New KNOWN-ISSUES entries, kept honest about which half was actually verified: the mail folder finding is confirmed live; the address book one is explicitly marked as withdrawn without being disproved, since Stalwart documents it as supported and there was no shared book left on the account by the time I looked.

328 web and 77 server tests pass. npm run typecheck clean.

🤖 Generated with Claude Code

Merged 2026-08-27 as coffey-labs/ihasmail@006190d523

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

Based on `main`, so it can merge independently of #95 and #96. ### Sharing a mail folder does nothing `Mailbox/set` takes the `shareWith` map, `Mailbox/get` reads it back, and the folder never appears for the account it was shared with. Confirmed on live 0.16.19 with `LEsite` shared read-only to another account on the same server, which never saw it. Stalwart's sharing docs list calendars, address books and file storage — mail folders are not among them. Nothing reports a failure anywhere, so a client that trusts what it reads back shows the share as live forever. Which is exactly what happened. The entry point is withdrawn. **Address book sharing goes with it on a report that it behaved the same way — not reproduced, and contradicted by Stalwart's own docs, so that one is expected back.** It's out because offering a share nobody can verify was worse than the gap. Files and calendars are untouched. ### Why the share couldn't be removed The dialog rendered the list of who a thing is shared with **inside** the branch that runs when the directory has principals to offer. A server with `allowDirectoryQueries` off returns none — that's the default, and it's how these shares came to be made in the first place — so the dialog showed one line of hint and nothing else. The share was there. There was no way to see it, let alone remove it. The list now renders whatever the directory says; only the *add* control depends on having someone to add. So the withdrawn entry points don't strand what they created: a folder or book already shared still offers **Stop sharing**, which is the one thing you want when the share is invisible everywhere else. ### The API was never the problem Worth recording, since it was my first guess: `shareWith: null` is accepted and clears the map. Tested against the live server on the stuck folder — `LEsite` is now unshared. ### Documented New KNOWN-ISSUES entries, kept honest about which half was actually verified: the mail folder finding is confirmed live; the address book one is explicitly marked as withdrawn *without* being disproved, since Stalwart documents it as supported and there was no shared book left on the account by the time I looked. 328 web and 77 server tests pass. `npm run typecheck` clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code) **Merged** 2026-08-27 as coffey-labs/ihasmail@006190d52327 <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#97