Ticket #2662 (new enhancement)
assign tickets to multiple users
| Reported by: | mala | Owned by: | jonas |
|---|---|---|---|
| Priority: | normal | Milestone: | next-major-0.1X |
| Component: | ticket system | Version: | 0.9.3 |
| Severity: | normal | Keywords: | tracobject user |
| Cc: | software@…, mjhweb-trac-tickets@…, josh.moore@…, david.l.jones@…, gjcarneiro@…, r.s.hatcher@…, benton@…, phuna24@…, sarcastyx@…, giekka@…, jsch@…, madbyk@…, fcorreia@…, zbedell@…, jean-gui@…, lucas.mendes@…, pwongvib@…, manolo.email@…, leho@…, dasch_87@…, standogan@… |
Description
It would be very nice, if I could assign a ticket to more than one user. I set the restrict owner-parameter to false and typed in two users. I tried with different syntax, but the trac system did not notice the ticket to belong to the them. Would be fine...
Attachments
Change History
comment:1 Changed 5 years ago by cboos
- Keywords tracobject user added
- Milestone changed from 0.9.4 to 0.12
comment:2 Changed 5 years ago by douard@…
I have the same need. Waiting for it to be properly implemented in Trac, here is my current hack:
- add a new ticket report with the following SQL query (this is a very naive hack, that do not work if 2 users have similar usernames, eg. 'toto' and 'toto_jr' will interfer):
SELECT p.value AS __color__, (CASE status WHEN 'assigned' THEN 'Assigned' ELSE 'Owned' END) AS __group__, id AS ticket, summary, component, version, milestone, t.type AS type, priority, time AS created, changetime AS _changetime, description AS _description, reporter AS _reporter FROM ticket t, enum p WHERE t.status IN ('new', 'assigned', 'reopened') AND p.name = t.priority AND p.type = 'priority' AND owner glob '*$USER*' ORDER BY (status = 'assigned') DESC, p.value, milestone, t.type, time - modified the Notify.py (from Trac 0.9.3) source code file, so the ticket notify system send a message to every owner of the component (must be separated with commas "," or white spaces):
File $PYTHONPATH/site-packages/trac/Notify.py, line 286, replace:
recipients.append(row[2])
with:
recipients.extend(row[2].replace(',', ' ').split())
comment:3 Changed 5 years ago by bpalmer
Thank you, previous commenter! I need this functionality for our new project, and it would have taken me hours to work out what you did, since I don't really know Python at all.
comment:6 Changed 4 years ago by david.l.jones@…
- Cc david.l.jones@… added
SQLite has some regexp capability, but it's not implemented (?). I'm not a SQLite person, so I'm not sure how to use it, but here's the blurb:
The REGEXP operator is a special syntax for the regexp() user function. No regexp() user function is defined by default and so use of the REGEXP operator will normally result in an error message. If a user-defined function named "regexp" is defined at run-time, that function will be called in order to implement the REGEXP operator.
( SQLite docs)
So if the regexp could be implemented, then a "smarter" parsing of the owner field would look like
-- ... AND p.name = t.priority AND p.type = 'priority' AND owner REGEXP '([^,]*,)*$USER(,[^,]*)*' -- ...
Of course, this depends on a user-provided regexp function in SQLite (whatever that means... ;) ). Alternatively, simply make sure that the field is padded left and right sides with commas, so then the glob looks like this:
-- ... AND p.name = t.priority AND p.type = 'priority' AND owner GLOB '*,$USER,*' -- ...
Of course, these are both hacks, and I don't condone using them, nor would I take responibility for using them in combination with any other queries, reports, database systems, prolonged sun exposure, narcotic pain killers, etc.
comment:9 Changed 4 years ago by anonymous
Has anyone implemented a hack to achieve this for Trac 0.10?
Adding a glob '*$USER*' to the report causes an error:
Report execution failed: not all arguments converted during string formatting
I don't know why this wouldn't work at 0.10, but does at 0.9.x
The ticket notification system has been rewritten and not knowing much python am finding it difficult to figure out what should be changed. Any help much appreciated.
comment:10 Changed 3 years ago by cboos
#4949 has been closed as duplicate.
A slight variant to this idea would be to have to possibility to use a group name for the owner. I thought this was proposed before, but couldn't find a reference to it...
comment:11 Changed 3 years ago by mala
I couldn't find the "original ticket" too. Close it, when you have found. I cannot see this is a duplicate.
comment:12 Changed 3 years ago by anonymous
Ah now I see it. Anyway I do want to specify any possible combination as a group. It would be fine to have the possibility to assign to more than one "real" users.
comment:15 Changed 3 years ago by andyg
This would certainly be a very useful feature for my organization. When the assign to field is restricted to a user list, it would be nice to be able to select multiple users from that list as well, as opposed to typing each in with some sort of delimiter.
comment:16 follow-ups: ↓ 17 ↓ 21 Changed 3 years ago by anonymous
I have a need for this. Sometimes, team members are assigned to finish same kind of tasks but not a single group task. e.g. "read this license" or "install secure ware to your PC." Everyone has to do it by themselvs. So, I would issue a ticket having the same task description to every member. Currently, I must issue a number of tickets one by one.
I guess the problem of my needs is more related to UI, than DB.
comment:17 in reply to: ↑ 16 Changed 3 years ago by anonymous
Replying to anonymous:
I have a need for this. Sometimes, team members are assigned to finish same kind of tasks but not a single group task. e.g. "read this license" or "install secure ware to your PC." Everyone has to do it by themselvs. So, I would issue a ticket having the same task description to every member. Currently, I must issue a number of tickets one by one.
I guess the problem of my needs is more related to UI, than DB.
My opinion was probably not too clear.
I suppose "create a ticket using an existing ticket" functionality is good enough for me. I can even use ticket keyword to follow up tens of tickets.
comment:19 Changed 2 years ago by anonymous
you can edit report using LIKE,
SELECT p.value AS __color__,
(CASE status WHEN 'assigned' THEN 'Assigned' ELSE 'Owned' END) AS __group__,
id AS ticket, summary, component, version, milestone,
t.type AS type, priority, time AS created,
changetime AS _changetime, description AS _description,
reporter AS _reporter
FROM ticket t
LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority'
WHERE t.status IN ('new', 'assigned', 'reopened') AND owner LIKE '%$USER%'
ORDER BY (status = 'assigned') DESC, p.value, milestone, t.type, time
it's "My ticket" example, but I think sqlite support REGEX is great!
comment:21 in reply to: ↑ 16 Changed 23 months ago by anonymous
Replying to anonymous:
I have a need for this. Sometimes, team members are assigned to finish same kind of tasks but not a single group task. e.g. "read this license" or "install secure ware to your PC." Everyone has to do it by themselvs. So, I would issue a ticket having the same task description to every member. Currently, I must issue a number of tickets one by one.
I guess the problem of my needs is more related to UI, than DB.
I have the same problem, are there any solutions? I just started using trac but can't find this option (multiple assign). Everything else works perfect!
comment:22 Changed 23 months ago by rblank
#6078 has been closed as a duplicate, and provides a patch allowing to specify several e-mail addresses for a user.
comment:24 Changed 20 months ago by madbyk@…
- Cc madbyk@… added
Is this really hard to implement? I mean SQLite REGEXP is there, you can change the dropdown box with a multiselect box and voila?
I love Trac and I think it should include this feature. So as a developer I'll do my best if theres anything I can do. Just let me know.
comment:25 Changed 20 months ago by FilipeCorreia
I see some advantages in being able to assign a ticket to several users. Namely, when doing pair programming, it makes all the sense.
however, just a thought, wouldn't having several user fields instead of just one be a cleaner solution?
comment:27 Changed 19 months ago by cboos
comment:29 Changed 18 months ago by anonymous
I don't like the hacks that are suggested in this ticket.
What do you think of my roles model i described in #8001? It would be very flexible to have an relation between tickets and users with a role attribute. Combining this with a workflow system that uses these relations could be very powerful.
comment:30 Changed 18 months ago by jean-gui@…
- Cc jean-gui@… added
I've created a plugin which adds a field "Default CC" per component. This field allows to specify a list of mail addresses or users that will be automatically added to the CC list when new tickets (of the corresponding component) are created. That's not exactly what the ticket is about, but I thought some of you might be interested.
comment:31 Changed 18 months ago by lucas.mendes@…
- Cc lucas.mendes@… added
I see this is a very old claim. This functionality will be very helpful for our team because we have a custom state called Review where multiple checkers should be assigned. We have been using cc field for that but users are not happy with that. Multiple assigners would be more intuitive.
comment:32 Changed 15 months ago by anonymous
Need is here as well, asign to more than one user and send e-mail to the assigned users. The same functionality for components as well.
I Previously worked with Jira and they have implemented this. Maybe you can get some ideas there for the implementation.
comment:35 Changed 9 months ago by lkraav <leho@…>
- Cc leho@… added
interesting, discovered today it would help me as well.
comment:36 Changed 7 months ago by dasch_87@…
Adding to cc list.
comment:38 Changed 5 months ago by anonymous
this is a must. use cases: 1) documentation team. ui team, design team , web services team. right now i can't assign tickets to teams. I have to make fake accounts and set up mailing lists. :(
We often have tickets that need to be reassigned from one team to another before they can be closed. It would makes it easier for people to see open tickets they might be interested in.
workflow:: new ticket -> assign to team 1 -> accepted by team1 member1 -> reassigned to team1 member2 -> accepted by team1 member2-> reassigned to team2 -> accepted by team2 member1 -> closed
comment:40 Changed 3 days ago by anonymous
This ticket is now open for 5 years. It would be nice to have a status update. Is this planned to ever be a feature of Trac or not? What is the progress?
In my opinion, this is an essential feature for many organizations, in particular helpdesk departments (like the one I am setting up atm).
I think implementing this is really difficult though. Trac never aimed to do authentication itself yet needs to interconnect with third party systems that are used in order to use the group information.
Your thoughts please...



Some remarks: