Feature #2323
closedWorkflow permissions for administrators
Added by Chaoqun Zou over 15 years ago. Updated over 12 years ago.
0%
Description
Since admin is designed to have all operation privileges, I think that though admin is not member of a project, he should also change the issue's status.
Do you think so?
If you agree with me, I can upload a patch for this.
And if you decide to leave this behavior as now, I will follow you, too.
Related issues
Updated by Jean-Philippe Lang over 15 years ago
- Tracker changed from Defect to Feature
Updated by Jean-Philippe Lang over 15 years ago
It was already discussed before but I can't find where.
In order not to break the workflow, a solution would be to give to admin users all the status transitions given to any role.
- 3 statuses are defined: A, B, C
- 2 roles: R1, R2
- R1 is allowed to do A -> B
- R2 is allowed to do B -> C
=> admins are allowed to do A -> B and B -> C (but not B -> A or C -> A and so on)
What do you think?
Updated by Thomas Pihl over 15 years ago
I really like it the way it is. The admin can change his/her role within the project as he/she see fit.
I use that all the time to be able to test different workflows. Imagine trying to create a workflow and having to log on as a different user all the time while testing.
My vote is for keeping this as it is.
/T
Updated by Chaoqun Zou over 15 years ago
Hi, Thomas
I think that the admin user's duty is to offer help to other users who may not be familiar to redmine. The admin user is a assistant of other users. He is commonly not a member of projects(at least he is not the member of every project).
So I think that allowing admin user to change issue's status of every project is a good feature.
But your request to keep the way as now is reasonable, too. Maybe we should wait for more comments.
By the way, after I studied the code about issue' status, I found that it was not very easy to implement this feature as I have expected. _
Updated by Peter Baumgartner about 15 years ago
IMO, Administrator == root user and should have full access to everything. If you want to test workflows, you should have to change to a different user. That is how every other system I've used works.
Updated by Jean-Philippe Lang over 14 years ago
- Subject changed from If admin is not member of a project, he cann't change the issue's status to Workflow permissions for admin users that do not belong to a project
Updated by Brandon Bonds over 14 years ago
Throwing in my thoughts, I agree that it should be changed. Every other aspect about an issue can be changed by the admin, including the person it is assigned to, the tracker, the project, etc. It can even be deleted. But the status cannot be changed... that seems out of place, especially considering that the admin is not prevented in any way from applying the workaround of temporarily adding the project to his/her account.
Updated by Brandon Bonds over 14 years ago
Jean-Philippe Lang wrote:
It was already discussed before but I can't find where.
Example:
In order not to break the workflow, a solution would be to give to admin users all the status transitions given to any role.
- 3 statuses are defined: A, B, C
- 2 roles: R1, R2
- R1 is allowed to do A -> B
- R2 is allowed to do B -> C
=> admins are allowed to do A -> B and B -> C (but not B -> A or C -> A and so on)
What do you think?
I vote to allow the admin to break the workflow. Perhaps a dialog box could ask "Are you sure?", or maybe have a warning next to the offending selections in the list, or even a warning (think red validation) that says it could break the workflow. Another thought... there could be a checkbox in workflow settings that says "[ ] Administrators are subject to workflow restrictions".
Anyway, there may be a good reason to break it... say that some issues have been left unresolved for a long time, and an admin needs to do a bulk close on the list.
And here's another aspect of your scenario to think about: could the admin also do A -> C now, since he/she can do A -> B -> C?
(By the way... great job on Redmine in general... the improvements over time have been much appreciated!)
Updated by Thomas Pihl over 14 years ago
It is very easy to create a super-user-role that have a checkmark in every box and thus can change anything.
Easy to add myself to the superuser-role if needed. Usually i don't use it.
Updated by Rolf Stetter over 12 years ago
Anyway, there may be a good reason to break it... say that some issues have been left unresolved for a long time, and an admin needs to do a bulk close on the list.
That excactly is the situation I face very often. And based on the nature of our business we have hundreds of projects where I would have to assign myself in a super-admin role.
So I definitly would like to do any status transition as admin.
Updated by Jean-Philippe Lang over 12 years ago
- Subject changed from Workflow permissions for admin users that do not belong to a project to Workflow permissions for administrators
- Category changed from Administration to Issues workflow
- Status changed from New to Closed
- Target version set to 1.4.0
- Resolution set to Fixed
Fixed in r8707 as proposed in note-2. Administrators are now allowed to do any status transition that is given to any role (even on projects they don't belong to).
For those who want administrators to be able to "break" the workflow, you just need to create a role with all status transitions allowed. No need to give it to any user, administrators will automatically inherit all these transitions on all projects.