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