Bug #20526
closed
Sorting should break ties consistently (stable sort order)
Description
Reported that when you sort by "name" in workbench and have items with the same name (unlike groups and collections, container requests do not have unique name constraint) it does not break ties consistently, resulting in different order across refreshes. The order parameter of the query from WB2 should use created_at as the secondary sort key.
Related issues
Updated by Tom Clegg over 1 year ago
- Description updated (diff)
Changing secondary sort key from modified_at to created_at, because modified_at can also change between refreshes and cause the same issue, albeit less frequently.
Updated by Peter Amstutz about 1 year ago
- Target version changed from Future to Development 2023-11-08 sprint
Updated by Peter Amstutz about 1 year ago
- Subject changed from Sorting should break ties consistently to Sorting should break ties consistently (stable sort order)
Updated by Peter Amstutz about 1 year ago
- Related to Bug #21077: Background refresh should not trigger the spinner added
Updated by Peter Amstutz about 1 year ago
- Target version changed from Development 2023-11-08 sprint to Development 2023-10-25 sprint
Updated by Peter Amstutz about 1 year ago
20526-sort-order @ arvados-workbench2|452a671ede48733833eb84d1a5c19f0441db606a
<https://ci.arvados.org/... (link to developer test job on jenkins)>
- All agreed upon points are implemented / addressed.
- yes
- Anything not implemented (discovered or discussed during work) has a follow-up story.
- n/a
- Code is tested and passing, both automated and manual, what manual testing was done is described
- passes integration tests run locally
- Documentation has been updated.
- n/a
- Behaves appropriately at the intended scale (describe intended scale).
- n/a
- Considered backwards and forwards compatibility issues between client and server.
- n/a
- Follows our coding standards and GUI style guidelines.
- yes
When sorting by column on various data tables, it now adds "created_at desc" to the sort order. This ensures that it breaks ties consistently (newest to oldest). I choose to use descending always (instead of sortDirection) because sort direction should only apply to the main key and it seems less confusing if items with the same sort value continue to appear in the same order, even if the main sort order is reversed.
Updated by Peter Amstutz about 1 year ago
- Status changed from New to In Progress
Updated by
Updated by Peter Amstutz about 1 year ago
- Status changed from In Progress to Resolved