Add shared collections deliberately, and pick recipients from the address books #101

Closed
opened 2026-08-27 18:16:41 +00:00 by jcoffey-dev · 0 comments
Owner

Two things, both from using it on two real accounts.

1. An account linked for its files also offered its calendar and address book

Neither had been shared. That wasn't ihasmail inventing them — asked about the other account, live 0.16.19 returns every calendar and every book it holds, each with full rights:

[email protected]
  calendar     "InBuxA Calendar (postmaster)"      isSubscribed: false
               myRights: read, write, share, delete — all true
  address book "InBuxA Address Book (postmaster)"  isSubscribed: false
               myRights: read, write, share, delete — all true

There is nothing in the rights to tell "shared with me" from "reachable at all", because the server doesn't distinguish them. isSubscribed does, and it's the field JMAP has for exactly this — false on all of them.

So a shared calendar or book is listed under Shared with me once added, and under Available to add until then, one button either way.

Nothing unsubscribed contributes anything. A calendar not added draws no events; a book not added lends no cards to the To field. That last one matters most — it's the difference between offering a colleague's contacts and offering a stranger's without anyone having asked.

The mock's shared collections now arrive unsubscribed, the way the real server hands them over, and its Calendar/set / AddressBook/set route by account since subscribing is a write to their account.

2. Recipients could only be typed, not browsed

Addressing worked only if you already knew the name you were half-way through typing. Autocomplete answers "finish this for me"; there was no answer to "who is there?".

The To row now opens the address books — from a button beside Cc and Bcc, where someone thinking about recipients is already looking, and from the To label itself. Search across every book or narrow to one, tick as many people as the message needs, send them to To, Cc or Bcc. Picking for a hidden field opens it, since a Bcc dropped somewhere invisible is worse than no Bcc.

Every address is its own row, not every person. Someone with a work address and a personal one is a choice the writer has to make; a picker that listed the card and quietly took the first address would make it for them.

Shared books are in it on the same footing as your own, with the account named on each row.

Verified

  • Shared calendar sits under Available to add with no events in the grid; adding moves it to Shared with me and its events appear; removing undoes both.
  • suggest("katherine") returns nothing until the shared book is added, then returns her.
  • The picker lists own and shared contacts, each row naming its source; ticking one of each and choosing Cc opens the Cc row with both in it.

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

🤖 Generated with Claude Code

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

Rebuilt from: GH Archive, git history, session transcript.

Two things, both from using it on two real accounts. ## 1. An account linked for its files also offered its calendar and address book Neither had been shared. That wasn't ihasmail inventing them — asked about the other account, live 0.16.19 returns every calendar and every book it holds, each with full rights: ``` [email protected] calendar "InBuxA Calendar (postmaster)" isSubscribed: false myRights: read, write, share, delete — all true address book "InBuxA Address Book (postmaster)" isSubscribed: false myRights: read, write, share, delete — all true ``` There is nothing in the rights to tell "shared with me" from "reachable at all", because the server doesn't distinguish them. `isSubscribed` does, and it's the field JMAP has for exactly this — false on all of them. So a shared calendar or book is listed under **Shared with me** once added, and under **Available to add** until then, one button either way. **Nothing unsubscribed contributes anything.** A calendar not added draws no events; a book not added lends no cards to the To field. That last one matters most — it's the difference between offering a colleague's contacts and offering a stranger's without anyone having asked. The mock's shared collections now arrive unsubscribed, the way the real server hands them over, and its `Calendar/set` / `AddressBook/set` route by account since subscribing is a write to *their* account. ## 2. Recipients could only be typed, not browsed Addressing worked only if you already knew the name you were half-way through typing. Autocomplete answers "finish this for me"; there was no answer to "who is there?". The To row now opens the address books — from a button beside Cc and Bcc, where someone thinking about recipients is already looking, and from the To label itself. Search across every book or narrow to one, tick as many people as the message needs, send them to To, Cc or Bcc. Picking for a hidden field opens it, since a Bcc dropped somewhere invisible is worse than no Bcc. **Every address is its own row, not every person.** Someone with a work address and a personal one is a choice the writer has to make; a picker that listed the card and quietly took the first address would make it for them. Shared books are in it on the same footing as your own, with the account named on each row. ### Verified - Shared calendar sits under Available to add with no events in the grid; adding moves it to Shared with me and its events appear; removing undoes both. - `suggest("katherine")` returns nothing until the shared book is added, then returns her. - The picker lists own and shared contacts, each row naming its source; ticking one of each and choosing Cc opens the Cc row with both in it. 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@d9995cd0b4c2 <sub>Rebuilt from: GH Archive, git history, session transcript.</sub>
This repo is archived. You cannot comment on issues.