Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.5.2
    • Fix Version/s: 2.0.0
    • Component/s: studio-ldapbrowser
    • Labels:
      None

      Description

      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.

        Issue Links

          Activity

          Hide
          Stefan Seelmann added a comment -

          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.

          Show
          Stefan Seelmann added a comment - 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.
          Hide
          Ari Maniatis added a comment -

          Unfortunately the chance of me having the time to work on this is close to zero. I'm not even finding enough time to work on the Apache projects I'm already involved with. And my knowledge of LDAP is only at the 'enough to be dangerous' level.

          Your caveats are all good and wise, but for people who have smaller directories this feature would be extremely useful without all the additional complexity of having to thread or page the extra lookups.

          Anyhow, I think this would be an extremely useful feature and the last thing holding us to the awful phpldapadmin. I'm biased but I think lots of other people would find this feature useful. I boldly set a fix version as 2.0

          Show
          Ari Maniatis added a comment - Unfortunately the chance of me having the time to work on this is close to zero. I'm not even finding enough time to work on the Apache projects I'm already involved with. And my knowledge of LDAP is only at the 'enough to be dangerous' level. Your caveats are all good and wise, but for people who have smaller directories this feature would be extremely useful without all the additional complexity of having to thread or page the extra lookups. Anyhow, I think this would be an extremely useful feature and the last thing holding us to the awful phpldapadmin. I'm biased but I think lots of other people would find this feature useful. I boldly set a fix version as 2.0

            People

            • Assignee:
              Unassigned
              Reporter:
              Ari Maniatis
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development