Redmine

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

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

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.

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'?

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