Put address books in the left pane, other people's included #98

New Issue

Closed

opened 2026-08-27 17:41:02 +00:00 by jcoffey-dev · 0 comments

jcoffey-dev commented

2026-08-27 17:41:02 +00:00

Owner

What it inherits from Files

Shared books are in the app's own left pane, not behind an account switch in the profile menu.
Yours and other people's sit under separate headings. A book belonging to someone else behaves differently, and one merged list would be quiet about whose contacts you're reading.
Opening Contacts re-reads the session, so a book shared while the tab was open turns up without signing out and in again.

The books pane the view kept to itself is gone, and with it the last module that ignored the sidebar it was given.

The one thing Files doesn't need

Shared contacts have to answer when someone types a name into a To field. So they're loaded up front rather than when a book is opened, and they're offered by suggest and found by lookupByEmail alongside the reader's own. Their own cards win a tie — a card someone wrote themselves should beat a colleague's copy of the same person.

That's the difference between a shared book you can look at and one you can use.

Ids collide across accounts

Cards from a shared account are held apart from the reader's and keyed by account as well as id. Ids are only unique within an account — two accounts each having a book ab1 is ordinary — and a flat map would have had one silently replace the other.

Verified

Against the mock, which grew an address book in its shared account with contacts in it, since none of this could be exercised otherwise:

Shared with me lists [email protected] / Team contacts; opening it shows Katherine and Dorothy and not the reader's own contacts
suggest("katherine") returns the shared contact — addressing a message sees the shared book
suggest("ada") still returns the reader's own
lookupByEmail("[email protected]") resolves, so a message from her shows her name
Share… is back on the reader's own books, gated on mayShare

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

Docs

KNOWN-ISSUES records the withdrawal as the mistake it was, rather than leaving it in the history looking like a finding. Mail folder sharing stays withdrawn — that one really is broken.

🤖 Generated with Claude Code

Merged 2026-08-27 as coffey-labs/ihasmail@25fd6404f2

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

Address book sharing was withdrawn a few hours ago in #97 on a report that it behaved like mail folder sharing. That was wrong — it works — and it's back, built the way Files is rather than the way it was. ### What it inherits from Files - **Shared books are in the app's own left pane**, not behind an account switch in the profile menu. - **Yours and other people's sit under separate headings.** A book belonging to someone else behaves differently, and one merged list would be quiet about whose contacts you're reading. - **Opening Contacts re-reads the session**, so a book shared while the tab was open turns up without signing out and in again. The books pane the view kept to itself is gone, and with it the last module that ignored the sidebar it was given. ### The one thing Files doesn't need Shared contacts have to answer when someone types a name into a **To** field. So they're loaded up front rather than when a book is opened, and they're offered by `suggest` and found by `lookupByEmail` alongside the reader's own. Their own cards win a tie — a card someone wrote themselves should beat a colleague's copy of the same person. That's the difference between a shared book you can look at and one you can use. ### Ids collide across accounts Cards from a shared account are held apart from the reader's and keyed by account as well as id. Ids are only unique within an account — two accounts each having a book `ab1` is ordinary — and a flat map would have had one silently replace the other. ### Verified Against the mock, which grew an address book in its shared account with contacts in it, since none of this could be exercised otherwise: - Shared with me lists `[email protected] / Team contacts`; opening it shows Katherine and Dorothy and not the reader's own contacts - `suggest("katherine")` returns the shared contact — addressing a message sees the shared book - `suggest("ada")` still returns the reader's own - `lookupByEmail("[email protected]")` resolves, so a message from her shows her name - Share… is back on the reader's own books, gated on `mayShare` 328 web and 77 server tests pass. `npm run typecheck` clean. ### Docs KNOWN-ISSUES records the withdrawal as the mistake it was, rather than leaving it in the history looking like a finding. **Mail folder sharing stays withdrawn** — that one really is broken. 🤖 Generated with [Claude Code](https://claude.com/claude-code) **Merged** 2026-08-27 as coffey-labs/ihasmail@25fd6404f27a <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#98