server side sorting

[jonbulz]

Short description

Add server-side sorting (for contacts) in list views. Clicking a table header in the list view will toggle the sorting by that column. Clicking the header again will reverse the sort. Multiple columns can be used for sorting simultaneously.

In the discussion, we agreed that sorting is only enabled for a single column at a time. If a different sortable table header is clicked, the sort switches to that column. Sorting can be disabled by clicking on the tabel header a third time. Sorting is enabled for the following columns in the Contacts list view:

• Area of Responsibility
• Name
• E-Mail
• Phone Number
• Mobile Phone Number
• Website

Proposed changes

• Define table_fields in list view (only for contacts thus far)
• Add _sortable_table_header template to generate table header from table fields
• Add sort_tags to make table header with sort label clickable
• Update FilterSortMixin to handle sort fields correctly

Side effects

• Hopefully none, but it is important that table_fields matches the rows of the list view, otherwise there could be table header/column mismatches

Faithfulness to issue description and design

There are no intended deviations from the issue and design.

How to test

Go to Contact list view, test sorting by clicking on column headers. Test that sorting works together with searching.
Thus far, sorting is only enabled for Contacts. Other list views should not be affected by the changes of this PR. Check that other list views are not broken and the default ordering is not affected.

Resolved issues

Fixes: #3347
Fixes: #3880

---

Pull Request Review Guidelines

[jonbulz]

I just noticed that this doesn't work well together with our search form. I'm working on a solution

[MizukiTemma]

Looks good 😸

I have just a small suggestion to add " ▲▼" to columns that can be used for sorting but not yet clicked, to singnalise users.

[hauf-toni]

From a usability perspective I'm not too happy about the triangles as they don't really align with best practice and might confuse users. Since this functionality is more about sorting then about filtering I would recommend to go with arrows that sort the content like in this image:

Behavior: The arrow should be inactive before it is clicked first and serve as an visual indicator. nothing happens until the user clicks it. after that it cycles through states like (unsorted →) ascending → descending and back to unsorted. Please let me know your thoughts.

[osmers]

I think arrows are also good - just to make sure: there is either an up arrow (ascending), a down arrow (descending) or no arrow (unsorted)? @hauf-toni
Behaviour is good - as would be expected, I think :)

[hauf-toni]

I think arrows are also good - just to make sure: there is either an up arrow (ascending), a down arrow (descending) or no arrow (unsorted)? @hauf-toni Behaviour is good - as would be expected, I think :)

We could show it as not active (grey color) until clicked, then as active (black).

[jonbulz]

Screen.Recording.2025-12-19.at.16.58.46.mov

Here's what I planned: Initially, all columns look the same. If a sortable column header is clicked, an arrow will appear next to the title. The sort can be reversed by clicking the same column again. The sort for that column is reset by double-clicking the column header.
The last part (resetting the sort by double-click) would be blocked by #4009

[osmers]

Here's what I planned: Initially, all columns look the same. If a sortable column header is clicked, an arrow will appear next to the title. The sort can be reversed by clicking the same column again. The search for that column is reset by double-clicking the column header. The last part (resetting the sort by double-click) would be blocked by #4009

Just to make sure - what you are showing in the video is obviously what works already but then there's a reset for the search that does not work yet? Can you explain to me the difference between sort and search in this case? @jonbulz

[jonbulz]

Here's what I planned: Initially, all columns look the same. If a sortable column header is clicked, an arrow will appear next to the title. The sort can be reversed by clicking the same column again. The search for that column is reset by double-clicking the column header. The last part (resetting the sort by double-click) would be blocked by #4009

Just to make sure - what you are showing in the video is obviously what works already but then there's a reset for the search that does not work yet? Can you explain to me the difference between sort and search in this case? @jonbulz

Sorry, I meant sort both times. What works is to sort by a column by clicking on the header, and then reversing the sort by clicking again. The only way to reset the sort in the current implementation is to refresh the whole page. That's what I meant.
It's not hard to implement an event listener that resets the sort on a column when there is a double-click on the header. In fact, I already did that, and I show it in the video. But it needs some custom JavaScript code, and that's why I need to wait for the frontend refactor. Because I didn't want this PR to be blocked by the frontend refactor, I did not include the double-click part here yet

[jarlhengstmengel]

What is the current state? Should I review or is this blocked by #4009?

[jonbulz]

