It would be better to check to see if the operation is a modrdn, and skip adding the objectclass in that case.

Replying to [comment:2 rmeggins]:

It would be better to check to see if the operation is a modrdn, and skip adding the objectclass in that case.

Actually I think we still need to try to add the objectclass, as the entry could of been out of scope and then moved into scope - in that case the entry would not have the managed entry objectclass.

Replying to [comment:3 mreynolds]:

Replying to [comment:2 rmeggins]:

It would be better to check to see if the operation is a modrdn, and skip adding the objectclass in that case.

Actually I think we still need to try to add the objectclass, as the entry could of been out of scope and then moved into scope - in that case the entry would not have the managed entry objectclass.

Ok. Then I think you should check for the return error code - if it is TYPE_OR_VALUE_EXISTS, then you can ignore it and assume the entry already has the correct objectclass.

Replying to [comment:4 rmeggins]:

Replying to [comment:3 mreynolds]:

Replying to [comment:2 rmeggins]:

It would be better to check to see if the operation is a modrdn, and skip adding the objectclass in that case.

Actually I think we still need to try to add the objectclass, as the entry could of been out of scope and then moved into scope - in that case the entry would not have the managed entry objectclass.

Ok. Then I think you should check for the return error code - if it is TYPE_OR_VALUE_EXISTS, then you can ignore it and assume the entry already has the correct objectclass.

But I still have to do the managed entry pointer addition in a separate mod operation.

Previously we lumped both operations into a single mod op.

        mods[0] = &oc_mod;
        mods[1] = &pointer_mod;
        mods[2] = 0;

So if the objectclass addition fails, then we don't add the managed entry pointer. So we can check for err 20, but then we still have to do another mod op to add the pointer mod.

Replying to [comment:5 mreynolds]:

Replying to [comment:4 rmeggins]:

Replying to [comment:3 mreynolds]:

Replying to [comment:2 rmeggins]:

It would be better to check to see if the operation is a modrdn, and skip adding the objectclass in that case.

Actually I think we still need to try to add the objectclass, as the entry could of been out of scope and then moved into scope - in that case the entry would not have the managed entry objectclass.

Ok. Then I think you should check for the return error code - if it is TYPE_OR_VALUE_EXISTS, then you can ignore it and assume the entry already has the correct objectclass.

But I still have to do the managed entry pointer addition in a separate mod operation.

Right.

Previously we lumped both operations into a single mod op.

        mods[0] = &oc_mod;
        mods[1] = &pointer_mod;
        mods[2] = 0;

So if the objectclass addition fails, then we don't add the managed entry pointer. So we can check for err 20, but then we still have to do another mod op to add the pointer mod.

Right.

Sorry I thought you still wanted me to keep everything in one operation, I'll rework the patch to check the objectclass operation result.

revision
0001-Ticket-47813-managed-entry-plugin-fails-to-update-me.patch

New patch attached(TET and jenkins PASSED)...

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1106917

git merge ticket47813
Updating ba9c8b6..0fe78df
Fast-forward
ldap/servers/plugins/mep/mep.c | 41 ++++++++++++++++++++++++++++++-----------
1 file changed, 30 insertions(+), 11 deletions(-)

git push origin master
ba9c8b6..0fe78df master -> master

commit 0fe78df
Author: Mark Reynolds mreynolds@redhat.com
Date: Mon Jun 9 12:27:04 2014 -0400

1f3510a..420bcdf 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit 420bcdf

c6b5630..aa9933e 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
commit aa9933e99e537027c0de15ccda996cdfcbd9c5a7

bdb5e35..7a3fd98 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit 7a3fd98

Previous commit had "goto bail", but "bail" did not exist on 1.3.2 and down.

420bcdf..4cdd7fd 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit 4cdd7fd

aa9933e..cc38a66 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
commit cc38a66854db8212ff3928f234ea9eecd57e0ce9

7a3fd98..cb8471b 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit cb8471b

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/1144

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.