Michiel Beijen wrote:
On wo, 2010-06-23 at 13:47 +0200, Jeroen van Meeuwen (Kolab Systems) wrote:
One possible future scenario in the Kolab Systems case could be that we provide the infrastructure for partner @partner.com to support customer @customer.com. I would add the cn=partner-partner.com LDAP group as a member to LDAP group cn=customer-customer.com.
Hey! This was not in your initial e-mail, there you just mentioned that customers working for a partner should be able to see all tickets from that particular partner.
Apologies, I was pondering this still while plowing through the vast amount of other settings.
In the use case you described now, where a partner needs access to all tickets of customers of that partner, I guess OTRS could need some improvement indeed. Right now the process would be that you create a field that holds the different customer id's in the LDAP. This field would then need to be manually administered.
http://doc.otrs.org/2.4/en/html/x1813.html#multi-customer-ids-ldap
I think that it would be cleaner if OTRS were able to read the contents for the 'customer_ids' field from LDAP permission groups. Adding and removing LDAP users from groups is easier, cleaner and better maintainable than editing a text field manually.
Would that help?
Yes, that would help very much. I'm thinking I could send a sane patch for the following logic: - Search a Groups OU (or BaseDN) for a LDAP::AccessAttr matching an expression based on the LDAP::UserAttr and current user login unique value, which gives us a list of groups the user is a member of, - Iterate over the list of groups, mapping all members of each group back to a user LDAP entry, and pushing any groups found back onto the stack[1], - get the customerID from the list of user entries - push these CustomerIDs onto, well, @CustomerIDs - return; Does such make sense as a first implementation? I might be able to look into caching later on. Of course, it goes without saying that this functionality should be made opt- in, and it shall probably not have to change normal OTRS behaviour in any way. [1] In cases where uniqueMember attributes contain a DN, this is very easy. -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeuwen@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08