Order indices in dynamic filter form

[LeXofLeviafan]

As far I'm aware, the number in the fltN_ part of filter name refers to the filter order in the form, intended to retain said order on page refresh; and in the form itself it's handled by the lastCount variable.

The way it's currently handled, however, is as follows:

• initially existing filters have stable indices (increasing by 1, starting from 0);
  this means filter indices are reset on form resubmission (which is also done by static links such as in pagination)
• new filters are added with a gap of 1 (so if there's 3 filters initially with indices up to 2, the next one to be added will have index 4, and if there's none, the first one added will have index 1);
  this means new filter indices differ from the ones they get on form resubmission
• if subtype of an existing filter is changed (i.e. by selecting a different one), it's assigned a new index as if it was a new filter added to the bottom of the list;
  this means the order of rows in the filter form will change after the form submission if any of them had their types modified in-place
• the filters are sorted lexicographically, but there's no check for filter indices > 9 (and such filters are forcibly renumbered in pagination links)
  this means when there's more than 9 filters, their positions will change around on every form submission (and/or when following pagination links)

Is this actually the intended behaviour? Because I'm pretty sure the intuitively expected behaviour would be for the filters to retain their indices and UI order across page refreshes (except for when a filter is removed, anyway).

[LeXofLeviafan]

Case in point: in a table without sortable columns, I've implemented sorting as a custom ‘filter’. This had a side effect of allowing to sort by multiple fields (e.g. “sort records by title in reverse order, and sort those with the same title by URL instead”)
?flt0_order_by_title=desc&flt1_order_by_url=asc

Now suppose the user wants to change the primary sorting field without changing the secondary one. He'll be expecting for the filters he set to retain their order after pressing ‘Apply’, right?

And yet what he gets after submitting his changes will be…
?flt3_order_by_tags=desc&flt1_order_by_url=asc

[LeXofLeviafan]

Example of filters being reordered when following pagination links:

Page 1 (initial)

Page 2 (opened from page 1)

Page 3 (opened from page 2)

[LeXofLeviafan]

An external ad-hoc fix was implemented in this pull-request (see bukuserver/static/bukuserver/js/filters_fix.js for the frontend fixes, and bukuserver/views.py for the backend fixes).

Note that since it's an external fix, the pagination links are fixed in the JS (the part starting with .pagination a:not([href^=javascript]) selector search), instead of fixing their generation code.