Provide a list of users a ticket can be assigned to

[dallmeier@…]

It would be nice if trac could provide the user with a list of people a ticket can be assigned to. What I would like to see is drop-down list with all users (or a list of all peoples tickets have been assigned to in the past) in the Assign to: field when I enter a new ticket.

[cboos]

See TracTickets#Assign-toasDrop-DownList.

However, this comes up so often I wonder if we shouldn't consider make that the default instead of the free text input form. The situation were known and valid users would be required for the "Assign to:" field seems to be more frequent than the one where any username can be given.

What do you think?

[sid]

Just as some feedback, I have 3 active Trac installations and I have the drop-down user list feature enabled on all of them.

[ThurnerRupert]

we'd prefer a slightly enhanced version, as we have technical user id's which users do not easily remember.

putting a nick and/or the username in the dropdown, like suggested in #3737 would be an ideal solution, like

...
  <option value="userid">nick, username</option>
...

[ThurnerRupert]

the other possibility would be to have the login changed/mapped i guess by mapping a technical userid to a nick ... then the rest of trac would be unchanged. what do you think?

[cboos]

Replying to ThurnerRupert:

the other possibility would be to have the login changed/mapped i guess by mapping a technical userid to a nick ...

Wouldn't the already existing "Full name:" information be enough?

[eblot]

Replying to cboos:

Replying to ThurnerRupert:

the other possibility would be to have the login changed/mapped i guess by mapping a technical userid to a nick ...

Wouldn't the already existing "Full name:" information be enough?

I think this discussion should be moved to #4210 which is a request for this very topic, or close #4210 as a duplicate.

Maybe the default settings could be related to the "openness" of an installation. There've been already another discussion about having more restriction about the default anonymous permissions: perhaps tracadmin initenv should prompt for some kind of security level (several Linux packages offer this kind of level selection):

• open system (anonymous can view everything, assignee is a free text field
• medium-level/corporate system (less permissions for anonymous, assignee is a drop-down box)
• enhanced security system (no permissions but for the admin)
• ...

Anyway, I'm myself off-topic. Maybe we should close this ticket, and open a new one...

[anonymous]

Ticket 4210 is not a duplicate. It should not be closed based-on this thread. 4266 has touched on the enhancment request of 4210 through the discussion --- but the topics are only somewhat related.

[sid]

Agreed, #4210 is not a duplicate of this ticket (only of ThurnerRupert's comments).

The original request combined with comment:1 is the meat of this ticket. I'm +1 for making the drop-down user assign list the default for Trac.

[anonymous]

Replying to eblot:

Replying to cboos:

Replying to ThurnerRupert:

the other possibility would be to have the login changed/mapped i guess by mapping a technical userid to a nick ...

Wouldn't the already existing "Full name:" information be enough?

Yes. That's what I'd hope for. The existing full name appearing in place of id. :)

I think this discussion should be moved to #4210 which is a request for this very topic, or close #4210 as a duplicate. Maybe the default settings could be related to the "openness" of an installation. There've been already another discussion about having more restriction about the default anonymous permissions: perhaps tracadmin initenv should prompt for some kind of security level (several Linux packages offer this kind of level selection): * open system (anonymous can view everything, assignee is a free text field * medium-level/corporate system (less permissions for anonymous, assignee is a drop-down box) * enhanced security system (no permissions but for the admin) * ... Anyway, I'm myself off-topic. Maybe we should close this ticket, and open a new one...

[anonymous]

Replying to cboos:

Replying to ThurnerRupert:

the other possibility would be to have the login changed/mapped i guess by mapping a technical userid to a nick ...

Wouldn't the already existing "Full name:" information be enough?

only if it can be used also an input, i.e. when assigning tickets, milestones, queries, cc. maybe #3737 can be seen as basic version fulfilling 90%, and this ticket is the "luxory version" by showing real user names?

[cboos]

Ok, letting aside the discussion about the nick (see #3737 for that), I propose that we make the "Assign-to as Drop-Down List" the default behavior for 0.11, as proposed in comment:1 and supported by sid.

[dbrewer]

I love this feature, but I have a further suggestion. Currently, the only users that show up in the list are those with TICKET_MODIFY permissions. This doesn't work for our shop because we only allow want certain people to close tickets -- QA staff and project managers. The people who are doing most of the work on tickets don't have permission to close them, they just assign them to those that do.

I would suggest that there be a separate permission that relates to this -- something like TICKET_ASSIGNEE or similar. TICKET_MODIFY could also provide this permission by default. Only users with this permission could be assigned to tickets or would show up in the list.

[ThurnerRupert]

this could be also done with a bandbox widget, isn't it? see #5378, and  zkoss userguide, bandboxes.

imo the best would be to allow: * search in users * add new/freetext

then the switch in track conf to select dropdown or freetext would be obsolete.

[cboos]

Replying to dbrewer:

I would suggest that there be a separate permission that relates to this -- something like TICKET_ASSIGNEE or similar.

Right. There are numerous voices saying it's not that obvious to get that list right, so before making this the default, we should perhaps improve things a bit in this respect. See also #4245.

[anonymous]

now there is  th:AutocompleteUsersPlugin solving most of this.

[cboos]

[OT] SPAM

Replying to anonymous:

In order to be able to assign a ticket to a user, that user has to be able to access that ticket. Thus, for example if you have a client named "Foo", then you need to assign "access Foo tickets" permissions to all users that we want to be able to assign Foo tickets to. With that done, anyone with "can assign tickets to other users" permissions should be able to assign tickets to other users with "access Foo tickets" permissions.I recommend you read  http://XXXXXXXXXXXXXXXXX. through INSTALL.txt to get a better understand of how the module is designed to work.

Wow, great spam! Google traced the original text to  http://drupal.org/node/436726#comment-1488808

That's quite vicious, as we can't really feed that seemingly valid content as "Spam" to the SpamFilter, and we're left having to block the target URL explicitly in BadContent.