Mercurial Repository: p/roundup/code: doc/customizing.txt comparison

comparison doc/customizing.txt @ 2991:b9a55628a78d

more doc fixes simplified the security API, and bumped those changes around a couple more TODO items so I don't forget

author	Richard Jones <richard@users.sourceforge.net>
date	Tue, 07 Dec 2004 23:32:50 +0000
parents	9614a101b68f
children	8fa6b5747a53 714f2a60a97e

comparison

equal deleted inserted replaced

-:f4023f1cc1d6
+:b9a55628a78d
 ===================
 Customising Roundup
 ===================
-:Version: $Revision: 1.160 $
+:Version: $Revision: 1.161 $
 .. This document borrows from the ZopeBook section on ZPT. The original is at:
 http://www.zope.org/Documentation/Books/ZopeBook/current/ZPT.stx
 .. contents::
 to define new actions, you may add them there (see `defining new
 web actions`_).
 Each action class also has a ``*permission*`` method which determines whether
 the action is permissible given the current user. The base permission checks
-are:
+for each action are:
-XXX REVIEW for Permissions changes
 **login**
-Determine whether the user has permission to log in. Base behaviour is
+Determine whether the user has the "Web Access" Permission.
-to check the user has "Web Access".
 **logout**
 No permission checks are made.
 **register**
-Determine whether the user has permission to register. Base behaviour
+Determine whether the user has the "Web Registration" Permission.
-is to check the user has the "Web Registration" Permission.
 **edit**
 Determine whether the user has permission to edit this item. If we're
 editing the "user" class, users are allowed to edit their own details -
 unless they try to edit the "roles" property, which requires the
 special Permission "Web Roles".
 **new**
 Determine whether the user has permission to create this item. No
 additional property checks are made. Additionally, new user items may
 be created if the user has the "Web Registration" Permission.
 **editCSV**
-Determine whether the user has permission to edit this class. Base
+Determine whether the user has permission to edit this class.
-behaviour is to check whether the user may edit this class.
 **search**
-Determine whether the user has permission to search this class. Base
+Determine whether the user has permission to view this class.
-behaviour is to check whether the user may view this class.
 Special form variables
 ----------------------
 implemented**)
 history         render the journal of the current item as HTML
 renderQueryForm specific to the "query" class - render the search form
 for the query
 hasPermission   specific to the "user" class - determine whether the
-user has a Permission
+user has a Permission. The signature is::
+hasPermission(self, permission, [classname=],
+[property=], [itemid=])
+where the classname defaults to the current context.
 is_edit_ok      is the user allowed to Edit the current item?
 is_view_ok      is the user allowed to View the current item?
 is_retired      is the item retired?
 download_url    generates a url-quoted link for download of FileClass
 item contents (ie. file<id>/<name>)
 # Assign the access and edit permissions for issue, file and message
 # to regular users now
 for cl in 'issue', 'file', 'msg', 'category':
 p = db.security.getPermission('View', cl)
-db.security.addPermissionToRole('User', p)
+db.security.addPermissionToRole('User', 'View', cl)
-p = db.security.getPermission('Edit', cl)
+db.security.addPermissionToRole('User', 'Edit', cl)
-db.security.addPermissionToRole('User', p)
+db.security.addPermissionToRole('User', 'Create', cl)
 These lines assign the View and Edit Permissions to the "User" role, so
 that normal users can view and edit "category" objects.
 This is all the work that needs to be done for the database. It will
 Optionally, you might want to restrict the users able to access this new
 class to just the users with a new "SysAdmin" Role. To do this, we add
 some security declarations::
-p = db.security.getPermission('View', 'support')
+db.security.addPermissionToRole('SysAdmin', 'View', 'support')
-db.security.addPermissionToRole('SysAdmin', p)
+db.security.addPermissionToRole('SysAdmin', 'Create', 'support')
-p = db.security.getPermission('Edit', 'support')
+db.security.addPermissionToRole('SysAdmin', 'Edit', 'support')
-db.security.addPermissionToRole('SysAdmin', p)
 You would then (as an "admin" user) edit the details of the appropriate
 users, and add "SysAdmin" to their Roles list.
 Alternatively, you might want to change the Edit/View permissions granted
 ``schema.py``::
 # New users not approved by the admin
 db.security.addRole(name='Provisional User',
 description='New user registered via web or email')
-p = db.security.addPermission(name='Edit Own', klass='issue',
-description='Can only edit own issues')
+# These users need to be able to view and create issues but only edit
+# and view their own
+db.security.addPermissionToRole('Provisional User', 'Create', 'issue')
+def own_issue(db, userid, itemid):
+'''Determine whether the userid matches the creator of the issue.'''
+return userid == db.issue.get(itemid, 'creator')
+p = db.security.addPermission(name='Edit Own Issues', klass='issue',
+code=own_issue, description='Can only edit own issues')
 db.security.addPermissionToRole('Provisional User', p)
+p = db.security.addPermission(name='View Own Issues', klass='issue',
-# Assign the access and edit Permissions for issue to new users now
+code=own_issue, description='Can only view own issues')
-p = db.security.getPermission('View', 'issue')
 db.security.addPermissionToRole('Provisional User', p)
-p = db.security.getPermission('Edit', 'issue')
-db.security.addPermissionToRole('Provisional User', p)
+# Assign the Permissions for issue-related classes
+for cl in 'file', 'msg', 'query', 'keyword':
+db.security.addPermissionToRole('User', 'View', cl)
+db.security.addPermissionToRole('User', 'Edit', cl)
+db.security.addPermissionToRole('User', 'Create', cl)
+for cl in 'priority', 'status':
+db.security.addPermissionToRole('User', 'View', cl)
 # and give the new users access to the web and email interface
-p = db.security.getPermission('Web Access')
+db.security.addPermissionToRole('Provisional User', 'Web Access')
-db.security.addPermissionToRole('Provisional User', p)
+db.security.addPermissionToRole('Provisional User', 'Email Access')
-p = db.security.getPermission('Email Access')
-db.security.addPermissionToRole('Provisional User', p)
 Then in the ``config.ini`` we change the Role assigned to newly-registered
 users, replacing the existing ``'User'`` values::
 [main]
 ...
 new_web_user_roles = 'Provisional User'
 new_email_user_roles = 'Provisional User'
-Finally we add a new *auditor* to the ``detectors`` directory called
-``provisional_user_auditor.py``::
-def audit_provisionaluser(db, cl, nodeid, newvalues):
-''' New users are only allowed to modify their own issues.
-'''
-if (db.getuid() != cl.get(nodeid, 'creator')
-and db.security.hasPermission('Edit Own', db.getuid(), cl.classname)):
-raise ValueError, ('You are only allowed to edit your own %s'
-% cl.classname)
-def init(db):
-# fire before changes are made
-db.issue.audit('set', audit_provisionaluser)
-db.issue.audit('retire', audit_provisionaluser)
-db.issue.audit('restore', audit_provisionaluser)
 Note that some older trackers might also want to change the ``page.html``
 template as follows::
 <p class="classblock"
 4. Use the usual "new" action as the ``@action`` on the final page, and
 you're done (the standard context/submit method can do this for you).
 -------------------
 Back to `Table of Contents`_
 .. _`Table of Contents`: index.html

Mercurial > p > roundup > code

comparison doc/customizing.txt @ 2991:b9a55628a78d