Vote #65386
未完了Assign an issue to person based on the issue status
0%
説明
In the same way we can assign an issue to a person based on the category, is it possible to have this ability when we change the status of an issue?
I have a need that when a status is changed from Development to Test for example, the issue must be assigned to another person that will conduct the tests. Later, once we marked as Resolved, it should be assigned to another person where it will do the final steps to closing the issue, like moving the code to production environment.
Is this feasible? I'm wondering if this could be included as an option in redmine or a plugin. I'm not familiar with Ruby so any help or advices will be very appreciated.
journals
Hello,
I am interisting with this facility for this case also. Or is it a way to do the same things.
Regards
Stephane
--------------------------------------------------------------------------------
Good idea! I like it!
--------------------------------------------------------------------------------
This is a fantastic idea! If implemented, it would allow Redmine to drive a process.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Well, this seems to be a good idea. In addition, this could be coupled with the categories.
Example:
# Ticket with status "new" and category "UI" is created
# Ticket will be assigned to group "Frontend Developers"
# Ticket will be set to resolved by a person of the group "Frontend Developers"
# Status resolve in category "UI" will set the assignment to "Codereview"
# Ticket will be set to closed by "Codereview" which closes the ticket, or will be set to "Rejected", which will reassign it to the group "Frontend Developers"
Example 2:
# Ticket with status "new" and category "Translation" is created
# Ticket will be assigned to group "Translators"
# Ticket will be set to resolved by a person of the group "Translators"
# Status resolve in category "Translation" will set the assignment to "Translationreview"
# Ticket will be set to closed by "Translationreview" which closes the ticket, or will be set to "Rejected", which will reassign it to the group "Translators"
Translationreview and Codereview are two different departments in the company and couldn't be in the same group. This way, we could have a complete automatic ticket workflow. What do you think?
--------------------------------------------------------------------------------
By now, workflows are defined in transition tables per tracker / per role. This way they are finite state machines.
However, these state machines lack of actions on transitions. If such actions were available and was possible to be defined by the user / administrator, above intentions could be fulfilled.
Here is an example list of actions on state transitions:
* change assignee to a previously defined group
* change done percent
* change priority
* change previously defined custom field to a new predefined value
* send e-mail to someone (? - Watcher system is enough?)
* activate external application
* something else...
And as an extension of above, instead of defining single actions, a set (or list) of actions could be defined on state transitions.
I suppose this could be done in a plugin using the hook :controller_issues_edit_before_save.
---------------------
Another idea based on above one idea.
Let's imagine User Interface that presents a state transitions table. Then an user chooses a transition. As a result a dialog activates that shows what will happen on the transition, asking for permission). And if the user confirm changes, they happen and new status is chosen at last.
How this could be activated?
* by a button in issue edit dialog: 'Make a transition' or 'Change status'
* by a menu item in the context menu
--------------------------------------------------------------------------------
I'd be interested in broader options for automating transitions between statuses. JIRA provides a good conceptual model for this kind of functionality at https://confluence.atlassian.com/display/JIRA/Configuring+Workflow#ConfiguringWorkflow-Stepsandtransitions.
The short version is that a workflow defines both steps (statuses) and transitions (status changes). In JIRA, the definition for a transition includes the target status (what the new issue status will be) as well as one or more of the following:
1. A screen, which provides all (and only) the fields related to the status change. Redmine can nearly replicate this behavior by defining all unrelated fields as "Read Only" for the target status, although setting these in the current UI is a real pain.
2. Conditions, which is just who can change an issue from status X to status Y. Redmine already does this.
3. Input Validators, which Redmine also provides already.
4. Post Functions, or automated changes to the issue that occur at the time of transition. These can include changing the assignee to a specified value, but they can include changes to other issue attributes as well.
If I knew enough Ruby, I would approach the problem in the following way:
Revise the UI for workflows around the concept of transitions; most of this replaces the "Read Only/Required" matrix of field settings in workflow administration. An administrator creates a Transition, and then adds Properties to the Transition. After clicking "Add Transition Property" the user is presented with three types of Properties:
(1) Field: Fields the user can change when changing the status; these appear in the Update panel
(2) Required Field: Fields the user _must change_ when changing the status, which appear as required fields in the Update panel, and
(3) Automatic Update: Fields that change automatically; for these the admin defines the new value for the field.
Back in the standard/original workflow UI, there is a space beneath each checkbox and a new column to the right with a list of Transitions. By dragging a Transition over a checkbox and releasing it, the box is checked (if it wasn't already) and the name of the transition appears below the check. (If we want simple but clunky, we could also include a drop-down menu beneath each checkbox.) That enables the selected User Role to perform the selected change from one state to another, but the change follows the rules defined by the assigned Transition. Changes without assigned Transitions, where the admin just checked the box, occur as normal.
Thoughts?
--------------------------------------------------------------------------------
+1 - Does anyone know if there's a plugin that implements this feature?
--------------------------------------------------------------------------------
Hello,
Any news about this really usefull feature ?
Cédric
--------------------------------------------------------------------------------
+1 Great Feature
--------------------------------------------------------------------------------
Yamuna Vee wrote:
> +1 - Does anyone know if there's a plugin that implements this feature?
you may want give http://www.redmine.org/plugins/redmine_luxury_buttons a spin. /m
--------------------------------------------------------------------------------
+1 for the request to implement the missing feature
markus schulte wrote:
> Yamuna Vee wrote:
> > +1 - Does anyone know if there's a plugin that implements this feature?
>
> you may want give http://www.redmine.org/plugins/redmine_luxury_buttons a spin. /m
The plugin looks great. Is anyone using it already?
It provides all the features, which redmine is lacking right now about ensuring status processes.
Any plans from the redmine dev lead to incorporate the plugin in default redmine?
--------------------------------------------------------------------------------
This plugins works!!!!
https://github.com/jjrosalesuci/redmine_auto_assigned
--------------------------------------------------------------------------------
Can you improve the documentation, please?
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
The link of https://github.com/jjrosalesuci/redmine_auto_assigned is not working, page not found
--------------------------------------------------------------------------------
/M Hasan
You're right.
The link of https://github.com/jjrosalesuci/redmine_auto_assigned is not working, page not found.
Does anyone know an active link of downloading the plugin of this feature?
--------------------------------------------------------------------------------
+1 Does anyone know an active link of downloading the plugin of this feature?
--------------------------------------------------------------------------------
This plug-in can be used for automatic setting of assignee in charge of workflow.
http://www.redmine.org/plugins/status_button
The original corresponds to 2.3, but github-forked version supports 3.2.
I hope you find it useful.
--------------------------------------------------------------------------------
thanks, I'm researching...
Yuuki NARA wrote:
> This plug-in can be used for automatic setting of assignee in charge of workflow.
>
> http://www.redmine.org/plugins/status_button
>
> The original corresponds to 2.3, but github-forked version supports 3.2.
>
> I hope you find it useful.
--------------------------------------------------------------------------------
+1, would be interested in this feature too.
Has anyone experiences with the plugin Status Button in conjunction with V3.x?
Is there any other plugin available which is not in alpha stadium since 4 years?
regards
gerhard
--------------------------------------------------------------------------------
related_issues
relates,New,521,Add preference to auto-reassign back to author on resolve or feedback
relates,New,10139,extend ability to associate settings based on initial category
relates,Closed,482,Default assignee on each project
duplicates,Closed,6708,Change owner when change status
duplicates,Closed,10947,Default assignment based on project and issue state (this is not a duplicate of issue #482).
duplicates,Closed,19231,Link between "status" and "assigned to" fileds
duplicates,Closed,13299,Autochange assignee depending on status change