Defect #15327
closed
move issue(s) disappeared / not functional
Added by Terence Mill over 10 years ago.
Updated about 1 month ago.
Category:
Issues permissions
Description
Since redmine 2.3.3 i don't have "move issue" operation anywhere (button on issue form, context menu entry in issue list) although i have a role for this project with checked "move issues" right.
When i manually call the url "https://redmine.local/issue_moves/new/13101" i get "Routing Error (no Route matches [Get]..."
I have no plugins installed
- Status changed from New to Closed
- Resolution set to Invalid
Ok i see.
In redmine 1.3 i could "move" issues from one status to another "ignoring" the workflow. That is very useful if you are admin/manager. Now - with the new merged features - i don't find any way to do that. Do i really have to modify the worflow to mahe such administrative work?
I can't say anything about how 1.3.x handled issue move, but (also starting with 1.4.0) administrators actually does have the ability to bypass the workflows (status transitions ánd field permissions). This was implemented as part of #2323 and is discussed in #11887 and #11625.
Kind regards,
Mischa.
- Status changed from Closed to Reopened
Hmm this is really ugly, because as i said in former redmine versions the "move" operation right gave everybody with the correspoding role's (issue move right) the possibility to change status beyond workflow. Now it looks like only system internal redmine users can do this any more, what means that this chnage is not downwards compatible and i have to model all possible transactions in worflow (also the project manager needs for maitenance beyond offical worflow). Our project managers are used to use this "old move" feature also to skip worflow steps or fast forward in edge cases. Despite the modeled worflow still is the most used specification and oblige for non manager /pl roles.
Without this feature as redmine admin i will have to make transitaions from nearly any status to another. I don't wanna discuss why that or this is not allowed with every project manager, because he/she is rsonsible in his project at the end.
Terence Mill wrote:
this chnage is not downwards compatible
Our project managers are used to use this "old move" feature
Sometimes we must deprecate old functions to implement features we think are better.
I don't wanna discuss why that or this is not allowed with every project manager
Solving human problems through technology does almost never work. If you want project managers to follow certain internal standards, than communication is the only feasible way.
- Description updated (diff)
- Related to Defect #11887: Issue permission doesn't apply to Administrators added
- Status changed from Reopened to Closed
- Priority changed from High to Normal
The defined workflows should be followed to avoid invalid cases. The old behavior that the workflows were sometimes ignored was a bug which was fixed. The current behavior is thus correct.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by Toshi MARUYAMA 
Updated by