Defect #28078

Workflows inconsistencies when removing "add/edit issue" permission to a role which already has a workflow defined

Added by Stephane Evr over 3 years ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-
Resolution: Affected version:

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)

Also available in: Atom PDF