View Issue Details

IDProjectCategoryView StatusLast Update
0011323mantisbtcustomizationpublic2014-09-23 18:05
Reporterchadrick Assigned Todregad  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
OSWindowsOS VersionXP 
Product Version1.2.0rc2 
Target Version1.2.9Fixed in Version1.2.9 
Summary0011323: Cross project relationships not picking up custom statuses
Description

I have two projects (A and B). Each project has its own status_enum_string defined.

Project A (10:new, 20:needs clarification, 30:ready for development, 40:assigned to developer, 50:ready for testing, 60:assigned to tester, 70:completed, 80:rejected)

Project B (10:new, 25:approved, 70:completed, 80:rejected)

I set a relationship from Project A to Project B. In Project B the issue has status of "approved". I bring up the issue in Project A and under Relationships the status is @25@. It should be "approved". I click the issue in the Relationship and still it's status is @25@.

I feel like this is a bug in the MANTIS code. It's like the Relationship is not using the correct project id to populate the status.

TagsNo tags attached.
Attached Files
0001-Correct-display-custom-status-in-cross-project-relat.patch (2,852 bytes)   
From 8f4a3c40756d7d688a0c99aa17681ec8e76a0a22 Mon Sep 17 00:00:00 2001
From: Damien Regad <damien.regad@merckgroup.com>
Date: Wed, 14 Dec 2011 17:20:48 +0100
Subject: [PATCH] Correct display custom status in cross-project relationships

In the bug relationships section in view.php, the target bug's status
was incorrectly displayed as "@X@" (where X is the status_enum id) if
the following conditions were true:
 - the target bug is in a different project
 - it is a custom status

This commit fixes the behavior, and displays the corresponding enum
element's language string.

2 new parameters have been added to function get_enum_element(): user
and project id (defaulted to null to preserve existing behavior). These
parameters are passed on to config_get() call, allowing to specify the
context for retrieving the enum element.

The call to get_enum_element() in function relationship_get_details()
has been altered to specify the target bug's project id.

Fixes #11323
---
 core/helper_api.php       |    9 ++++++---
 core/relationship_api.php |    2 +-
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/core/helper_api.php b/core/helper_api.php
index 1354a90..ab0d902 100644
--- a/core/helper_api.php
+++ b/core/helper_api.php
@@ -85,13 +85,16 @@ function get_status_color( $p_status ) {
 }
 
 /**
- * Given a enum string and num, return the appropriate string
+ * Given a enum string and num, return the appropriate string for the
+ * specified user/project
  * @param string $p_enum_name
  * @param int $p_val
+ * @param int|null $p_user user id, defaults to null (all users)
+ * @param int|null $p_project project id, defaults to null (all projects)
  * @return string
  */
