
Hallo Jeroen, We applaud that your company is willing to contribute to OTRS. But first I'd like to point out that I guess your patch is not needed to realize the scenario you want. The Customer ID is not necessarily unique per customer user! We often make it unique for whatever in your world defines a logical set of customers, this can be a customer company, or a department if you do in-house IT, or a cost center, or such. So if you would have customer users like this: User Customer ID ====================== John D. example.com Bill O. example.com Dave K. acme.com Sue S. acme.com This way you can let people from acme.com view all tickets from acme.com without the need to patch or change anything in your OTRS setup. The only thing is that you need to find an attibute in LDAP that is the same for all customers that belong to one company (or 'partner'). Would this work for you? -- ((enjoy)) Michiel Beijen Senior Consultant Follow me on Twitter: @otrsnl [https://twitter.com/otrsnl] OTRS BV Schipholweg 103 2316 XC Leiden The Netherlands T: +31 71 8200 255 F: +31 71 8200 254 I: http://www.otrs.com GET OTRS::ITSM 2.0 NOW - including the brand new change management module! It's the only ITILĀ® V3 compatible open-source IT Service Management solution certified by PinkVERIFY worldwide! - http://bit.ly/dv4CJF
Hi there,
My name is Jeroen van Meeuwen, and I'm relatively new to OTRS.
I wanted to acquire some feedback on the following scenario, since I didn't seem to able to simply deploy it using current OTRS functionality.
Kolab Systems AG is the vendor for Kolab Groupware solutions, and as such mostly supports it's customers through a Partner channel system. In a nutshell, Partners help the customer and Kolab Systems helps the partners.
Long story short, these Parters (to us) are Customer Companies, and so inherently we want all employees of a partner to have all tickets logged by any other employee of that partner be available in their customer interface.
Since we are using a centralized LDAP backend for both agents and customer authentication, it seems that the proper solution suggested in the OTRS documentation, is to make one or the other LDAP attribute represent a list of "CustomerIDs", and use it to attach such attribute to a single customer LDAP entry.
However, considering we need this to be a full mesh, the administrative overhead would be enormous.
Since, also, this is a business related effort, we can safely assume that partner employees all have the same domain name space for their email addresses. Ergo, employee1@company.com is very likely to work for the same company as employee2@company.com.
I've implemented the following functionality;
In otrs/Kernel/System/CustomerUser.pm, instead of populating the CustomerIDs the user also has access to through a list of CustomerIDs from an LDAP attribute, I use the @company.com part of the email address and simply find other people also using @company.com (and stuff those email addresses in the @CustomerIDs list).
Now, the implementation I've done is simple, dirty and quick (patch attached). However, since the application may help many more organizations, and since Kolab Systems is a very much FOSS-minded company, they are willing to let me work on this with you.
That is, of course, if you find it sufficiently interesting to have this developed a little more/better as well ;-)
Thanks in advance,
--------------------------------------------------------------------- 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
NEW! ENTERPRISE SUBSCRIPTION - Get more information NOW! http://www.otrs.com/en/support/enterprise-subscription/