Unfortunately, that doesn’t work very well if you are offering multiple services to each customer. If I read ITIL correctly, services vs customers is potentially a many-to-many relationship, eg services are predefined “things you offer” to zero or more consumers (note that in a highly-composed service-oriented architecture, the “customer” could be another service as well as a company), and there may be zero or more consumers that have access to a service. This gets particularly nasty if you involve a CMDB of managed objects that provide certain services to customers – you need to track the consumer to service mapping to calculate who is affected by a service failure, and multiple consumers get mapped to a single service.

The first part of this I don't follow because certainly you can create *Services* CustomerAService  or CustomerA::Service1, CustomerA::Service2 
Which you can assign to zero or more consumers. And zero or more customers may have any, all, or none of the Services created.

The second part I don't follow precisely either, because there isn't any more a default, "everyone in this queue" any more or less to "everyone with this service" mapping, is there? 

Further, if you want a service ACL, that seems just as reasonable as creating a whole set of queues for a customer, assigning the appropriate membership for agents, getting the agents to have that additional queue in their "My Queues" ... versus, essentially, creating an ACL for services template .pm file that you copy/modify/paste into Kernel/Config/Files and establishing that the services Possible are [CompanyName]::Services1, [CompanyName]::Services2 when matching CustomerID.

That ACL already wins all the time for the Customer, period. No additional work necessary, independently verifiable. Now, if you have an Agent who mucks around with that, that's a different issue, but now even if the wrong checkbox is checked, the customer can't see it, because the ACL wins.

Now you can scan the services by search and see essentially the same information.

Customers don't belong to queues. A queue belongs to a group. Customers belong to group(s). Services belong to customers. 

This isn't even *my* preference, thought, or anything, it's simply how OTRS is. There's nothing to a Queue that tells you a queue's membership. I could definitively tell you which users are assigned a service, and with a simple (really simple) ACL I can tell you which services any customer can see, even if an agent clicks the wrong one. For a Queue, I have to determine the membership of the group to which the queue was assigned, and a big list of queues and associated tickets for the queues that survive even if the customer doesn't.

By the way, I'm not arguing for the sake of argument. People ask a bunch of questions how to get queues to act like (customer-assigned) services and then they'll ask for types to act like queues (how do I assign permissions to types? How do I stop autoresponse for a given type? How do I assign agents to a given type?). If it works that way for some people, great, but it's really easy to get it done the OTRS way and still do what you want ITIL wise.

Thank you again for your response. 

On Wed, Jul 18, 2012 at 3:07 PM, David Boyes <dboyes@sinenomine.net> wrote:

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. 

 

Unfortunately, that doesn’t work very well if you are offering multiple services to each customer. If I read ITIL correctly, services vs customers is potentially a many-to-many relationship, eg services are predefined “things you offer” to zero or more consumers (note that in a highly-composed service-oriented architecture, the “customer” could be another service as well as a company), and there may be zero or more consumers that have access to a service. This gets particularly nasty if you involve a CMDB of managed objects that provide certain services to customers – you need to track the consumer to service mapping to calculate who is affected by a service failure, and multiple consumers get mapped to a single service.

 

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).

 

Yup. And that is exactly what bites you in the ass without ACLs that permit independent auditing. Having customer A see only one queue (or a small set of queues) and having agents scan the customer-dedicated queues for specific services (easy to do with a predefined query) they’re trained for (or you can also pull those skills from a CMDB entry for a “Person”). It’d be a very nice option to have OTRS support such a multidimensional security model out of the box, but that’s a lot of work for them for a fairly small community of users.


---------------------------------------------------------------------
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