Mercurial > p > roundup > code
view share/roundup/templates/minimal/schema.py @ 5222:9bf221cebef3
Make properties method return only properties the user can search.
See:
https://sourceforge.net/p/roundup/mailman/roundup-devel/thread/20170405002844.2004B80690%40vm71.cs.umb.edu/#msg35769250
[Roundup-devel] Bug in context/properties, lists properties user can't search.
The HTMLClass::properties() method returns a list of all
properties. This is used when creating sort on/group by filters on
index pages.
However somewhere in the code, a user needs search permission on the
property in order for it to be used for grouping or sorting.
This means the user can choose to sort/group an index page by a
property that they have no search permission for. As a result the
sort/group is ignored. This is confusing.
I have changed the properties method to only return properties the
user has View/Search permissions on. I also added a new cansearch
argument set by default to True. If set to False, all properties
regardless of Search permission are returned.
Doc updated to include the new default operation and mention the use
of cansearch argument.
| author | John Rouillard <rouilj@ieee.org> |
|---|---|
| date | Wed, 05 Apr 2017 21:38:32 -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 :
