WIP: support properties' read permission in the GUI and in getProperty
This is really an early stage, I wrote the GUI test using
reference_property, but reference is kind of special property as it is used to calculate compact title. I had to do e47cb7f9 , but I am not sure it's a good idea, probably we should use a more standard property in the test.
I changed a lot the implementation for
getProperty('*_list') I have no idea why this was getting the method on the class and passing self as first argument. Now it we just get method on the instance, like we do for single properties.
Don't forget (in)famous propertyMap() method that is guarded in access content information permission on the object itself...
Thanks @kazuhiko , that's right. There are others in this family, at least propertyItems & propertyValues (I wonder if we really need those)
Similar, there is asXML and probably others.
I think that the if all these methods raise a "big" Unauthorized as long as there is one property that user cannot access we are ok.
The first test result shows some errors.
- one is with constraints, here the problem seem to be that constraints instances are not acquisition wrappers. I guess we can just call getReference here, since all constraints should have a getReference method (because it inherits from IdAsReferenceMixin.
- another difference is that acquired properties now require that you can access the object where the property is acquired. I am not really sure this is a bug, if you don't have access to that default email document, shouldn't
person.getDefaultEmailText()raise ? for example if this person have a subordination to an organisation user cannot access,
person.getSubordinationTitle()will raise Unauthorized, so this new behavior is consistent.
I feel these are not blocker issues though and eventhough tests are failing a bit we can continue in this direction.
Also, I was thinking that maybe this whole thing of trying to support different permissions for properties is maybe a bad idea in the first place and we should never do this, but just use a different (sub)document if we need a different permission.
I came up to the same problem recently.
for example if this person have a subordination to an organisation user cannot access, person.getSubordinationTitle() will raise Unauthorized, so this new behavior is consistent.
Yes, this should be the correct hebavior. Then at least we can protect information by using a different (sub)document. If acquired property ignores subdocument permission, we can't even take this option. But I would like to support different permissions for properties.
I realized that to support different permissions for property getters(I said properties in the previous post, it was about property getters) is meaningless because property(not getter) is not protected by the same permission. For setters, to support different permissions is still useful I think.
And acquired property getters should check permission. This is meaningful. I will do it first.