View Issue Details

IDProjectCategoryView StatusLast Update
0012144mantisbtcustomizationpublic2014-12-08 02:07
ReporterKarlReichert Assigned Toatrol  
PriorityurgentSeveritymajorReproducibilityalways
Status closedResolutionunable to reproduce 
Product Version1.2.1 
Target Version1.3.0-beta.1 
Summary0012144: changing to the next custom status does not work
Description

I have the following configuration in config.inc.php:
[...]
$g_status_enum_string = '10:new,20:reopened,50:in progress,59:implemented,67:in review,90:closed'
[...]

In custom_constant_inc.php:
[...]
define( 'CQ_NEW', 10 );
define( 'CQ_REOPENED', 20 );
define( 'CQ_INPROGRESS', 50 );
define( 'CQ_IMPLEMENTED', 59 );
define( 'CQ_INREVIEW', 67);
define( 'CQ_CLOSED', 90 );
[...]

And in custom_string.php:
[...]
$s_in_review_bug_button = "Problem ist in Review";
$s_in_review_bug_title = "Setze Problem auf in Review";
$s_email_notification_title_for_status_bug_in_review = "Das folgende Problem ist in Review.";
[...]

I configured the workflow in a way, that after status 50, status 59 or 67 is possible:
$g_status_enum workflow = array (
10 => '50:in Arbeit',
20 => '50:in Arbeit',
50 => '59:umgesetzt,67:in Review',
59 => '90:geschlossen,20:Wiederaufnahme',
67 => '50:in Arbeit,20:Wiederaufnahme',
90 => '20:Wiederaufnahme',
)

When my issue is in status 50, I have the possibility to change it's status via the dropbox and only the both configured status following status 50 are displayed (see 1.png).
When I try to set it to status 67, I get the correct mask (see 2.png).
However, if I now click "Problem ist in review", the issue is not set to status 67, but status 59 instead ("umgesetzt", see 3.png).

Additional Information

Maybe this issue is connected with bug http://www.mantisbt.org/bugs/view.php?id=11956, because my default status (67) is also not concerned, when an issue is in status 50 ...

TagsNo tags attached.
Attached Files
1.png (20,022 bytes)   
1.png (20,022 bytes)   
2.png (27,039 bytes)   
2.png (27,039 bytes)   
3.png (1,865 bytes)   
3.png (1,865 bytes)   
bug_update.php (10,221 bytes)   
<?php
# MantisBT - a php based bugtracking system

