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

--------------------------------------------------------------------------------
> 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.
--------------------------------------------------------------------------------
I think this should be an option in the application settings ...
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
I have this problem too. I'm testing the new Issue permission and changing field permissions doesn't affect any ussers
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
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:

<pre>
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
</pre>
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

relates,Reopened,15327,move issue(s) disappeared / not functional
duplicates,Closed,12331,Configurable required fields per tracker/status/role not respected by Admin Role
duplicates,Closed,12942,Administrators are not required to fill out fields set to "required" via Workflow field permissions
duplicates,Closed,13980,Custom field permissions not applying
duplicates,Closed,13926,Changing field permissions doesn't affect all users
duplicates,Closed,19417,status change is allowed with empty workflow-required custom field
duplicates,Closed,20628,Standard field (Due Date) for Redmine not showing as required.