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.

[cboos]

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

[cmlenz]

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.

[cboos]

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.

[cboos]

#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

[ecarter]

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.