# MantisBT is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 2 of the License, or
# (at your option) any later version.
#
# MantisBT is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with MantisBT.  If not, see <http://www.gnu.org/licenses/>.

	/**
	 * Update bug data then redirect to the appropriate viewing page
	 *
	 * @package MantisBT
	 * @copyright Copyright (C) 2000 - 2002  Kenzaburo Ito - kenito@300baud.org
	 * @copyright Copyright (C) 2002 - 2011  MantisBT Team - mantisbt-dev@lists.sourceforge.net
	 * @link http://www.mantisbt.org
	 */
	 /**
	  * MantisBT Core API's
	  */
	require_once( 'core.php' );

	require_once( 'bug_api.php' );
	require_once( 'bugnote_api.php' );
	require_once( 'custom_field_api.php' );

	form_security_validate( 'bug_update' );

	$f_bug_id = gpc_get_int( 'bug_id' );
	$f_update_mode = gpc_get_bool( 'update_mode', FALSE ); # set if called from generic update page
	$f_new_status	= gpc_get_int( 'status', bug_get_field( $f_bug_id, 'status' ) );

	$t_bug_data = bug_get( $f_bug_id, true );
	if( $t_bug_data->project_id != helper_get_current_project() ) {
		# in case the current project is not the same project of the bug we are viewing...
		# ... override the current project. This to avoid problems with categories and handlers lists etc.
		$g_project_override = $t_bug_data->project_id;
	}

	if ( !(
				( access_has_bug_level( access_get_status_threshold( $f_new_status, bug_get_field( $f_bug_id, 'project_id' ) ), $f_bug_id ) ) ||
				( access_has_bug_level( config_get( 'update_bug_threshold' ) , $f_bug_id ) ) ||
				( ( bug_get_field( $f_bug_id, 'reporter_id' ) == auth_get_current_user_id() ) &&
						( ( ON == config_get( 'allow_reporter_reopen' ) ) ||
								( ON == config_get( 'allow_reporter_close' ) ) ) )
			) ) {
		access_denied();
	}

	# extract current extended information
	$t_old_bug_status = $t_bug_data->status;

	$t_bug_data->reporter_id		= gpc_get_int( 'reporter_id', $t_bug_data->reporter_id );
	$t_bug_data->handler_id			= gpc_get_int( 'handler_id', $t_bug_data->handler_id );
	$t_bug_data->duplicate_id		= gpc_get_int( 'duplicate_id', $t_bug_data->duplicate_id );
	$t_bug_data->priority			= gpc_get_int( 'priority', $t_bug_data->priority );
	$t_bug_data->severity			= gpc_get_int( 'severity', $t_bug_data->severity );
	$t_bug_data->reproducibility	= gpc_get_int( 'reproducibility', $t_bug_data->reproducibility );
	$t_bug_data->status				= gpc_get_int( 'status', $t_bug_data->status );
	$t_bug_data->resolution			= gpc_get_int( 'resolution', $t_bug_data->resolution );
	$t_bug_data->projection			= gpc_get_int( 'projection', $t_bug_data->projection );
	$t_bug_data->category_id		= gpc_get_int( 'category_id', $t_bug_data->category_id );
	$t_bug_data->eta				= gpc_get_int( 'eta', $t_bug_data->eta );
	$t_bug_data->os					= gpc_get_string( 'os', $t_bug_data->os );
	$t_bug_data->os_build			= gpc_get_string( 'os_build', $t_bug_data->os_build );
	$t_bug_data->platform			= gpc_get_string( 'platform', $t_bug_data->platform );
	$t_bug_data->version			= gpc_get_string( 'version', $t_bug_data->version );
	$t_bug_data->build				= gpc_get_string( 'build', $t_bug_data->build );
	$t_bug_data->fixed_in_version		= gpc_get_string( 'fixed_in_version', $t_bug_data->fixed_in_version );
	$t_bug_data->view_state			= gpc_get_int( 'view_state', $t_bug_data->view_state );
	$t_bug_data->summary			= gpc_get_string( 'summary', $t_bug_data->summary );
	$t_due_date = gpc_get_string( 'due_date', null );

	if( access_has_project_level( config_get( 'roadmap_update_threshold' ), $t_bug_data->project_id ) ) {
		$t_bug_data->target_version		= gpc_get_string( 'target_version', $t_bug_data->target_version );
	}
	
	if( $t_due_date !== null) {
		if ( is_blank ( $t_due_date ) ) {
			$t_bug_data->due_date = 1;
		} else {
			$t_bug_data->due_date = strtotime( $t_due_date );
		}		
	}

	$t_bug_data->description		= gpc_get_string( 'description', $t_bug_data->description );
	$t_bug_data->steps_to_reproduce	= gpc_get_string( 'steps_to_reproduce', $t_bug_data->steps_to_reproduce );
	$t_bug_data->additional_information	= gpc_get_string( 'additional_information', $t_bug_data->additional_information );

	$f_private						= gpc_get_bool( 'private' );
	$f_bugnote_text					= gpc_get_string( 'bugnote_text', '' );
	$f_time_tracking			= gpc_get_string( 'time_tracking', '0:00' );
	$f_close_now					= gpc_get_string( 'close_now', false );

	# Handle auto-assigning
	if ( ( config_get( 'bug_submit_status' ) == $t_bug_data->status )
	  && ( $t_bug_data->status == $t_old_bug_status )
	  && ( 0 != $t_bug_data->handler_id )
	  && ( ON == config_get( 'auto_set_status_to_assigned' ) ) ) {
		$t_bug_data->status = config_get( 'bug_assigned_status' );
	}

	helper_call_custom_function( 'issue_update_validate', array( $f_bug_id, $t_bug_data, $f_bugnote_text ) );

	$t_resolved = config_get( 'bug_resolved_status_threshold' );
	$t_closed = config_get( 'bug_closed_status_threshold' );

	$t_custom_status_label = "update"; # default info to check
	if ( $t_bug_data->status == $t_resolved ) {
		$t_custom_status_label = "resolved";
	}
	if ( $t_bug_data->status == $t_closed ) {
		$t_custom_status_label = "closed";
	}

	$t_related_custom_field_ids = custom_field_get_linked_ids( $t_bug_data->project_id );
	foreach( $t_related_custom_field_ids as $t_id ) {
		$t_def = custom_field_get_definition( $t_id );

		# Only update the field if it would have been display for editing
		if( !( ( !$f_update_mode && $t_def['require_' . $t_custom_status_label] ) ||
						( !$f_update_mode && $t_def['display_' . $t_custom_status_label] && in_array( $t_custom_status_label, array( "resolved", "closed" ) ) ) ||
						( $f_update_mode && $t_def['display_update'] ) ||
						( $f_update_mode && $t_def['require_update'] ) ) ) {
			continue;
		}

		# Do not set custom field value if user has no write access.
		if( !custom_field_has_write_access( $t_id, $f_bug_id ) ) {
			continue;
		}

		# Produce an error if the field is required but wasn't posted
		if ( !gpc_isset_custom_field( $t_id, $t_def['type'] ) &&
			( $t_def['require_' . $t_custom_status_label] ) ) {
			error_parameters( lang_get_defaulted( custom_field_get_field( $t_id, 'name' ) ) );
			trigger_error( ERROR_EMPTY_FIELD, ERROR );
		}

		$t_new_custom_field_value = gpc_get_custom_field( "custom_field_$t_id", $t_def['type'], '' );
		$t_old_custom_field_value = custom_field_get_value( $t_id, $f_bug_id );

		# Don't update the custom field if the new value both matches the old value and is valid
		# This ensures that changes to custom field validation will force the update of old invalid custom field values
		if( $t_new_custom_field_value === $t_old_custom_field_value &&
			custom_field_validate( $t_id, $t_new_custom_field_value ) ) {
			continue;
		}

		# Attempt to set the new custom field value
		if ( !custom_field_set_value( $t_id, $f_bug_id, $t_new_custom_field_value ) ) {
			error_parameters( lang_get_defaulted( custom_field_get_field( $t_id, 'name' ) ) );
			trigger_error( ERROR_CUSTOM_FIELD_INVALID_VALUE, ERROR );
		}
	}

	$t_notify = true;
	$t_bug_note_set = false;
	if ( ( $t_old_bug_status != $t_bug_data->status ) && ( FALSE == $f_update_mode ) ) {
		# handle status transitions that come from pages other than bug_*update_page.php
		# this does the minimum to act on the bug and sends a specific message
		if ( $t_bug_data->status == $t_resolved     #12144 KarlReichert
			&& $t_bug_data->status < $t_closed
			&& $t_old_bug_status < $t_resolved ) {
			# bug_resolve updates the status, fixed_in_version, resolution, handler_id and bugnote and sends message
			bug_resolve( $f_bug_id, $t_bug_data->resolution, $t_bug_data->fixed_in_version,
				$f_bugnote_text, $t_bug_data->duplicate_id, $t_bug_data->handler_id,
				$f_private, $f_time_tracking );
			$t_notify = false;
			$t_bug_note_set = true;

			if ( $f_close_now ) {
				bug_set_field( $f_bug_id, 'status', $t_closed );
			}

			// update bug data with fields that may be updated inside bug_resolve(), otherwise changes will be overwritten
			// in bug_update() call below.
			$t_bug_data->handler_id = bug_get_field( $f_bug_id, 'handler_id' );
			$t_bug_data->status = bug_get_field( $f_bug_id, 'status' );
		} else if ( $t_bug_data->status == $t_closed    #12144 KarlReichert
			&& $t_old_bug_status < $t_closed ) {
			# bug_close updates the status and bugnote and sends message
			bug_close( $f_bug_id, $f_bugnote_text, $f_private, $f_time_tracking );
			$t_notify = false;
			$t_bug_note_set = true;
		} else if ( $t_bug_data->status == config_get( 'bug_reopen_status' ) ) {    #12144 KarlReichert
			bug_set_field( $f_bug_id, 'handler_id', $t_bug_data->handler_id ); # fix: update handler_id before calling bug_reopen
			# bug_reopen updates the status and bugnote and sends message
			bug_reopen( $f_bug_id, $f_bugnote_text, $f_time_tracking, $f_private );
			$t_notify = false;
			$t_bug_note_set = true;

			// update bug data with fields that may be updated inside bug_resolve(), otherwise changes will be overwritten
			// in bug_update() call below.
			$t_bug_data->status = bug_get_field( $f_bug_id, 'status' );
			$t_bug_data->resolution = bug_get_field( $f_bug_id, 'resolution' );
		}
	}

	# Plugin support
	$t_new_bug_data = event_signal( 'EVENT_UPDATE_BUG', $t_bug_data, $f_bug_id );
	if ( !is_null( $t_new_bug_data ) ) {
		$t_bug_data = $t_new_bug_data;
	}

	# Add a bugnote if there is one
	if ( false == $t_bug_note_set ) {
		bugnote_add( $f_bug_id, $f_bugnote_text, $f_time_tracking, $f_private, 0, '', NULL, FALSE );
	}

	# Update the bug entry, notify if we haven't done so already
	$t_bug_data->update( true, ( false == $t_notify ) );

	form_security_purge( 'bug_update' );

	helper_call_custom_function( 'issue_update_notify', array( $f_bug_id ) );

	print_successful_redirect_to_bug( $f_bug_id );
