Defect #34570
Misleading workflow/permission issue
| Status: | New | Start date: | ||
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | Permissions and roles | |||
| Target version: | - | |||
| Resolution: | Affected version: | 4.1.1 |
Description
I'm using the latest version of Turnkey Linux Redmine:
https://www.turnkeylinux.org/redmine
Environment: Redmine version 4.1.1.stable Ruby version 2.6.6-p146 (2020-03-31) [x86_64-linux] Rails version 5.2.4.2 Environment production Database adapter Mysql2 Mailer queue ActiveJob::QueueAdapters::AsyncAdapter Mailer delivery sendmail SCM: Subversion 1.10.4 Git 2.20.1 Filesystem Redmine plugins: no plugin installed
If a user is assigned multiple roles, any workflow defined on any role will affect that user, even if one of those roles has no editing issue edit permission.
Example:- Role 1
- I don't remove Close status from all statuses in that role's Workflow.
- I remove all edit permissions from Issue Tracking permissions.
- Role 2
- I remove Close status from all statuses from that role's Workflow.
- I allow Edit Issues permission in Issue Tracking permissions.
If I assign a user both Role 1 and Role 2, he will be able to Close issues.
Not sure if you'd consider this a defect per se, but I just spent a chunk of time configuring a new redmine server at work, and it took me a bit to figure out why my users had the ability to close issues, even when the workflows I painstakingly defined for them appeared to prevent it.
It was because I was using multiple roles to control their access, and I hadn't edited the workflow of the other role to match, or at least not conflict.
The confusion is bolstered by the fact that you can't see the role in the dropdown on the Workflow edit page, to correct such a mistake, until you restore the edit permissions on that Role's edit page, in the Permission's section.
Since issue status workflows only really come into play for someone who has edit permission for Issues, I suggest that worfklows become effectively disabled for any role whenever that role loses edit permission for Issues.
History
#1
Updated by Go MAEDA 15 days ago
James Brady wrote:
Example:
- Role 1
- I don't remove Close status from all statuses in that role's Workflow.
- I remove all edit permissions from Issue Tracking permissions.
- Role 2
- I remove Close status from all statuses from that role's Workflow.
- I allow Edit Issues permission in Issue Tracking permissions.
If I assign a user both Role 1 and Role 2, he will be able to Close issues.
It is normal behavior. A user with multiple roles has all permissions assigned to the roles. And the user also is allowed all status transitions configured for the roles.
Since the user in the example belongs to "Role 1" and "Role 2", all permissions and status transitions configured in both roles are available for the user. The user has "Edit issues" permission because it is allowed via "Role 2", and is allowed to change the status of an issue to "Close" because the transition is allowed via "Role 1".
#2
Updated by James Brady 14 days ago
I understand that the user has edit capability because the permissions are active on at least one of the roles.
I still suggest it's a bit unclear, on its face, that the workflow for the role without edit permission affects anything, particularly since that workflow cannot be edited while the edit permissions are off.