View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005432 | mantisbt | bugtracker | public | 2005-04-12 17:12 | 2005-07-23 02:23 |
Reporter | polzin | Assigned To | thraxisp | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 0.19.2 | ||||
Fixed in Version | 1.0.0rc1 | ||||
Summary | 0005432: Viewing a bug should change the "current project" | ||||
Description | I need to have different configurations for different projects. I played around with custom_strings_inc and config_inc and it works quite well. One problem is: If a user jumps to a bug (e.g. from "All Projects", by giving the Bug-ID, by relations...) the bug_view page displays the issue but does not change the "current project". Therefore, the bug_view may work with the wrong configuration. A patch is included. | ||||
Additional Information |
Index: bug_view_advanced_page.php RCS file: /cvsroot/mantisbt/mantisbt/bug_view_advanced_page.php,v * 31,36 **
| ||||
Tags | No tags attached. | ||||
related to | 0005790 | acknowledged | different filters, different projects in one session | |
related to | 0005722 | closed | thraxisp | bug_actiongroup_page.php : drop down list doesn't match the project |
related to | 0005969 | closed | thraxisp | Incorrect recipients for notifications |
related to | 0003897 | closed | grangeway | inconsistent list of "remindable" user when jumping to a bug while in a private project |
child of | 0005460 | closed | vboctor | Critical Issues to Fix for Mantis 1.0.0 Release |
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. |
|
This issue should be re qualified as major AND critical for 1.0.0 |
|
Fixed in CVS. bug_view_advanced_page.php -> 1.70 |
|
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 |
|
Will this issue be fixed, so ? |
|
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 |
|
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_actiongroup*.php still needs to be fixed. |
|
@thraxisp: 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 |
|