#52 Table Editor bugs when several names for same attribute

[Konstantin Kolinko]

Summary

In an LDAP schema there may be defined several names
for the same attribute, e.g.

RFC 1274 + RFC 2247

attributetype ( 0.9.2342.19200300.100.1.25
NAME ( 'dc' 'domainComponent' )
DESC 'RFC1274/2247: domain component'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-
VALUE )

where 'dc' and 'domainComponent' name the same
attribute.

An objectclass definition in a schema may mention the
attribute by either of the available names, e.g. by the
second one:

objectclass ( 0.9.2342.19200300.100.4.13 NAME 'domain'
SUP top STRUCTURAL
MUST domainComponent
MAY ( associatedName $ organizationName $
...
))

Table Editor lists all available attributes on an entry.

If LDAP server uses another name when returning the
list of attributes, not the one mentioned in schema, the
Table Editor does not recognize it for being the same
attribute.

If the attribute is mandatory, but was returned by the
server using an alternate name, then when editing the
entry the Table Editor shows the mandatory attribute as
having no value, and does not allow submitting the
changes, saying "All Mandatory Attributes must have
values!".

In my case, 'domainComponent' attribute was shown as
having no value, but a 'dc' attribute was there with the
value I expected.

Copying the value from 'dc' to 'domainComponent' also
resulted in an "Unable to perform Modify operation" error
message (LDAP: error code 20, value #0 already exists).

Moving the value from 'dc' to 'domainComponent',
where 'dc' remains in the table with an empty value,
resuted in an "Unable to perform Modify operation" with
java.lang.NullPointerException being shown in details.

Thus there are no ways to edit/update this entry using
the Table Editor.

Similar issues occur when you trying to create an entry,
using an alternate name for the attribute. In this case,
when you create a 'domain' entry using RDN 'dc=xxx'
instead of 'domainComponent=xxx'.

Workaround

1. Modify the schema definition file on the server, so
   that all the definitions used the same name of the
   attribute.

Configuration

OpenLDAP 2.2.6-37.19 on SuSE Linux Ent. 9
JXplorer 3.1 rc5 on Windows

schemas invloved:

1. core.schema (defines 'dc' attributetype)
2. cosine.schema (defines 'domain' objectclass with a
   MUST attribute 'domainComponent')

Steps to reproduce

1. Create an entry with object classes 'domain' and 'top'
   and RDN: domainComponent=xxx. A Table Editor is
   shown. Press "Submit" to create the entry.

2. Refresh the tree (View > Refresh).

Refreshing is required, because DN of the entry will now
show up having a 'dc=' component instead of
having 'domainComponent='. (Without refreshing there
will be other bugs when editing / submiting).

1. Select the created entry. Shitch to the Table Editor
   view. You will see the following attributes:
   domainComponent (in bold): (no value, empty cell)
   objectClass (in bold): domain
   objectClass (in bold): top
   dc (in plain text): abc (bold, in blue color, as part of DN)

And below are 'associatedName' and other attributes, in
plain text, with no values.

1. Press "Submit". You will see a message box saying "All
   Mandatory Attributes must have values!".

I have found no ways to submit changes to this entry,
using the Table Editor.

1. Create a sibling 'domain' entry at the same level of
   the tree. In the new entry dialog ("Set Entry Object
   Classes") I am suggested to enter RDN as "dn=".

Doing so shows up a Table Editor for the new entry,
with a value for 'dc' attribute and no value
for 'domainComponent'.

I have found no ways to submit the values to create
the new entry. ( Copying the value of "dc" attribute
into "domainComponent" attribute results in "Unable to
perform Modify operation." with "LDAP: error code 20 -
attribute 'dc' provided more than once". Copying the
value of "dc" attribute into "domainComponent" attribute
with setting "dc" attribute to an empty value results
in "Unable to perform Modify operation." with
javax.naming.InvalidNameException:
dc=,dc=ldap2,dc=rian,dc=net: [LDAP: error code 34 -
invalid DN]; )

The workaround is to ignore suggested "dc=" when
creating the entry and use "domainComponent=" instead.

[Brad Mace]

Logged In: YES
user_id=370261

I've noticed this problem as well since 3.0. It cripples
what woudl otherwise be an excellent program

[Christopher Betts]

Logged In: YES
user_id=558207

remember you can always turn schema checking off in the options, in
which case it should work fine :-)!

Long term I'll change the schema checking to use OIDs rather than the
display name for checking this sort of stuff...

[Christopher Betts]

Logged In: YES
user_id=558207

By the way, this is identical to the existing bug 787908 ... as is the
comment about the workaround :-)