Bestehende Liste duplizieren #159
Labels
No labels
priority/could
priority/must
priority/should
priority/wont
status/blocked
status/claimed
status/done-migrated
type/bug
type/feature
type/infra
type/tech-debt
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
robert/todo#159
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Story: Bestehende Liste duplizieren
As a Nutzer, der eine wiederkehrende Situation (z. B. eine regelmaessige Einkaufsliste oder ein
wiederkehrendes Projekt) neu starten moechte,
I want to eine bestehende Liste als Vorlage duplizieren koennen, um eine neue, unabhaengige Liste
mit denselben Eintraegen zu erhalten,
so that ich nicht jedes Mal alle Eintraege von Hand neu anlegen muss.
Background
Es gibt bereits feste, kuratierte Listen-Vorlagen (
TodoListTemplateCatalog,#24), aber keineMoeglichkeit, eine der eigenen bestehenden Listen als Ausgangspunkt fuer eine neue zu verwenden.
Acceptance criteria:
Erledigt-Status, Zuweisung oder Kommentare.
der Originalliste werden nicht uebernommen.
Masterpackliste), soweit fuer den jeweiligen Typ sinnvoll.
Out of scope for this story:
Open questions: (escalate to human if unanswered)
werden, oder verweist die Kopie auf dieselben?
Claimed. Starting implementation.
Decision on the open question (whether list-own categories/labels should be duplicated or the copy should reference the originals): duplicated, into new rows owned by the new list. This isn't really a toss-up given the schema - TodoCategoryEntity/ShoppingCategoryEntity/PantryCategoryEntity and the *LabelEntity types are all strictly scoped to a single owning list via a non-nullable FK, so a duplicated entry literally cannot reference the original list's category/label rows across the list boundary; the only valid option is to create equivalent rows under the new list and remap entries onto them.
A few additional scope decisions, since the AC's "nicht deren Erledigt-Status, Zuweisung oder Kommentare" line doesn't enumerate every field on every entity across 5 list types:
Implementation composes the existing single-item Create*Command per entry inside one DbTransactionDecorator, mirroring #83's CSV-import precedent and #63's template-seeding precedent, rather than a raw bulk insert - same reasoning: each item gets identical validation and change-publishing side effects as if the user had created it by hand.
Done. Backend commit
1c82c9a, frontend commit77e3e12, memory notes76cbdcd.Scope delivered:
Duplicate{Todo,Shopping,MasterPacking}ListCommand/DuplicatePantryCommand: each creates a new, independent list of the same type from an existing one, copying categories/labels/entries but resetting collaborative state (done-status, assignee, comments), with the duplicating user as sole owner.Decision on the issue's own open question (duplicate categories/labels, or reference the originals): duplicate, into new rows owned by the new list. Not really a toss-up given the schema - every category/label entity is FK-scoped to exactly one owning list, so referencing the original across the list boundary isn't a valid option at all.
Per-type scope decisions, since the AC's exclusion list (done-status/assignee/comments) doesn't cover every field on every entity across 4 types:
New list title: computed client-side via i18n ("{{title}} (Copy)"/"{{title}} (Kopie)") rather than backend-generated, since every other backend-authored user-facing string in this app is plain English.
Tests: one handler test per type (category/label remapping, per-type reset rules) plus a dedicated Priority-matrix carry-forward test for Todo, plus 5 frontend menu-interaction tests (one per type/flow, including a non-owner-can-still-duplicate check).
Verification: backend
dotnet build/dotnet testclean (Docker unavailable in this environment all cycle - confirmed all 4 new handlers' tests fail with the known DockerUnavailableException shape, not a DI/setup error); frontendnpm run buildand full vitest suite green (125 files / 1158 tests). A dedicated security-review subagent traced authorization and cross-user data-mixing risk across all 4 handlers end to end (source-list access checked before any read, every query scoped to ids derived from that authorized source, new membership always keyed to the actual caller) and found nothing. Real CI waspendingon the whole matrix throughout the cycle (known runner-congestion pattern, now observed continuously across 3 consecutive cycles) - not yet confirmed green on the actual pipeline as of this comment.