Problem
Four dashboard widgets were fixed to order by id instead of the default
created_at (which doesn't exist — all four underlying models have
$timestamps = false):
Modules/Expenses/Filament/Company/Widgets/RecentExpensesWidget.php
Modules/Payments/Filament/Company/Widgets/RecentPaymentsWidget.php
Modules/Projects/Filament/Company/Widgets/RecentProjectsWidget.php
Modules/Projects/Filament/Company/Widgets/RecentTasksWidget.php
(->latest() → ->latest('id'))
Their corresponding tests (Recent*WidgetTest.php, all four) only assert
that the widget renders and shows a link to the resource's index
(assertSee(...Resource::getUrl('index'), false)) — none of them assert
ordering. If this fix were ever accidentally reverted (->latest()) or
inverted (->oldest('id')), no test would catch it.
SMART Plan
Specific: Add an ordering assertion to each of the four
Recent*WidgetTest.php files: create records with distinct, out-of-insertion-
order ids (or rely on factory sequence + explicit id overrides), render
the widget, and assert the most-recently-created record appears before an
older one in the rendered table/list output.
Measurable: Reverting any of the four ->latest('id') fixes back to
->latest() or ->oldest('id') causes the corresponding test to fail.
Achievable: Small, mechanical addition — same pattern across all four
files, following whatever assertion style
(assertSeeInOrder/assertSeeTextInOrder or manual record inspection) fits
Filament's TableWidget test helpers already in use elsewhere in the suite.
Relevant: Closes the actual regression path for a fix that already
shipped once — the underlying bug (->latest() silently sorting by a
nonexistent column) is exactly the kind of thing that's easy to reintroduce
without a test catching it.
Time-bound: Low priority, no urgency — good first issue / cleanup task.
Origin
Surfaced during a senior-review pass over the fork's develop branch
(11 commits ahead of upstream at the time, including the widget ordering fix
itself).
Problem
Four dashboard widgets were fixed to order by
idinstead of the defaultcreated_at(which doesn't exist — all four underlying models have$timestamps = false):Modules/Expenses/Filament/Company/Widgets/RecentExpensesWidget.phpModules/Payments/Filament/Company/Widgets/RecentPaymentsWidget.phpModules/Projects/Filament/Company/Widgets/RecentProjectsWidget.phpModules/Projects/Filament/Company/Widgets/RecentTasksWidget.php(
->latest()→->latest('id'))Their corresponding tests (
Recent*WidgetTest.php, all four) only assertthat the widget renders and shows a link to the resource's index
(
assertSee(...Resource::getUrl('index'), false)) — none of them assertordering. If this fix were ever accidentally reverted (
->latest()) orinverted (
->oldest('id')), no test would catch it.SMART Plan
Specific: Add an ordering assertion to each of the four
Recent*WidgetTest.phpfiles: create records with distinct, out-of-insertion-order
ids (or rely on factory sequence + explicitidoverrides), renderthe widget, and assert the most-recently-created record appears before an
older one in the rendered table/list output.
Measurable: Reverting any of the four
->latest('id')fixes back to->latest()or->oldest('id')causes the corresponding test to fail.Achievable: Small, mechanical addition — same pattern across all four
files, following whatever assertion style
(
assertSeeInOrder/assertSeeTextInOrderor manual record inspection) fitsFilament's
TableWidgettest helpers already in use elsewhere in the suite.Relevant: Closes the actual regression path for a fix that already
shipped once — the underlying bug (
->latest()silently sorting by anonexistent column) is exactly the kind of thing that's easy to reintroduce
without a test catching it.
Time-bound: Low priority, no urgency — good first issue / cleanup task.
Origin
Surfaced during a senior-review pass over the fork's
developbranch(11 commits ahead of upstream at the time, including the widget ordering fix
itself).