View Issue Details

IDProjectCategoryView StatusLast Update
0005432mantisbtbugtrackerpublic2005-07-23 02:23
Reporterpolzin Assigned Tothraxisp  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version0.19.2 
Fixed in Version1.0.0rc1 
Summary0005432: 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

<pre>
Index: bug_view_advanced_page.php

RCS file: /cvsroot/mantisbt/mantisbt/bug_view_advanced_page.php,v
retrieving revision 1.69
diff -c -r1.69 bug_view_advanced_page.php
*** bug_view_advanced_page.php 12 Feb 2005 20:01:05 -0000 1.69
--- bug_view_advanced_page.php 12 Apr 2005 16:45:52 -0000


* 31,36 **
--- 31,44 ----

    $t_bug = bug_prepare_display( bug_get( $f_bug_id, true ) );
  • if( $t_bug->project_id != helper_get_current_project() ) {

  • in case the current project is not the same project of the bug

  • ...we set on fly the current project. This to avoid problems

  • $t_redirect_url = "set_project.php?project_id=" . $t_bug->project_id .

  • "&make_default=no&ref=" . urlencode( "bug_view_advanced_page.php?bug_id=" . $f_bug_id );

  • print_header_redirect( $t_redirect_url );

  • }

  • compress_enable();
    
    html_page_top1( bug_format_summary( $f_bug_id, SUMMARY_CAPTION ) );

    Index: bug_view_page.php

    RCS file: /cvsroot/mantisbt/mantisbt/bug_view_page.php,v
    retrieving revision 1.72
    diff -c -r1.72 bug_view_page.php
    *** bug_view_page.php 12 Feb 2005 20:01:05 -0000 1.72
    --- bug_view_page.php 12 Apr 2005 16:45:52 -0000


    * 34,39 **
    --- 34,47 ----

    $t_bug = bug_prepare_display( bug_get( $f_bug_id, true ) );
  • if( $t_bug->project_id != helper_get_current_project() ) {

  • in case the current project is not the same project of the bug

  • ...we set on fly the current project. This to avoid problems

  • $t_redirect_url = "set_project.php?project_id=" . $t_bug->project_id .

  • "&make_default=no&ref=" . urlencode( "bug_view_page.php?bug_id=" . $f_bug_id );

  • print_header_redirect( $t_redirect_url );

  • }

  • $t_access_level_needed = config_get( 'view_history_threshold' );
    $t_can_view_history = access_has_bug_level( $t_access_level_needed, $f_bug_id );

</pre>

TagsNo tags attached.

Relationships

related to 0005790 acknowledged different filters, different projects in one session 
related to 0005722 closedthraxisp bug_actiongroup_page.php : drop down list doesn't match the project 
related to 0005969 closedthraxisp Incorrect recipients for notifications 
related to 0003897 closedgrangeway inconsistent list of "remindable" user when jumping to a bug while in a private project 
child of 0005460 closedvboctor Critical Issues to Fix for Mantis 1.0.0 Release 

Activities

polzin

polzin

2005-06-01 03:49

reporter   ~0010308

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

polzin

polzin

2005-06-01 04:22

reporter   ~0010310

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.

malaussena

malaussena

2005-06-07 12:01

reporter   ~0010393

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.

malaussena

malaussena

2005-06-08 05:34

reporter   ~0010405

Last edited: 2005-06-08 05:42

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

thraxisp

thraxisp

2005-06-09 16:05

reporter   ~0010456

Fixed in CVS.

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

thraxisp

thraxisp

2005-06-09 21:21

reporter   ~0010464

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.

thraxisp

thraxisp

2005-06-09 21:28

reporter   ~0010465

CVS fix was removed.

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

malaussena

malaussena

2005-06-10 00:15

reporter   ~0010467

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

thraxisp

thraxisp

2005-06-10 09:36

reporter   ~0010473

Alternatives to implement the fix are being discussed.

thraxisp

thraxisp

2005-06-12 17:07

reporter   ~0010489

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

polzin

polzin

2005-06-13 04:38

reporter   ~0010492

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.

malaussena

malaussena

2005-06-14 04:35

reporter   ~0010504

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

It is ok in bug view.

thraxisp

thraxisp

2005-06-14 17:58

reporter   ~0010526

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.

thraxisp

thraxisp

2005-06-14 18:01

reporter   ~0010527

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.

polzin

polzin

2005-06-15 07:47

reporter   ~0010531

@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

polzin

polzin

2005-06-15 07:54

reporter   ~0010533

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.

malaussena

malaussena

2005-06-15 08:19

reporter   ~0010534

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.

thraxisp

thraxisp

2005-06-15 22:31

reporter   ~0010544

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

Issue History

Date Modified Username Field Change
2005-04-12 17:12 polzin New Issue
2005-06-01 03:49 polzin Note Added: 0010308
2005-06-01 04:22 polzin Note Added: 0010310
2005-06-07 12:01 malaussena Note Added: 0010393
2005-06-08 05:34 malaussena Note Added: 0010405
2005-06-08 05:42 malaussena Note Edited: 0010405
2005-06-08 10:41 thraxisp Relationship added child of 0005460
2005-06-08 10:46 thraxisp Severity feature => major
2005-06-08 10:46 thraxisp Status new => confirmed
2005-06-09 10:30 thraxisp Assigned To => thraxisp
2005-06-09 10:30 thraxisp Status confirmed => assigned
2005-06-09 16:05 thraxisp Status assigned => resolved
2005-06-09 16:05 thraxisp Fixed in Version => 1.0.0a4
2005-06-09 16:05 thraxisp Resolution open => fixed
2005-06-09 16:05 thraxisp Note Added: 0010456
2005-06-09 21:21 thraxisp Status resolved => feedback
2005-06-09 21:21 thraxisp Resolution fixed => reopened
2005-06-09 21:21 thraxisp Note Added: 0010464
2005-06-09 21:28 thraxisp Note Added: 0010465
2005-06-09 21:28 thraxisp Fixed in Version 1.0.0a4 =>
2005-06-10 00:15 malaussena Note Added: 0010467
2005-06-10 09:36 thraxisp Note Added: 0010473
2005-06-10 09:36 thraxisp Status feedback => assigned
2005-06-12 17:07 thraxisp Status assigned => resolved
2005-06-12 17:07 thraxisp Fixed in Version => 1.0.0a4
2005-06-12 17:07 thraxisp Resolution reopened => fixed
2005-06-12 17:07 thraxisp Note Added: 0010489
2005-06-13 04:38 polzin Status resolved => feedback
2005-06-13 04:38 polzin Resolution fixed => reopened
2005-06-13 04:38 polzin Note Added: 0010492
2005-06-14 04:35 malaussena Note Added: 0010504
2005-06-14 17:58 thraxisp Note Added: 0010526
2005-06-14 18:01 thraxisp Note Added: 0010527
2005-06-15 07:47 polzin Note Added: 0010531
2005-06-15 07:54 polzin Note Added: 0010533
2005-06-15 08:19 malaussena Note Added: 0010534
2005-06-15 08:30 thraxisp Relationship added related to 0005790
2005-06-15 22:31 thraxisp Status feedback => resolved
2005-06-15 22:31 thraxisp Resolution reopened => fixed
2005-06-15 22:31 thraxisp Note Added: 0010544
2005-06-17 18:10 thraxisp Relationship added related to 0005722
2005-07-22 11:39 thraxisp Relationship added related to 0005969
2005-07-22 12:54 thraxisp Relationship added related to 0003897
2005-07-23 02:23 vboctor Status resolved => closed