Bug - Neue Liste ohne Gruppenauswahl landet trotzdem in der letzten Gruppe #203
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#203
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?
Regression aus #201. Beim Anlegen einer neuen Liste ohne Gruppenauswahl (Feld bleibt auf "Keine Gruppe") wird die Liste server-seitig ans Ende der gesamten Reihenfolge angehaengt. Existiert bereits eine Gruppe, deren Ueberschrift die letzte im gesamten Order ist, landet die neue Liste dadurch trotzdem innerhalb dieser Gruppe (kein nachfolgender Header begrenzt ihre Mitgliedschaft) - obwohl der Nutzer keine Gruppe ausgewaehlt hat.
Gleiche Ursache wie der bereits in #201 gefundene und behobene Bug beim manuellen "Keine Gruppe" im Options-Menue.
Fix: jeder Erstellungsdialog ruft moveListToGroup jetzt auch bei leerer Gruppenauswahl auf (mit null statt uebersprungen), sobald mindestens eine Gruppe existiert - platziert die neue Liste explizit vor der ersten Ueberschrift statt sich auf die Server-Standardposition zu verlassen.
Claiming - fix already implemented (found live while verifying #201), will commit and close shortly.
Implemented and shipped in
479c02cf.Fix: every list-creation dialog (Standard/Project/Priority/Shopping/Pantry/MasterPacking) now calls moveListToGroup unconditionally whenever the user has at least one group, passing null when none was picked - not just when a group was explicitly selected. This protects against the same positional-membership trap #201 already found for the manual "Add to group" -> "No group" action: the server's default placement (end of the whole order) can land a new list inside a trailing group's span if that group happens to be the last one in the order.
Tests: a new regression test added per dialog confirming a plain creation with groups existing (but none selected) still repositions the list to "no group", plus the existing "skips the reorder entirely when there are no groups at all" optimization stays covered.
Live-verified alongside #204's testing. Closing as done.