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 <dbo...@sinenomine.net> wrote: > 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 >
--------------------------------------------------------------------- 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
