I am on OTRS 3.0.11 currently, but observed this very problem in 2.4.x as well:
ServiceList seems to be returning a HASH of services (with DB IDs and names) that are valid (as in the valid flag is 1 in the service table). This is performed by loading every single record from the services table and then performing hash operations to identify and remove the invalid entries from the temp hashes. Seems quite costly as a properly formatted SQL query would have returned the valid records only, but this is not my issue currently.
At the very end of ServiceList() there is a final activity with two nested for() routines to remove service entries from a temp hash that has the same name as the entries in another temp hash (which contain known invalid service names). The inner for() performs a regex check and deletes the service entry from the hash if the name matches:
Code: Select all
if ( $ServiceList{$ServiceID} =~ m{ \A \Q$InvalidName\E :: }xms ) {
delete $ServiceList{$ServiceID};
last INVALIDNAME;
}
SSO (set to invalid in DB as it is just a 'folder name' in the hierarchy)
SSO::SomeServiceName
SSO::SomeOtherServiceName
SDU (set to invalid)
SDU::OtherServiceName
SDU::YetAnotherOne
The above regex fails miserably with these services. The ServiceList() method properly identifies both SSO and SDU to be invalid but every time it compares these to a child service, it incorrectly matches them!
So for =~ m{ \A \Q$InvalidName\E :: }xms "SSO::" is exactly the same as "SSO::SomeServiceName"!!
And due to this my OTRS fails to load any service record whatsoever because the above nested for() cycle simply removes ALL service entries from the temp hashes regardless of their valid flag in the DB.
The only way I could make it work is to replace the regex to "m{ ^$InvalidName$ }xms".
Did anybody ever observed similar issues? I don't want to bother the developers if this is some localized issue with my OTRS...
Thanks!
Regards,
Peter