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

comparison doc/customizing.txt @ 3276:3124e578db02

Email fixes: - fix checking of "Email Access" for Anonymous email registration [SF#177057] - disable "Email Access" for Anonymous by default to stop spam regsitering users on public trackers - doc fixes / additions too

author	Richard Jones <richard@users.sourceforge.net>
date	Wed, 13 Apr 2005 03:38:23 +0000
parents	e41e1540a287
children	5da323b46907

comparison

equal deleted inserted replaced

-:3e216b862018
+:3124e578db02
 ===================
 Customising Roundup
 ===================
-:Version: $Revision: 1.176 $
+:Version: $Revision: 1.177 $
 .. This document borrows from the ZopeBook section on ZPT. The original is at:
 http://www.zope.org/Documentation/Books/ZopeBook/current/ZPT.stx
 .. contents::
 Before you get too far, it's probably worth having a quick read of the Roundup
 `design documentation`_.
 Customisation of Roundup can take one of six forms:
-1. `tracker configuration`_ file changes
+1. `tracker configuration`_ changes
 2. database, or `tracker schema`_ changes
 3. "definition" class `database content`_ changes
 4. behavioural changes, through detectors_
 5. `security / access controls`_
 6. change the `web interface`_
 =====================
 The ``config.ini`` located in your tracker home contains the basic
 configuration for the web and e-mail components of roundup's interfaces.
+Changes to the data captured by your tracker is controlled by the `tracker
+schema`_.  Some configuration is also performed using permissions - see the
+`security / access controls`_ section. For example, to allow users to
+automatically register through the email interface, you must grant the
+"Anonymous" Role the "Email Access" Permission.
 The following is taken from the `Python Library Reference`__ (May 20, 2004)
 section "ConfigParser -- Configuration file parser":
 The configuration file consists of sections, led by a "[section]" header
 and followed by "name = value" entries, with line continuations on a
 would resolve the "%(dir)s" to the value of "dir" ("frob" in this case)
 resulting in "foodir" being "frob/whatever".
 __ http://docs.python.org/lib/module-ConfigParser.html
-Configuration variables may be referred to in lower or upper case. In code,
-variables not in the "main" section are referred to using their section and
-name, so "domain" in the section "mail" becomes MAIL_DOMAIN. The
-configuration variables available are:
 Section **main**
 database -- ``db``
 Database directory path. The path may be either absolute or relative
 to the directory containig this config file.
 on followups too. If ``no``, they're never added to the nosy.
 Allowed values: ``yes``, ``no``, ``new``
 You may generate a new default config file using the ``roundup-admin
 genconfig`` command.
+Configuration variables may be referred to in lower or upper case. In code,
+variables not in the "main" section are referred to using their section and
+name, so "domain" in the section "mail" becomes MAIL_DOMAIN. The
+configuration variables available are:
 Tracker Schema
 ==============
 - Create (everything)
 - Edit (everything)
 - View (everything)
-Every Class you define in your tracker's schema also gets an Create, Edit
+These are assigned to the "Admin" Role by default, and allow a user to do
-and View Permission of its own.
+anything. Every Class you define in your `tracker schema`_ also gets an
+Create, Edit and View Permission of its own. The web and email interfaces
-The default interfaces define:
+also define:
-- Web Registration
+*Email Access*
-- Web Access
+If defined, the user may use the email interface. Used by default to deny
-- Web Roles
+Anonymous users access to the email interface. When granted to the
-- Email Registration
+Anonymous user, they will be automatically registered by the email
-- Email Access
+interface (see also the ``new_email_user_roles`` configuration option).
+*Web Access*
+If defined, the user may use the web interface. All users are able to see
+the login form, regardless of this setting (thus enabling logging in).
+*Web Roles*
+Controls user access to editing the "roles" property of the "user" class.
+TODO: deprecate in favour of a property-based control.
 These are hooked into the default Roles:
 - Admin (Create, Edit, View and everything; Web Roles)
 - User (Web Access; Email Access)
-- Anonymous (Web Registration; Email Registration)
+- Anonymous (Web Access)
 And finally, the "admin" user gets the "Admin" Role, and the "anonymous"
 user gets "Anonymous" assigned when the tracker is installed.
 For the "User" Role, the "classic" tracker defines:
 - Create, Edit and View issue, file, msg, query, keyword
 - View priority, status
 - View user
-- Edit their own record
+- Edit their own user record
 And the "Anonymous" Role is defined as:
+- Web interface access
 - Create user (for registration)
 - View issue, file, msg, query, keyword, priority, status
 Put together, these settings appear in the tracker's ``schema.py`` file::
 #
 # REGULAR USERS
 #
 # Give the regular users access to the web and email interface
-p = db.security.getPermission('Web Access')
+db.security.addPermissionToRole('User', 'Web Access')
-db.security.addPermissionToRole('User', p)
+db.security.addPermissionToRole('User', 'Email Access')
-p = db.security.getPermission('Email Access')
-db.security.addPermissionToRole('User', p)
 # Assign the access and edit Permissions for issue, file and message
 # to regular users now
 for cl in 'issue', 'file', 'msg', 'query', 'keyword':
-p = db.security.getPermission('View', cl)
+db.security.addPermissionToRole('User', 'View', cl)
-db.security.addPermissionToRole('User', p)
+db.security.addPermissionToRole('User', 'Edit', cl)
-p = db.security.getPermission('Edit', cl)
+db.security.addPermissionToRole('User', 'Create', cl)
-db.security.addPermissionToRole('User', p)
-p = db.security.getPermission('Create', cl)
-db.security.addPermissionToRole('User', p)
 for cl in 'priority', 'status':
-p = db.security.getPermission('View', cl)
+db.security.addPermissionToRole('User', 'View', cl)
-db.security.addPermissionToRole('User', p)
 # May users view other user information? Comment these lines out
 # if you don't want them to
-p = db.security.getPermission('View', 'user')
+db.security.addPermissionToRole('User', 'View', 'user')
-db.security.addPermissionToRole('User', p)
+# Users should be able to edit their own details -- this permission
-# Users should be able to edit their own details. Note that this
+# is limited to only the situation where the Viewed or Edited item
-# permission is limited to only the situation where the Viewed or
+# is their own.
-# 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,
 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.
-p = db.security.getPermission('Web Access')
+db.security.addPermissionToRole('Anonymous', 'Web Access')
-db.security.addPermissionToRole('Anonymous', p)
 # 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)
-p = db.security.getPermission('Email Access')
+# This is disabled by default to stop spam from auto-registering users on
-db.security.addPermissionToRole('Anonymous', p)
+# public trackers.
+#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
-p = db.security.getPermission('Create', 'user')
+db.security.addPermissionToRole('Anonymous', 'Create', 'user')
-db.security.addPermissionToRole('Anonymous', p)
 # Allow anonymous users access to view issues (and the related, linked
 # information)
 for cl in 'issue', 'file', 'msg', 'keyword', 'priority', 'status':
-p = db.security.getPermission('View', cl)
+db.security.addPermissionToRole('Anonymous', 'View', cl)
-db.security.addPermissionToRole('Anonymous', p)
 # [OPTIONAL]
 # Allow anonymous users access to create or edit "issue" items (and the
 # related file and message items)
 #for cl in 'issue', 'file', 'msg':
-#   p = db.security.getPermission('Create', cl)
+#   db.security.addPermissionToRole('Anonymous', 'Create', cl)
-#   db.security.addPermissionToRole('Anonymous', p)
+#   db.security.addPermissionToRole('Anonymous', 'Edit', cl)
-#   p = db.security.getPermission('Edit', cl)
-#   db.security.addPermissionToRole('Anonymous', p)
 Automatic Permission Checks
 ---------------------------
 New users are assigned the Roles defined in the config file as:
 - NEW_WEB_USER_ROLES
 - NEW_EMAIL_USER_ROLES
+The `users may only edit their issues`_ example shows customisation of
+these parameters.
 Changing Access Controls
 ------------------------

Mercurial > p > roundup > code

comparison doc/customizing.txt @ 3276:3124e578db02