Opened 9 years ago

Closed 8 years ago

# Complex Permissions for Workflows

Reported by: Owned by: josh@… Eli Carter normal AdvancedTicketWorkflowPlugin normal 0.11

### Description

It would be nice if it were possible to set the permissions for workflow options to more than just the trivial case of 'User has permission X'. For example, enable a workflow option if they /lack/ a particular permission, or if they are part of a particular user group.

### comment:1 Changed 9 years ago by Eli Carter

For the 'part of a particular user group', give that group a permission that can be used by the workflow.

For the 'lacks a given permission' case, can you give a couple use-cases where this would be necessary?

### comment:2 Changed 9 years ago by josh@…

Our use-case for both instances is this:

We have three streams of people accessing our Trac instance: Managers, Developers and Clients. Managers have TRAC_ADMIN permissions, Developers have most permissions, but can't monkey around in the admin panel, and Clients have a strict subset of the permissions Developers have (mostly to do with creating and modifying tickets). There are certain workflow options that we'd like to present to our Clients, but which are irrelevant for developers and managers, and which we don't want cluttering up the already increasing number of workflow options they're presented with.

As we don't have any spare ('throw-away' permissions) to give Clients but not developers, there currently seems to be no way to do this. Particularly since our managers have TRAC_ADMIN permissions, and thus all other permissions.

Being able to specify a workflow for a particular user-group (e.g. user is in group 'clients') or for when a user lacks a particular permission (e.g. 'TICKET_ADMIN') would seem to solve these problems.

### comment:3 Changed 9 years ago by Eli Carter

The extra permissions can be created using the sample-plugins/permissions/extrapermissionsprovider.py plugin from the Trac source. It will let you create arbitrary permissions to use in your workflows. Does that solve the first part of your request?

Could you create a managers group that had all the permissions that TRAC_ADMIN contains without specifying TRAC_ADMIN, or is there some ability they need that is directly dependant on the TRAC_ADMIN permission? If you can do that, you could specify a permission that the managers don't have. I can see that having the ability to specify !SOME_PERMISSION would be handy as a short-cut for this method, but I'm not certain it's the right solution... (And I fear the follow-on "I want SOME_PERMISSION and (!OTHER_PERM or SPECIAL_PERM)" request as well. ;) )

### comment:4 Changed 9 years ago by josh@…

The extra permissions thing would work in our case (I wasn't aware that existed). Bypassing that by being able to specify User-Groups as well as Permissions would nevertheless be quite useful.

### comment:5 Changed 8 years ago by derek@…

There is also the BlackMagicTicketTweaksPlugin that you can use to add arbitrary PERMISSIONS, then assign these permissions to users/groups. And use said permissions in workflow.

E.g. add MY_SPECIAL_PERMISSION via BlackMagicTicketTweaksPlugin in trac.ini, create a group called grp_my_special_people, assign the permission to the group, and then the group to all the relevant users. Using this approach you can achieve the result you're after.

IMHO it would break the security model if you rely on "the user belongs to a group" because that relationship should be distilled into a list of permissions before deciding whether a user may / may not do something.

### comment:6 Changed 8 years ago by Eli Carter

Resolution: → wontfix new → closed

The original usecases can already be addressed, and groups vs permissions is outside the scope of this plugin.

### Modify Ticket

Change Properties
Action
as closed The owner will remain Eli Carter.
The resolution will be deleted.