Could you provide more details? Are all of your projects private?

I can't see any change in the code between the versions you mentioned that affect the reporter list.

Yes.
I use a private project and 3 private sub-projects (related to the primer).

When the project is selected, the reporter list is wrong (too few members).

Private projects are only accessible to those on the project list (Manage -> Manage Project -> select project). The exception is those who, by default, have access rights greater than $g_private_project_threshold (default DEVELOPER).

Have the missing people been added to the project?

Yes, of course. As I was saying, with a previous version of core/filter_api.php, issue is solved.

The differences between 1.107 and 1.112 are either un-related (additions for RSS feeds) or cosmetic (replacement of strings with constants). I don't think that this is the root cause.

Have you changed versions of core/print_api.php as well? This is where the user list is created. There were some performance optimizations here.

Do the missing users share any characteristics?

Amazing...

I'm not at work right now. I will try and reinstall 1.112.

I should give more informations...

I found my problem.

I have 1 project and 2 sub-projects.
Users are the same for each project but, in manage_config_work_threshold_page.php, nobody can report for the project (issues can be reported only in sub-projects).

So, reporter list for the project only displays [All].

I wanted to use project as a way to have an agregated view of issues for all sub-projects, with possibility to filter... but filter only displays reporters, developers, etc... of the current project, not of the sub-projects...

Is there another way to get this ?

Well, with the last CVS HEAD, Reporter List is OK for the project but returns all users (and it's a prvzte project) for the sub-project.

Could you please open another issue to track the request to use a project to aggregate the users from the subprojects?

As for the last issue, where opening a subproject gives you all reporters. How are you selecting the new subproject, via the dropdown menu or project list menu? I found no issues with the former. There seems to be a minor display issue with the latter.

Fix for subproject selection via project menu bar submitted to CVS.

core/html_api.php -> 1.172

I don't understand how [Reporter] filter works.

For a private current project, the filter returns not only users defined for the project (as reporter and above) but also others users based on their "default" rigths (for public projects).

Idem with [Monitored] and [Assigned] filter.

How they are supposed to work for a private project ?

Two groups of users can access private projects. Any user explicitly added to the project by an admin, as well as any user who meets the "private_project_threshold" (default administrator) can access the project. This should be listed on the project page.

The lists in the filter menu are derived from this information with restrictions based on access level. Reporters meet the "report_bug_threshold", monitor meets the "monitor_bug_threshold", and assigned is the "handle_bug_threshold" setting.

So, I have a bug :

private_project_threshold is set as default value (ADMINISTRATOR).

But users listed by the filter are not a subset from the users added to the project.

It's the same list I have when [All project] is the current project.

Idem with the Monitor filter.

[Assign to] filter seems false too, but with different results. It's not the same as [All projects]... but contains users not added to the project...

This doesn't seem to be possible unless the project is actually public. Would it be possible to get a copy of your database for test purposes? Please email me privately.

Where can I find your email ?
I can send you copy of my entire database except bug_file_table and my customization files.

Ok. I've found. I've sent a mail to you. Thanks a lot

Fixed in CVS. There was an obscure error in the threshold calculation.

core/project_api.php -> 1.75