[Solved] Restricting Ticket Types Available to Customers

[adupre01]

What would be the best way to restrict the ticket types available to customers? I would like to have a large pool of ticket types from which agents are able to choose ticket types so they can be more specific. For example when the Agents create or edit a ticket they could choose Password Problem , Hardware, Software, Database, Webiste etc...

But I do not want customers to have such a large/detailed list. So for example the customer would be able to choose Computer Problem, or Phone Problem. A small, very generic list of ticket types available to them so they can still help us Agents a bit but are not overwhelmed or slowed down trying to pick through a list of a dozen or two different types.

[crythias]

Use queues.

[adupre01]

I already have queues setup for our support structure. We have a queue for each group in our department (tier 1, 2, 3, Network, AV, Tel, etc). I have it set so that all tickets created by customers automatically go to the Tier 1 queue. We have about a dozen queues so far and I would rather not have too many more. I know I could restrict customer options using queues but every queue I create is one more that our tier 1 has to watch. We would really prefer to have just 1 queue for our tier 1 to manage.

The other reason I would like to be able to use types more than queues for this purpose is for tracking. Since the queue may change as our tickets are elevated to tier 2, 3 or another group it would be nice to use types to keep track of the specific type of problem people are having. On further thought I may then just end up not giving the customer the ability to choose the type and just have tier 1 do that. Though it would be nice I think to be able to control access to ticket types for customers and agents separately.

[adupre01]

I solved the issue myself using ACL. For newbies like me this is what I did:

1. Consult the manual and Search the Web

When first starting OTRS the manual can be large and daunting but reading through it can really help. To be honest, I hadn't read all of the manual when I first posted so I hadn't come across the part about ACL's (Access Control Lists) which allow one to control access to certain modules, ticket properties etc. After reading many posts (some only vaguely related to my problem) I had seen references to ACL's but didn't know what they were. I finally put 2 and 2 together and looked through the manual again and found good instructions on what ACL's are and how to use them.

ACL from the Manual http://doc.otrs.org/3.0/en/html/acl.html
A blog post with a little more (not much) explanation http://blog.otrs.org/2010/08/17/state-m ... s-via-acl/

2. Test out some code

Below is the specific code I used to filter ticket types for customers, but not for Agents.

Code: Select all

    $Self->{TicketAcl}->{'ACL-Name-1'} = 
	{
        # these are the properties used for matching ticket etc.
        Properties => 
		{
            # match propertie = all customer tickets
            Frontend => 
			{
                Action => ['CustomerTicketMessage'],
            }
        },
        # return possible options (white list)
        Possible => 
		{
            # possible ticket options. Ticket types available for customer selection has been restricted.  
			#Note - spelling/case must be exact for these variables.
            Ticket => 
			{
                Type => ['Incident', 'Problem', 'default'],
            },
        },
    };

An explanation of what the code does. The Properties line establishes which property to filter for. Here we have said that we want all customer tickets. The Possible line says what variable or action is possible for a given filtered object. Here we have said we want all tickets to have only ‘incident, problem, and default’ available as ticket Type. Together this property and possible makes it so that when a customer creates a new ticket the only type they have available to them is the ones in the possible list. Meanwhile, Agents still have access to the full list of ticket types when they create tickets. What this means is that we can now allow our customers to help us sort our tickets into general types of requests (without having so many options as to overwhelm them) and then (if needed) we the agents can change the type to give more detail to the ticket.

[MichaelR]

Yeah, I extensively use ACLs to filter Ticket Types, available States etc for Customers and particular agents.

Just want dependent freetextfields!

[kruegerM]

I'm unable to get ACL's to make a difference - issue:
Type 'Incident' has a choice of two Queues: 'IS Help' or 'Technical'
Type 'Problem' has a choice of two Queues: 'Hardware' or 'Software'
No matter which type I select - I still see all four queues.

Code: Select all

    
$Self->{TicketAcl}->{'ACL-Name-Inc'} = {
  Properties => {
    Ticket => {
      Type => ['Incident'],
    }
  },
  Possible => {
    Ticket => {
      Queue => ['IS Help', 'Technical'],
     },
  },
};
$Self->{TicketAcl}->{'ACL-Name-Prob'} = {
  Properties => {
  Properties => {
    Ticket => {
      Type => ['Problem'],
    }
  },
  Possible => {
    Ticket => {
      Queue => ['Hardware', 'Software'],
     },
  },
};

[MichaelR]

That's not going to work, as you are talking about depended fields. ACL's will restrict the selection when the page is being loaded. Not once the page has loaded. You will need to rig up some AJAX for that