This feature allows the user to modify or replace an Entry's current objectClass set or in the case of a New Child item on the Edit menu (or Button Bar if displayed) to select the objectClass(es) on which a new entry will be based.
The Change or Add objectclass window is shown and described in subsequent sections:
The left hand panel contains all available objectClasses on the currently connected LDAP server, the right hand panel will contain the objectClass(es) in this Entry.
In the illustrated example the right-hand window is initially populated with the objectClass inetOrgPerson because the Change or Add objectClass request was initiated from the Modify Class Action button in the Table editor on an Entry which only used this objectClass, had the initiator been the New Child item on the Edit menu the right hand panel would have been empty.
Selecting an objectClass in the left-hand panel and clicking Add will add the objectClass to the right-hand panel. Selecting an objectClass in the right-hand panel and clicking Remove will delete it from the right-hand panel (it is still available, if required, in the left-hand panel).
The user may Cancel the operation at any time.
The Help button displays this page.
If the OK button is selected the objectClass(es) in the right-hand panel will be used in the changed (or new) Entry. Attributes which exist in the selected objectClass set will be kept (with all data unmodified). Attributes which do not will be silently deleted (with their corresponding data).
To find the attributes of any objectClass either use the Schema Tree or, if the objectClass exists in the entry, right-click and select Object Definition.
Note: It is not necessary to add all the objectClass(es) in the hierarchy, LDAPviewer will automatically assemble the objectClass hierarchy and include all necessary attributes. However, if the user feels more comfortable doing this they are free to do so. (The resulting Entry, irrespective of the actual objectClass(es)) in the right-hand panel will always contain the full objectClass hierarchy(ies).)
This example shows an AUXILIARY objectClass (in this case posixAccount) being added to an existing Entry:
In this case no data will be lost from an existing Entry and the additional attributes (including a significant number of MUST attributes for posixAccount) will be added to the entry. Any new MUST attribute data must be added before an Update or a Submit operation to avoid a user prompt.
This example assumes that an existing entry is using the organizationalPerson objectClass as shown:
We can simply add the child objectClass inetOrgPerson (the SUP of inetOrgPerson is organizationalPerson) as shown:
In this case no data will be lost but the additional attributes of inetOrgPerson will be added as empty attribute entries in the table.
Note: The objectclass organizationalPerson may be left in the right hand panel or removed as a matter of taste - there will be no difference in the resulting attribute set.
It is possible to remove and replace any objectClass(es) with any other objectClass(es) in this example we again assume a starting position of an entry based on the inetOrgPerson objectclass as shown:
We add the AUXILIARY objectClass posixAccount and in this case replace inetOrgPerson with pilotPerson as shown:
pilotPerson is a child objectClass of person as, indeed, is inetOrgPerson but has fewer (and many different) attributes. The result of this change will be to silently remove from the entry all attributes (and their corresponding data) that are not in the new set. However, since they both share a common root objectClass (person) the MUST attributes cn and sn for the changed entry are preserved.
Note: If one (or more) of the Naming Attribute(s) have been removed by this operation this will initiate a DN rename operation when the Update or Submit operation is actioned.
© LV Project 2016. Creative Commons Attribution 4.0 International License.