Defect #11887
open
Issue permission doesn't apply to Administrators
Added by Gabriel Mazetto over 13 years ago. Updated almost 11 years ago.
Description
I'm testing the new Issue permissions, and created a state that requires a field to be filled. While accessing the project as administrator, that specific permission doesn't apply to me.
That's somehow expected as It can't figure out what's my role as I haven't defined anyone.
But after I attached a role to my administrator user to that project, it continues to ignore that "required" field permission.
I believe that it shouldn't.
Files
Related issues
Updated by Chris Riether over 13 years ago
Is there any restriction (exept the workflow order) working for admins?
Seems not to me.
Have experienced the same. Argued to myself that if I would like to change the data, i could do it in the DB. So it wouldn't change a thing, if restrictions would work. It would only slow down my attempt. Admins are evil^^ You have to trust them.
Required data could be erased afterwards. So it doesn't matter, too.
But for the good feeling restrictions should be enabled.
Vote for it: +1
Best regards, Chris
PS.: thinking about it admins shouldn't be in worker roles.. like in the Linux-world adviced
Updated by Jean-Philippe Lang over 13 years ago
But after I attached a role to my administrator user to that project, it continues to ignore that "required" field permission.
Currently, admin users inherits workflow/fields permissions for all roles. So if the field is not required for at least one role, it's not required for admins. But if you set the field required for all roles, then it will be required for admin users too.
Updated by Florent Fievez over 13 years ago
I think this should be an option in the application settings ...
Updated by Daniel Felix over 13 years ago
Well i think, the whole admin-permission system should be more "flexible" more settings to set admin permissions to each role. and remove those admin checkbox. This way, we could define some "mini-admins" which could define custom fields, but can't change systemconfigurations and so on.
Updated by 
Updated by milena jael silva morales over 12 years ago
I have this problem too. I'm testing the new Issue permission and changing field permissions doesn't affect any ussers
Updated by Perico Os Palotes over 12 years ago
I would like to seed some light on this, based on my own experience, using Redmine 2.3.0.
You can test:
1. Login as "admin" account
2. Create a new project, let's call it "project1" accepting all default values
3. Create a new tracker, let's name it "new_tracker":
-Mark the checkbox "Copy workflow from" and select "Bug" in the dropdown
-Mark the checkbox "project_1"
-Click on "Create" leaving the other options untouched.
4. Go to Administration / Workflow
5. Select "Manager" in the role dropdown and "new_tracker" in the tracker dropdown and click Edit
6. Click on "Field permissions" tab
7. Select "Required" in the "Description" standard field (X coordinate) and for "In progress" status (see attachment) and click "Save"
8. Repeat steps 5-7 to all roles
9. Create a new user, let's call it "user1", and make it admin.
10. Go to Administration / Projects and click on "project1"
11. Click on "Members" tab and select at the same time "user1" and "Manager" role, and then click "Add"
11. Login as "user1", if possible in another browser, keeping "admin" session open
12. Create a new issue, selecting "new_tracker" in the Tracker drop down, fill just the subject and click on "Create"
13. Click on "update" and then change the status to "In progress"
If you followed all the steps below, the "Description" field will be updated and be mandatory, so you will not be able to click on the "Submit" button with the field empty.
The rule is: the field ("Description" in our example) and the status ("In progress" in our example) should be "Required" or "Read-only" to ALL the roles in order to be applied to "admin" users.
If just one role does not have this field - status combination to "Required" or "Read-only", no restriction will be applied to admin users for this field - status combination.
I hope that this help to understand a little bit the logic of field permissions regarding admin users.
Updated by Toshi MARUYAMA over 12 years ago
- Related to Defect #15327: move issue(s) disappeared / not functional added
Updated by Frederico Camara almost 11 years ago
Trere is a strange behaviour in the app/models/issue.rb model.
A tracker (issue type) has to have a required custom field in ALL ROLES the user is using on a project, for the field to be actually required.
This way I can't have roles that give just specific permissions.
I think that from the roles the user have on a project, only the roles that can change a tracker (issue) to a certain state should be checked. Roles that have no meaningful workflow could not be determinant to if a field becomes readonly or required.
Unfortunately a recent change in 2.6.5 interferes with my patch. Anyway, here's the patch against redmine 2.6.3, maybe it can be adapted:
533c533,534 < workflow_permissions = WorkflowPermission.where(:tracker_id => tracker_id, :old_status_id => status_id, :role_id => roles.map(&:id)) --- > vroles = WorkflowTransition.where(:tracker_id => tracker_id, :new_status_id => status_id, :role_id => roles.map(&:id)).pluck(:role_id) & roles.map(&:id) > workflow_permissions = WorkflowPermission.where(:tracker_id => tracker_id, :old_status_id => status_id, :role_id => vroles) 541c542 < next if rules.size < roles.size --- > next if rules.size < vroles.size
Updated by Mischa The Evil over 10 years ago
- Has duplicate Defect #19417: status change is allowed with empty workflow-required custom field added
Updated by Toshi MARUYAMA over 10 years ago
- Has duplicate Defect #20628: Standard field (Due Date) for Redmine not showing as required. added
Updated by Go MAEDA over 1 year ago
- Related to Feature #6670: Admin rights should not override rights given through roles added