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
