How to limit the assign permission?

[NS]

Guys, I want to know how can I limit few of my trac users, so that they will have limited permissions on ticket assigning?

Basically, It's like this....We have 4 user groups as;

Super Admin - John
Engineer Admin - Jane, Jack, 
Engineer - Peter, Sam, 
Quality Assurance - Bill, Steve, Rose

This is how our main daily routine goes, 

* Enginner Admins can create tickets and assign it to any of the other member so they will work on it.
* Engineers don't actually create anything, but in some cases they will create.
* QA team tests the product and create new tickets for bugs...and they assign it to anyone they want.

So with basic features we have in Trac, this is all fine..But now, the time has come to limit these QA guys because it's not going easy anymore when they assign any one they want.

Instead, I want them to be able to assign only to Jane or Jack, who is in the Engineer Admin group. (If I add anyone to Eng. admin group in future, they should be able to assign him/her to too)

Then Jane or Jack will assign the ticket to the relevant Enginner who is in the Engineer Group.

How can I get this done?

I tried many ways like custom permission, workflows and so on..But had no luck so far. I hope somebody can help me soon.

Thanks in advance!!!!!!!

[Ryan Ollos]

Previously discussed in:
http://stackoverflow.com/questions/26965933/trac-limited-assign-permissions/26970812#26970812

Please post your [extra-permissions] [components] and [ticket-workflow] sections from trac.ini

[Patrick Schaaf]

Am 18.11.2014 08:09 schrieb "NS" <nime...@gmail.com>:
>
> Guys, I want to know how can I limit few of my trac users, so that they will have limited permissions on ticket assigning?
>
> Basically, It's like this....We have 4 user groups as;
>
> Super Admin - John
> Engineer Admin - Jane, Jack,
> Engineer - Peter, Sam,
> Quality Assurance - Bill, Steve, Rose

Have a look at http://trac-hacks.org/wiki/GroupingAssignToPlugin

I wrote that, and use it in production, for trac 0.11.6, but maybe you are lucky and it will work with newer versions.

best regards
  Patrick

[RjOllos]

I'll attempt to clarify the previously described recipe. I ran through these steps on a clean Trac instance with Trac 1.0.1.

Here is what I understand your requirements to be:

 - Users in all 4 groups can create tickets.

 - Users in the Super Admin, Engineer Admin and Engineer groups can assign a ticket to anyone.

 - Users in the Quality Assurance group can only assign to users in the Engineer Admin group.

1. Enable ExtraPermissionsProvider

Navigate to Admin tab, then General > Plugins (url is /admin/general/plugin)

Or you can enable by directly editing trac.ini:

[components]

tracopt.perm.config_perm_provider.extrapermissionsprovider = enabled

2. Define permission by directly editing trac.ini:

[extra-permissions]

_perms = TICKET_ASSIGN_QA, TICKET_ASSIGN

3. Edit [ticket-workflow] in trac.ini

Started with the basic default workflow,

[ticket-workflow]

accept = new,assigned,accepted,reopened -> accepted

accept.operations = set_owner_to_self

accept.permissions = TICKET_MODIFY

leave = * -> *

leave.default = 1

leave.operations = leave_status

reassign = new,assigned,accepted,reopened -> assigned

reassign.operations = set_owner

reassign.permissions = TICKET_MODIFY

reopen = closed -> reopened

reopen.operations = del_resolution

reopen.permissions = TICKET_CREATE

resolve = new,assigned,accepted,reopened -> closed

resolve.operations = set_resolution

resolve.permissions = TICKET_MODIFY

Added special actions for the QA group and modified the permissions for the existing actions:

[ticket-workflow]

accept = new,assigned,accepted,reopened -> accepted

accept.operations = set_owner_to_self

accept.permissions = TICKET_ASSIGN

leave = * -> *

leave.default = 1

leave.operations = leave_status

reassign = new,assigned,accepted,reopened -> assigned

reassign.operations = set_owner

