[
https://issues.apache.org/jira/browse/DIRSTUDIO-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835629#action_12835629
]
Stefan Seelmann commented on DIRSTUDIO-626:
-------------------------------------------
Sure, such a value editor is possible and reasonable.
As you already mentioned the extension point, you are welcomed to implement it
on your own and submit a patch :-) Most current value editor implementations
are available here:
http://svn.apache.org/repos/asf/directory/studio/trunk/valueeditors/
Some notes I have in mind about such a value editor:
In LDAP it is not possible to have server-side "joins". So for each lookup an
additional request is necessary. I already saw groups with thousands of
members, in such a case thousands of requests would be fired to the LDAP server.
It would be nice if that value editor would be configurable in some ways:
- limit of lookups to avoid thousands of lookups (e.g. 10 or max. 100 as
default)
- which attribute to lookup and show (CN isn't always filled with an good
value), better allow patterns in the form "{title} {sn}, {givenName} of
{departmentNumber}"
- maybe caching of lookup results?
- maybe parallel lookups in multiple threads? (as we use RCP we could use
eclipse jobs)
Also it doesn't need to be restricted to DN values. In some groups (e.g.
posixGroup) only an attribute (e.g. uid) of the member is stored. In that case
it would be nice to define the search parameters (base, scope, filter with
variable) for the lookup.
> Value editor for 'member'
> -------------------------
>
> Key: DIRSTUDIO-626
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-626
> Project: Directory Studio
> Issue Type: Improvement
> Components: studio-ldapbrowser
> Affects Versions: 1.5.2
> Reporter: Ari Maniatis
> Fix For: 2.0.0
>
>
> Value editors can already be extended as per
> http://cwiki.apache.org/confluence/display/DIRxSTUDIO/Value+Editor+Extension+Point
> Although there is an old old task DIRSTUDIO-22 for improving usability with
> common entities (such as groupOfNames), a simpler first step improvement
> would be to create an editor for the common "member" attribute. It should be
> capable of resolving the DN value to the CN of the related record. A brief
> discussion was had here: http://markmail.org/message/vi3uyjkennzdu727
> This improvement would make a huge difference to the ease of managing LDAP
> directories which use groupOfNames extensively.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