What is the current state? Should I review or is this blocked by #4009?

It's ready for review. The part that needs #4009 will come in a separate PR

[hauf-toni]

Screen.Recording.2025-12-19.at.16.58.46.mov
Here's what I planned: Initially, all columns look the same. If a sortable column header is clicked, an arrow will appear next to the title. The sort can be reversed by clicking the same column again. The sort for that column is reset by double-clicking the column header. The last part (resetting the sort by double-click) would be blocked by #4009

Pardon my late reply, I just wanted to add that from a usability perspective I would not recommend to hide the functionality. As the sorting is not visible before clicking the first time the the user needs insider knowledge to access it. I would strongly recommend (with my ui/ux hat on, not the PO hat 🧢 ) that we adjust it to be visible before it clicked, eg by displaying the arrow as disabled first.

[jonbulz]

I'd love to give you the opportunity to test this yourself @hauf-toni because I think it's hard to capture the user experience in a video. However, changing the icons and the way they are displayed is not a big code change. We could either:

• wait for this to be testable on the test system before changing the design
• change the design now, but I'd ask for concrete instructions then
• schedule a meeting where I show the current implementation in my local environment

[osmers]

I'd love to give you the opportunity to test this yourself @hauf-toni because I think it's hard to capture the user experience in a video. However, changing the icons and the way they are displayed is not a big code change. We could either:

• wait for this to be testable on the test system before changing the design
• change the design now, but I'd ask for concrete instructions then
• schedule a meeting where I show the current implementation in my local environment

We could have a look today during our meeting :)

[jonbulz]

In our discussion today, we decided to abolish multi-column sorting and reset the sort by clicking the header and cycling through:
no sort -> ascending -> descending -> no sort

[dkehne]

Review Summary

What it does

1. Adds server-side sorting for contact list view (clickable column headers)
2. Creates reusable _sortable_table_header.html template
3. Creates sort_tags.py with sort_link and render_table_header template tags
4. Updates FilterSortMixin to derive sort_fields from table_fields
5. Changes search form from POST to GET (for URL-based sorting/filtering)
6. Adds default ordering ["-pk"] to AbstractBaseModel

Key observations

1. Good reusable architecture - table_fields defines both sortable fields and labels in one place:

   table_fields = [
       (None, _("Name of related location")),  # None = not sortable
       ("area_of_responsibility", _("Area of responsibility")),  # sortable
       ...
   ]

2. Sort toggle works correctly - Click cycles: unsorted → ascending (▼) → descending (▲) → unsorted

3. POST to GET change - Necessary for URL-based sorting to work with pagination and bookmarkable URLs

4. Also adds mixins to POIListView - Extends sorting/filtering to POIs as well

5. Potential concern: AbstractBaseModel ordering - Adding ordering = ["-pk"] affects ALL models inheriting from it. This is a broad change - were other list views tested to ensure this doesn't break existing sorting?

Note: There's an ongoing design discussion in comments about the arrow styling. Waiting for design input.

[jarlhengstmengel]

Thank you very much! Works as I would expect! I have the feeling that the ongoing discussion is over so I approve 👍 Don't forget to fix the failing pipeline!

[jonbulz]

@jarlhengstmengel I fixed the pipeline. That required a few small code changes, so if you get around to it, I'd happily accept another review 😊 If not, I'll count your approval as still valid.
The translations come from the script, so I hope what it does is correct 🤷

[jarlhengstmengel]

@jonbulz sorry for the late response, still looks good to me!

[jarlhengstmengel]

And thanks for adding the ADR :)

[juliankehne]

Tested on cms-test. Didn't notice any issues.

[osmers]

@jonbulz when was the decision taken not to sort by related POI? I'm sorry to only be asking now - I just noticed while testing and then saw that related POIs are not mentioned above in the description and I cannot remember when and why the decision was taken.

[jonbulz]

@osmers it's a related field and thus not in the same table in the database. To enable sorting by related fields might need a separate PR that I would have to look into

[jonbulz]

@jonbulz when was the decision taken not to sort by related POI? I'm sorry to only be asking now - I just noticed while testing and then saw that related POIs are not mentioned above in the description and I cannot remember when and why the decision was taken.

@osmers actually, #4194 now introduces sorting by related fields. If you think this it is important enough you could open a ticket to include sorting by related POI. should be a simple change now :)