With the new possibilities of setting project depended configurations with mantis 1.0 the Severity should be raised from "feature" to "minor" or "major", as it is a bug in the current CVS-head. (I experienced it with a project depended "show_view" mantis_config_table entry, but probably it also applies to mure security relevant cases).

Warning: The above patch has a minor problem with hierarchical projects: If we switch from a project A to a project C (which is a subproject of B), then the current_project is switched correctly but the "Switch project option list" on the top right corner is missing the information about the parent and therefore cannot set the "select" tag and "ALL Projects" is displayed there.

Yes. I confirm it is very important.
If I view an issue with another current project (by link from an email, for instance), all lists (status, assign to, etc...) are wrong.

This issue should be re qualified as major AND critical for 1.0.0

Fixed in CVS.

bug_view_advanced_page.php -> 1.70
bug_view_page.php -> 1.73

After discussion with the other developers, this fix breaks the tracking of filters. This behavious was removed from earlier versions. I've backed the change out of CVS.

CVS fix was removed.

bug_view_advanced_page.php -> 1.71
bug_view_page.php -> 1.74

Will this issue be fixed, so ?
Because it's a fault of safety in the workflow.

Alternatives to implement the fix are being discussed.

New approach submitted to CVS. helper_get_current_project() has an override to be used on bug view/update/report pages if bug project is different than current project.

bug_report_advanced_page.php -> 1.50
bug_report_page.php -> 1.53
bug_update_advanced_page.php -> 1.86
bug_update_page.php -> 1.89
bug_view_advanced_page.php -> 1.72
bug_view_page.php -> 1.75
core/helper_api.php -> 1.60

For my initial problem this fix does not help. As config_inc and custom_strings_inc are parsed before bug_view_page.php the override comes too late.

I must admit that this is due to my personal needs of project depended status names and that the more severe problems of mismatching reporters will probably be fixed by the current patch.

Thus, if the developers decide that the my problem is a "won't fix", the issue may be set to "resolved" again. I just wanted to note that the originally posted problem was not resolved.

Perhaps one has the time to explain to me what´s the problem with reloading the page, i.e. what does "breaks tracking of filters" mean, so that I could think of a better solution for me and for you.

List "assign to" in bug_change_status_page.php is wrong.

It is ok in bug view.

One scenario that would show the problem with your fix is as follows. Open view_all_bugs in a window, with All Projects selected. From here, open another window from one of the bug links. In a few minutes, the filter window will update and take on the new project value. It is possible that all of the filter settings would be lost if they are not appropriate for the new project.

More changes submitted to CVS.

bug_assign.php -> 1.42
bug_change_status_page.php -> 1.22
bug_monitor.php -> 1.28

bug_actiongroup*.php still needs to be fixed.

@thraxisp:
Thanks for the explanation.
I would consider this as a bug in the filters :-).
Starting from view_all_bug_page, all Projects there are so many possibilities to change implicitly the page after reloading:
1) Open another "view vissues" and change the filter there
2) Click on "Report Issue"... you have to choose a project here. (Additionally the display changes to the selected porject, but the "current project switch" on the right top still shows "All Projects")
3) Click on a Project name listed in the "Category" column (perhaps thats a different bug 0005787)

I accept your opinion, but I think that it also could be considered as more consistent to change the current project (and you wouldn´t have to patch dozen of places).

Best would be to fix the filters, but this is probably not so easy and a different story... see 0005790

Additional minor inconsistency:

If there is a project mismatch and you press "report issue" the issues is reported for the project of the "current project switch" and not for the project of the bug you looked at before.

I do agree with polzin.

Users usually knows that the issue they're viewing is part of the current project displayed.

So, viewing an issue with a "wrong" current project disturb them.

Fix for bug_groupaction* submitted to CVS.

Will look at rewriting this in the next release to address the concerns in 0005790 in the next major revision.

bug_actiongroup.php -> 1.47
bug_actiongroup_page.php -> 1.51
core/config_api.php -> 1.28
lang/strings_english.txt -> 1.259