make the user overview page and the user creation page separate pages

Replying to mderickx:

Since we have quite a few users on our system it takes some time to load the user admin page (trac.ourdomain.org/admin/accounts/users to be precise).

Here is the original mailing list post about the issue. This is only an issue since upgrading to Trac 0.12, right? How many users do you have?

Yes indeed that was only since upgrading to trac 0.12 . I put more relevant information at the google groups discussion. We have slightly more then 800 accounts.

Replying to mderickx:

Yes indeed that was only since upgrading to trac 0.12 . I put more relevant information at the google groups discussion. We have slightly more then 800 accounts.

Do you use account locking at that system or other advanced features? Some have been added to AcctMgr lately, and despite not getting complaints by now, i.e. checking all accounts for lock condition might contribute to the lag that you notice.

I understand that your idea could help for creating new users, but I'd rather not separate the user form from that page, because it's much harder to change account information without seeing current values. We should profile this instead and improve performance as much as possible, since I'm aware of at least one other installation with that many users.

I'm not aware of us using any advanced features, we just use a password file specific for trac. The relevant config can be found at the google groups discussion.

On the profile part of things. I'm reasonably fammiliar with python but not so much with the inner workings of trac and the account manager plugin. If you give me some hints on where to start looking for the functions that are being called when the mentioned page is loaded I can maybe track down the source of the slowness myself.

I also oppose separating out the account list and create account features into separate pages. Profiling and optimization sound like good goals, and we could also consider paginating the account list.

That would also help a lot. Another possible solution might be modifying the page in such a way that it loads the account creation form first and then the account overview list. I'm b.t.w. still willing to help with the profiling, but still have no clue where to start looking. Could someone give me the name of the function that returns the account list?

Replying to mderickx:

Could someone give me the name of the function that returns the account list?

I'll have to take a closer look at the code, but plan to get back to you soon.

Replying to mderickx:

That would also help a lot. Another possible solution might be modifying the page in such a way that it loads the account creation form first and then the account overview list.

I don't know, if this would even work in all recent browsers. Better look for another solution.

I'm b.t.w. still willing to help with the profiling, but still have no clue where to start looking. Could someone give me the name of the function that returns the account list?

Great. I do really care for performance. Most of the data harvesting work is done inside acct_mgr.admin.fetch_user_data, but more in AccountManagerAdminPanel._do_users too.

Odd Simon Simonsen wrote about profiling Trac requests in his blog, including support code to help with that task, an excellent jump-start and reference: https://www.coderesort.com/u/simon/blog/2011/09/06/trac_profiling

(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.

(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.

(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.

(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.

(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.

There have been more complains from other installations, where the user list would not even load at all, caused i.e. by thousands of spam account registrations.

I'm very eager to learn, if the new pager resolves your issue with long load times of accounts users admin panel too.

From testing with Trac 0.11 I recognized, that placement of the "max items per page" form is pretty much less than ideal yet.

Floating it over the list is certainly not an option, so I'll try to move it above the list to save some precious space for the user list.

(In [12739]) AccountManagerPlugin: Tweak 'max_per_page' preferences dialog to save space for user list, refs #9946.

Hey, someone has shrunken the preferences side-panel! Done to allow full-width user listing, not only in pager mode.

(In [12745]) AccountManagerPlugin: CSS clean-up, getting decent presentation for Trac 0.12 too, refs #9946.

While most changes are just to unify formatting, some more are specifically done to prevent badly interfering Trac 0.12 styles from admin.css.

I was deliberately shocked, when testing latest trunk in production today.

At first I thought it was another IE bug, but thanks to Firebug I could trace it down to styles inherited from admin.css. I had tested with Trac 0.11 and 1.0 before, but this one apparently was a 0.12-only issue.

Another reason to hurry for next release and subsequent branching to refocus development target. I'll certainly not want to support yet another major Trac version with the same code base.