Directory Studio
  1. Directory Studio
  2. DIRSTUDIO-748

Entry attribute name not displayed correctly in Table Entry Editor.

    Details

      Description

      Entry attribute name is not displayed correctly in Table Entry Editor. Specifically for any entry with LDIF:

      dn: cn=bill,ou=Aliases,dc=example,dc=com
      objectClass: virtualaccount
      cn: bill
      mailacceptinggeneralid: basil@example.com
      mailacceptinggeneralid: bill@sales.example.com
      mailacceptinggeneralid: bill@example.com
      mailacceptinggeneralid: basil@sales.example.com
      maildrop: bill@example.com
      owner: cn=SalesAdmins,ou=Groups,dc=example,dc=com
      description: Aliases to bill account

      ...in the Table Entry Editor we see "maildrop" attribute displayed as "mailacceptinggeneralid"! So, there are 5 mailacceptinggeneralid attribute values displayed, and no "maildrop" attribute values!

      The problem is important because we can't tell which of the displayed values of "mailacceptinggeneralid" is in fact "maildrop"!

      This does not happen in any other LDAP Browser/editor we have tried.

      Note that LDIF export works correctly.

      Schema for the above entry is custom and follows, for your reference:

      attributetype ( 1.3.6.1.4.1.25260.1.000
      NAME 'mailacceptinggeneralid'
      DESC 'Defines an address that we accept mail for'
      EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

      attributetype ( 1.3.6.1.4.1.25260.1.001
      NAME 'maildrop'
      DESC 'Defines the address mail goes to'
      EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

      attributetype ( 1.3.6.1.4.1.25260.1.002
      NAME 'mailacceptinguser'
      DESC 'Defines if this user accepts mail'
      EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

      attributetype ( 1.3.6.1.4.1.25260.1.003
      NAME 'aliasInactive'
      SINGLE-VALUE
      EQUALITY booleanMatch
      DESC 'A flag, for marking the alias as not in use'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )

      objectClass ( 1.3.6.1.4.1.25260.1.1.100
      NAME 'virtualaccount'
      DESC 'Holds mail info for a virtual account'
      STRUCTURAL
      MUST ( owner $ mailacceptinggeneralid $
      maildrop $ cn )
      MAY ( description $ aliasInactive )
      )

      objectClass ( 1.3.6.1.4.1.25260.1.1.101
      NAME 'maillist'
      DESC 'Virtual account for holding mailing list info'
      STRUCTURAL
      MUST ( mailacceptinggeneralid $
      maildrop $ cn )
      MAY ( owner $ description $ aliasInactive )
      )

      objectClass ( 1.3.6.1.4.1.25260.1.1.102
      NAME 'mailAccount'
      DESC 'Email account details'
      AUXILIARY
      MUST ( mailacceptinguser $
      maildrop $ cn )
      MAY ( mailacceptinggeneralid $ aliasInactive )
      )

      objectClass ( 1.3.6.1.4.1.25260.1.1.105
      NAME 'virtualbox'
      DESC 'Mailbox for system use'
      STRUCTURAL
      MUST ( owner $ mail $
      uid $ cn )
      MAY ( description )
      )

        Issue Links

          Activity

          Hide
          Pierre-Arnaud Marcelot added a comment -

          Version 2.0.0 M1 has been released.

          Closing the issue.

          Show
          Pierre-Arnaud Marcelot added a comment - Version 2.0.0 M1 has been released. Closing the issue.
          Hide
          Pierre-Arnaud Marcelot added a comment -

          Fixed by Emmanuel on Shared/API at revision 1207961.

          http://svn.apache.org/viewvc?rev=1207961&view=rev

          Show
          Pierre-Arnaud Marcelot added a comment - Fixed by Emmanuel on Shared/API at revision 1207961. http://svn.apache.org/viewvc?rev=1207961&view=rev
          Hide
          Nick Applenet added a comment -

          Good news Pierre,

          We' ll be looking forward to the new 2.0.0 release!

          Thanks to all those who work on the project.

          Show
          Nick Applenet added a comment - Good news Pierre, We' ll be looking forward to the new 2.0.0 release! Thanks to all those who work on the project.
          Hide
          Pierre-Arnaud Marcelot added a comment -

          Great! Thanks for the confirmation.

          Hmm, it's hard to say for a 1.5.4 version.
          2.0.0 has been in the works for quite some time now and a lot of refactorings have affected the codebase.
          It will probably be harder to back-port some fixes to the 1.5.4 branch than to finish the work on 2.0.0.
          We expect a first milestone version of Studio 2.0.0 for the end of the year (or early 2012 if we're late).

          Show
          Pierre-Arnaud Marcelot added a comment - Great! Thanks for the confirmation. Hmm, it's hard to say for a 1.5.4 version. 2.0.0 has been in the works for quite some time now and a lot of refactorings have affected the codebase. It will probably be harder to back-port some fixes to the 1.5.4 branch than to finish the work on 2.0.0. We expect a first milestone version of Studio 2.0.0 for the end of the year (or early 2012 if we're late).
          Hide
          Nick Applenet added a comment -

          I have tested http://people.apache.org/~pamarcelot/ApacheDirectoryStudio-win32-x86-2.0.0-SNAPSHOT.zip and it works fine.

          All attribute names are displayed correctly.

          Is there going to be a 1.5.4 version too? Or 2.0.0 will be the new Apache Directory Studio release?

          Show
          Nick Applenet added a comment - I have tested http://people.apache.org/~pamarcelot/ApacheDirectoryStudio-win32-x86-2.0.0-SNAPSHOT.zip and it works fine. All attribute names are displayed correctly. Is there going to be a 1.5.4 version too? Or 2.0.0 will be the new Apache Directory Studio release?
          Hide
          Emmanuel Lecharny added a comment -

          @Stefan : you are right. RFC 4512 sticks to the ASN.1 definition of a 'number' which must start with something different than a 0 when there is more than one digit.

          However, I don't see the value of rejecting such OIDs. When read, the values will be stored as integer, making the leading 0 irrelevant. All in all, it's just a String representation of a integer...

          Show
          Emmanuel Lecharny added a comment - @Stefan : you are right. RFC 4512 sticks to the ASN.1 definition of a 'number' which must start with something different than a 0 when there is more than one digit. However, I don't see the value of rejecting such OIDs. When read, the values will be stored as integer, making the leading 0 irrelevant. All in all, it's just a String representation of a integer...
          Hide
          Nick Applenet added a comment -

          Thanks Pierre for the compiled version.

          I am downloading now. I will test tomorrow (it's too late now - already midnight) and let you know.

          Bye for now.

          Show
          Nick Applenet added a comment - Thanks Pierre for the compiled version. I am downloading now. I will test tomorrow (it's too late now - already midnight) and let you know. Bye for now.
          Hide
          Stefan Seelmann added a comment - - edited

          Numeric OID is defined differently in RFC 2252 and RFC 4512:

          RFC 2252 allows OID with leading "0":
          d = "0" / "1" / "2" / "3" / "4" /
          "5" / "6" / "7" / "8" / "9"
          numericstring = 1*d
          numericoid = numericstring *( "." numericstring )

          But RFC4512 does not:
          DIGIT = %x30 / LDIGIT ; "0"-"9"
          LDIGIT = %x31-39 ; "1"-"9"
          number = DIGIT / ( LDIGIT 1*DIGIT )
          numericoid = number 1*( DOT number )

          So maybe we should have a strict and relaxed mode, similar to what we have for the syntax parser?

          Show
          Stefan Seelmann added a comment - - edited Numeric OID is defined differently in RFC 2252 and RFC 4512: RFC 2252 allows OID with leading "0": d = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" numericstring = 1*d numericoid = numericstring *( "." numericstring ) But RFC4512 does not: DIGIT = %x30 / LDIGIT ; "0"-"9" LDIGIT = %x31-39 ; "1"-"9" number = DIGIT / ( LDIGIT 1*DIGIT ) numericoid = number 1*( DOT number ) So maybe we should have a strict and relaxed mode, similar to what we have for the syntax parser?
          Hide
          Pierre-Arnaud Marcelot added a comment -
          Show
          Pierre-Arnaud Marcelot added a comment - Here's another for the 64 bit version (just in case): http://people.apache.org/~pamarcelot/ApacheDirectoryStudio-win32-x86_64-2.0.0-SNAPSHOT.zip
          Show
          Pierre-Arnaud Marcelot added a comment - Here's the link: http://people.apache.org/~pamarcelot/ApacheDirectoryStudio-win32-x86-2.0.0-SNAPSHOT.zip
          Hide
          Pierre-Arnaud Marcelot added a comment -

          Good news!

          I was able to reproduce the bug using Apache Directory Studio 1.5.3 and ApacheDS 2.0.0-M4-SNAPSHOT.
          But... The bug seem no longer reproductible with the current trunk version of Apache Directory Studio (2.0.0-SNAPSHOT).
          It has probably been fixed while fixing other bugs.

          Nick, I'm preparing you a compiled version of the current trunk. Could you please verify if you have the same behavior and the bug is gone?

          I'm currently uploading it and will give you the downloading link in my next comment.

          Thanks!

          Show
          Pierre-Arnaud Marcelot added a comment - Good news! I was able to reproduce the bug using Apache Directory Studio 1.5.3 and ApacheDS 2.0.0-M4-SNAPSHOT. But... The bug seem no longer reproductible with the current trunk version of Apache Directory Studio (2.0.0-SNAPSHOT). It has probably been fixed while fixing other bugs. Nick, I'm preparing you a compiled version of the current trunk. Could you please verify if you have the same behavior and the bug is gone? I'm currently uploading it and will give you the downloading link in my next comment. Thanks!
          Hide
          Nick Applenet added a comment - - edited

          Hello Pierre,

          I am using OpenLDAP v2.4.26 on CentOS 5.7 x86_64, using LTB RPMs (http://ltb-project.org/wiki/documentation/openldap-rpm).

          I hope that helps.

          Show
          Nick Applenet added a comment - - edited Hello Pierre, I am using OpenLDAP v2.4.26 on CentOS 5.7 x86_64, using LTB RPMs ( http://ltb-project.org/wiki/documentation/openldap-rpm ). I hope that helps.
          Hide
          Emmanuel Lecharny added a comment -

          There is a bug in the schema-value.g file. The numericOid lexical element is badly expecting some non 0 number on the left side of a number :

          protected LDIGIT : '1'..'9' ;
          protected DIGIT : '0'..'9' ;
          protected NUMBER : DIGIT | ( LDIGIT (DIGIT)+ ) ;
          protected NUMBER2 : (DIGIT)+ ;
          protected NUMERICOID : NUMBER ( '.' NUMBER )+ ;

          The last line should be :
          protected NUMERICOID : NUMBER2 ( '.' NUMBER2 )+ ;

          Show
          Emmanuel Lecharny added a comment - There is a bug in the schema-value.g file. The numericOid lexical element is badly expecting some non 0 number on the left side of a number : protected LDIGIT : '1'..'9' ; protected DIGIT : '0'..'9' ; protected NUMBER : DIGIT | ( LDIGIT (DIGIT)+ ) ; protected NUMBER2 : (DIGIT)+ ; protected NUMERICOID : NUMBER ( '.' NUMBER )+ ; The last line should be : protected NUMERICOID : NUMBER2 ( '.' NUMBER2 )+ ;
          Hide
          Pierre-Arnaud Marcelot added a comment -

          Hi Nick,

          I'm trying to reproduce the bug using ApacheDS and Apache Directory Studio.

          May I ask what server (vendor/version) you are using?

          Thanks.

          Show
          Pierre-Arnaud Marcelot added a comment - Hi Nick, I'm trying to reproduce the bug using ApacheDS and Apache Directory Studio. May I ask what server (vendor/version) you are using? Thanks.
          Hide
          Nick Applenet added a comment -

          Yes, the suggested change corrected the problem.

          However, according to RFC 2252, the value is supposed to be numericstring, which should not exclude values like 000, 001, etc.

          So, I guess such values should be supported in future releases!

          Show
          Nick Applenet added a comment - Yes, the suggested change corrected the problem. However, according to RFC 2252, the value is supposed to be numericstring, which should not exclude values like 000, 001, etc. So, I guess such values should be supported in future releases!
          Hide
          Emmanuel Lecharny added a comment -

          I confirm the problem...

          Wondering if the strange ID used can be the cause : xxx.000/001 etc is not really common (even if valid).

          Can you give it a try with 0, 1, 2 instead of 000, 001, 002 ?

          Show
          Emmanuel Lecharny added a comment - I confirm the problem... Wondering if the strange ID used can be the cause : xxx.000/001 etc is not really common (even if valid). Can you give it a try with 0, 1, 2 instead of 000, 001, 002 ?
          Hide
          Nick Applenet added a comment -

          Note: The entry is used to define an email alias for use in Postfix mail server. The same behavior occurs for other similar mail alias structural object classes as well: nisMailAlias and maillist.

          Show
          Nick Applenet added a comment - Note: The entry is used to define an email alias for use in Postfix mail server. The same behavior occurs for other similar mail alias structural object classes as well: nisMailAlias and maillist.
          Hide
          Nick Applenet added a comment -

          Here is how the entry is displayed (confidential data greyed-out)

          Show
          Nick Applenet added a comment - Here is how the entry is displayed (confidential data greyed-out)

            People

            • Assignee:
              Unassigned
              Reporter:
              Nick Applenet
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development