When writing #50544, I have noticed that some classes in 00core.ldif do not match or are inconsistent to the openldap definitions. I would rather have these "migrated by us" by hand than as part of the migration tool. We should investigate and check what steps we can take to resolve these manually in a compatible, and safe manner.
SchemaClassInconsistent -> ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ internationalISDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) ) to 2.5.6.7 ('organizationalPerson',) may -> ('title', 'x121Address', 'registeredAddress', 'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber', 'teletexTerminalIdentifier', 'telephoneNumber', 'internationaliSDNNumber', 'facsimileTelephoneNumber', 'street', 'postOfficeBox', 'postalCode', 'postalAddress', 'physicalDeliveryOfficeName', 'ou', 'st', 'l') must -> () sup -> ('person',) SchemaClassInconsistent -> ( 2.5.6.9 NAME 'groupOfNames' SUP top STRUCTURAL MUST cn MAY ( member $ businessCategory $ seeAlso $ owner $ ou $ o $ description ) ) to 2.5.6.9 ('groupOfNames',) may -> ('businessCategory', 'seeAlso', 'owner', 'ou', 'o', 'description') must -> ('member', 'cn') sup -> ('top',) SchemaClassInconsistent -> ( 2.5.6.10 NAME 'residentialPerson' SUP person STRUCTURAL MUST l MAY ( businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ internationalISDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l ) ) to 2.5.6.10 ('residentialPerson',) may -> ('businessCategory', 'x121Address', 'registeredAddress', 'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber', 'teletexTerminalIdentifier', 'telephoneNumber', 'internationaliSDNNumber', 'facsimileTelephoneNumber', 'preferredDeliveryMethod', 'street', 'postOfficeBox', 'postalCode', 'postalAddress', 'physicalDeliveryOfficeName', 'st', 'l') must -> ('l',) sup -> ('person',) SchemaClassCreate -> 2.5.6.12 ('applicationEntity',) may -> ('supportedApplicationContext', 'seeAlso', 'ou', 'o', 'l', 'description') must -> ('presentationAddress', 'cn') sup -> ('top',) SchemaClassCreate -> 2.5.6.13 ('dSA',) may -> ('knowledgeInformation',) must -> () sup -> ('applicationEntity',) SchemaClassInconsistent -> ( 2.5.6.17 NAME 'groupOfUniqueNames' SUP top STRUCTURAL MUST cn MAY ( uniqueMember $ businessCategory $ seeAlso $ owner $ ou $ o $ description ) ) to 2.5.6.17 ('groupOfUniqueNames',) may -> ('businessCategory', 'seeAlso', 'owner', 'ou', 'o', 'description') must -> ('uniqueMember', 'cn') sup -> ('top',) SchemaClassCreate -> 2.5.6.20 ('dmd',) may -> ('userPassword', 'searchGuide', 'seeAlso', 'businessCategory', 'x121Address', 'registeredAddress', 'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber', 'teletexTerminalIdentifier', 'telephoneNumber', 'internationaliSDNNumber', 'facsimileTelephoneNumber', 'street', 'postOfficeBox', 'postalCode', 'postalAddress', 'physicalDeliveryOfficeName', 'st', 'l', 'description') must -> ('dmdName',) sup -> ('top',)
PR https://pagure.io/389-ds-base/pull-request/50948
Metadata Update from @tbordaz: - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None
Metadata Update from @mreynolds: - Issue set to the milestone: 1.4.3
Metadata Update from @firstyear: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/4000
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.