Proposed Changes
Introduce a reusable test pattern for model-backed tables that verifies every declared orderable column can be rendered in both ascending and descending order without raising an exception.
As part of that work, add lightweight per-table smoke tests for the canonical model tables and a small coverage check to help ensure new tables are not added without this test coverage. The helper should focus on the querysets used by sortable list views (or allow an explicit queryset override where needed), so it exercises realistic ordering behavior without creating noise from bulk edit/delete confirmation views.
This should give us a consistent way to catch unsupported ordering on columns backed by generic foreign keys, complex accessors, calculated values, and annotated count columns.
Justification
We have now hit this class of problem more than once: a column is left orderable, the table renders normally at first, and the failure only shows up when that specific column is sorted. These regressions are easy to miss in manual testing and can also be triggered later by a saved table preference.
A shared test helper plus basic coverage enforcement would make this much easier to maintain across apps, reduce copy/paste regression tests, and give contributors a clearer pattern for declaring and validating sortable table columns. It also keeps targeted bugfix PRs small while giving us a dedicated place to improve table-ordering test coverage more broadly.
Proposed Changes
Introduce a reusable test pattern for model-backed tables that verifies every declared orderable column can be rendered in both ascending and descending order without raising an exception.
As part of that work, add lightweight per-table smoke tests for the canonical model tables and a small coverage check to help ensure new tables are not added without this test coverage. The helper should focus on the querysets used by sortable list views (or allow an explicit queryset override where needed), so it exercises realistic ordering behavior without creating noise from bulk edit/delete confirmation views.
This should give us a consistent way to catch unsupported ordering on columns backed by generic foreign keys, complex accessors, calculated values, and annotated count columns.
Justification
We have now hit this class of problem more than once: a column is left orderable, the table renders normally at first, and the failure only shows up when that specific column is sorted. These regressions are easy to miss in manual testing and can also be triggered later by a saved table preference.
A shared test helper plus basic coverage enforcement would make this much easier to maintain across apps, reduce copy/paste regression tests, and give contributors a clearer pattern for declaring and validating sortable table columns. It also keeps targeted bugfix PRs small while giving us a dedicated place to improve table-ordering test coverage more broadly.