[otrs] Queue permission
Carlos Ribas
Ugo Bellavance
> Hello All,
>
> I´m new with OTRS. I installed the latest version and now I'm
> trying to understand how it works. I´m reading the manual page, but one
> point is not clear to me.
>
> I can set groups, roles and queues. My doubt is if it is possible
> to have, for example, two queues in the same group, but one queue
> visible only to customer and both visible to agent. I saw that I can
> have this configuration using two groups, but I would like to know if it
> is possible to use only one.
clients can see their ticket via a web interface, but not all the queue.
---------------------------------------------------------------------
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
Alvaro Cordero
that (groups) you can use either customergroupAllwaysGroup or
Customer<->Group feature, but eitherway once you enable a group for a
customer they can see everything (All queues).
Another posibility is to create your own ACLs in Config.pm
Regards
> 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
___________________________
Alvaro Cordero Retana
Consultor de Tecnologias
Gridshield Monitoreo de Redes e
Infraestructura.
2258-5757 ext 123
alv...@gridshield.net
www.gridshield.net
Carlos Ribas
Carlos Ribas
Stephan Lang
$Self->{'CustomerPanelOwnSelection'} = {
'Junk' => 'First Queue',
'Misc' => 'Second Queue'
};
Mit freundlichen Grüßen
Bock 1 GmbH & Co. KG
An der Heide 17
92353 Postbauer-Heng
Sitz: Postbauer-Heng
Amtsgericht Nürnberg, HRA 11 240
pers. haft. Geschäftsführer: Hermann Bock
Bock 1 Verwaltungs GmbH
Sitz: Postbauer-Heng
Amtsgericht Nürnberg, HRB 93 10
Geschäftsführer: Harald Meyer, Andreas Großhauser
Diese E-Mail enthält möglicherweise vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.
This email may contain confidential and/or privileged information. If you are not the intended recipient (or have received this email in error) please notify the sender immediately and destroy this email. Any unauthorized copying, disclosure or distribution of the material in this email is strictly forbidden.
Gerald Young
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.
Gerald Young
Carlos Ribas
Stefano Ricci
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.
Gerald Young
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.