View Issue Details

IDProjectCategoryView StatusLast Update
0022676mantisbtfeaturepublic2017-04-18 03:36
Reporterdoker Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status newResolutionopen 
Product Version2.3.0 
Summary0022676: Don't change status
Description

Hello!
When I assign bug to other person - ticket don't change status to "Assigned". Ticket assigning to another person with current status.
In config I check - $g_auto_set_status_to_assigned = ON;

This begin after update to version 2.3.0

TagsNo tags attached.

Relationships

related to 0021203 closedcproensa option auto_set_status_to_assigned can change status even if not allowed by workflow 

Activities

doker

doker

2017-04-10 05:02

reporter   ~0056459

Anybody have the same problem?

atrol

atrol

2017-04-10 06:40

developer   ~0056460

doker,

I was not able to reproduce your problem with a fresh install of 2.3.0.

You should provide detailed step-by-step instructions to reproduce the issue; the following additional information may also be useful:

  • Exact version of PHP, Database, Web server, Browser and Operating System
  • Relevant customizations (e.g. changes in config_inc.php, etc)
  • Installed plugins or custom functions ?
  • Was the MantisBT source code modified in any way ?

This begin after update to version 2.3.0

Which version did you use before?

doker

doker

2017-04-10 07:04

reporter   ~0056462

step-by-step:
1) create ticket 0012345 (for example)
2) assign ticket to person1
3) person1 change status to "feedback" (or any other)
4) assign ticket 0012345 to person2
5) ticket assign to person2 and have status "feedback", but must will be in status "Assigned"

  • PHP 5.5.15, mysql 5.5.39, Apache 2.4.10, FreeBSD 9.2, any browser.

before we use version 1.3.

Do you need my config_inc.php?

atrol

atrol

2017-04-10 07:44

developer   ~0056463

Last edited: 2017-04-10 07:44

I am not complete sure, but the issue might be caused by the changes in 0021203.

atrol

atrol

2017-04-10 07:45

developer   ~0056464

@cproensa, maybe you can have a deeper look at it?

cproensa

cproensa

2017-04-10 08:58

developer   ~0056468

The conditions on which the status change occurs are:

The conditions needed for automatic change to 'bug_assigned_status' are:

  • current handler is empty
  • new handler is not empty
  • status is not already part of the bug modification
  • current status is lower than 'bug_assigned_status'
  • 'bug_assigned_status' is reachable by workflow

At the described case, "current handler is empty" is not met, so the status change is not triggered.

We could discuss if this condition is necessary. I'm not sure if removing that would present side effects for other scenarios.
Also, we could argue if an issue waiting for feedback, should stays in that state even if the assignee has changed.

atrol

atrol

2017-04-10 09:33

developer   ~0056470

Also, we could argue if an issue waiting for feedback, should stays in that state even if the assignee has changed.

Exactly what I thought when looking at the code.
Changing the assigned user does not neccessarily mean that there is no longer feedback needed.
Of course, we should change the status to assigned if the assigned user is the reporter of the issue.

doker

doker

2017-04-10 09:38

reporter   ~0056471

Hi cproensa, thx for your response.
So, if current handler is not empty - status don't change in case assign bug to other person?

Isn't good news for me, because in version 1.3 status was change if bug was be assing to other handler. How we can we revert this feature?

Person 1 take ticket to youself, set status "comfitmed" and fixed part of bugs, then assign it to person 2 for continue, so person 2 will be see this bug in current status - "confirmed", but realy bug not confirmed by person 2.

doker

doker

2017-04-10 09:41

reporter   ~0056473

atrol, status "feedback" I explain as example. We can use status "comfirmed", the same problem. If bug in status "comfirmed" will be assing to other handler, status not change to "Assigned"

doker

doker

2017-04-13 02:20

reporter   ~0056518

So, can we revert this feature? Or maybe has workaround?

doker

doker

2017-04-14 03:15

reporter   ~0056543

?

atrol

atrol

2017-04-15 10:52

developer   ~0056565

At the described case, "current handler is empty" is not met, so the status change is not triggered.
We could discuss if this condition is necessary.

@doker you could remove the mentioned condition

This would mean to search for the following line in core/bug_api.php (should be line 2160)

if( $p_current_handler == NO_USER &&
and change it to
if(

but keep in mind what @cproensa told

I'm not sure if removing that would present side effects for other scenarios.

doker

doker

2017-04-18 03:36

reporter   ~0056605

Great!
This solve my issue. Thank you! We will test it.