No way to delete more than one contact at a time #277

New Issue

Open

opened 2026-09-04 15:23:07 +00:00 by jcoffey-dev · 0 comments

jcoffey-dev commented

2026-09-04 15:23:07 +00:00

Owner

Raised by the submitter on #174 as part of the migration workflow: import, notice something is wrong, delete what came in, correct the export, start over.

This workflow requires you to be able to quickly delete all imported entries & start over.

It is broader than a migration convenience, though. Looking at what is actually there:

Contacts have no multi-select at all. The only delete in the module is the ✕ on a single card's detail pane, one card at a time, each with its own confirmation. There are no checkboxes in the list and nothing that selects a range. destroyCards() in the store already takes a list of ids and is batched against maxObjectsInSet — the capability is there and nothing in the UI ever hands it more than one id.

So "empty this address book" is the ask, but "delete these fourteen contacts" is equally missing, and both want the same thing underneath.

The workaround today costs more than it should. You can delete the address book itself — destroyBook passes onDestroyRemoveContents: true, so the cards go with it — and then create a new one. That loses the book's name, its sharing, and its default-for-new-cards status, all of which have to be set up again. Fine as an accident recovery, wrong as the documented way to retry an import.

What this probably wants

Selection in the contacts list, matching how mail already does it rather than inventing a second idiom.
Empty this address book in the book's own menu, where import and export now live after #224. It is the operation the migration workflow actually asks for, and it does not need a selection to exist first.
A confirmation naming the count and the book, since this is not undoable — ContactCard/set destroy has no trash to land in.
Report what the server actually destroyed rather than what was asked, the way bulk delete was corrected to do in #218.

Worth deciding before building

Whether emptying a shared book is offered at all. Someone else's book can be exported today (#226 deliberately kept that). Destroying its contents is a different weight of action, and the rights to do it may not be there.

Whether this is less urgent than it was. Since #223, an LDIF or vCard re-import updates rather than duplicates, so a corrected export no longer needs a clean slate to land on — which was the original reason for asking. What it does not cover is an import that brought in entries which should not be there at all, where correcting the file leaves the extras behind. So the need is smaller than when it was raised, and not gone.

Related: #174, #223.

_{Rebuilt from: session transcript.}

Raised by the submitter on #174 as part of the migration workflow: import, notice something is wrong, delete what came in, correct the export, start over. > This workflow requires you to be able to quickly delete all imported entries & start over. It is broader than a migration convenience, though. Looking at what is actually there: **Contacts have no multi-select at all.** The only delete in the module is the ✕ on a single card's detail pane, one card at a time, each with its own confirmation. There are no checkboxes in the list and nothing that selects a range. `destroyCards()` in the store already takes a list of ids and is batched against `maxObjectsInSet` — the capability is there and nothing in the UI ever hands it more than one id. So "empty this address book" is the ask, but "delete these fourteen contacts" is equally missing, and both want the same thing underneath. **The workaround today costs more than it should.** You can delete the address book itself — `destroyBook` passes `onDestroyRemoveContents: true`, so the cards go with it — and then create a new one. That loses the book's name, its sharing, and its default-for-new-cards status, all of which have to be set up again. Fine as an accident recovery, wrong as the documented way to retry an import. ## What this probably wants - Selection in the contacts list, matching how mail already does it rather than inventing a second idiom. - **Empty this address book** in the book's own menu, where import and export now live after #224. It is the operation the migration workflow actually asks for, and it does not need a selection to exist first. - A confirmation naming the count and the book, since this is not undoable — `ContactCard/set destroy` has no trash to land in. - Report what the server actually destroyed rather than what was asked, the way bulk delete was corrected to do in #218. ## Worth deciding before building **Whether emptying a shared book is offered at all.** Someone else's book can be exported today (#226 deliberately kept that). Destroying its contents is a different weight of action, and the rights to do it may not be there. **Whether this is less urgent than it was.** Since #223, an LDIF or vCard re-import *updates* rather than duplicates, so a corrected export no longer needs a clean slate to land on — which was the original reason for asking. What it does not cover is an import that brought in entries which should not be there at all, where correcting the file leaves the extras behind. So the need is smaller than when it was raised, and not gone. Related: #174, #223. <sub>Rebuilt from: 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#277