Brett @Google wrote:
I don't want to hold you back from implementing the EQUALITY matching rule for PostalAdress syntax.
But you could also just delete the whole attribute and re-add the value(s) needed. (That's how the delta-modification works in web2ldap if the EQUALITY matching rule is not implemented.)
Yes that's what i did to fix my test data, but specifically this change was made indirectly by the collect.c overlay, not manually by me, which populates attributes from a parent or template object through to all the children of that object. I want to use the collect overlay to make child objects have the same postalAddress (amoung other attributes) of some parent or template object, such as some superior ou entry that is component of the user's dn.
This issue arises as to what happens to when you try to edit postalAddress in a child object which has collected an attribute from some parent, what is presently happening is that the parent gets another duplicate attribute value on the inherited attribute. In other words it allows the change, but it cannot tell that the new attribute value is the same as the old attribute value.
slapo-collect should intercept the write request and forbid the write access if the attribute type is declared with COLLECTIVE.
While this probably can be simply fixed by disallowing writes on attributes of child object which are collect-ed from a parent, my thought was that if there was an equality matching rule and it were implemented, the update would fail or silently ignore the update (as ldap would normally) because the attribute already has that value, and it would be a tidier / more correct solution.
Again: I'd appreciate if you would implement caseIgnoreListMatch but this particular issue should be fixed in a more general way.
Ciao, Michael.