Customer unable to reply

[ChrisMachnicki]

Hi,
I am setting up a new OTRS installation to replace the version we have at the moment (hopefully setting it up correctly this time).
There will be in excess of 1000 users when it is configured and thus far I have been struggling with the concept of how it should be setup to how it has been for years.

I am keen to use the roles as managing users in the past has been a tedious affair but want it to be simple so I have created 3 roles, Service Desk, IT and Rest of Business (ROB).
I have several queues but the main one is - 'Service Desk' which will be the default queue for all tickets from the (ROB) customers, the plan here is that the 1st line dept triage the tickets into there relevant queues that the IT role has access too (Others will follow).

I have setup the Service Desk with full access to all queues and to remove the ability for (ROB) customers to put tickets directly into these areas only given the role read only access. Unfortunately this now means that once the ticket has been moved to a queue outside other than 'service desk' they are unable to reply.

Can anyone help? or am I going about setting it up wrong?

Thanks

Chris

[jojo]

customers are not agents. so they are not using the agent interface but the customer interface

[crythias]

Somewhere among the blunt pencils, there's a point... (and a question).

customers to put tickets directly into these areas only given the role read only access.

customers are not agents. so they are not using the agent interface but the customer interface

customers aren't given agent roles. They log in to customer.pl . If CustomerGroupSupport is not enabled, customers are not restricted

[ChrisMachnicki]

Thanks for the reply. I understand that agents and customers are separate and have tried to set up the groups but running into problems when associating to users i.e. the queue structure I have so far is -
-Service Desk
--1st Line
--2nd Line
-Development

An agent/customer from the Service desk should be able to access all queues but an agent/customer in dev should only be allowed to see the Service Desk and Development queue (not 1st/2nd line) and customers from elsewhere in the business should only be able to see the Service Desk queue (not 1st/2nd line/dev) when submitting through the customer portal. However when the ticket moves between the queues the customer should still be able to see and reply to the ticket.

To give full scope of what I have done so far I will include the agent setup too -
I set up 3 roles - Service Desk, Rest of IT and Rest of the business.
I added a Service Desk agent to all the roles and nothing to the others; I only recently found out that roles aren't available for customers so now assume I don't need the Rest of the business role. I later plan on adding more users to the Rest of IT role with limited access to things like reporting, admin, etc. but don't see much point unless I can master the Service Desk and Rest of the business permissions.

For agents I added a few groups - Service Desk and all of IT. I then associated the Service desk and all of IT groups to their respective Roles and allowed full rights to the service desk and restricted the rest of IT to exclude things like stats. I added both roles to the users group with full rights.

The problem I found here was what to set the queue / group relationship too as you can only select one group per queue.

From the customer side I added two users - a service desk customer and a 'rest of the business' customer. I added the service desk user to the service desk group and have played with several settings for the ROB user but seem to be stuck in a perpetual loop of either giving them the option to choose queues I don't want, losing the visibility of the ticket when it is moved or not allowing them to reply.

[crythias]

An agent/customer from the Service desk should be able to access all queues but an agent/customer in dev should only be allowed to see the Service Desk and Development queue (not 1st/2nd line) and customers from elsewhere in the business should only be able to see the Service Desk queue (not 1st/2nd line/dev) when submitting through the customer portal. However when the ticket moves between the queues the customer should still be able to see and reply to the ticket.

stop. Don't confuse us with combining agents and customers in permissions.

What is the distinction for "in dev" vs "from the Service Desk"? Customer Group support?

There's a difference between "access all queues" and "display all queues". For instance, if you don't want a customer to be able to choose a queue, hide it in ACL (better, provide exactly the queues you want to have the customer have access to.

The problem I found here was what to set the queue / group relationship too as you can only select one group per queue.

There is no problem, only your non statement of how your confusion applies.

From the customer side I added two users - a service desk customer and a 'rest of the business' customer.

You need one customer for every human.

[crythias]

Here's how it should work, for a customer:

Web interface:
Customer logs in with her unique login to otrs/customer.pl

Customer chooses an available queue, fills fields, submits ticket.

Customer adds to ticket as necessary.

All other parts of your query are agent, hidden from customer and basically immaterial to the topic title.

The customer cannot see tickets for which, if CustomerGroupSupport is enabled, the ticket is in a queue of which the customer is not in the group of the queue.

However, with CustomerGroupSupport disabled, the customer may not be prohibited from adding to a ticket on her interface side no matter what queue is available, but she may be prevented from submitting to specific queues by ACL.


Agent side:
A user (agent) can be a member of multiple groups, and multiple roles. A role is a way to assign multiple group membership by inheritance. If you choose to use roles, you may wish to assign agents ONLY to roles, because it'll be easier to manage (you'll lose some granularity, but you will track permissions at the Role level.)

For dev queues, they should be part of dev group, or individual groups uniquely assigned to the queues. If you were not using roles, the dev group handles permissions. If you were using roles, the role that contains the groups for the queues handles permission in an aggregate fashion, for the group permissions within the role.

These groups are not necessarily the same (though they can be) named groups that restrict access permissions on the agent side for interface changes.

[ChrisMachnicki]

The default for all new tickets is the Service Desk queue. From there the 1st line guys triage the tickets into there respective queues so as an example a customer may ask for some dev work and a ticket is raised into the Service Desk queue, 1st line review the request and see its a dev ticket and put it into the dev queue. The devs may then contact the customer directly for further clarity.
1st and 2nd line service desk also have there own queues for tickets they can deal with.

The current setup leaves customers frustrated because tickets enter as they call it a 'black hole' and I guess this is due to the rights they have been given.

I think you hit the nail on the head with ACLs. These are a relative new concept here as access to the config files was not previously possible due to the risk and lack of a test environment), but I see in the new version this has been opened up from the management console and we now have a test box with the newest version on.

During the many different config changes I have tried one of them allowed the customer to reply to tickets and gave them the visibility but I wrote this off due to the fact all queues showed in their drop-down and we can't rely on the user not putting tickets into the wrong queues.

With regards to the the statement 'From the customer side I added two users - a service desk customer and a 'rest of the business' customer.', I have only added two users so far and know I need to add one for each person in the future. I just didn't want to complicate matters with lots of different users.

I guess I just need to find this setup and learn how to use ACLs

Thanks

[crythias]

viewtopic.php?f=60&t=7138

[ChrisMachnicki]

Thanks. Everything fell into place once I got over this hurdle I was trying to jump. I removed all the useless roles and groups I setup, scaled it back and very quickly found another topic which addressed the ACL - viewtopic.php?f=53&t=23705

With the addition of a ReadOnly group which gives RO & RW to users (not associated to any queues) I can now move tickets around whilst retaining the ability to reply and restricting the dropdown to only show the Service Desk option if you are added to the ReadOnly group.

I'm sure this will evolve into far more complicated setups but the foundation is there now!