reassign.permissions = TICKET_ASSIGN

reopen = closed -> reopened

reopen.operations = del_resolution

reopen.permissions = TICKET_CREATE

resolve = new,assigned,accepted,reopened -> closed

resolve.operations = set_resolution

resolve.permissions = TICKET_MODIFY

qa_reassign = new,assigned,accepted,reopened -> assigned

qa_reassign.name = reassign

qa_reassign.operations = set_owner

qa_reassign.permissions = TICKET_ASSIGN_QA

qa_reassign.set_owner = Jane, Jack

4. Groups - it sounds like you've already defined these and I tried to copy what you have. Here it is for reference:

5. Permissions

I started with the default permission scheme.

a. Give the Super Admin, Engineer Admin and Engineer groups the TICKET_ASSIGN permission. I took for your description that those groups should be able to create tickets and assign to anyone.

b. Give the Quality Assurance group the TICKET_ASSIGN_QA permission. This will give them limited assign-to ability, but they will be able to create any tickets.

Here is a demonstration. I'm logged in as Steve and created a new ticket. The workflow dialog shows:

The assign-to select element contains just two users: Jack and Jane. When additional users are added to the Engineer Admin group in the future the qa_reassign.set_owner list in the [ticket-workflow] section will need to be edited to add those users. This would all be a bit nicer if a group could be specified for qa_reassign.set_owner, but Trac doesn't allow that yet. Maybe the aforementioned GroupingAssignToPlugin can help with that, I'm not sure. For a small scale operation in which you aren't adding new users too often I wouldn't expect this to be much of an issue, just document the steps to be done when adding users to groups.

You also said "Then Jane or Jack will assign the ticket to the relevant Enginner who is in the Engineer Group.". If you want to restrict the list of users that Jane and Jack see in the assign-to list, you would follow the same steps as above to create a new assign-to permission, and a new workflow action that applies only to users with that permission.

When logged in as Jane I can assign to anyone. If you have [ticket] restrict_owner = True you'll see a list of all users rather than a simple input box.

References:

 * http://trac.edgewall.org/wiki/ExtraPermissionsProvider

 * http://trac.edgewall.org/wiki/TracWorkflow

 * http://stackoverflow.com/questions/26965933/trac-limited-assign-permissions/26970812#26970812

[RjOllos]

One more thing. The [[Workflow]] macro inserted anywhere that wiki markup is allowed will display the configured workflow. This can be a useful tool to get the desired workflow.

[RjOllos]

On Tuesday, November 18, 2014 6:33:19 AM UTC-8, RjOllos wrote:

The assign-to select element contains just two users: Jack and Jane. When additional users are added to the Engineer Admin group in the future the qa_reassign.set_owner list in the [ticket-workflow] section will need to be edited to add those users. This would all be a bit nicer if a group could be specified for qa_reassign.set_owner, but Trac doesn't allow that yet.

Proposed change to allow groups to be specified in the `set_owner` attribute in #11839:
http://trac.edgewall.org/ticket/11839

[Patrick Schaaf]

Am 18.11.2014 22:23 schrieb "RjOllos" <rjo...@gmail.com>:
>
> Proposed change to allow groups to be specified in the `set_owner` attribute in #11839:
> http://trac.edgewall.org/ticket/11839

Yeah! :)

One question after looking at that change: is it established convention now that everything starting with an uppercase letter, is a permission, and everything else is not? In other words, permission "groups" might NOT start with an uppercase letter?

In our deployment, we use the convention
* usernames are all lower case
* Group_Names are mixed case
* PER_MISSIONS are ALL uppercase
which would clash a bit with the scheme as you implemented it. No big deal, should we ever get around to upgrading to a current trac version we could easily change our scheme. Just saying.

best regards
  Patrick

[Patrick Schaaf]

> In our deployment, we use the convention
> * usernames are all lower case
> * Group_Names are mixed case
> * PER_MISSIONS are ALL uppercase

