Hi Jeroen, On 23.06.2010, at 16:03, Jeroen van Meeuwen (Kolab Systems) wrote:
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.
YES it does! :) I'm surprised to get so good discussions on the list! :)
Jeroen van Meeuwen Senior Engineer, Kolab Systems AG
-Martin