Roundup Tracker - Issues

Message6685

Author rouilj
Recipients rouilj
Date 2019-10-05.15:59:48
Message-id <1570291188.29.0.982005741348.issue2551062@roundup.psfhosted.org>
In-reply-to
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?
History
Date User Action Args
2019-10-05 15:59:48rouiljsetrecipients: + rouilj
2019-10-05 15:59:48rouiljsetmessageid: <1570291188.29.0.982005741348.issue2551062@roundup.psfhosted.org>
2019-10-05 15:59:48rouiljlinkissue2551062 messages
2019-10-05 15:59:48rouiljcreate