Redmine

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.

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)".

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

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!

Is there any chance that this fix/feature should be included into official release?

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.

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

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:

1. Usability problem: if the current status is not available in the list the first status should be selected by default
2. 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:

1. if the current state is not allowed as next state, the first option in the state select needs to get the "selected" attribute
2. 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