Yes, with the introduction of backend transaction plugins in 1.3.3, if a plugin fails to do its "job", the entire operation should fail. This applies to all the plugins now. I believe this was documented in the DS 10 release notes, and for upstream releases the ticket that applied this change was listed here(http://www.port389.org/docs/389ds/releases/release-1-3-3-0.html). I apologize for any inconvenience this has caused you. See more comments below...Looks like the behavior change was introduced in this ticket: https://fedorahosted.org/389/ticket/47810
As you noted this design change is not what impacted the behavior you are now seeing, but the change to make most plugins backend transaction aware.
** The change of behavior/consistency issue: since memberOf plugin has been redesigned in 1.3.3 (http://www.port389.org/docs/389ds/design/memberof-plugin-configuration.html) its behavior has changed a bit.
This is a bug then, it should have been refused. I'll reopen ticket 47810 to address this...At the same time if we do "replace" of "uniquemember" instead of "add", then it works:
dn: cn=LDAP Test group,ou=Groups,dc=example,dc=com
changetype: modify
replace: uniqueMember
uniqueMember: uid=user1,ou=People,dc=example,dc=com
-
The error message in this case is information only and the modification is not refused:
[04/Aug/2015:11:04:45 +0200] - Entry "uid=user1,ou=People,dc=example,dc=com" -- attribute "memberOf" not allowed
Or use a standard objectclass that allows memberOf like: inetUser.For now, as a workaround we have changed the schema to allow "memberOf" attribute in all the classes used in entries referenced by "uniqueMember" in our directory.