By default, if a role has access to a client's tickets, then all users in that role can be assigned a ticket in the drop down list or autocomplete field, given that the ticket is not assigned at creation. This may become problematic if you want to exclude certain roles from getting assigned the ticket.

For example, a company may have a product inquiry section built from the Support Ticketing System. There may be thousands of customers posting tickets on the same client; they will need to be permitted to access the client, but you may want to exclude them from the assignment list.

Assign tickets to a specific role

The patch basically adds a permission option "Can be assigned a ticket". Roles with permission to access a client must also have this option checked to be able to appear in autocomplete/drop down list. Roles with "Administer support" won't be affected by this option.

CommentFileSizeAuthor
#9 support-client_specific_permission-1448936-11-D7.patch2.35 KBsupriyarajgopal
#2 support-role_assign-1448936-2.patch2.34 KBamplus
#1 support-role_assign-1448936-1.patch2.11 KBamplus

Comments

amplus’s picture

amplus commented
StatusFileSize
new support-role_assign-1448936-1.patch2.11 KB
amplus’s picture

amplus commented
Issue summary: View changes

This post refers to the issue above.

amplus’s picture

amplus commented
StatusFileSize
new support-role_assign-1448936-2.patch2.34 KB

The last patch should not have modified the subscribe autocomplete field. It also contains a SQL parsing bug.
The new patch uses the IN and GROUP to select the users with better accuracy.

jeremy’s picture

jeremy commented
Status: Needs review » Needs work

Needs to make proper use of t() to avoid XSS type bus.

I'm not sure I like this solution; I understand the goal, but I'd like to avoid adding yet-another-permission. Note that if we go this route, it should probably affect both the "assign" field and the "subscribe" field.

bugagain’s picture

bugagain commented
Status: Needs work » Needs review

I've really benefitted this patch. Works perfectly. Allows for support users to have a more simpler workflow. Please modify and accept the patch for others to test it in the dev version.

AIGAIJ’s picture

AIGAIJ commented

Also appreciate the additional permission here.
Ultimately looking for more "bucketed" approach, and this patch begins to address the gap in functionality we are experiencing at the moment.

Balbo’s picture

Balbo commented

I'm having several users (a lot) that can open tickets on a client queue but only those with "service" role can be assigned to the ticket. Once I create a ticket I have a long list of users (mostly "customer" and not "service") in the "Assigned to" dropdown. Just about to use the patch and I hope this will do the magic. I guess several people (and module-usability) would benefit from it and I think this should be committed if the only problem is just it's "adding yet-another-permission" ;-)

BTW: this module rocks!

Balbo’s picture

Balbo commented

I patched the file line by line, by hand since it seems that it cannot be applied to latest dev version.
I now can only assign tickets to user with Admin roles and the "Can be assigned a ticket" permission seems not to work.

Balbo’s picture

Balbo commented
Issue summary: View changes

additional information to this patch.

Frogtown’s picture

Frogtown commented
Issue summary: View changes

Has there been any further about this? I wholeheartedly support adding the additional permission -- as it is, at least in our use case here, there is no reason for the majority of the clients, except for a few of the systems support staff that would ever need a ticket assigned to them, and this makes it a much cleaner way than scrolling through a huge list of assignees. Also, the patch is nice, but the query relies on the role's RID matching (so both permissions have to be checked, regardless if there's another role associated that already has the 'Access X client), it'd be nice to have it able to be in a stand alone role -- I will see what I can do about rolling a different patch. Anyways, the main thing I'm saying, is there still any demand for this possibly being integrated? I think it is highly useful, at least in my use cases, and I don't think a single new permission is too much.

supriyarajgopal’s picture

supriyarajgopal commented
StatusFileSize
new support-client_specific_permission-1448936-11-D7.patch2.35 KB

Hello everyone,

Firstly, thank you amplus for this patch.

Now, I was looking for a similar feature & landed on this page.
However, my requirement was slightly different as follows:

  1. Any authenticated user can 'access X client' & 'access Y client' to raise tickets
  2. Only users (say A,B) of role 'Tech Support for X client' should be assigned tickets of X client
  3. Only users(say C,D) of role 'Tech Support for Y client' should be assigned tickets of Y client

The patch submitted in #2 allows tickets of X client to be assigned to any user (i.e A,B,C,D) of both roles (Tech Support for X client & Tech Support for Y client) because both roles have 'Can be assigned a ticket' permission. This patch does not consider which ticket to be assigned to which role.

Hence, I modified the patch submitted in #2 (see attached).

My patch provides permissions for client specific tickets to be assigned to specific roles.
Thus, Tickets of X client can be assigned only to either A or B & tickets of Y client can be assigned only to either C or D.

Hope this helps people looking for similar feature.
Kindly revert with any queries.

Regards,
Supriya Rajgopal

supriyarajgopal’s picture

supriyarajgopal commented
Status: Needs review » Needs work
supriyarajgopal’s picture

supriyarajgopal commented
Status: Needs work » Needs review
purencool’s picture

purencool commented
Version: 7.x-1.x-dev » 8.x-1.x-dev