PR https://github.com/mantisbt/mantisbt/pull/238

The proposed fix is for master, I plan to backport it to 1.2.x if accepted.

The reason for targeting 1.2 was that our tracker was heavily affected by this issue. Now that we have upgraded it, a 1.3.x target is probably best (assuming I ever find the time to get to it :/).

The impact is still major IMO, although not blocking for release since not so many instances are likely to be affected by this.

for solving half of the problem: why not rewrite the user selector in filter section to fetch all users that appear in existing bugs?

This would be a query (fine tuned to some degree by filter parameters), but surely less work on the server.
The real problem here is that for "all projects", its fetching and combining a list of all users, repeating for every project.

And, for an improved resolution, change the select into an autocomplete widget (when available by js), with progressive remote search

change the select into an autocomplete widget (when available by js), with progressive remote search

This is exactly where I want to go. I'm pretty sure I have a feature branch with initial research on this somehere, but I can't find it ATM.

I'm pretty sure I have a feature branch

Maybe this one?
https://github.com/dregad/mantisbt/commits/dynamic-reporter-select

Independet from AJAX some other optimizations that did not make their way into the product but might be worth to review them again.

https://github.com/mantisbt/mantisbt/pull/238
https://github.com/mantisbt/mantisbt/pull/271

^^^ regarding that:
please have a look at 0020225, its somewhat related to the affected core functions

i have this branch with a rewrite of the affected functions
https://github.com/cproensa/mantisbt/tree/project_user_list

this shows great improvement, as testing with 20k users, 0000054:0000100 projects
still it can get faster, but i have some questions before it can be done
should i open a PR to comment there?

PR: https://github.com/mantisbt/mantisbt/pull/668

Changing status to minor based on @dregad's 0017577:0051429 and offline discussion with @atrol since we are trying to identify blocking issues for v1.3. Though this may make it before the release, it is not blocking.

cproensa's PR https://github.com/mantisbt/mantisbt/pull/769 (see related changeset below) greatly improves this performance issue.

Independent from the AJAX approach and other optimizations, but will also enhance performance at least for some of the user lists, e.g. "Reporter" on "View Issues" page:

Wouldn't it be better to list just the users that reported an issue for the current project (distinct reporter_id from bug table)?

This will reduce the number of listed users and solve also the issue that we are not able to search for issues that have been reported by deactivated or deleted users, see 0010141.

distinct xxx from bug table

yes, that would be the simplest solution. For several filter fields this should be a valid approach.

able to search for issues that have been reported by deactivated or deleted users

but, irrc, then someone can complain that a reporter gets a hint of the existence of the deactivated users (i dont think this is an issue, just saying)

Now that theres some will to change things it filter api, this is a thing that should be done

someone can complain that a reporter gets a hint of the existence of the deactivated users

We could add a new option for it, something like $g_show_deactivated_users_threshold = MANAGER;
But this will not prevent a user from using "View Issues" page to list all issues and look for users which are displayed strike out.
So adding this option would just let some people think that users with access level < $g_show_deactivated_users_threshold can't find deactivated users.

Unless someone objects, I'd like to mark this one as resolved, considering cproensa's commit MantisBT master b433e7e6 - on this tracker it takes about 3-5 seconds to load the reporters' list (about 35K users), which I think is acceptable.

Other ideas for improvement should be tracked separately.

or when using adm_config_report.php, especially when the current project is 'All Projects'

This is still quite slow.
Didn't have a deeper look, might be caused by missing indices on mantis_config_table.

@cproensa wrote in 0017577:0051728

And, for an improved resolution, change the select into an autocomplete widget (when available by js), with progressive remote search

Opened 0025666 to track this