view share/roundup/templates/minimal/schema.py @ 4587:a2eb4fb3e6d8

New Chameleon templating engine, engine is now configurable. We now have two configurable templating engines, the old Zope TAL templates (called zopetal in the config) and the new Chameleon (called chameleon in the config). A new config-option "template_engine" under [main] can take these config-options, the default is zopetal. Thanks to Cheer Xiao for the idea of making this configurable *and* for the actual implementation! Cheer Xiao commit log: - The original TAL engine ported from Zope is thereafter referred to as "zopetal", in speech and in code - A new option "template_engine" under [main] introduced - Zopetal-specific code stripped from cgi/templating.py to form the new cgi/engine_zopetal.py - Interface to Chameleon in cgi/engine_chameleon.py - Engines are supposed to provide a Templates class that mimics the behavior of the old cgi.templating.Templates. The Templates class is preferably subclassed from cgi.templating.TemplatesBase. - New function cgi.templating.get_templates to get the appropriate engine's Templates instance according to the engine name
author Ralf Schlatterbeck <rsc@runtux.com>
date Thu, 23 Feb 2012 18:10:03 +0100
parents b30bdfae4461
children 0c54c846ea6a
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")
#
# 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
db.security.addPermissionToRole('User', 'View', 'user')

# 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 :

Roundup Issue Tracker: http://roundup-tracker.org/