Defect #2418

workflow defect

Added by great dodo almost 14 years ago. Updated about 13 years ago.

Status:ClosedStart date:2008-12-30
Priority:UrgentDue date:
Assignee:-% Done:

0%

Category:Issues
Target version:-
Resolution:Wont fix Affected version:

Description

Hello,

our workflow look like this:

assigned -> done
assigned -> feedback
feedback -> feedback
feedback -> done

none of these three states are marked as default or closed.

When we create a new issue with status new which is default, then manager role changes it to assigned. And then when some other role with the workflow specified above want's to change it, it has the possibility to change it from assigned -> assigned which is not permited. So is this a bug?

rails version is 2.0.2
redmine 0.8.0 stable
os gentoo linux (webrick)
db mysql

History

#1 Updated by Jean-Philippe Lang almost 14 years ago

it has the possibility to change it from assigned -> assigned

"assigned -> assigned" is not really a change, is it?

#2 Updated by Thomas Pihl almost 14 years ago

There is no connection between assigned to and workflow. Some days i wish for one of those (or maybe assign to group), some days i do not.

Currently we're avoiding 'assigned to' in most cases. We use workflow together with RSSOwl. Why? A few reasons:
  • We do not spam mailboxes with high volume of status updates (but external reporters and similar can still ger email notify)
  • We keep track on issue assignment with (personal or public) saved filters monitored by RSSOwl (with a nice update-windows every 10 minutes in bottom right corner of the screen when we have new issues to manage). A typical filter consist of one or more trackers together with a workflow status and perhaps some categories to show all those issues that I can do something about. All "queue"-states are followed in the workflow with a "in progress"-state to show that someone have grabbed the issues (no longer in the queue).
  • We use a similar filter to select issues still open but getting stale (to long time from created to solved). This is a sub-optimal solution, some day we'll need a multiple-timer-solution connected to SLAs instead, but not today.
Weaknesses:
  • RSSOwl will only display an issue once (as reported to me, not checked fact). If it shows up again in another filter it gets ignored
  • Not easy to see what issues are "owned" by any one team-member (you have to look into the issue to see who changed the issue status from "queue" to "in progress" to see who owns it). Assigned to it a lot stronger in this area. Perhaps some metadata in the status together with automagic settings of assigned to in the future?

Well, this is perhaps something to put on wiki, instead of as a comment in a defect report as why i do not consider this to be a defect. But yet again, just my 0.02 SEK (another banana-republic currency).
/T

Happy New year BTW.

#3 Updated by Felix Dominguez over 13 years ago

When you say it has the possiblity to change from assigned->assigned it sounds like your saying the issue changes ownership. For example:
  1. a new issue is created. _status_=new _assigned to_=[blank]
  2. manager role changes status to 'assigned' and changes assigned to to 'bob'
  3. Tim comes around and takes ownership of the issue and changes assigned to to 'tim'

In the example above, you workflow really did go from assigned to assigned

Is it my understanding that you don't want this behavior? You want the issue to stay assigned to 'bob' and prevent it from being taken by 'tim'?

#4 Updated by great dodo over 13 years ago

Your example is correct, but the point is, that (in our case) only manager can changed the status to assigned, nobody else. And the bug (or feature?) is that other role is able to do so, even if we did not allowed it. I have replicated the bug again and it looks as follows:

when you open the status listbox you get this:

0. assigned - this was set by manager
1. feedback
2. resolved

The user can only change to 1 or 2. The problem is, the user is not forced to change the status from 0 to 1 or 2. He is not allowed to choose 0, but he should be forced to do so, when the 0 is something he is not allowed to choose. The zero is simly the actual state of the listbox, and it should be automaticaly removed when it is not allowed.

thanks

redmine is cooooool

#5 Updated by Felix Dominguez over 13 years ago

  • Status changed from New to Resolved

I understand now.

Unfortunately it is not a bug in redmine. It is operating as it was designed. When you disallow a role to select a status, in this case the assigned status, what you are essentially saying is, "I am not allowing a role to CHANGE the status from another status to assigned". So it is like Jean-Phillipe said, it is not really a change when a role that is not allowed to CHANGE the status to assigned updates a ticket and just saves it. The internal workings of redmine do not see it as a change of status.

If I may suggest, what we have done in-house is create a status named "WIP" which is short of "Work In Progress". We have then asked the techs to update the status to "WIP" when they have started on a task. This allows the manager to see what tasks have been started and what tasks are still queued.

Since this is not really a defect of redmine, I am changing the status to resolved. However, if this is a feature you would like to see in redmine, request it by creating a new issue in the Feature Tracker.

#6 Updated by Jean-Philippe Lang about 13 years ago

  • Category set to Issues
  • Status changed from Resolved to Closed
  • Resolution set to Wont fix

Also available in: Atom PDF