Project

General

Profile

Actions

Defect #11887

open

Issue permission doesn't apply to Administrators

Added by Gabriel Mazetto over 11 years ago. Updated about 9 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 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

01.png (53.1 KB) 01.png Perico Os Palotes, 2013-09-18 17:53

Related issues

Related to Redmine - Defect #15327: move issue(s) disappeared / not functionalClosed

Actions
Has duplicate Redmine - Defect #12331: Configurable required fields per tracker/status/role not respected by Admin RoleClosed

Actions
Has duplicate Redmine - Defect #12942: Administrators are not required to fill out fields set to "required" via Workflow field permissionsClosed

Actions
Has duplicate Redmine - Defect #13980: Custom field permissions not applying Closed

Actions
Has duplicate Redmine - Defect #13926: Changing field permissions doesn't affect all usersClosed

Actions
Has duplicate Redmine - Defect #19417: status change is allowed with empty workflow-required custom fieldClosed

Actions
Has duplicate Redmine - Defect #20628: Standard field (Due Date) for Redmine not showing as required.Closed

Actions
Actions #1

Updated by Chris Riether over 11 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

Actions #2

Updated by Jean-Philippe Lang over 11 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.

Actions #3

Updated by Florent Fievez over 11 years ago

I think this should be an option in the application settings ...

Actions #4

Updated by Daniel Felix over 11 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.

Actions #5

Updated by Andreas Hestermeyer almost 11 years ago

+1

Actions #6

Updated by milena jael silva morales over 10 years ago

I have this problem too. I'm testing the new Issue permission and changing field permissions doesn't affect any ussers

Actions #7

Updated by Perico Os Palotes over 10 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.

Actions #8

Updated by Toshi MARUYAMA over 10 years ago

  • Related to Defect #15327: move issue(s) disappeared / not functional added
Actions #9

Updated by Frederico Camara about 9 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
Actions #10

Updated by Mischa The Evil almost 9 years ago

  • Has duplicate Defect #19417: status change is allowed with empty workflow-required custom field added
Actions #11

Updated by Toshi MARUYAMA over 8 years ago

  • Has duplicate Defect #20628: Standard field (Due Date) for Redmine not showing as required. added
Actions

Also available in: Atom PDF