#4266 closed enhancement (duplicate)
Provide a list of users a ticket can be assigned to
Reported by: | Owned by: | Jonas Borgström | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | ticket system | Version: | 0.10.2 |
Severity: | normal | Keywords: | owner user |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
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.
Attachments (0)
Change History (22)
comment:1 by , 18 years ago
comment:2 by , 18 years ago
Just as some feedback, I have 3 active Trac installations and I have the drop-down user list feature enabled on all of them.
comment:3 by , 18 years ago
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> ...
follow-up: 5 comment:4 by , 18 years ago
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?
follow-ups: 6 10 comment:5 by , 18 years ago
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?
follow-up: 9 comment:6 by , 18 years ago
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…
comment:7 by , 18 years ago
comment:8 by , 18 years ago
comment:9 by , 18 years ago
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. :)
comment:10 by , 18 years ago
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?
comment:11 by , 18 years ago
Keywords: | owner user added |
---|---|
Milestone: | → 0.11 |
follow-up: 14 comment:12 by , 18 years ago
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.
comment:13 by , 17 years ago
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.
comment:14 by , 17 years ago
Milestone: | 0.11.1 → 0.12 |
---|
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.
comment:17 by , 16 years ago
[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.
follow-up: 22 comment:18 by , 12 years ago
Up. Is there today a fix to restrict the users in that drop-down list as suggested by dbrewer with his TICKET_ASSIGNEE permission?
Thanks
follow-up: 20 comment:19 by , 12 years ago
hello! its will be great using full names eg Peter Jones in new tickets instead USER LOGIN, most peoples dont know what login of owner and they want to use Full names in new tickets or when modify tickets. We use drop down list, but there is only logins of users, not full names
comment:20 by , 12 years ago
Replying to dlotarev@…:
hello! its will be great using full names eg Peter Jones in new tickets instead USER LOGIN, …
You'll want to follow #7339 for that feature.
comment:21 by , 10 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Replying 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.
After #2045 the ticket create action must be specified in the Trac workflow. By default there is an Assign action that respects [ticket] restrict_owner
, and determines the allowed owners for a ticket.
comment:22 by , 10 years ago
comment:23 by , 10 years ago
Milestone: | next-major-releases |
---|
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?