Yes, you can't see other customer's tickets in the default setup, but there's more to it than that. Here's why customer-based queue lists are important to us:
The reasoning from the powers that be here is that customers should see only the services they are entitled to, and nothing more --in many cases we're contractually obligated to not identify customers to each other, not to use or expose the customer's name in any way, and to deny all knowledge of customer B if customer A asks - consider the case where A and B are direct competitors. If you're serving both A and B, you need to be able to prove to both A and B that information can't (and won't) leak between the two, especially if the queues handle potentially confidential or sensitive information that could represent an advantage to one or the other. We have customers where that could potentially mean billions one way or the other. If you have customer based queues (or better yet, queue sets), the ACLs can be much simpler (customers are restricted to their own queue or a clearly auditable set of queues) and get the experience of being our "only" customer from their perspective. You could probably do this with service-based queues and some fancy ACL handwaving, but the extra step of adding a specific set of queues to a specific customer id adds an additional dimension to the security model that makes it a lot easier to *prove* that information can't leak. And yes, it is a total PITA. But, you can look the security guys in the eye and say "A cannot access data from B" and be able to concretely prove it with data to back it up. The customer-based queue approach is also conceptually a bit easier to templatize - get a new customer, create the following queues, set the ACLs so, and the agents know what process doc to refer to based on customer name and/or queue name. It you're doing strict ITSM, the service-based approach is probably technically more correct, but it's hard for business heads and clerks to think that way. customerA-service1, customerA-service2 are easy for them to grok immediately, and having your agents concentrate on the "-service1, -service2" parts is a fairly easy adaptation. From: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] On Behalf Of Gerald Young Sent: Wednesday, July 11, 2012 4:05 PM To: User questions and discussions about OTRS. Subject: Re: [otrs] Queue permission I know that people keep asking this type of question ... why do you want a customer based queue? Last conversation I had was inconclusive. Basically, the person wanted it because they wanted it. What's the point in segregating queues from (between) customers? (yes, you *can* do it, but *why* do you *want* to do it?) Now, I can understand why you might want to put a ticket in a queue that's handled by agents that customers can't access (tier2, for instance) but as much headache as I see managing what queues are available for *this* group of customers versus *that* group of customers, especially in terms of large numbers of customers, why bother? "I don't want this customer to see that customer's queues!" is ... well, why do you say that? The customers can't see each others' tickets anyway. (I'm not saying it's wrong, I'm just trying to figure out the reason.)
--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
