Mercurial > p > roundup > code
view share/roundup/templates/minimal/schema.py @ 5705:457fc482e6b1
Method PUT: ignore specification of protected properties which can not
be set. Filtering them out of the payload list. This lets the result
of a get using:
class/id?@protected=true&@verbose=0
be used as input to a PUT operation without having to strip the
protected properties.
Note this does not raise an error if the PUT protected property is
different from the value in the db. If the property is different but
the etag/if-match passes, the user attempted to set the protected
property and this should result in an error, but will not with this
patch.
Method DELETE class/id/attribute: raise error when trying to delete
protected or required attribute/property. Raise UsageError
when attribute doesn't exist.
Method PATCH class/id:
raise error when trying to replace/remove protected attribute/property
raise error when trying to remove required attribute/property
Catch KeyError at top level and turn into 400 error.
If payload has an attribute/property that does not exist, raise
UsageError which becomes a 400 error.
| author | John Rouillard <rouilj@ieee.org> |
|---|---|
| date | Thu, 11 Apr 2019 20:54:39 -0400 |
| parents | a403c29ffaf9 |
| children | 94a7669677ae |
line wrap: on
line source
# # TRACKER SCHEMA # # Class automatically gets these properties: # creation = Date() # activity = Date() # creator = Link('user') # actor = Link('user') # The "Minimal" template gets only one class, the required "user" # class. That's it. And even that has the bare minimum of properties. # Note: roles is a comma-separated string of Role names user = Class(db, "user", username=String(), password=Password(), address=String(), alternate_addresses=String(), roles=String()) user.setkey("username") db.security.addPermission(name='Register', klass='user', description='User is allowed to register new user') # # TRACKER SECURITY SETTINGS # # See the configuration and customisation document for information # about security setup. # # REGULAR USERS # # Give the regular users access to the web and email interface db.security.addPermissionToRole('User', 'Web Access') db.security.addPermissionToRole('User', 'Email Access') # May users view other user information? # Comment these lines out if you don't want them to p = db.security.addPermission(name='View', klass='user', properties=('id', 'username')) db.security.addPermissionToRole('User', p) # Users should be able to edit their own details -- this permission is # limited to only the situation where the Viewed or Edited item is their own. def own_record(db, userid, itemid): '''Determine whether the userid matches the item being accessed.''' return userid == itemid p = db.security.addPermission(name='View', klass='user', check=own_record, description="User is allowed to view their own user details") db.security.addPermissionToRole('User', p) p = db.security.addPermission(name='Edit', klass='user', check=own_record, properties=('username', 'password', 'address', 'alternate_addresses'), description="User is allowed to edit their own user details") db.security.addPermissionToRole('User', p) # # ANONYMOUS USER PERMISSIONS # # Let anonymous users access the web interface. Note that almost all # trackers will need this Permission. The only situation where it's not # required is in a tracker that uses an HTTP Basic Authenticated front-end. db.security.addPermissionToRole('Anonymous', 'Web Access') # Let anonymous users access the email interface (note that this implies # that they will be registered automatically, hence they will need the # "Create" user Permission below) db.security.addPermissionToRole('Anonymous', 'Email Access') # Assign the appropriate permissions to the anonymous user's # Anonymous Role. Choices here are: # - Allow anonymous users to register db.security.addPermissionToRole('Anonymous', 'Register', 'user') # vim: set et sts=4 sw=4 :
