See issue2551032. The class was defined using organisation while the
Edit permission for the class was defined with organization.
db.security.addPermission doesn't validate the list of permissions.
There is a chicken and egg issue here. Calls to addPermision occur
while loading the schema. The db can't be opened until after the
schema is loaded, so there is no way to see what classes/properties
are defined in the db. Also the db may still need to be modified
based on changes to the schema.
I can validate the data on first use in security::hasPermission.
The plan is:
add new prop: _properties_valid to the Permission class/object
add new method: validate_properties to the Permission class
In security.hasPermission check each permission. If
_properties_valid is not True, see if the permission has
properties. In this case call a property validator method on the
permission, passing the (now valid) db from the security
object. Then set the _properties_valid to True if all properties are
valid, otherwise raise ValueError.
Recording the validation state in the object should reduce the impact
of validating at use time rather than creation time.
However this is a breaking change. E.G. this very issue tracker uses:
for cl in ('file', 'msg'):
p = db.security.addPermission(name='View', klass=cl,
description="allowed to see metadata object regardless of spam status",
properties=('id', 'creation', 'activity',
'creator', 'actor',
'name', 'spambayes_score',
'spambayes_misclassified',
'author', 'recipients',
'date', 'files', 'messageid',
'inreplyto', 'type',
'description', ))
would break since author is a property of msg not file and name is a
prop of file the class not msg.
I have code that implements this, but should I put it behind a tracker
config option to enable/disable validating the properties as there may
be trackers that use this unitended mechanism?
Thoughts? |