Give the address books the menus the calendars have #226

New Issue

Closed

opened 2026-09-02 16:06:14 +00:00 by jcoffey-dev · 0 comments

jcoffey-dev commented

2026-09-02 16:06:14 +00:00

Owner

Closes #224. Two remarks from the reporter's colleague on #174, both the same underlying thing: contacts and calendar grew their menus at different times and it shows.

The dots button on hover

The calendar has offered its per-item menu two ways since it was written — the button and right-click. Contacts only had right-click, which is undiscoverable and unavailable on touch.

The rows are already .nav-item, which has carried the hover-reveal rule (.nav-item:hover .nav-more) for mail folders all along. So this is the button and no CSS.

Import and export move into those menus

As a pair of buttons at the foot of the sidebar they did not say which address book they acted on — they meant "whatever is selected", which is not something a button can tell you. The calendar settled this already: its iCAL import lives in the calendar's own menu, because that is where which one? is answered by where you clicked.

The events they dispatch now carry the book rather than meaning the selection.

A behaviour fix that came with it: exporting a book now exports that book, not the list on screen. The old export handed you whatever was showing, so a search box with something in it quietly narrowed the file you got. Fine while the button sat under that list; wrong from a menu in the sidebar.

Two things that would otherwise have been lost

"All contacts" gets the same menu, so exporting everything still has a home (and importing there files into the default book — which is what the old button quietly did anyway).
A shared book gets a menu rather than the bare X. Somebody else's book can be exported too, and losing that when the sidebar's export button went would have been a regression dressed as a tidy-up. The X moves inside as "Remove from my contacts" — worth calling out, since it turns a one-click action into two.

Verified

Driven in a real browser against the mock: the hover button appears on "All contacts", on an own book, and on a shared book; each menu opens with the right items for its row; nothing clips at the popover width (the first draft's "Export this address book" did, so the label is "Export address book" and the menu is 230 like the calendar's 220-ish).

I did not trigger an actual export or import in the browser — one starts a file download and the other opens a native file picker. The wiring is typechecked and the store paths are covered by the existing import tests, but the click-through of those two actions is unverified by me.

Strings

Five new keys across all nine catalogues; "Export all" and "Export book" retired. i18n:check back to the same six pre-existing stale keys, no new ones. Mine, not native-reviewed, like the rest.

npm run typecheck, npm test (908 web + 122 server), npm run build pass.

Merged 2026-09-02 as coffey-labs/ihasmail@cb69115be1

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

Closes #224. Two remarks from the reporter's colleague on [#174](https://github.com/Coffey-Labs/ihasmail/issues/174#issuecomment-5507056538), both the same underlying thing: contacts and calendar grew their menus at different times and it shows. ## The dots button on hover The calendar has offered its per-item menu two ways since it was written — the button and right-click. Contacts only had right-click, which is undiscoverable and unavailable on touch. The rows are already `.nav-item`, which has carried the hover-reveal rule (`.nav-item:hover .nav-more`) for mail folders all along. So this is the button and no CSS. ## Import and export move into those menus As a pair of buttons at the foot of the sidebar they did not say which address book they acted on — they meant "whatever is selected", which is not something a button can tell you. The calendar settled this already: its iCAL import lives in the calendar's own menu, because that is where *which one?* is answered by where you clicked. The events they dispatch now carry the book rather than meaning the selection. **A behaviour fix that came with it:** exporting a book now exports *that book*, not the list on screen. The old export handed you whatever was showing, so a search box with something in it quietly narrowed the file you got. Fine while the button sat under that list; wrong from a menu in the sidebar. ## Two things that would otherwise have been lost - **"All contacts" gets the same menu**, so exporting everything still has a home (and importing there files into the default book — which is what the old button quietly did anyway). - **A shared book gets a menu rather than the bare X.** Somebody else's book can be exported too, and losing that when the sidebar's export button went would have been a regression dressed as a tidy-up. The X moves inside as "Remove from my contacts" — worth calling out, since it turns a one-click action into two. ## Verified Driven in a real browser against the mock: the hover button appears on "All contacts", on an own book, and on a shared book; each menu opens with the right items for its row; nothing clips at the popover width (the first draft's "Export this address book" did, so the label is "Export address book" and the menu is 230 like the calendar's 220-ish). I did **not** trigger an actual export or import in the browser — one starts a file download and the other opens a native file picker. The wiring is typechecked and the store paths are covered by the existing import tests, but the click-through of those two actions is unverified by me. ## Strings Five new keys across all nine catalogues; "Export all" and "Export book" retired. `i18n:check` back to the same six pre-existing stale keys, no new ones. Mine, not native-reviewed, like the rest. `npm run typecheck`, `npm test` (908 web + 122 server), `npm run build` pass. **Merged** 2026-09-02 as coffey-labs/ihasmail@cb69115be12f <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#226