If opreturn is SLAPI_PLUGIN_NOOP, it returns at the line 644, but if opreturn is non-zero (e.g., SLAPI_PLUGIN_FAILURE), it goes forward.
389 int 390 ldbm_back_modify( Slapi_PBlock *pb ) [...] 630 opreturn = plugin_call_plugins(pb, SLAPI_PLUGIN_BE_PRE_MODIFY_FN); 631 if (opreturn || 632 (slapi_pblock_get(pb, SLAPI_RESULT_CODE, &ldap_result_code) && ldap_result_code) || 633 (slapi_pblock_get(pb, SLAPI_PLUGIN_OPRETURN, &opreturn) && opreturn)) { 634 slapi_pblock_get(pb, SLAPI_RESULT_CODE, &ldap_result_code); 635 slapi_pblock_get(pb, SLAPI_PLUGIN_OPRETURN, &opreturn); 636 if (!ldap_result_code) { 637 LDAPDebug0Args(LDAP_DEBUG_ANY, "ldbm_back_modify: SLAPI_PLUGIN_BE_PRE_MODIFY_FN " 638 "returned error but did not set SLAPI_RESULT_CODE\n"); 639 ldap_result_code = LDAP_OPERATIONS_ERROR; 640 } 641 if (SLAPI_PLUGIN_NOOP == opreturn) { 642 not_an_error = 1; 643 rc = opreturn = LDAP_SUCCESS; 644 goto error_return; 645 } else if (!opreturn) { 646 opreturn = -1; 647 slapi_pblock_set(pb, SLAPI_PLUGIN_OPRETURN, &opreturn); 648 } 649 }
Historically, the return value of plugins were just ignored and the process goes forward in the backend. But it's strictly checked now. (See SLAPI_PLUGIN_BE_PRE_{ADD,DELETE,MODRDN}_FN.) SLAPI_PLUGIN_BE_PRE_MODIFY_FN should follow the rule.
A workaround is in place but a fix is expected (as soon as possible) in 1.3.2
git patch file (master) 0001-Ticket-47919-ldbm_back_modify-SLAPI_PLUGIN_BE_PRE_MO.patch
Reviewed by Mark (Thank you!!)
Pushed to master: 5f3aaa2..cb17381 master -> master commit cb17381
Pushed to 389-ds-base-1.3.3: 0f29b5e..1729443 389-ds-base-1.3.3 -> 389-ds-base-1.3.3 commit 1729443
Pushed to 389-ds-base-1.3.2: b2e24bb..65c73b4 389-ds-base-1.3.2 -> 389-ds-base-1.3.2 commit 65c73b4
Pushed to 389-ds-base-1.3.1: c26a7b1..b721da8 389-ds-base-1.3.1 -> 389-ds-base-1.3.1 commit b721da8061074126db6028e819e629bc51c37784
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1150695
Metadata Update from @nhosoi: - Issue set to the milestone: 1.3.2.24
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/1250
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.