Always show the personal group's own row, even with no places #186
Loading…
Reference in a new issue
No description provided.
Delete branch "feature/task-247-personal-group-row"
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?
Task 247. Reverses part of ADR-0095 (Rob's own product call from live use, task 241's investigation under PR #185):
PlaceAccordion.HasNothingToShownow gates the flat "You have no places yet." message on the merged row set itself (AccordionGroups.Count == 0) rather than on place count plus non-personal groups, so a brand-new account's personal group gets its own named row — heading, visibility toggle, edit-group button — from first sign-in, exactly like any other placeless group has since task 183.HasNothingToShowsurvives, narrowed: it's still reachable whenCallerGroupsStatefails to load and the caller has no places either, so the flat message doesn't vanish into a blank component on that path. Proved reachable with a new test (PlaceAccordion_NoPlacesAndCallerGroupsFailedToLoad_ShowsTheFlatEmptyMessage), and the reversed test (PlaceAccordion_AccountHasOnlyItsPersonalGroupAndNoPlaces_ShowsThePersonalGroupsOwnRow) was watched red against the old gate before the fix, green after.No change to add-a-place gating (
EligibleGroups), which was already correct.ADR-0161 records the decision and partially supersedes ADR-0095; ADR-0095's own Status/
Partially superseded bymetadata updated to match (no other edits to its frozen body). README index regenerated viascripts/regenerate-adr-readme.cs.594398ede47cfe34f5dfVerdict: mergeable
Checked the points from the review brief:
HasNothingToShow(AccordionGroups.Count == 0) is genuinely reachable, not dead code:AccordionGroupsis empty exactly when bothPlacesState.GroupsandCallerGroups.Groupsare empty, which the newCallerGroupsFailedToLoadtest forces via a stubbed 500. Confirmed by hand against the old gate too — that test's assertions (Find("button.accordion-header")etc.) throw against unpatched source, so the red-before-green claim holds.PlacesState.Groups.Count == 0 && !CallerGroups.Groups.Any(g => !g.IsPersonal)) evaluates the same way whenCallerGroups.Groupsis empty from a load failure. Not a regression from this PR, and out of scope for task 247, but worth a ticket at some point — a failed groups load is indistinguishable from an empty account.HasNothingToShowonly matters whenAccordionGroupsis empty, so any account with ≥1 group is untouched by this gate change.OidcSignInJourneyTestsonly asserts the "Add a place" button, gated onEligibleGroups(untouched) — unaffected either way.@if (group.Places.Count > 0)branch, no personal-group special-casing).EligibleGroupsgating untouched.Partially supersedescall is correct against ADR-0107: ADR-0095's account-wide-empty paragraph was a decision made in frozen prose (and an alternative explicitly rejected), not a question left open for a later record —Answered bygenuinely doesn't apply, and the PR's own alternatives-considered section shows that was checked, not assumed. The diff to ADR-0095 touches only theStatus/Partially superseded byfields; body untouched.No blocking issues found.