Ask for shareWith, or the server does not send it #109

New Issue

Closed

opened 2026-08-27 20:25:14 +00:00 by jcoffey-dev · 0 comments

jcoffey-dev commented

2026-08-27 20:25:14 +00:00

Owner

Nothing was ever badged as shared, Stop sharing never appeared, and the share dialog opened on "not shared with anyone yet" over live shares. The sharing itself was fine — the client simply never learned about it.

Stalwart does not return `shareWith` unless you name it

A Calendar/get or AddressBook/get with no properties comes back without the field at all — not null, not empty, absent. Confirmed against live 0.16.19 on a calendar and an address book that really were shared:

Calendar/get { ids: null }                        → { id, name, … }            no shareWith
Calendar/get { ids: null, properties: [… ,"shareWith"] }
                                                  → shareWith: { o: { mayReadItems: true, … } }

Both stores fetched everything by asking for nothing, and got less than they would have by asking. They name the properties now.

The dialog is the part worth dwelling on

It seeds itself from the shareWith it was handed, so it has been showing an empty sharee list on collections that were shared. The one screen whose whole job is managing sharing was the one most confidently wrong about it — someone opening it to see who had access, or to take it away, was told there was nobody.

That is very likely what was behind the earlier "the context menu does not let me delete the share".

Why Files was fine

fileNodeProps has named the property since file sharing went in — same reason, same surprise, learned once and not carried across. The two stores that fetched with ids: null and no properties are exactly the two that were blind.

The mock now fails the same way

It used to hand shareWith over unasked, which lets a client that never asks look correct everywhere except against a real server. That is precisely how this got here, so the mock omits it now too.

Verified

Sharing a calendar puts the sharee in the store, badges the row, adds Stop sharing, and the dialog lists them — while a Calendar/get with no properties still comes back without the field, so the mock is reproducing the server's behaviour rather than papering over it.

333 web and 77 server tests pass. npm run typecheck clean. KNOWN-ISSUES records it.

🤖 Generated with Claude Code

Merged 2026-08-27 as coffey-labs/ihasmail@e14fc36785

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

Nothing was ever badged as shared, **Stop sharing** never appeared, and the share dialog opened on *"not shared with anyone yet"* over live shares. The sharing itself was fine — the client simply never learned about it. ### Stalwart does not return `shareWith` unless you name it A `Calendar/get` or `AddressBook/get` with no `properties` comes back **without the field at all** — not null, not empty, absent. Confirmed against live 0.16.19 on a calendar and an address book that really were shared: ``` Calendar/get { ids: null } → { id, name, … } no shareWith Calendar/get { ids: null, properties: [… ,"shareWith"] } → shareWith: { o: { mayReadItems: true, … } } ``` Both stores fetched everything by asking for nothing, and got *less* than they would have by asking. They name the properties now. ### The dialog is the part worth dwelling on It seeds itself from the `shareWith` it was handed, so it has been showing an empty sharee list on collections that were shared. The one screen whose whole job is managing sharing was the one most confidently wrong about it — someone opening it to see who had access, or to take it away, was told there was nobody. That is very likely what was behind the earlier "the context menu does not let me delete the share". ### Why Files was fine `fileNodeProps` has named the property since file sharing went in — same reason, same surprise, learned once and not carried across. The two stores that fetched with `ids: null` and no properties are exactly the two that were blind. ### The mock now fails the same way It used to hand `shareWith` over unasked, which lets a client that never asks look correct everywhere except against a real server. That is precisely how this got here, so the mock omits it now too. ### Verified Sharing a calendar puts the sharee in the store, badges the row, adds Stop sharing, and the dialog lists them — while a `Calendar/get` with no properties still comes back without the field, so the mock is reproducing the server's behaviour rather than papering over it. 333 web and 77 server tests pass. `npm run typecheck` clean. KNOWN-ISSUES records it. 🤖 Generated with [Claude Code](https://claude.com/claude-code) **Merged** 2026-08-27 as coffey-labs/ihasmail@e14fc367855c <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#109