Hi Moritz,
((enjoy))
Carlos Rodríguez
On Dec 12, 2013, at 11:12 AM, Moritz Lenz
Hi,
On 12/12/2013 09:18 AM, Martin Gruner wrote:
Hi Moritz,
this sounds great to me.
and it turns out it's not too hard to implement either :-) See https://github.com/OTRS/otrs/pull/180
Am 10.12.13 13:58, schrieb Moritz Lenz:
Hi all,
recently I found out that although we use only very few ACLs, the ACL mechanism slows down our OTRS installation. Part of the problem is that our CustomerUser-backend talks to an external data source, which is slow. But the problem is more general: Lots of data is assembled in Kernel::System::Ticket->TicketACL, which isn't actually used later on. Since ACLs are also checked for ticket lists (like in AgentTicketQueue or AgentTicketSearch), this can be a significant overhead.
For normal ACLs, we can easily find out which data they actually use. For ACL modules, I propose we add extra configuration.
Before, the configuration of an ACL module looks like this in Kernel::Config:
$Self->{'Ticket::Acl::Module'}->{'TheAclModulename'} = { Module => 'Kernel::System::Ticket::Acl::TheAclModule', };
If we extend that to something like this:
$Self->{'Ticket::Acl::Module'}->{'TheAclModulename'} = { Module => 'Kernel::System::Ticket::Acl::TheAclModule', Checks => ['Owner', 'Queue', 'SLA', 'Ticket'], ReturnType => 'Ticket', ReturnSubType => ['State', 'Service'], };
we can apply two optimizations:
1) Only invoke an Acl Module if the ReturnType and ReturnSubType overlap with the TicketAcl params ReturnType and ReturnSubType 2) Only gather data for the requested Checks elements. If for example no Acl and no ACL module depends on the Service or the CustomerUser, than those pieces of infomation don't need to retrieved at all.
Yes. This can be implemented backwards compatible, i. e. if the configuration is not present, always run the ACL.
That's how I've done it in https://github.com/moritz/otrs/commit/e1ccd3f5d8b625580e52c41d21d8846062f9f3...
As a further note, most information seems to show up twice in the %Checks argument to the Acl module, for example both as $Checks{Owner} and $Checks{Ticket}{Owner}. To get the desired speedup, a module which only lists the check 'Ticket' would get whatever data TicketGet returns, not the additional data that is currently added in method TicketAcl.
I'm not sure about this one. Let's hear what Carlos Rodriguez has to say about it.
I have mitigated possible fallout from this approach by looking a bit deeper into the ACL. If for example an ACL has
Properties => { Ticket => { Queue => ... } }
then both the Ticket and the Queue data is fetched. Which makes all the available ACL unit tests pass.
The problem I see here is that Properties hash does not mandatory needs a Ticket hash, but it could be for example: Properties => { Queue => { Calendar => [‘MyCalendar’], }, }, Then if we get the parameter ‘QueueID’ we needed also to do a QueueGet() in this case (in order to match the Calendar name with the ACL).
P.S. for the sake of completeness I've gone through Kernel::System::Ticket, and looked up the possible values for Checks, ReturnType and ReturnSubType. Here they are:
Checks: CustomerUser DynamicField Frontend Owner Priority Process Queue Responsible Service SLA State Ticket Type
ReturnType: Action Ticket
ReturnSubType: Type Queue State Service SLA Priority
Nice. Please feel free to add this to the POD, and also to improve the existing code where you see fit.
I'll update the documentation a bit.
Cheers, Moritz _______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev