Status change: the htmx table-row answer is an empty row, nothing asks for it, and its test cannot fail #402

New issue

Closed

opened 2026-10-01 10:46:26 +00:00 by tiagoagueda · 1 comment

tiagoagueda commented

2026-10-01 10:46:26 +00:00

Owner

Found on 2026-09-29 in a read-only review of postulo at 95348908d, reading ApplicationStatusView, searching the templates and static/js/app.js for posts to applications:status, and posting to it with the test client.

Checked again on 2026-10-01 against main at 0a5cad587: still present.

ApplicationStatusView still has a branch that answers an htmx request with a table row, for a list page that no longer posts to it. The row it renders has no cells, because the row partial draws one cell per entry in columns and the view does not pass any. The test that covers the branch checks only the row's id, so it passes against an empty row.

Where: applications/views.py:557-561 in ApplicationStatusView.post (renders applications/partials/application_row.html with only {"application": application}); the comment at applications/views.py:565-567 ("The list page posts to the same status view and wants a table row"); templates/applications/partials/application_row.html:6-14 (the checkbox needs bulk_form_id, every cell needs columns); tests/test_application_swaps.py:75-87 (test_the_list_page_still_gets_its_row).
What happens: a status POST with HX-Request: true and HX-Target: application-1 answers <tr id="application-1" class="…"> with only whitespace inside. No page sends that request: the only hx-post to applications:status is on the detail page's status card (partials/status_card.html:48), which is handled by the wants_a_detail_fragment branch above; the board card (partials/application_card.html:61) and the gone-quiet widget (widgets/gone_quiet.html:50) are plain posts, and data-autosubmit submits them with requestSubmit(), not htmx. Nothing in the sibling repositories posts to it either.
Why it matters: the branch and its comment tell the next reader that the list swaps rows in place, and the green test confirms it. Anyone who wires a row-level status control into the table again gets a row that blanks itself, with the test still passing.
Fix: remove the request.htmx row branch, correct the comment above DETAIL_TARGETS, and replace test_the_list_page_still_gets_its_row with a test that an htmx request with any other target gets the ordinary redirect. If the row swap is to stay, render it with the table's context (columns=table.visible, bulk_form_id, a queryset annotated as the list's is) and make the test assert that the role and status cells are present.

Done when

tests/test_application_swaps.py either asserts that a status post with HX-Target: application-<pk> redirects, or asserts that the returned row contains the application's title and status label; the second fails today.

Related to #257 (closed), whose description of the list page asking for a swapped row no longer holds.

Found on 2026-09-29 in a read-only review of postulo at 95348908d, reading `ApplicationStatusView`, searching the templates and `static/js/app.js` for posts to `applications:status`, and posting to it with the test client. Checked again on 2026-10-01 against `main` at `0a5cad587`: still present. `ApplicationStatusView` still has a branch that answers an htmx request with a table row, for a list page that no longer posts to it. The row it renders has no cells, because the row partial draws one cell per entry in `columns` and the view does not pass any. The test that covers the branch checks only the row's `id`, so it passes against an empty row. - **Where:** `applications/views.py:557-561` in `ApplicationStatusView.post` (renders `applications/partials/application_row.html` with only `{"application": application}`); the comment at `applications/views.py:565-567` ("The list page posts to the same status view and wants a table row"); `templates/applications/partials/application_row.html:6-14` (the checkbox needs `bulk_form_id`, every cell needs `columns`); `tests/test_application_swaps.py:75-87` (`test_the_list_page_still_gets_its_row`). - **What happens:** a status `POST` with `HX-Request: true` and `HX-Target: application-1` answers `<tr id="application-1" class="…">` with only whitespace inside. No page sends that request: the only `hx-post` to `applications:status` is on the detail page's status card (`partials/status_card.html:48`), which is handled by the `wants_a_detail_fragment` branch above; the board card (`partials/application_card.html:61`) and the gone-quiet widget (`widgets/gone_quiet.html:50`) are plain posts, and `data-autosubmit` submits them with `requestSubmit()`, not htmx. Nothing in the sibling repositories posts to it either. - **Why it matters:** the branch and its comment tell the next reader that the list swaps rows in place, and the green test confirms it. Anyone who wires a row-level status control into the table again gets a row that blanks itself, with the test still passing. - **Fix:** remove the `request.htmx` row branch, correct the comment above `DETAIL_TARGETS`, and replace `test_the_list_page_still_gets_its_row` with a test that an htmx request with any other target gets the ordinary redirect. If the row swap is to stay, render it with the table's context (`columns=table.visible`, `bulk_form_id`, a queryset annotated as the list's is) and make the test assert that the role and status cells are present. ## Done when - `tests/test_application_swaps.py` either asserts that a status post with `HX-Target: application-<pk>` redirects, or asserts that the returned row contains the application's title and status label; the second fails today. Related to #257 (closed), whose description of the list page asking for a swapped row no longer holds.

tiagoagueda added this to the 0.6.0 milestone

2026-10-01 10:46:26 +00:00

tiagoagueda added the

enhancement

tier

labels

2026-10-01 10:46:26 +00:00

tiagoagueda referenced this issue from a commit

2026-10-06 03:03:42 +00:00

Stop answering a status post aimed at a table row with an empty row

tiagoagueda commented

2026-10-06 09:32:07 +00:00