Feature request: let the duplicate prompt choose among several matching shopping list items #31

New issue

Open

opened 2026-10-03 06:27:44 +00:00 by araemer · 0 comments

araemer commented

2026-10-03 06:27:44 +00:00

Owner

Idea

When an item name matches more than one item on a shopping list, the duplicate prompt should let the user choose which of them to edit.

Today the prompt can only ever reach one of them. Example: add "Milch" with comment "frisch", then "Milch" with comment "H-Milch" via "Separat hinzufügen". Adding "Milch" a third time and choosing "Bestehenden bearbeiten" always opens the first Milch (frisch). The second one (H-Milch) can't be reached from the prompt, only through its own row (tap → "Bearbeiten").

The reason is the contract: on a match, POST /shopping-list/:id/add-item returns a single item, by rule "if several match: the topmost open one, otherwise the most recently ticked one" (api-contract/src/shopping-lists.ts, AddShoppingListItemResponse). The spec has the same gap: "Edit existing: opens the existing item for editing" assumes there is only one match, although "Add separately" is exactly how a list gets several.

Proposal

Contract: a DUPLICATE response carries every matching item (open and ticked) in a defined order, instead of a single one. For example, item becomes matches: ShoppingListItemDto[] for DUPLICATE, while ADDED keeps the new item.
App: the duplicate prompt lists the matches with what tells them apart (amount, unit, comment, ticked), e.g. "Milch · frisch" / "Milch · H-Milch", and "Bestehenden bearbeiten" opens the chosen one. A ticked choice is unticked first, as today. With a single match the prompt stays as it is.
Backend: return all matches instead of picking one. The matching rule itself (case, surrounding spaces, plural endings without umlaut change) is unchanged.

The duplicate check stays on the server, as decided in docs/adr/2026-09-27-shopping-list-contract.md. Re-implementing the matching in the app to find the other items was considered and rejected for that reason.

Notes

Contract change affecting both siblings: needs an ADR that partly supersedes the duplicate-check part of docs/adr/2026-09-27-shopping-list-contract.md, plus a spec wording change ("Edit existing" with several matches).
Spec B of E01 (filling lists from a meal plan) uses the same matching for merging, so it should be decided whether merging also needs to handle several matches.
Order of the matches: probably open items first in list order, then ticked ones, most recently ticked first, mirroring today's pick rule.

Found during manual testing of spec 001 (recipe-app#47); postponed to a follow-up.

🤖 Generated with Claude Code

## Idea When an item name matches more than one item on a shopping list, the duplicate prompt should let the user choose which of them to edit. Today the prompt can only ever reach one of them. Example: add "Milch" with comment "frisch", then "Milch" with comment "H-Milch" via "Separat hinzufügen". Adding "Milch" a third time and choosing "Bestehenden bearbeiten" always opens the first Milch (frisch). The second one (H-Milch) can't be reached from the prompt, only through its own row (tap → "Bearbeiten"). The reason is the contract: on a match, `POST /shopping-list/:id/add-item` returns a single `item`, by rule *"if several match: the topmost open one, otherwise the most recently ticked one"* (`api-contract/src/shopping-lists.ts`, `AddShoppingListItemResponse`). The spec has the same gap: "Edit existing: opens the existing item for editing" assumes there is only one match, although "Add separately" is exactly how a list gets several. ## Proposal - **Contract:** a `DUPLICATE` response carries every matching item (open and ticked) in a defined order, instead of a single one. For example, `item` becomes `matches: ShoppingListItemDto[]` for `DUPLICATE`, while `ADDED` keeps the new item. - **App:** the duplicate prompt lists the matches with what tells them apart (amount, unit, comment, ticked), e.g. "Milch · frisch" / "Milch · H-Milch", and "Bestehenden bearbeiten" opens the chosen one. A ticked choice is unticked first, as today. With a single match the prompt stays as it is. - **Backend:** return all matches instead of picking one. The matching rule itself (case, surrounding spaces, plural endings without umlaut change) is unchanged. The duplicate check stays on the server, as decided in `docs/adr/2026-09-27-shopping-list-contract.md`. Re-implementing the matching in the app to find the other items was considered and rejected for that reason. ## Notes - Contract change affecting both siblings: needs an ADR that partly supersedes the duplicate-check part of `docs/adr/2026-09-27-shopping-list-contract.md`, plus a spec wording change ("Edit existing" with several matches). - Spec B of E01 (filling lists from a meal plan) uses the same matching for merging, so it should be decided whether merging also needs to handle several matches. - Order of the matches: probably open items first in list order, then ticked ones, most recently ticked first, mirroring today's pick rule. Found during manual testing of spec 001 (recipe-app#47); postponed to a follow-up. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

araemer/recipe-platform#31

No description provided.

Rows
Columns