Edgewall Software
Modify

Opened 14 years ago

Closed 5 years ago

Last modified 5 years ago

#3580 closed enhancement (duplicate)

AssignTo Ideas

Reported by: shawn Owned by:
Priority: normal Milestone:
Component: ticket system Version: devel
Severity: major Keywords:
Cc: gt4329b@…, hju@… Branch:
Release Notes:
API Changes:

Description (last modified by Christian Boos)

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.

Attachments (1)

ticket-3580-v1.patch (819 bytes ) - added by Eli Carter 9 years ago.
proposed solution

Download all attachments as: .zip

Change History (22)

comment:1 by anonymous, 14 years ago

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

comment:2 by Christian Boos, 14 years ago

Description: modified (diff)
Keywords: workflow added
Milestone: 0.10
Severity: normalminor

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

comment:3 by Christopher Lenz, 14 years ago

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.

comment:4 by dbrewer, 13 years ago

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.

comment:5 by Christian Boos, 13 years ago

Milestone: 0.12

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.

comment:6 by Christian Boos, 13 years ago

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

comment:7 by Christian Boos, 13 years ago

Keywords: restrict_owner added

comment:8 by Morris, 13 years ago

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.

comment:9 by anonymous, 13 years ago

Cc: gt4329b@… added

comment:10 by Morris, 13 years ago

Ticket w/patch created: #5858

Last edited 5 years ago by Ryan J Ollos (previous) (diff)

comment:11 by Eli Carter, 12 years ago

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.

comment:12 by hju@…, 12 years ago

Cc: hju@… added

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.

comment:13 by anonymous, 11 years ago

Owner: changed from Jonas Borgström to zoran

comment:14 by Christian Boos, 10 years ago

Owner: zoran removed
Severity: minormajor

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).

by Eli Carter, 9 years ago

Attachment: ticket-3580-v1.patch added

proposed solution

comment:15 by Eli Carter, 9 years ago

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?

comment:16 by Remy Blank, 9 years ago

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.

in reply to:  15 comment:17 by osimons, 9 years ago

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.

comment:18 by Eli Carter, 9 years ago

Branch for this is sandbox/ticket-3580

comment:19 by Ryan J Ollos, 6 years ago

#10271 was closed as a duplicate.

comment:20 by Ryan J Ollos, 5 years ago

Resolution: duplicate
Status: newclosed

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

comment:21 by Ryan J Ollos, 5 years ago

Keywords: workflow restrict_owner removed
Milestone: next-major-releases

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to as closed The owner will be changed from (none) to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.