This project has moved and is read-only. For the latest updates, please go here.

Assign tickets to a group and not an induvidual

Sep 17, 2015 at 7:02 PM

I want to modify the solution to assign tickets to a group (billing etc) instead of a person. A user then can login in and pick a ticket from a specific group.

Hi-level. How to achieve this?


Sep 18, 2015 at 2:05 AM
In general, most issue trackers avoid assignment to groups rather than individuals. There are good reasons for that, the two biggest being that 1) it becomes unclear who is responsible for any issue and 2) the UI behaviors and permissible actions become counter-intuitive or complex. Instead, most issue trackers require issues to belong to specific individuals, they are the issue's responsible party.

On the technical end, it is very complex to handle non-user assignments. For example, who should get notifications? If your groups have only a few people, it's fine to notify the whole group when a group assigned ticket is updated; but what happens when the group has 10 people, 50, 500, 5000? Next thing you know, your system is on every anti-spam blacklist in the world. And that's just the complexities of one small area (notifications). When you consider all the activities, permission checks, workflows, business behaviors, etc. it can become a total nightmare very fast.

But the main point is that it is difficult to design an issue tracker with group assignments in a way that remains useful for a broad range of organizations.

For your particular case, as you describe it, you can probably achieve what you want without messing with how tickets are actually assigned. I see three ways you might potentially do that, depending on your specific needs:

A) Use the Ticket Type or Category field as a group/departmental indicator. This is ideal if you don't need a hard separation between departments, just an easy way for users to filter / sort tickets in the ticket center to find the issues that fall into their area of responsibility.

B) Use the new projects feature to create separate group/departmental projects. This option creates a more formal and strict separation between tickets that belong to each group (project), but again lets you assign specific individuals to the tickets with each group. Currently all users have access to all projects, but once the new identity system in in place (TD 2.6) projects will allow administrators to control which users have access to which project.

C) The option I like least, but which might be a great option in some environments, would be to just use shared logins. If you are assigning tickets to "groups", and all members of the group act as generic and interchangeable representatives of that group, then why not just have a "billing" user account and let all the people in billing support login as that same user. For notifications, you can just create a group email address for the shared login, and then handle routing emails to individual members of the group entirely within on email server.

Code Option:

If you really did want to implement a traditional security group type system though, you would have to do a number of adjustments to the stock code, but overall it shouldn't be too technically difficult to change the system to use roles instead of users; but I haven't cataloged all the side-effects that such a change might produce; and how to solve those side-effects would depend on your particular organizational requirements.

At a minimum though, you would need to beef up the admin tools so you can define custom roles and assign users to them. The business domain code doesn't enforce any particular rules for what IDs are placed into the assignto and owner fields in the database; but you would need to adjust the UI to deal with the fact that some or all of those IDs map to roles instead of users. This includes changing select lists for those fields, and the display name in ticket center, emails, and ticket viewer UIs.

If you intended to keep the notifications system, you would need to modify it to split ticket change notifications to multiple user notifications when a group assigned ticket changes. This could get hairy, but then again you might just want to disable email notifications instead rather than spam the crap out of the whole group all the time.

As long as you made sure your users belonged to at least one of the built-in roles, in addition to your custom roles, that might be all the changes you need.
Marked as answer by kriskumar69 on 10/7/2015 at 12:40 PM
Feb 14 at 7:11 PM
I am in need of the feature described above in section B. Did TD2.6 ever get released?