Description of problem: When we use one operation to add two(or more) links to some entry, and the value of the first attribute is valid, but other values are unexisting entries, then the managed attribute will be added, but the link attribute won't.
How reproducible: Always
Steps to Reproduce: 1) Enable Linked Attributes plug-in; ldapmodify -h localhost -p 389 -D "cn=Directory manager" -W cn=Linked Attributes,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on
2) Create the plug-in instance; ldapmodify -h localhost -p 389 -D "cn=Directory manager" -W dn: cn=Manager Link,cn=Linked Attributes,cn=plugins,cn=config changetype: add objectClass: top objectClass: extensibleObject cn: Manager Link linkType: directReport managedType: manager
3) Add two entries; ldapmodify -h localhost -p 389 -D "cn=Directory manager" -W dn: uid=employee1,ou=People,dc=example,dc=com changetype: add objectClass: extensibleobject objectClass: inetorgperson objectClass: organizationalPerson objectClass: person objectClass: top cn: Employee 1 sn: Employee 1 uid: employee1
dn: uid=manager1,ou=People,dc=example,dc=com changetype: add objectClass: extensibleobject objectClass: inetorgperson objectClass: organizationalPerson objectClass: person objectClass: top cn: manager 1 sn: manager 1 uid: manager1
4) Execute link operation with existing and unexisting entries; ldapmodify -h localhost -p 389 -D "cn=Directory manager" -W dn: uid=manager1,ou=People,dc=example,dc=com changetype: modify add: directreport directreport: uid=employee1,ou=People,dc=example,dc=com directreport: uid=doNotExist,ou=People,dc=example,dc=com
Actual results: ldapsearch -h localhost -p 389 -D "cn=Directory manager" -W -b ou=people,dc=example,dc=com
dn: uid=employee1,ou=People,dc=example,dc=com objectClass: extensibleobject objectClass: inetorgperson objectClass: organizationalPerson objectClass: person objectClass: top cn: Employee 1 sn: Employee 1 uid: employee1 manager: uid=manager1,ou=People,dc=example,dc=com
dn: uid=manager1,ou=People,dc=example,dc=com objectClass: extensibleobject objectClass: inetorgperson objectClass: organizationalPerson objectClass: person objectClass: top cn: manager 1 sn: manager 1 uid: manager1
Expected results: ldapsearch -h localhost -p 389 -D "cn=Directory manager" -W -b ou=people,dc=example,dc=com
dn: uid=manager1,ou=people,dc=example,dc=com objectClass: extensibleobject objectClass: inetorgperson objectClass: organizationalPerson objectClass: person objectClass: top cn: manager 1 sn: manager 1 uid: manager1 directreport: uid=employee1,ou=People,dc=example,dc=com
Additional info: 1) If we execute the link operation like this: ldapmodify -h localhost -p 389 -D "cn=Directory manager" -W dn: uid=manager1,ou=People,dc=example,dc=com changetype: modify add: directreport directreport: uid=doNotExist,ou=People,dc=example,dc=com directreport: uid=employee1,ou=People,dc=example,dc=com
Then nothing will be added.
2) If we try to repair it with fixup-linkedattrs.pl or "cn=fixup linked attributes task", then no directreport attribute will be added to uid=manager1,ou=People,dc=example,dc=com. Manager attribute will be deleted from uid=employee1,ou=People,dc=example,dc=com.
In this test case,
dn: uid=manager1,ou=People,dc=example,dc=com changetype: modify add: directreport directreport: uid=employee1,ou=People,dc=example,dc=com directreport: uid=doNotExist,ou=People,dc=example,dc=com the first directreport add has no problem and it also successfully add the managedtype to uid=employee1,ou=People,dc=example,dc=com. But the second directreport add fails since adding managedtype attempt fails due to the missing entry (uid=doNotExist).
Then, the Linked Attributes plug-in returns the failure at SLAPI_PLUGIN_BE_TXN_POST_MODIFY_FN in ldbm_back_modify, which makes the main operation fail and rollback.
The fist directreport add success was successfully done. That means, the managed entry has "manager: uid=manager1,ou=People,dc=example,dc=com" in the entry uid=employee1, which is in the entry cache as well as in the db cache. The latter one is rolled back automatically, but the former has no way to rolled back for now.
Although it is against the original expectation, what we could do is if the second or the after operation fails, undoing the successfully finished operation(s). That makes the entire operation fail if one of them does.
git patch file (master) 0001-Ticket-48295-Entry-cache-is-not-rolled-back-Linked-A.patch
git patch file (master) -- CI test 0002-Ticket-48295-CI-test-added-test-cases-for-ticket-482.patch
Reviewed by Mark (Thanks!!)
Pushed to master: 08c40e8..63b8ece master -> master commit 088ddec commit 63b8ece
Metadata Update from @nhosoi: - Issue assigned to nhosoi - Issue set to the milestone: 1.3.5 backlog
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/1626
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.