Saved views: dragging a column's width, applying Columns or pressing Reset deletes every saved view #503

Closed
opened 2026-10-01 10:47:09 +00:00 by tiagoagueda · 0 comments
Owner

Found on 2026-09-29 in a read-only review of postulo at 95348908d, reading how table settings are saved and running clean_settings with the snapshot's interpreter.

Checked again on 2026-10-01 against main at 0a5cad587: still present. The code is now at static/js/app.js:2079-2101 (saveWidth); the other locations have not moved.

Saved views (#259) are stored under views in the same per-table dictionary as the columns, page size, widths and shape. Every path through table_settings except the shape switch replaces that dictionary with one that has no views key, so the person's saved views, including the one the table opens as, disappear without a word.

  • Where: core/tables.py:660-719, Table.clean_settings, which builds cleaned = {"columns": columns, "page_size": page_size, "widths": widths} (line 713) and carries only shape across; core/views_tables.py:23-38, table_settings, which stores that result in place of the old settings, and stores None on Reset; static/js/app.js:1846-1868, saveWidth, which posts every width drag and every arrow-key resize to the same view; templates/partials/table/columns.html:46-51, where Apply, the up and down buttons and Reset post; core/tables.py:459-461, is_customised, true as soon as a view exists, so Reset is offered then.
  • What happens: a person saves Waiting three weeks and makes it the default, then widens the Company column by dragging it. The background POST runs clean_settings, whose result has no views, and save_settings stores it. The Views menu is empty and the table no longer opens as the default. The same happens on Apply or a move in the Columns menu. Reset says "Back to the usual columns." and removes the views as well. Checked: CompaniesTable.clean_settings(QueryDict("width=name&px=300&order=name&show=name"), current) with one stored view returns only the keys columns, page_size and widths.
  • Why it matters: the views are things the person built and named, and the commonest gesture on a table, resizing a column, loses all of them. Nothing in tests/test_saved_views.py or tests/test_tables.py stores a view and then saves columns.
  • A second effect of the same post: with a view applied (?saved=…), visible shows the view's columns, so the Columns form and saveWidth (which posts every shown header as show) write the view's columns into the person's own columns. After one drag, the table shows the view's columns even with no view applied.
  • Fix: in clean_settings, carry views across as shape is (if isinstance(current.get("views"), list): cleaned["views"] = current["views"]). Make Reset clear only columns, page size and widths (keeping views and shape), as its message says. For the width drag, post only width and px, and have clean_settings keep current["columns"] and current["page_size"] when no order arrives, so a drag under an applied view does not overwrite the person's columns.

Related to #259 (closed), which added saved views beside the stored columns and widths without carrying them through these saves.

Done when

  • tests/test_saved_views.py has tests that a stored view survives a width POST, an Apply, a move and a Reset to core:table_settings, and that a width POST made while a view is applied leaves the stored columns unchanged.
Found on 2026-09-29 in a read-only review of postulo at 95348908d, reading how table settings are saved and running `clean_settings` with the snapshot's interpreter. Checked again on 2026-10-01 against `main` at `0a5cad587`: still present. The code is now at `static/js/app.js:2079-2101` (`saveWidth`); the other locations have not moved. Saved views (#259) are stored under `views` in the same per-table dictionary as the columns, page size, widths and shape. Every path through `table_settings` except the shape switch replaces that dictionary with one that has no `views` key, so the person's saved views, including the one the table opens as, disappear without a word. - **Where:** `core/tables.py:660-719`, `Table.clean_settings`, which builds `cleaned = {"columns": columns, "page_size": page_size, "widths": widths}` (line 713) and carries only `shape` across; `core/views_tables.py:23-38`, `table_settings`, which stores that result in place of the old settings, and stores `None` on Reset; `static/js/app.js:1846-1868`, `saveWidth`, which posts every width drag and every arrow-key resize to the same view; `templates/partials/table/columns.html:46-51`, where *Apply*, the up and down buttons and *Reset* post; `core/tables.py:459-461`, `is_customised`, true as soon as a view exists, so *Reset* is offered then. - **What happens:** a person saves *Waiting three weeks* and makes it the default, then widens the *Company* column by dragging it. The background POST runs `clean_settings`, whose result has no `views`, and `save_settings` stores it. The *Views* menu is empty and the table no longer opens as the default. The same happens on *Apply* or a move in the *Columns* menu. *Reset* says "Back to the usual columns." and removes the views as well. Checked: `CompaniesTable.clean_settings(QueryDict("width=name&px=300&order=name&show=name"), current)` with one stored view returns only the keys `columns`, `page_size` and `widths`. - **Why it matters:** the views are things the person built and named, and the commonest gesture on a table, resizing a column, loses all of them. Nothing in `tests/test_saved_views.py` or `tests/test_tables.py` stores a view and then saves columns. - **A second effect of the same post:** with a view applied (`?saved=…`), `visible` shows the view's columns, so the *Columns* form and `saveWidth` (which posts every shown header as `show`) write the view's columns into the person's own columns. After one drag, the table shows the view's columns even with no view applied. - **Fix:** in `clean_settings`, carry `views` across as `shape` is (`if isinstance(current.get("views"), list): cleaned["views"] = current["views"]`). Make *Reset* clear only columns, page size and widths (keeping `views` and `shape`), as its message says. For the width drag, post only `width` and `px`, and have `clean_settings` keep `current["columns"]` and `current["page_size"]` when no `order` arrives, so a drag under an applied view does not overwrite the person's columns. Related to #259 (closed), which added saved views beside the stored columns and widths without carrying them through these saves. ## Done when - `tests/test_saved_views.py` has tests that a stored view survives a width POST, an *Apply*, a `move` and a *Reset* to `core:table_settings`, and that a width POST made while a view is applied leaves the stored `columns` unchanged.
tiagoagueda added this to the 0.5.0 milestone 2026-10-01 10:47:09 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Postulo/postulo#503
No description provided.