-function get_enum_element( $p_enum_name, $p_val ) {
-	$config_var = config_get( $p_enum_name . '_enum_string' );
+function get_enum_element( $p_enum_name, $p_val, $p_user = null, $p_project = null ) {
+	$config_var = config_get( $p_enum_name . '_enum_string', null, $p_user, $p_project );
 	$string_var = lang_get( $p_enum_name . '_enum_string' );
 
 	return MantisEnum::getLocalizedLabel( $config_var, $string_var, $p_val );
diff --git a/core/relationship_api.php b/core/relationship_api.php
index bb4d5e0..759ac2d 100644
--- a/core/relationship_api.php
+++ b/core/relationship_api.php
@@ -625,7 +625,7 @@ function relationship_get_details( $p_bug_id, $p_relationship, $p_html = false,
 
 	# get the information from the related bug and prepare the link
 	$t_bug = bug_get( $t_related_bug_id, false );
-	$t_status_string = get_enum_element( 'status', $t_bug->status );
+	$t_status_string = get_enum_element( 'status', $t_bug->status, null, $t_bug->project_id );
 	$t_resolution_string = get_enum_element( 'resolution', $t_bug->resolution );
 
 	$t_relationship_info_html = $t_td . string_no_break( $t_relationship_descr ) . '&#160;</td>';
-- 
1.7.5.4

11323.patch (3,723 bytes)   
diff --git a/core/columns_api.php b/core/columns_api.php
index 95aa081..96e94d6 100644
--- a/core/columns_api.php
+++ b/core/columns_api.php
@@ -1127,7 +1127,7 @@ function print_column_resolution( $p_bug, $p_columns_target = COLUMNS_TARGET_VIE
  */
 function print_column_status( $p_bug, $p_columns_target = COLUMNS_TARGET_VIEW_PAGE ) {
 	echo '<td class="center">';
-	printf( '<span class="issue-status" title="%s">%s</span>', get_enum_element( 'resolution', $p_bug->resolution ), get_enum_element( 'status', $p_bug->status ) );
+	printf( '<span class="issue-status" title="%s">%s</span>', get_enum_element( 'resolution', $p_bug->resolution ), get_enum_element( 'status', $p_bug->status, auth_get_current_user_id(), $p_bug->project_id ) );
 
 	# print username instead of status
 	if(( ON == config_get( 'show_assigned_names' ) ) && ( $p_bug->handler_id > 0 ) && ( access_has_project_level( config_get( 'view_handler_threshold' ), $p_bug->project_id ) ) ) {
diff --git a/core/custom_function_api.php b/core/custom_function_api.php
index a60068a..20b3189 100644
--- a/core/custom_function_api.php
+++ b/core/custom_function_api.php
@@ -63,7 +63,7 @@ function custom_function_default_changelog_print_issue( $p_issue_id, $p_issue_le
 	}
 
 	if( !isset( $t_status[$t_bug->status] ) ) {
-		$t_status[$t_bug->status] = get_enum_element( 'status', $t_bug->status );
+		$t_status[$t_bug->status] = get_enum_element( 'status', $t_bug->status, auth_get_current_user_id(), $t_bug->project_id );
 	}
 	echo ' - ', $t_status[$t_bug->status], '.<br />';
 }
@@ -102,7 +102,7 @@ function custom_function_default_roadmap_print_issue( $p_issue_id, $p_issue_leve
 	}
 
 	if( !isset( $t_status[$t_bug->status] ) ) {
-		$t_status[$t_bug->status] = get_enum_element( 'status', $t_bug->status );
+		$t_status[$t_bug->status] = get_enum_element( 'status', $t_bug->status, auth_get_current_user_id(), $t_bug->project_id );
 	}
 	echo ' - ', $t_status[$t_bug->status], $t_strike_end, '.<br />';
 }
diff --git a/core/helper_api.php b/core/helper_api.php
index 1354a90..ab0d902 100644
--- a/core/helper_api.php
+++ b/core/helper_api.php
@@ -85,13 +85,16 @@ function get_status_color( $p_status ) {
 }
 
 /**
- * Given a enum string and num, return the appropriate string
+ * Given a enum string and num, return the appropriate string for the
+ * specified user/project
  * @param string $p_enum_name
  * @param int $p_val
+ * @param int|null $p_user user id, defaults to null (all users)
+ * @param int|null $p_project project id, defaults to null (all projects)
  * @return string
  */
-function get_enum_element( $p_enum_name, $p_val ) {
-	$config_var = config_get( $p_enum_name . '_enum_string' );
+function get_enum_element( $p_enum_name, $p_val, $p_user = null, $p_project = null ) {
+	$config_var = config_get( $p_enum_name . '_enum_string', null, $p_user, $p_project );
 	$string_var = lang_get( $p_enum_name . '_enum_string' );
 
 	return MantisEnum::getLocalizedLabel( $config_var, $string_var, $p_val );
diff --git a/core/relationship_api.php b/core/relationship_api.php
index bb4d5e0..a895b23 100644
--- a/core/relationship_api.php
+++ b/core/relationship_api.php
@@ -625,7 +625,7 @@ function relationship_get_details( $p_bug_id, $p_relationship, $p_html = false,
 
 	# get the information from the related bug and prepare the link
 	$t_bug = bug_get( $t_related_bug_id, false );
-	$t_status_string = get_enum_element( 'status', $t_bug->status );
+	$t_status_string = get_enum_element( 'status', $t_bug->status, auth_get_current_user_id(), $t_bug->project_id );
 	$t_resolution_string = get_enum_element( 'resolution', $t_bug->resolution );
 
 	$t_relationship_info_html = $t_td . string_no_break( $t_relationship_descr ) . '&#160;</td>';
11323.patch (3,723 bytes)   

Relationships

related to 0015721 closedgrangeway Functionality to consider porting to master-2.0.x 
related to 0013682 closeddregad Color codes for custom statuses not displayed cross-project 
related to 0013707 closeddregad Custom resolutions not displayed cross-project 
child of 0013728 closeddregad Various display issues of custom enums cross-project 

Activities

jojow

jojow

2011-09-06 09:51

reporter   ~0029648

In 1.2.6 the Problem is the same:
Project A with Status:
10:new,20:feedback,50:assigned,80:resolved,90:closed
Project B with Status: 10:new,20:feedback,25:analysis,55:development,65:test,70:release,80:resolved,90:closed

An issue(123) in Project B with 25:analysis related to an issue(456) in Project A.

In issue(456) you see only @25@ as Statusinformation for issue(123).

JanHegewald

JanHegewald

2011-12-12 12:45

reporter   ~0030557

A work around to this issue is to have all statuses in status_enum_string of all projects. It's a dirty solution, but as long as you don't put the unwanted statuses into status_enum_workflow, nobody is able to set an issue to this status.

Anybody with another working solution?

dregad

dregad

2011-12-13 18:27

developer   ~0030592

That should be easy to fix, it's a simple matter of using the target bug's project id when looking up the status string. I'll have a look and upload a patch later.

dregad

dregad

2011-12-14 11:52

developer   ~0030609

I uploaded a patch for this, could you please test it and let me know the results.

JanHegewald

JanHegewald

2011-12-14 12:17

reporter   ~0030611

I applied the patch and for me this seems to be fixed on 1.2.8.

The last thing missing there is the color. Right now the lines for relationships to issues in different projects are shown in white. What can be done concerning this problem, except my workaround?

I also applied the patch to my 1.2.1 installation, and unfortunately the patch seems to be no resolution for the problem in 1.2.1. The status name is simply not shown then, there is a blank space where formerly the @X@ was shown. I have to check wether I can upgrade this installation also to 1.2.8, but im not certain if I really want to do this. Or do you have another solution for 1.2.1?

dregad

dregad

2011-12-14 12:30

developer   ~0030612

Jan,

Thanks for testing. Could you please open a separate issue to track the missing color bug ?

With regards to a 1.2.1 patch, I'm sorry but we have enough work as it is maintaining the current versions, without backporting bugs to older releases. If you need a fix for 1.2.1, it is up to you to adapt my patch or otherwise find the root cause and adapt the code yourself. I can only recommend that you upgrade to the latest version.

jojow

jojow

2011-12-15 02:15

reporter   ~0030614

I tested the patch to my 1.2.6 installation, and the patch has no resolution for the problem in 1.2.6. The status name is as @X@ shown. And die Color shown in white.

dregad

dregad

2011-12-15 07:54

developer   ~0030627

My patch relies on a fix which was introduced in 1.2.8 (see attached changeset), try to apply this to your 1.2.1 / 1.2.6 installation and let me know how it goes.

dregad

dregad

2011-12-15 10:01

developer   ~0030629

Revised patch attached, fixes other occurences of the @X@ problem (in View Issues, Change Log and Roadmap)

jojow

jojow

2011-12-15 10:29

reporter   ~0030630

I have tested the 11323.patch in my 1.2.6 Version. Unfortunately, no result. It is still displayed @x@.
But I will update to 1.2.8 and than test it again.

JanHegewald

JanHegewald

2011-12-19 03:31

reporter   ~0030650

In 1.2.1, the line

$t_status_string = get_enum_element( 'status', $t_bug->status );

from relationship_api.php is really this line:

$t_status = get_enum_element( 'status', $t_bug->status );

The variable name is not $t_status_string, but $t_status. Changing the name back to $t_status, the fix from dregad works for me, also without applying the changeset!

JanHegewald

JanHegewald

2011-12-19 03:43

reporter   ~0030651

Unfortunately, this fix doesn't seem to be working for resolutions. I changed line 1127 in columns_api.php to

printf( '<span class="issue-status" title="%s">%s</span>', get_enum_element( 'resolution', $p_bug->resolution, auth_get_current_user_id(), $p_bug->project_id ), get_enum_element( 'status', $p_bug->status, auth_get_current_user_id(), $p_bug->project_id ) );

so the same is done for resolution and status. But viewing the 'View Issues' page with a project selected that has some subprojects give me a @X@ in some cases where custom resolutions are used.

Shall I open a new issue to track this?

dregad

dregad

2011-12-31 20:19

developer   ~0030752

Jan, I have opened new issue 0013707 to track this latest issue on resolution.

jojow

jojow

2012-01-02 05:14

reporter   ~0030759

I have tested the 11323.patch in my new 1.2.8 version. And it works fine!
The last (small) problem is the missing color.

dregad

dregad

2012-01-04 13:37

developer   ~0030793

Thanks for testing. Regarding missing colors, please check 0013682

grangeway

grangeway

2013-04-05 17:57

reporter   ~0036376

Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch

Related Changesets

MantisBT: master-1.2.x 4b7492d4

2011-08-29 09:01

Paul Richards

Committer: dhx


Details Diff
Project override should only apply if $p_project hasn't been explicity set.

For the most part, we use config_get(var) to get information for the current project [or overriden project]

If we are explicity passing in a project ID, we should use this ID instead, and not override.

Signed-off-by: David Hicks <d@hx.id.au>
Affected Issues
0011323, 0013682
mod - core/config_api.php Diff File

MantisBT: master 3f4829c6

2011-12-14 03:20

dregad


Details Diff
Correct display custom status in cross-project relationships

In the bug relationships section in view.php, the target bug's status
was incorrectly displayed as "@X@" (where X is the status_enum id) if
the following conditions were true:
- the target bug is in a different project
- it is a custom status

This commit fixes the behavior, and displays the corresponding enum
element's language string.

2 new parameters have been added to function get_enum_element(): user
and project id (defaulted to null to preserve existing behavior). These
parameters are passed on to config_get() call, allowing to specify the
context for retrieving the enum element.

The call to get_enum_element() in function relationship_get_details()
has been altered to specify the target bug's project id.

Fixes 0011323
Affected Issues
0011323
mod - core/helper_api.php Diff File
mod - core/relationship_api.php Diff File

MantisBT: master-1.2.x f33c0f81

2011-12-14 03:20

dregad


Details Diff
Correct display custom status in cross-project relationships

In the bug relationships section in view.php, the target bug's status
was incorrectly displayed as "@X@" (where X is the status_enum id) if
the following conditions were true:
- the target bug is in a different project
- it is a custom status

This commit fixes the behavior, and displays the corresponding enum
element's language string.

2 new parameters have been added to function get_enum_element(): user
and project id (defaulted to null to preserve existing behavior). These
parameters are passed on to config_get() call, allowing to specify the
context for retrieving the enum element.

The call to get_enum_element() in function relationship_get_details()
has been altered to specify the target bug's project id.

Fixes 0011323
Affected Issues
0011323
mod - core/helper_api.php Diff File
mod - core/relationship_api.php Diff File