Defect #28078
closedWorkflows inconsistencies when removing "add/edit issue" permission to a role which already has a workflow defined
0%
Description
I've tested this on a vanilla Redmine (3.4):
Steps to reproduce, as admin:
Setup:
- Set 2 new roles with add/edit issues permission. We have: Role A, Role B
- Set 1 new Tracker: Tracker A
- Set 3 new statuses: Status A, Status B, Status C
- Define a Workflow for Role A, Tracker A with the following: All transitions are checked between Status A, Status B. Transitions to and from Status C are NOT checked.
- Define a Workflow for Role B, Tracker A with the following: All transitions are checked between Status A, Status B, Status C.
Correct case:
- As an admin, or as a user with Role A AND Role B, go to the New issues form, and for tracker, choose "Tracker A"
- In the "Status" dropdown, Status A, Status B and Status C are shown
Incorrect case:
- As an admin, remove the add/edit issues permission for Role B
- As an admin, or as a user with Role A AND Role B, go to the New issues form, and for tracker, choose "Tracker A"
Observed:
- In the "Status" dropdown, Status A, Status B and Status C are shown
Expected:
- In the "Status" dropdown, Status A and Status B are shown
Reasons why this happens:
- When we uncheck the permission add/edit issues from a Role, the WorkflowRules are kept in base.
- In the method used to get the new statuses allowed, we don't filter out roles which are not allowed to add/edit issues, hence still reading the WorkflowRules above.
See details below
Details:
https://github.com/redmine/redmine/blob/e8bc1dbaa80dd714254da9c19e4ffaae4fbf9736/app/models/issue.rb#L988
https://github.com/redmine/redmine/blob/d105365e06eddfdd66406c56b5f45dba2fda6769/app/models/issue_status.rb#L66
Options to solve the problem:
- Delete the WorkflowRules associated with the role when add/edit issues permission is unchecked (maybe too destructive)
- Always filter (see links above) on roles for which the method consider_workflow?
returns true (seems the simplest)
Related issues