Feature #13560
open
Force status transition on issue update
Added by VD DV over 11 years ago. Updated over 9 years ago.
0%
Description
I will try to explain this situation by using provided screenshot that represents one dummy workflow (created just for this purpose).
If user that owns "Reporter" role updates issue that is in state "Resolved" he is not restricted to "Feedback" status only (according to workflow). This user can also update this issue and leave issue status as "Resolved" (this transition is not allowed).
Files
| shot.jpg (36 KB) shot.jpg | dummy workflow | VD DV, 2013-03-22 12:18 | |
| shot2.jpg (29 KB) shot2.jpg | "Resolved"->"Resolved" issue status | VD DV, 2013-03-27 09:26 |
Related issues
Updated by Jean-Philippe Lang over 11 years ago
- Tracker changed from Defect to Feature
- Subject changed from Status transitions does not entirely follow workflow definition to Force status transition on issue update
Updating an issue without changing its status is allowed by design. That would mean that the user is not even allowed to add a note without changing the status. What is the use case behind this?
Updated by VD DV over 11 years ago
Here is use case. We are planning to create new statuses "Feedback to customer" and "Feedback from customer". We want to have simple mechanism of forcing change of issue status from "Feedback to customer" to "Feedback from customer" if customer edits issue that is in status "Feedback to customer". Of course it can be only possible if this status transition ("Feedback to customer"->"Feedback from customer") is the only one defined in customers workflow in row where current status is "Feedback to customer".
I think that problem that you have stated with inability to add notes can be solved if that workflow transition from one issue status to same issue status is defined (see "Resolved"->"Resolved" issue status in example screenshot shot2.jpg). Right now that transition (from some issue status to same issue status) in workflow does not have any affect. Am I right?
It could be useful to have ability to force Issue status change if transition from/to same issue status is not defined in workflow.
Updated by Arin Lipman over 11 years ago
Another use case (which is one that I'm looking for) is when the issue is New. Once it is updated (if I've set this up in the Workflow) it should no longer be possible to be New.
Updated by Joe Cullin over 11 years ago
We have the workflow that VD DV described above. We count on users to manually change the status, which is not 100% reliable. It's not usually a big deal if someone forgets to change the status: one of the watchers or the assignee will notice the oversight and fix it. And if that doesn't happen, I usually spot it on a report that I get the next morning.
I've used another issue tracking system in the past which did have this feature. The only annoying thing about that was that sometimes customers would respond with updates that shouldn't have been status-changing. For example, "I haven't had a chance to try your suggested fix yet, I'll try it within the next week and let you know how it worked." That would bump the issue out of Need Feedback, and then you'd have to go put it back.
Because there are always exceptions, I probably wouldn't go for a heavy-handed approach that forces a status change. But I would like it if there were a more-prominent prompt, asking the user to consider a status change. Other than Notes, status is our most-frequently-changed field, and it kind of gets lost amongst the other issue properties. Maybe they'd get an alert on submit, or they'd see a reminder next to the submit button, or they could even see multiple submit buttons: "submit (keep in Need Feedback)" or "submit (Feedback given)".
Updated by Tadashi Hirata over 10 years ago
It seems to me just a bug.
Definitely there are some use cases as above, and I support the idea that if you don't check status_A/status_A crossing point in your workflow, status_A shouldn't appear in its edit view.
model/issues.rb includes the following line but it is nonsense (if updating an issue without changing its status is allowed, you don't need "unless" condition simply). Does it mean "ifstatuses.empty?" ??
After applying this patch, it shold work as VD DV wanted.
--- a/app/models/issue.rb
+++ b/app/models/issue.rb
@@ -751,7 +751,7 @@ class Issue < ActiveRecord::Base
author == user,
assigned_to_id_changed? ? assigned_to_id_was == user.id : assigned_to_i
)
- statuses << initial_status unless statuses.empty?
+ statuses << initial_status if statuses.empty?
statuses << IssueStatus.default if include_default
statuses = statuses.compact.uniq.sort
blocked? ? statuses.reject {|s| s.is_closed?} : statuses
Updated by Jose Juan Montes over 10 years ago
It seems to me just a bug.
Definitely there are some use cases as above, and I support the idea that if you don't check status_A/status_A crossing point in your workflow, status_A shouldn't appear in its edit view.
+1
model/issues.rb includes the following line but it is nonsense (if updating an issue without changing its status is allowed, you don't need "unless" condition simply). Does it mean "ifstatuses.empty?" ??
After applying this patch, it shold work as VD DV wanted.
Confirmed. The patch works for me. Thanks for this!
Updated by VD DV over 10 years ago
Is there any chance that this fix/feature should be included into official release?
Updated by Tadashi Hirata over 10 years ago
VD DV wrote:
Is there any chance that this fix/feature should be included into official release?
It seems "Feature" category less interests most of developers, I sent the patch to
"Patch" category too (#16364), then it might be accepted.
Updated by Toshi MARUYAMA over 10 years ago
- Related to Patch #16364: Issue workflow doesn't force status transition though workflow is defined so added
Updated by VD DV almost 10 years ago
Please can you consider including this feature into 3.0 release? You might also make this feature optional by adding switch at global redmine settings (or individual project settings) that can be used to tun on or off this new feature (just in case you are considered how this feature would affect other redmine users).
Thank you
Updated by Alexander Stehlik over 9 years ago
Adding my comments from the patch #16364 here:
I just realized that there is a usability / validation issue, when the currently selected status is not allowed as new status.
The select field is rendered and does not contain the current status any more. But no value is selected by default which makes the browsers (Chrome / Firefox) render an empty option that is selected by default.
When the form is submitted with the empty option, the status does not change.
This indicates two problems:
- Usability problem: if the current status is not available in the list the first status should be selected by default
- Validation problem: when the form is submitted and the current state is not allowed any more there should be an error.
Both problems show up when you really want to force workflow transition.
With the current patch both issues will hit you, when you want to force a state change during saving.
To solve those problems two additions are needed for the patch to work nicely:
- if the current state is not allowed as next state, the first option in the state select needs to get the "selected" attribute
- there needs to be a validation that makes sure that the submitted state is allowed as next state. So if the current state must be changed (forced transition) an empty state must not be an allowed value