Had a look at what I actually did in GroupingAssignToPlugin three years ago. It is:
* anything all-lowercase is conidered a username, and not recursively checked
* anything else is recursively resolved

So, I could, in addition to the Group_Names I actually use, also put some PER_MISSIONS into the workflow step .owner_group setting, like .owner_group = TICKET_MODIFY, and have it populate the box with all users having that permission.

Again, just noting the differences to your implementation - you are infinitely better suited to judge what's the "tracky" way of doing it :)

best regards
  Patrick

[RjOllos]

I believe the only constraint in the Trac code should be that all-uppercase are permission names. That's specified on the TracPermissions page (1).

"Use at least one lowercase character in user names, as all-uppercase names are reserved for permissions." 

The "if not perm[1].isupper()" condition in in the list comprehension for all_groups says that any permission that is not all uppercase is a group name.

Permission groups can therefore be all lowercase or mixed-case. I think your scheme should work fine with the patch.

(1) http://trac.edgewall.org/wiki/TracPermissions#GraphicalAdminTab

[RjOllos]

On Tuesday, November 18, 2014 10:34:58 PM UTC-8, Patrick Schaaf wrote:

> In our deployment, we use the convention
> * usernames are all lower case
> * Group_Names are mixed case
> * PER_MISSIONS are ALL uppercase

Had a look at what I actually did in GroupingAssignToPlugin three years ago. It is:
* anything all-lowercase is conidered a username, and not recursively checked
* anything else is recursively resolved

So, I could, in addition to the Group_Names I actually use, also put some PER_MISSIONS into the workflow step .owner_group setting, like .owner_group = TICKET_MODIFY, and have it populate the box with all users having that permission.

This could be a good feature to support. If we don't implement the ability to put a permission in the set_owner field then you'd have to make sure that all users with TICKET_MODIFY share a group or set or groups that each have the TICKET_MODIFY permission. This could be extremely simple or very complicated depending on the data in your permissions table.

 

Again, just noting the differences to your implementation - you are infinitely better suited to judge what's the "tracky" way of doing it :)

best regards
  Patrick

Thank you for the feedback! 

[Patrick Schaaf]

Am 19.11.2014 07:39 schrieb "RjOllos" <rjo...@gmail.com>:
>
> The "if not perm[1].isupper()" condition in in the list comprehension for all_groups says that any permission that is not all uppercase is a group name.

My python reading comprehension is obviously lacking. Thanks for the clarification.

best regards
  Patrick

[RjOllos]

On Tuesday, November 18, 2014 10:51:08 PM UTC-8, RjOllos wrote:

On Tuesday, November 18, 2014 10:34:58 PM UTC-8, Patrick Schaaf wrote:

> In our deployment, we use the convention
> * usernames are all lower case
> * Group_Names are mixed case
> * PER_MISSIONS are ALL uppercase

Had a look at what I actually did in GroupingAssignToPlugin three years ago. It is:
* anything all-lowercase is conidered a username, and not recursively checked
* anything else is recursively resolved

So, I could, in addition to the Group_Names I actually use, also put some PER_MISSIONS into the workflow step .owner_group setting, like .owner_group = TICKET_MODIFY, and have it populate the box with all users having that permission.

This could be a good feature to support. If we don't implement the ability to put a permission in the set_owner field then you'd have to make sure that all users with TICKET_MODIFY share a group or set or groups that each have the TICKET_MODIFY permission. This could be extremely simple or very complicated depending on the data in your permissions table.

Trac #11839 has been resolved - permissions and groups can be included in the comma-separated list of the `set_owner` workflow attribute. Trac 1.1.3 will be released in a few days. Please let us know if you are able to try out the new feature, and if you see any deficiencies in the implementation.

I briefly documented how to upgrade from the GroupingAssignToPlugin, but more detailed information might be useful:
http://trac-hacks.org/wiki/GroupingAssignToPlugin?action=diff&verion=7&old_version=4