Let the owner stop sharing a calendar or an address book #108

New Issue

Closed

opened 2026-08-27 20:11:32 +00:00 by jcoffey-dev · 0 comments

jcoffey-dev commented

2026-08-27 20:11:32 +00:00

Owner

Revoking a share meant opening the share dialog, removing each person in turn, and saving. That's the right tool for changing who has access and the wrong one for withdrawing it altogether — which is the more urgent of the two, and the one someone is likely to want in a hurry.

Both now offer Stop sharing in the context menu, clearing the lot after a confirmation that says how many people lose access. It appears only when there's something to revoke, so the menu also tells you whether a thing is shared.

A calendar now says it is shared

Address books have carried that badge since they gained sharing; calendars never did. The only way to find out was to open the dialog and look — which, for the owner of a dozen calendars, means opening a dozen dialogs.

Verified

Against the mock, both kinds: sharing one shows the badge and adds the menu entry; confirming clears shareWith; the badge goes; and the entry disappears with it, since there is no longer anything to stop.

Both go through the existing updateCalendar / updateBook paths, which already read notUpdated, so a server that refuses is reported rather than swallowed.

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

Note

This is the owner withdrawing a share. It's separate from the sharee's Remove from my view added in #101/#103, which only stops them seeing something still shared with them. Mail folders already had this from #97, where the entry survives precisely so an undeliverable share can still be cleared.

🤖 Generated with Claude Code

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

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

Revoking a share meant opening the share dialog, removing each person in turn, and saving. That's the right tool for *changing* who has access and the wrong one for *withdrawing* it altogether — which is the more urgent of the two, and the one someone is likely to want in a hurry. Both now offer **Stop sharing** in the context menu, clearing the lot after a confirmation that says how many people lose access. It appears only when there's something to revoke, so the menu also tells you whether a thing is shared. ### A calendar now says it is shared Address books have carried that badge since they gained sharing; calendars never did. The only way to find out was to open the dialog and look — which, for the owner of a dozen calendars, means opening a dozen dialogs. ### Verified Against the mock, both kinds: sharing one shows the badge and adds the menu entry; confirming clears `shareWith`; the badge goes; and the entry disappears with it, since there is no longer anything to stop. Both go through the existing `updateCalendar` / `updateBook` paths, which already read `notUpdated`, so a server that refuses is reported rather than swallowed. 333 web and 77 server tests pass. `npm run typecheck` clean. ### Note This is the **owner** withdrawing a share. It's separate from the sharee's *Remove from my view* added in #101/#103, which only stops them seeing something still shared with them. Mail folders already had this from #97, where the entry survives precisely so an undeliverable share can still be cleared. 🤖 Generated with [Claude Code](https://claude.com/claude-code) **Merged** 2026-08-27 as coffey-labs/ihasmail@f83157464c44 <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#108