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: [email protected] t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 --------------------------------------------------------------------- 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/
