I thank you for the insight, and in my limited view, I'm thinking of
"Services" to handle the segregation as -- I'd hope -- only the assigned
services would be available to the customer, meanwhile the queue would be
the type of thing your agents would generically provide. The Service is
unique to a customer, and does everything else mentioned here, without need
for ACL.
At least, that's what I understand. Every plan is different, to be sure,
but thinking in terms of what you present here, it seems reasonable that
the only change you'd need to do to add a new customer would be to add a
specific service and attach it to the customer.
Now those pesky checkboxes are the thing to bite you in the rear... (No,
I'm not making fun, I'm serious. It's not extremely obvious that you
haven't assigned a service to the competitor).
Anyway, I appreciate the feedback. It will help me to consider different
views.
Regards.
On Wed, Jul 11, 2012 at 5:33 PM, David Boyes
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-bounces@otrs.org [mailto:otrs-bounces@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