Project

General

Profile

Actions

Defect #34570

open

Misleading workflow/permission issue

Added by James Brady about 3 years ago. Updated about 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Permissions and roles
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Affected version:

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.


Related issues

Related to Redmine - Defect #34284: In Role edit view the per tracker table only shows up when "View Issues" permission is selectedNew

Actions
Follows Redmine - Defect #15988: Unexpected behaviour on issue fields for users that have multiple roles ClosedJean-Philippe Lang

Actions
Follows Redmine - Feature #285: Tracker role-based permissioningClosedJean-Philippe Lang

Actions
Actions

Also available in: Atom PDF