Routing customer portal tickets to different queue

[cbruigom]

Hello,

I am looking for any ideas around how I can automatically assign a queue to different types of customers, creating tickets through the customer portal. I have one broad group of customers for demo purposes "Demo" and one for public customers "Public".

If they create tickets via email I am using postmaster filters to write their customer ID and Queue which works perfectly, however if new customers create their tickets in the customer portal I am a little stuck.

Any ideas?

[crythias]

Don't use customer based queues
If you need a single queue, set it as default in sysconfig (optionally, hide queue).
If you need specific sets of queues, you can turn on customer group support and make sure the customers are not of the group(s) of the hidden queues (users is part of CustomerGroups always groups).

[cbruigom]

Hi Crythias,

I thought that customer based groups was not preferable to be used? I was using CustomerID to group my customers. The thing is that I am allowing public customers to try out OTRS. As I said from email thats not an issue but from the portal it becomes a little more difficult. The reason I want a separate queue is I am expecting some junk data to be coming in and I dont want it in the same queue as my other incoming tickets which I am using for sales and for support.

Is it also possible to set a specific customerID when a customer registers, as I see the email address is used by default?

Would this be possible?

[crythias]

I thought that customer based groups was not preferable to be used?

Sometimes, you don't have a choice. When you wish to hide queues, there are two (main) ways to do it: ACL and Group Membership. Or, of course, set a default queue. Or Custom Queues See also: viewtopic.php?f=60&t=7138

Your reasoning for wanting a separate queue isn't as important as how to do it. :)

Is it also possible to set a specific customerID when a customer registers

Not in stock OTRS.
HOWEVER, it seems possible that modifying the .dtl to ask for it can work.

The code Kernel/System/Web/InterfaceCustomer.pm says:

Code: Select all

if ( !$GetParams{UserCustomerID} ) {
            $GetParams{UserCustomerID} = $GetParams{UserEmail};
        }
        if ( !$GetParams{UserLogin} ) {
            $GetParams{UserLogin} = $GetParams{UserEmail};
        }

and ...
>CustomerUserAdd(
%GetParams,

Kernel/Output/HTML/Standard/CustomerLogin.dtl says (a bunch of stuff) but the gist is that if you pass UserCustomerID or UserLogin through the CreateAccount form (neither are in core templates), InterfaceCustomer.pm should accept it.

Note that assigning a fixed CustomerID (or even that you allow someone to guess one) means that all people with the same CustomerID will be able to see all tickets from the same CustomerID in Company Tickets. Since the email address tends to be unique to a user, this isn't inherently a problem with self register. You *might* be able to use some javascript to assign a CustomerID field based upon domain name for self-register.

Personally, I'm not a fan of self-register because the people who should be in your ticketing system are allegedly supposed to be known customers in your system. I realize this doesn't work for everyone, but since it's probably going to cost money to handle tickets, it's best to allocate resources to known customers. There are definitely ways to link to existing databases for customer demographics to offset some things. On others, I realize that certain support reps deal with large companies who for some reason won't divulge a company authorized ticket submitter list and so anyone with an @companyname can submit tickets. There are options around that, too, but it can be handled with development.