Allow table columns on Users page to be sorted

[Ryan J Ollos]

This has been on my mind since recent work on UserManagerPlugin in #10586. It should be fairly straightforward to make the columns sortable by clicking on the column headings, so that we can, e.g. sort by Last Login. Sorting by Last Login is the use case I specifically had in mind while considering this feature.

[Ryan J Ollos]

I'm going to hold off working on this ticket until we resolve #10741 and #10743 since there are overlapping changes to the user_table template.

[Ryan J Ollos]

I'll be patterning the implementation after [12286].

[Steffen Hoffmann]

(In [12515]) AccountManagerPlugin: Allow filtering of account list in user admin panel by account status, refs #9946 and #10682.

The filter implementation of Trac's query module was used as a guide. We won't care for banned accounts by default, just active ones and these marked as pending for approval, on registration time and via the email verification process, if enabled.

This could help a bit with rendering performance of the user admin panel too, i.e. if you accumulate many banned accounts over time.

[Steffen Hoffmann]

(In [12539]) AccountManagerPlugin: Fix user admin panel forms after [12515], refs #9946 and #10682.

The main form has been broken by adding another form, the user list filter, because HTML doesn't allow nesting of forms. Obviously I've been concerned too much about visual style to do full regression testing, sorry.

Another correction: Do no longer hide all bottons, when user deletion is not supported by any password store. This would unwarrantedly disable account approval/banning and access to the account properties clean-up too.

[Steffen Hoffmann]

(In [12606]) AccountManagerPlugin: Fix filter field names in user admin panel, refs #9946, #10682 and #10684.

This was flawed since the start with [12515] and I still didn't recognize the duplicate 'email' field in both, account property editor and new filter form when fixing their illegal nesting in [12539].

Thanks to Ryan J Ollos for notification to make me go and finally find it.

[Ryan J Ollos]

I really like the filter. I think the sorting and filter will nicely complement one another. The pagination mentioned in #10873 would be nice as well.

[Ryan J Ollos]

Last evening I started looking at implementing the table sorting in jQuery rather than HTML (as in [12286]). The upside is that the table sorting is extremely fast to implement when using a jQuery plugin such as ​jQuery Tablesorter, and the table can be sorted without a page refresh. The obvious downside is that the table sorting won't work when JavaScript is disabled. We'd also be adding another dependency, and if the Trac core adopts a jQuery table-sorting plugin down the road, the code would probably need to be migrated; probably not a big deal, however.

So here is my tentative plan:

1. Provide a patch that implements table sorting in HTML for the users table.
2. Open a ticket in the Trac core for implementing table sorting on the Admin Milestones, Components and Versions tables, and propose implementing the feature using a jQuery tabler-sorting plugin.
3. Possibly provide a patch for the users table that implements table sorting in JavaScript, overriding the HTML table sorting when JavaScript is available.

[Ryan J Ollos]

Just a quick follow-up to the comment on IRC: but consider implementing in SQL or Python rather than anything else, for performance and compatibility with the pager logic, that will come rather sooner than later, ok?.

I think we are thinking the same here. I suggested initially implementing the feature in HTML, and by that I mean to do the actual sorting server-side (as in [12286]), and allow the sorting to be invoked through some HTML interaction. I do think the client-side sorting in JavaScript is useful and worth exploring, but that is for latter, and may not work well for this particular table. I'm thinking more generally, and in some cases at least, the client-side sorting in JavaScript may prove to be useful (such as the Admin Components table).

[Steffen Hoffmann]

(In [12660]) AccountManagerPlugin: Complete filter fix for user admin panel, refs #9946, #10682 and #10684.

While removing the name clash in [12606], the same changes actually broke saving of filter values completely.

Thanks to slav0nic for confirmation of that unexpected discovery.

[Steffen Hoffmann]

(In [12738]) AccountManagerPlugin: Move pager to user list in accounts admin panel, refs #809, #9946, #10682, #10745, #10754 and #10873.

This should fix broken display of extra-long user lists, and it makes selections from user list useful for the clean-up page as requested.

Dumped access to anonymous session attributes for the current solution, so these are no longer available for clean-up in the admin web-UI, but I'll re-implement this later on, if it will be missed too much.

[Ryan J Ollos]

Looking at this again today, I'm wondering if the Max accounts per page should be moved to filter form.

On the Custom Query page it is positioned below the filters.

[Steffen Hoffmann]

I see your point and will give it a shot, when touching that template next time.

It has the potential to reduce complexity of that page, what is good, but I'll have to check at all three versions design (Trac 0.11/0.12./1.0). Each is significantly different from the other due to CSS and template modifications in-between, so it usually takes hours to get to a sufficiently compatible solution that fits all to some acceptable degree.

[Steffen Hoffmann]

(In [13241]) AccountManagerPlugin: Polish slide animation off 'Max accounts per page' preference box in users admin panel, refs #9946 and #10682.

Thanks to Ryan J Ollos for providing the patch to this improvement as well as background information to learn more about the underlying issues.