You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ux(opportunities): confirm expand-chevron position (moved to front of Resource Type) #1006
Summary (QA row 568 / step 3.2, Read-Only User; also visible to other roles)
On the Opportunities page, the row-expand button (">") has moved from the far left of each row (in front of the Provider column) to in front of the Resource Type column. QA flagged this as an unexpected position change.
Open question (needs product confirmation)
Is the relocated chevron position intended, or should it return to the far-left (checkbox/Provider column)?
Related work: #280 / PR #798 ("enlarge cell-expand chevron + reposition") touches the recommendations-table chevron and its placement test asserts the chevron sits in td.checkbox-col (far-left). It is unclear whether #798 also covers the Opportunities-page table this row observed, or whether the Opportunities page uses a separate component still rendering the chevron in front of Resource Type.
Acceptance criteria
Decide the canonical expand-chevron position on the Opportunities page (far-left vs in front of Resource Type) and apply it consistently.
Root cause identified (via verification of PR #798): in frontend/src/recommendations.ts the expand chevron has TWO render paths. When showCheckboxes is true it renders far-left in td.checkbox-col; when showCheckboxes is FALSE an inlineChevron branch (~line 3091) injects it inside .rec-cell-summary-content immediately before resource_type. The Read-Only user on the Opportunities page hits the showCheckboxes=false path, which is exactly why QA saw the chevron 'in front of Resource Type'. PR #798 (closes #280) only enlarges the chevron and does not touch this branch, so it does NOT resolve this. Decision needed: should the chevron be far-left in both modes? If yes, the fix is to render a leading cell carrying the chevron even when checkboxes are hidden (instead of inlining before resource_type), plus a showCheckboxes=false placement test.
Product decision (owner): the disclosure chevron should sit at the row's far-left leading edge (before Provider), which is the standard placement for an expand/collapse control. Restore it there (it had drifted to just before Resource Type). Small frontend fix; implementer dispatched.
Activity
cristim commentedon Jun 6, 2026
Root cause identified (via verification of PR #798): in frontend/src/recommendations.ts the expand chevron has TWO render paths. When showCheckboxes is true it renders far-left in td.checkbox-col; when showCheckboxes is FALSE an inlineChevron branch (~line 3091) injects it inside .rec-cell-summary-content immediately before resource_type. The Read-Only user on the Opportunities page hits the showCheckboxes=false path, which is exactly why QA saw the chevron 'in front of Resource Type'. PR #798 (closes #280) only enlarges the chevron and does not touch this branch, so it does NOT resolve this. Decision needed: should the chevron be far-left in both modes? If yes, the fix is to render a leading cell carrying the chevron even when checkboxes are hidden (instead of inlining before resource_type), plus a showCheckboxes=false placement test.
cristim commentedon Jul 17, 2026
Product decision (owner): the disclosure chevron should sit at the row's far-left leading edge (before Provider), which is the standard placement for an expand/collapse control. Restore it there (it had drifted to just before Resource Type). Small frontend fix; implementer dispatched.