When filtering lists, their "FirstRow" is not reset

[solth]

The filters on process, task and user lists do not reset the "FirstRow" parameter of the lists. This results in empty search results for valid filters when applying a filter after using the paginator to navigate to a later page in the hitlist.

Steps to reproduce:

• set "Tabellgröße"/"Table size" in user settings to a sufficiently small value (for example the default value 10)
• open a page with a list containing more then 10 records
• navigate to the second page
• insert a filter that should reduce the number of records to at least 1, but less than 10
• => the list is empty and doesn't show the expected records, because it remains on - the now invalid - page 2 even though the filtered list of records has fewer than 10 entries and therefor only produces one page in the filtered "hitlist"

[matthias-ronge]

The typical UI behavior is that after a new search, i.e. changing filter, page 1 is shown, even if there would be enough data that there is still content on the page you were on before. I would suggest implementing it that way in Production, too.

[matthias-ronge]

loosely related to #3641

[henning-gerhardt]

Re-opening this issues as the issue is existing again.

I can re-produce this issue in 3.6.0-SNAPSHOT from 3 March 2023, release 3.7.0 and release 3.7.1 and I think this is even happening on the current master branch.

After changing the filter on the process list or task list with lower amount of hits than the current filtering (f.e. from 244 hits to 2 and staying on page two or three of the 244 hits) the new hits are hidden and if the amount of hits fits on one page the navigation arrows are disabled so I must hard reload (Shift F5) the browser tabs to see the new hits of the new filtering.

[solth]

Strange, I am unable to re-produce the error in the current master. When I navigate to the last page of the process list and then filter by the ID of a process from the first page, the paginator is correctly reset to the first page, see video below:

Bildschirmaufnahme.2024-12-11.um.19.35.47.mov

[henning-gerhardt]

Strange. With the current master and most recent 3.7.x and 3.8.x branches I can not reproduce this issue any more :-(

I don't know if all the search requests which are executed in the background while editing the filter (see #6221 (comment)) are fixing or hiding this issue but at least this background searches are annoying. // Edit: for this I opened #6348