bug_update.php (10,221 bytes)   
20.diff (1,147 bytes)   
diff --git a/bug_update.php b/bug_update.php
index 3ca886a..7e4957c 100644
--- a/bug_update.php
+++ b/bug_update.php
@@ -166,7 +166,7 @@
 	if ( ( $t_old_bug_status != $t_bug_data->status ) && ( FALSE == $f_update_mode ) ) {
 		# handle status transitions that come from pages other than bug_*update_page.php
 		# this does the minimum to act on the bug and sends a specific message
-		if ( $t_bug_data->status >= $t_resolved
+		if ( $t_bug_data->status == $t_resolved
 			&& $t_bug_data->status < $t_closed
 			&& $t_old_bug_status < $t_resolved ) {
 			# bug_resolve updates the status, fixed_in_version, resolution, handler_id and bugnote and sends message
@@ -184,7 +184,7 @@
 			// in bug_update() call below.
 			$t_bug_data->handler_id = bug_get_field( $f_bug_id, 'handler_id' );
 			$t_bug_data->status = bug_get_field( $f_bug_id, 'status' );
-		} else if ( $t_bug_data->status >= $t_closed
+		} else if ( $t_bug_data->status == $t_closed
 			&& $t_old_bug_status < $t_closed ) {
 			# bug_close updates the status and bugnote and sends message
 			bug_close( $f_bug_id, $f_bugnote_text, $f_private, $f_time_tracking );
20.diff (1,147 bytes)   

Relationships

has duplicate 0015236 closeddregad Bug status is ignored on update 

Activities

fxm

fxm

2010-10-05 09:58

reporter   ~0026954

Hi,

I have the same problem as you ... Do you have a solution / workaround ?

Thks for your help.

KarlReichert

KarlReichert

2010-10-05 10:03

reporter   ~0026955

Try updating to the newest MantisBT version, as issue 0011956, which might be a duplicate of this issue, has been solved since MantisBT v1.2.2

After you tried, please report if it works with the current MantisBT version, because if so, we could close this bug.

fxm

fxm

2010-10-06 02:34

reporter   ~0026965

Hi,

I already run the 1.2.2 version.

Thks for your support. Problem not solved.

KarlReichert

KarlReichert

2011-04-08 04:15

reporter   ~0028565

Pushing this up again, as this issue still appears with Mantis v1.2.5

KarlReichert

KarlReichert

2011-04-08 11:11

reporter   ~0028572

I think I found the reason for that bug! In v1.2.5 of file bug_update.php, line 169, there is:
if ( $t_bug_data->status >= $t_resolved && $t_bug_data->status < $t_closed && $t_old_bug_status < $t_resolved ) {
bug_resolve( $f_bug_id, $t_bug_data->resolution, $t_bug_data->fixed_in_version, $f_bugnote_text, $t_bug_data->duplicate_id, $t_bug_data->handler_id, $f_private, $f_time_tracking );
[...]
}

  • $t_bug_data->status holds the new status (the status desired to change to)
  • $t_old_bug_status holds the old status (the status desired to change from)
  • $t_resolved holds the status that represents RESOLVED
  • $t_closed holds the status that represents CLOSED

In the listed above configuration, my resolved status is "59:umgesetzt". As described, I'm trying to change from status "50:in Arbeit" to status "67:in Review".
My resolved status (59) is in between 50 and 67. That's why the if listed is TRUE. So function bug_resolve() is called.
However, in this function, the new bug status is always set to the status that represents RESOLVED, i.e. "59:umgesetzt".

So to fix this issue, the listed above if has to be changed to:
if ( $t_bug_data->status == $t_resolved && $t_bug_data->status < $t_closed && $t_old_bug_status < $t_resolved ) {
bug_resolve( $f_bug_id, $t_bug_data->resolution, $t_bug_data->fixed_in_version, $f_bugnote_text, $t_bug_data->duplicate_id, $t_bug_data->handler_id, $f_private, $f_time_tracking );
[...]
}
( the first check in the if has changed from >= to == )

Furthermore, I think all the following if else statements in this bloack are not really correct, because they always check for >= or <= instead of ==

Please see the attached file, which I patched to be correct (in my opinion). I made 3 changes which are marked by comment "0012144 KarlReichert"

If this patch looks good to you, please use it for the next MantisBT version!

KarlReichert

KarlReichert

2011-04-18 07:50

reporter   ~0028645

Is my patch okay or is some redesign necessary?

sveyrie

sveyrie

2011-10-27 12:49

reporter   ~0030088

Last edited: 2011-10-27 12:55

I have the same problem on 1.2.8 and Karl's patch fixes it.

Is it possible to include it in 1.2.9 ?

rombert

rombert

2011-10-28 07:46

reporter   ~0030089

Thank you for the report and suggested fix. Would you consider submitting pull requests for this functionality? This would greatly increase the speed of including these changes in MantisBT.

Ideally you would submit pull requests for both the master and master-1.2.x branches at https://github.com/mantisbt/mantisbt .

sveyrie

sveyrie

2011-10-28 08:12

reporter   ~0030091

Pull request: https://github.com/mantisbt/mantisbt/pull/20

sveyrie

sveyrie

2011-10-28 08:19

reporter   ~0030092

This one was for master-1.2.x. This file seems to have changed on master so I have to look after the good line.

sveyrie

sveyrie

2011-10-28 09:54

reporter   ~0030093

The whole "bug_update.php" file has changed, with no reference to function "bug_resolve". Maybe the refactoring process has eliminated the bug.

The best thing to do is to test this bug against a dev version from master.

grangeway

grangeway

2011-10-29 04:19

reporter   ~0030104

If you have a patch for this issue, can you attach it to this bug.

Between master-1.2.x, trunk and our future 1.3 work, a lot has changed, so to ensure that this issue gets included in future 1.3 versions this would be useful.

sveyrie

sveyrie

2011-11-02 05:20

reporter   ~0030145

The diff file is really easy to fin in github:

https://github.com/mantisbt/mantisbt/pull/20.diff

Also attached.

dhx

dhx

2011-11-04 07:11

reporter   ~0030158

Thanks for the patch. You have identified a problem, that is - what if the resolved and closed states are the same? The checks needs to be updated so that the following test is performed, optional to the existing tests:

($t_bug_data->status == $t_resolved && $t_resolved == $t_closed)

We can not simply perform a $t_bug_data->status == $t_resolved test because multiple resolved and closed states may exist.

sveyrie

sveyrie

2011-11-04 07:17

reporter   ~0030159

Last edited: 2011-11-04 07:25

[edit]this is the same comment as in github, but I now see that it was not the same comment from the team[/edit]

Was before edit:
[That's exactly our point: custom states between "resolved" and "closed"

The problem is that if those states are set, "bug_resolve" overides the state to "resolved"

i.e. the user performs "set state to foo" and Mantis sets the state to "resolved" and NOT "foo" (see Karl's description).]

dhx

dhx

2012-01-06 23:44

reporter   ~0030838

Sorry, I initially misunderstood this issue.

bug_update.php in master-1.2.x is completely different to the version used in the master branch. I rewrote the entire file in master and I believe this bug no longer exists. As per an earlier comment, bug_resolve is no longer used because it's a bad approach.

For the 1.2.x branch, the bug_resolve function will always set the status to the value of $g_bug_resolved_status_threshold. To solve this issue, we either shouldn't use bug_resolve (this is the fix used in the 1.3.x branch) or add a new status argument to this function (so we can pass the correct resolved status).

JanHegewald

JanHegewald

2012-03-20 05:13

reporter   ~0031493

dhx, does your comment (0012144:0030838) mean, that the patch that was provided by KarlReichert and submitted by sveryie is not correct? I was stumbling over this point again and would need a fix for this.

sveyrie

sveyrie

2012-03-20 05:23

reporter   ~0031494

Last edited: 2012-03-20 05:24

Jan, I think that dhx means that:

1) on 1.2, this patch is a regression for some use cases; a more intrusive change is necessary to fix it without regression
2) on 1.3, the issue is fixed by complete rewrite

Meanwhile, I applied Karl's patch on our installation because it is suitable for us.

JanHegewald

JanHegewald

2012-03-20 05:39

reporter   ~0031495

Ok, so the problem is still the same as what dhx described in 0012144:0030158 (what if more than one resolved and closed state exists)?

dregad

dregad

2012-11-26 03:46

developer   ~0034393

An alternative patch to fix this issue was proposed by trehn in 0015236

rombert

rombert

2013-04-23 16:31

reporter   ~0036651

@dregad, can this be closed as a dupe/won't fix then?

dregad

dregad

2013-04-24 04:50

developer   ~0036659

Don't think so, see dhx's note 0012144:0030838 as well as on github https://github.com/mantisbt/mantisbt/pull/20#issuecomment-2629358

atrol

atrol

2013-04-27 18:21

developer   ~0036696

Removed assignment. dhx will not contribute to this issue in near future.

atrol

atrol

2014-06-16 16:42

developer   ~0040821

I was not able to reproduce the issue using current master.

vboctor

vboctor

2014-11-02 02:57

manager   ~0041747

Marked as resolved 'unable to reproduce' based on @atrol's testing.