AssignTo Ideas

[shawn]

This is what I was thinking about the Assign To list. Please note that this will only work if you have a finite number of users you want to show in the Assign To list.

1. The trac.ini file will have a new option added. Maybe something like "restrict_grouplist". This group list will determine what users will be added to the Assign To list.
2. In the PERMISSION table, someone has to add the usernames associated to the group(s) that will be used to populate the Assign To list.
3. Modify the code accordingly.

Just a thought…

Feel free to comment.

[anonymous]

Shoot…. forgot about wikiformatting. Can an admin please modify the description so that AssignTo isn't a wiki link.

[Christian Boos]

Done. As for the idea itself, well we have to see how this could be easily adapted once the WorkFlow stuff is merged…

[Christopher Lenz]

Note that in 0.10 we already restrict the list of users in the assign to dropdown to those that have TICKET_MODIFY permissions, which I think should be good enough for most uses.

[dbrewer]

Consider this another vote for populating the drop down using something different than TICKET_MODIFY. In our shop, only a few people have permission to close tickets. Most staff are instructed to do the work on the ticket and then assign it to one of these project managers to confirm the work is done before closing the ticket.

As a result, we can't use the assign to field in dropdown mode because most of the users don't show up in the list. I suggest a TICKET_ASSIGNEE permission be created to populate this list; TICKET_MODIFY could include this permission by default, so it should be completely backwards compatible for those who are using the system the way it is now.

[Christian Boos]

See also #2662. There in comment:10, I propose an alternative for setting multiple owner for a ticket, by using group names. This has the advantage of not requiring to change the workflow logic (afaict) and the dropdown could still be used. The only requirement would be, as this ticket is about, to have an alternative way to fill the dropdown box.

[Christian Boos]

#4289 was closed as duplicate. That tickets lists other reasons why relying on the logged in info is probably not optimal.

[Morris]

I've got a patch for a specific use case: you're serving on Windows and want to get your list of assignable-to users from your Active Directory. It requires:

• Windows-based Trac installation;
• Trac ≥0.11dev-r5883 (might work with lower revs, but this is what I built from);
• LDAP/Active Directory server available that has the groups w/users defined;
• pywin32 and ​active_directory modules installed

I've added a few new keys to the [ticket] section of trac.ini:

[ticket]
## this is a variant of the trac default restrict_owner 
##  flag -- instead of restricting ticket assignments 
##  to people who have logged in, it restricts assignments 
##  to members of the LDAP groups specified in ldap_valid_owner_groups (below)
ldap_restrict_owner_by_groups = true

## this is the LDAP user object attribute to use in the 
##  drop-down list -- e.g., sAMAccountName, uid, etc.
ldap_show_user_attribute = sAMAccountName

## ldap_valid_owner_groups should be a comma-delimited 
##  list of group CNs from your LDAP/AD 
ldap_valid_owner_groups = IT Apps Dev,IT Apps Support

Given the above configuration, the AssignTo dropdown on a ticket would now list the sAMAccountName of each user in each of those groups (where the users are UNIONed using sets, so there shouldn't be any dupes). I'll be posting a ticket-with-patch soon (hopefully today) — when I do, I'll post another comment here with a link to that ticket in case anyone is interested.

[Morris]

Ticket w/patch created: ​http://trac.edgewall.org/ticket/5858

[Eli Carter]

With the configurable workflow, the set_owner operation provides a bit of functionality that may help here. Example trac.ini snippet:

myaction = whatever -> whateverelse
myaction.operations = set_owner
myaction.set_owner = john,betty,alice,bob

If a single owner is listed, it will not be a dropdown list at all.

It does not (currently) allow for groups.

[hju@…]

I'm facing a problem with groups which I have not found adressed searching the tickets. Perhaps I'm right in this ticket…

I'm using group for two reasons

1. assigning tickets to this group (i.e. developers) as a pool.
   In this case I need the group in the AssignTo list.
2. groups for permission.
   I introduced groups holding special permissions (i.e. customer_grp). Therefore I dont need to add all the detailed permissions to a new single user. I only need to assign the new user to the group.
   Problem: these groups are also shown in the AssignTo list.

If there were a selectbox "Show in AssignTo" or something like this my problem would be solved.

[Christian Boos]

A clarification of the logic followed by Trac w.r.t. ticket "assign to" list in restrict_owner mode would be more than welcome, especially in the light of the severe performance issue this can sometimes cause (#4245).

[Eli Carter]

proposed solution

[Eli Carter]

The proposed (and untested) patch would add a <action>.set_owner_perm option in the configurable workflow, and would restrict the owner list to those users who possessed the specified permission. (And note that arbitrary permissions can be added to Trac for this purpose.) This would allow more flexibility than the current 'restrict owner' option because the users available to be assigned a ticket may be based on the ticket's current state. (So in one state, users with TRAC_WORKFLOW_DEVELOPER would be available, while in another state, users with TRAC_WORKFLOW_TESTER would be available.)

Since this works in exactly the same way as 'restrict owner', it does not address any performance problems. It also does not address the problem of groups showing up in the list; as far as I know we don't have a distinction between users and groups. It also does not replace the existing 'restrict owner' option, even though its functionality is a superset of that. And it does not include the documentation changes that would be required.

I rather like this approach, but before I flesh out the patch to address the missing aspects (other than performance), I'd like some feedback on it. Thoughts, comments, etc?

[Remy Blank]

Looks good to me. You may want to mention the ExtraPermissionsProvider component from tracopt.perm.config_perm_provider in the documentation for adding arbitrary permissions.

[osimons]

Replying to ecarter:

It also does not address the problem of groups showing up in the list; as far as I know we don't have a distinction between users and groups.

No, but restrict_owner are populated from sessions (via env.get_known_users()) and then washed against permissions. And seeing groups don't do login, it ends up adequately accurate. Asking the permission system will not be nearly as accurate.

[Eli Carter]

Branch for this is sandbox/ticket-3580

[Ryan J Ollos]

#10271 was closed as a duplicate.

[Ryan J Ollos]

Closing as a duplicate of #11839, which will be fixed in milestone:1.1.3.