Your fix on the logging looks good. I have one question regarding the returning error message. The following message is returned to each client? Assuming it, the ordinary user is not allowed to do the operation to "set passwordIsGlobalPolicy to 'on' in cn=config"... Also, the information might look a bit tricky to share among end users... Maybe, more generic "ask administrator" type of message would be preferable?
{{{
66 int op_shared_is_allowed_attr (const char attr_name, int replicated_op)
66 int op_shared_is_allowed_attr (const char attr_name, int replicated_op, char errtxt)
67 67 {
[...]
106 106 / this attribute is not allowed /
107 *errtxt = "Rejecting replicated password policy operation. To "
108 "allow these changes to be accepted, set "
109 "passwordIsGlobalPolicy to 'on' in cn=config.";
}}}

Replying to [comment:4 nhosoi]:

Your fix on the logging looks good. I have one question regarding the returning error message. The following message is returned to each client? Assuming it, the ordinary user is not allowed to do the operation to "set passwordIsGlobalPolicy to 'on' in cn=config"... Also, the information might look a bit tricky to share among end users... Maybe, more generic "ask administrator" type of message would be preferable?

Good point, in fact maybe we should just leave the client message empty(like it was), and only report the message in the error log. Clients should not be trying to do this anyway, and that message is only reported in a replication session. So I guess it's really not needed in the client result. Thoughts?

{{{
66 int op_shared_is_allowed_attr (const char attr_name, int replicated_op)
66 int op_shared_is_allowed_attr (const char attr_name, int replicated_op, char errtxt)
67 67 {
[...]
106 106 / this attribute is not allowed /
107 *errtxt = "Rejecting replicated password policy operation. To "
108 "allow these changes to be accepted, set "
109 "passwordIsGlobalPolicy to 'on' in cn=config.";
}}}

Replying to [comment:5 mreynolds]:

Good point, in fact maybe we should just leave the client message empty(like it was), and only report the message in the error log. Clients should not be trying to do this anyway, and that message is only reported in a replication session. So I guess it's really not needed in the client result. Thoughts?

I agree that the client message is not really needed. It's probably best to just log it on the system where the config change is needed.

revision
0001-Ticket-620-Better-logging-of-error-messages-for-389-.patch

Agreed, client message removed. Pushed

git merge ticket620
Updating ac8ceb9..a4c4daa
Fast-forward
ldap/servers/slapd/modify.c | 46 ++++++++++++++++++++++++++----------------
1 files changed, 28 insertions(+), 18 deletions(-)

git push origin master
Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 1.25 KiB, done.
Total 6 (delta 4), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
ac8ceb9..a4c4daa master -> master

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

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.