Fixing some potential security holes

Enhanced checking was added to the user registration auditor. If you run a public tracker you should update your tracker’s detectors/userauditor.py using the new code from share/roundup/templates/classic/detectors/userauditor.py. In most cases you may just copy the file over, but if you’ve made changes to the auditor in your tracker then you’ll need to manually integrate the new code.

Some HTML templates were found to have formatting security problems:

html/page.html:

-tal:replace="request/user/username">username</span></b><br>
+tal:replace="python:request.user.username.plain(escape=1)">username</span></b><br>

html/_generic.help-list.html:

-tal:content="structure python:item[prop]"></label>
+tal:content="python:item[prop]"></label>

The lines marked “+” should be added and lines marked “-” should be deleted (minus the “+”/”-” signs).

Some HTML interface tweaks

You may wish to copy the user_utils.js and style.css` files from the source distribution ``share/roundup/templates/classic/html/ directory to the html directory of your trackers as it includes a small improvement.

If you have made local changes to those files you’ll need to manually work the differences in to your versions or ignore the changes.

Close potential security hole

If your tracker has untrusted users you should examine its schema.py file and look for the section granting the “Edit” permission to your users. This should look something like:

p = db.security.addPermission(name='Edit', klass='user', check=own_record,
    description="User is allowed to edit their own user details")

and should be modified to restrict the list of properties they are allowed to edit by adding the properties= section like:

p = db.security.addPermission(name='Edit', klass='user', check=own_record,
    properties=('username', 'password', 'address', 'realname', 'phone',
        'organisation', 'alternate_addresses', 'queries', 'timezone'),
    description="User is allowed to edit their own user details")

Most importantly the “roles” property should not be editable - thus not appear in that list of properties.

Grant the “Register” permission to the Anonymous role

A separate “Register” permission has been introduced to allow anonymous users to register. This means you will need to add the following to your tracker’s schema.py to add the permission and assign it to the Anonymous role (replacing any previously assigned “Create user” permission for the Anonymous role):

+db.security.addPermission(name='Register', klass='user',
+     description='User is allowed to register new user')

 # Assign the appropriate permissions to the anonymous user's Anonymous
 # Role. Choices here are:
 # - Allow anonymous users to register
-db.security.addPermissionToRole('Anonymous', 'Create', 'user')
+db.security.addPermissionToRole('Anonymous', 'Register', 'user')

The lines marked “+” should be added and lines marked “-” should be deleted (minus the “+”/”-” signs).

You should also modify the html/page.html template to change the permission tested there:

-tal:condition="python:request.user.hasPermission('Create', 'user')"
+tal:condition="python:request.user.hasPermission('Register', 'user')"

Generic class editor may now restore retired items

The instructions for doing so won’t be present in your tracker unless you copy the _generic.index.html template from the roundup distribution in share/roundup/templates/classic/html to your tracker’s html directory.

Customized MailGW Class

If you have customized the MailGW class in your tracker: The new MailGW class opens the database for each message in the method handle_message (instance.open) instead of passing the opened database as a parameter to the MailGW constructor. The old handle_message has been renamed to _handle_message. The new method opens the database and wraps the call to the old method into a try/finally.

Your customized MailGW class needs to mirror this behavior.

Fix the “remove” button in issue files and messages lists

The “remove” button(s) in the issue messages list needs to be altered. Find the following in your tracker’s html/issue.item.html template:

<td>
 <form style="padding:0" tal:condition="context/is_edit_ok"
       tal:attributes="action string:issue${context/id}">
  <input type="hidden" name="@remove@files" tal:attributes="value file/id">

and add method="POST" as shown below:

<td>
 <form style="padding:0" method="POST" tal:condition="context/is_edit_ok"
       tal:attributes="action string:issue${context/id}">
  <input type="hidden" name="@remove@files" tal:attributes="value file/id">

Then also find:

<td>
 <form style="padding:0" tal:condition="context/is_edit_ok"
       tal:attributes="action string:issue${context/id}">
  <input type="hidden" name="@remove@messages" tal:attributes="value msg/id">

and add method="POST" as shown below:

<td>
 <form style="padding:0" method="POST" tal:condition="context/is_edit_ok"
       tal:attributes="action string:issue${context/id}">
  <input type="hidden" name="@remove@messages" tal:attributes="value msg/id">

Fixing the “retire” button in user management list

Some previous versions of this upgrading document missed method="POST" in the change to the “retire” link in the user management list in section Migrating from 1.4.x to 1.4.7. Make sure the change is done as listed below in this document.

Grant the “retire” permission to users for their queries

Users will no longer be able to retire their own queries. To remedy this you will need to add the following to your tracker’s schema.py just under the line that grants them permission to edit their own queries:

  p = db.security.addPermission(name='Edit', klass='query', check=edit_query,
     description="User is allowed to edit their queries")
  db.security.addPermissionToRole('User', p)
+ p = db.security.addPermission(name='Retire', klass='query', check=edit_query,
+    description="User is allowed to retire their queries")
+ db.security.addPermissionToRole('User', p)
  p = db.security.addPermission(name='Create', klass='query',
     description="User is allowed to create queries")
  db.security.addPermissionToRole('User', p)

The lines marked “+” should be added, minus the “+” sign.

Fix the “retire” link in the users list for admin users

The “retire” link found in the file html/user.index.html:

<td tal:condition="context/is_edit_ok">
 <a tal:attributes="href string:user${user/id}?@action=retire&@template=index"
  i18n:translate="">retire</a>

Should be replaced with:

<td tal:condition="context/is_retire_ok">
   <form style="padding:0" method="POST"
         tal:attributes="action string:user${user/id}">
    <input type="hidden" name="@template" value="index">
    <input type="hidden" name="@action" value="retire">
    <input type="submit" value="retire" i18n:attributes="value">
   </form>

Fix for Python 2.6+ users

If you use Python 2.6 you should edit your tracker’s detectors/nosyreaction.py file to change:

import sets

at the top to:

from roundup.anypy.sets_ import set

and then all instances of sets.Set() to set() in the later code.

Trackers currently allowing HTML file uploading

Trackers which wish to continue to allow uploading of HTML content against issues will need to set a new configuration variable in the [web] section of the tracker’s config.ini file:

# Setting this option enables Roundup to serve uploaded HTML # file content as HTML. This is a potential security risk # and is therefore disabled by default. Set to ‘yes’ if you # trust all users uploading content to your tracker. # Allowed values: yes, no # Default: no allow_html_file = no

1.3.0 Web interface changes

Some of the HTML files in the “classic” and “minimal” tracker templates were changed to fix some bugs and clean them up. You may wish to compare them to the HTML files in your tracker and apply any changes.

1.2.0 Sorting and grouping by multiple properties

Starting with this version, sorting and grouping by multiple properties is possible. This means that request.sort and request.group are now lists. This is reflected in several places:

• renderWith now has list attributes for sort and group, where you previously wrote:

  renderWith(... sort=('-', 'activity'), group=('+', 'priority')

  you write now:

  renderWith(... sort=[('-', 'activity')], group=[('+', 'priority')]

• In templates that permit to edit sorting/grouping, request.sort and request.group are (possibly empty) lists. You can now sort and group by multiple attributes. For an example, see the classic template. You may want search for the variable n_sort which can be set to the number of sort/group properties.

• Templates that diplay new headlines for each group of items with equal group properties can now use the modified batch.propchanged method that can take several properties which are checked for changes. See the example in the classic template which makes use of batch.propchanged.

1.1.1 “Clear this message”

In 1.1.1, the standard page.html template includes a “clear this message” link in the green “ok” message bar that appears after a successful edit (or other) action.

To include this in your tracker, change the following in your page.html template:

<p tal:condition="options/ok_message | nothing" class="ok-message"
   tal:repeat="m options/ok_message" tal:content="structure m">error</p>

to be:

<p tal:condition="options/ok_message | nothing" class="ok-message">
  <span tal:repeat="m options/ok_message"
     tal:content="structure string:$m <br/ > " />
   <a class="form-small" tal:attributes="href request/current_url"
      i18n:translate="">clear this message</a>
</p>

If you implemented the “clear this message” in your 1.1.0 tracker, then you should change it to the above and it will work much better!

1.1 Login “For Session Only”

In 1.1, web logins are alive for the length of a session only, unless you add the following to the login form in your tracker’s page.html:

<input type="checkbox" name="remember" id="remember">
<label for="remember" i18n:translate="">Remember me?</label><br>

See the classic tracker page.html if you’re unsure where this should go.

1.1 Query Display Name

The dispname web variable has been renamed @dispname to avoid clashing with other variables of the same name. If you are using the display name feature, you will need to edit your tracker’s page.html and issue.index.html pages to change dispname to @dispname.

A side-effect of this change is that the renderWith method used in the home.html page may now take a dispname argument.

1.1 “Clear this message”

In 1.1, the standard page.html template includes a “clear this message” link in the green “ok” message bar that appears after a successful edit (or other) action.

To include this in your tracker, change the following in your page.html template:

<p tal:condition="options/ok_message | nothing" class="ok-message"
   tal:repeat="m options/ok_message" tal:content="structure m">error</p>

to be:

<p tal:condition="options/ok_message | nothing" class="ok-message">
  <span tal:repeat="m options/ok_message"
     tal:content="structure string:$m <br/ > " />
   <a class="form-small" tal:attributes="href string:issue${context/id}"
      i18n:translate="">clear this message</a>
</p>

1.0 New Query Permissions

New permissions are defined for query editing and viewing. To include these in your tracker, you need to add these lines to your tracker’s schema.py:

# Users should be able to edit and view their own queries. They should also
# be able to view any marked as not private. They should not be able to
# edit others' queries, even if they're not private
def view_query(db, userid, itemid):
    private_for = db.query.get(itemid, 'private_for')
    if not private_for: return True
    return userid == private_for
def edit_query(db, userid, itemid):
    return userid == db.query.get(itemid, 'creator')
p = db.security.addPermission(name='View', klass='query', check=view_query,
    description="User is allowed to view their own and public queries")
db.security.addPermissionToRole('User', p)
p = db.security.addPermission(name='Edit', klass='query', check=edit_query,
    description="User is allowed to edit their queries")
db.security.addPermissionToRole('User', p)
p = db.security.addPermission(name='Create', klass='query',
    description="User is allowed to create queries")
db.security.addPermissionToRole('User', p)

and then remove ‘query’ from the line:

# Assign the access and edit Permissions for issue, file and message
# to regular users now
for cl in 'issue', 'file', 'msg', 'query', 'keyword':

so it looks like:

for cl in 'issue', 'file', 'msg', 'keyword':

0.8.3 Nosy Handling Changes

A change was made to fix a bug in the nosyreaction.py standard detector. To incorporate this fix in your trackers, you will need to copy the nosyreaction.py file from the templates/classic/detectors directory of the source to your tracker’s templates directory.

If you have modified the nosyreaction.py file from the standard version, you will need to roll your changes into the new file.

0.8.0 Backend changes

Backends ‘bsddb’ and ‘bsddb3’ are removed. If you are using one of these, you must migrate to another backend before upgrading.

0.8.0 API changes

Class.safeget() was removed from the API. Test your item ids before calling Class.get() instead.

0.8.0 New tracker layout

The config.py file has been replaced by config.ini. You may use the roundup-admin command “genconfig” to generate a new config file:

roundup-admin genconfig <tracker home>/config.ini

and modify the values therein based on the contents of your old config.py. In most cases, the names of the config variables are the same.

The select_db.py file has been replaced by a file in the db directory called backend_name. As you might guess, this file contains just the name of the backend. To figure what the contents of yours should be, use the following table:

select_db.py contents	backend_name contents
from back_anydbm import ...	anydbm
from back_metakit import ...	metakit
from back_sqlite import ...	sqlite
from back_mysql import ...	mysql
from back_postgresql import ...	postgresql

The dbinit.py file has been split into two new files, initial_data.py and schema.py. The contents of this file are:

initial_data.py

You don’t need one of these as your tracker is already initialised.

schema.py

Copy the body of the def open(name=None) function from your old tracker’s dbinit.py file to this file. As the lines you’re copying aren’t part of a function definition anymore, one level of indentation needs to be removed (remove only the leading four spaces on each line).

The first few lines – those starting with from roundup.hyperdb import ... and the db = Database(config, name) line – don’t need to be copied. Neither do the last few lines – those starting with import detectors, down to return db inclusive.

You may remove the __init__.py module from the “detectors” directory as it is no longer used.

There’s a new way to write extension code for Roundup. If you have code in an interfaces.py file you should move it. See the customisation documentation for information about how extensions are now written. Note that some older trackers may use interfaces.py to customise the mail gateway behaviour. You will need to keep your interfaces.py file if this is the case.

0.8.0 Permissions Changes

The creation of a new item in the user interfaces is now controlled by the “Create” Permission. You will need to add an assignment of this Permission to your users who are allowed to create items. The most common form of this is the following in your schema.py added just under the current assignation of the Edit Permission:

for cl in 'issue', 'file', 'msg', 'query', 'keyword':
    p = db.security.getPermission('Create', cl)
    db.security.addPermissionToRole('User', p)

You will need to explicitly let anonymous users access the web interface so that regular users are able to see the login form. 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. It’s enabled by adding to your schema.py:

p = db.security.getPermission('Web Access')
db.security.addPermissionToRole('Anonymous', p)

Finally, you will need to enable permission for your users to edit their own details by adding the following to schema.py:

# Users should be able to edit their own details. Note that 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")
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)

0.8.0 Use of TemplatingUtils

If you used custom python functions in TemplatingUtils, they must be moved from interfaces.py to a new file in the extensions directory.

Each Function that should be available through TAL needs to be defined as a toplevel function in the newly created file. Furthermore you add an inititialization function, that registers the functions with the tracker.

If you find this too tedious, donfu wrote an automatic init function that takes an existing TemplatingUtils class, and registers all class methods that do not start with an underscore. The following hack should be placed in the extensions directory alongside other extensions:

class TemplatingUtils:
     # copy from interfaces.py

def init(tracker):
     util = TemplatingUtils()

     def setClient(tu):
         util.client = tu.client
         return util

     def execUtil(name):
         return lambda tu, *args, **kwargs: \
                 getattr(setClient(tu), name)(*args, **kwargs)

     for name in dir(util):
         if callable(getattr(util, name)) and not name.startswith('_'):
              tracker.registerUtil(name, execUtil(name))

0.8.0 Logging Configuration

See the administration guide for information about configuring the new logging implemented in 0.8.0.

0.7.3 Configuration

If you choose, you may specify the directory from which static files are served (those which use the URL component @@file). Currently the directory defaults to the TEMPLATES configuration variable. You may define a new variable, STATIC_FILES which overrides this value for static files.

0.7.2 DEFAULT_TIMEZONE is now required

The DEFAULT_TIMEZONE configuration variable is now required. Add the following to your tracker’s config.py file:

# You may specify a different default timezone, for use when users do not
# choose their own in their settings.
DEFAULT_TIMEZONE = 0            # specify as numeric hour offest

0.7.1 Permission assignments

If you allow anonymous access to your tracker, you might need to assign some additional View (or Edit if your tracker is that open) permissions to the “anonymous” user. To do so, find the code in your dbinit.py that says:

for cl in 'issue', 'file', 'msg', 'query', 'keyword':
    p = db.security.getPermission('View', cl)
    db.security.addPermissionToRole('User', p)
    p = db.security.getPermission('Edit', cl)
    db.security.addPermissionToRole('User', p)
for cl in 'priority', 'status':
    p = db.security.getPermission('View', cl)
    db.security.addPermissionToRole('User', p)

Add add a line:

db.security.addPermissionToRole('Anonymous', p)

next to the existing 'User' lines for the Permissions you wish to assign to the anonymous user.

0.7.0 Permission assignments

Due to a change in the rendering of web widgets, permissions are now checked on Classes where they previously weren’t (this is a good thing).

You will need to add some additional Permission assignments for your regular users, or some displays will break. After the following in your tracker’s dbinit.py:

# 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', p)
    p = db.security.getPermission('Edit', cl)
    db.security.addPermissionToRole('User', p)

add:

for cl in 'priority', 'status':
    p = db.security.getPermission('View', cl)
    db.security.addPermissionToRole('User', p)

0.7.0 Getting the current user id

The Database.curuserid attribute has been removed.

Any code referencing this attribute should be replaced with a call to Database.getuid().

0.7.0 ZRoundup changes

The templates in your tracker’s html directory will need updating if you wish to use ZRoundup. If you’ve not modified those files (or some of them), you may just copy the new versions from the Roundup source in the templates/classic/html directory.

If you have modified the html files, then you’ll need to manually edit them to change all occurances of special form variables from using the colon “:” special character to the at “@” special character. That is, variables such as:

:action :required :template :remove:messages ...

should become:

@action @required @template @remove@messages ...

Note that tal: statements are unaffected. So are TAL expression type prefixes such as python: and string:. Please ask on the roundup-users mailing list for help if you’re unsure.

0.7.0 Edit collision detection

Roundup now detects collisions with editing in the web interface (that is, two people editing the same item at the same time).

You must copy the _generic.collision.html file from Roundup source in the templates/classic/html directory. to your tracker’s html directory.

0.6.3 Configuration

You will need to copy the file:

templates/classic/detectors/__init__.py

to your tracker’s detectors directory, replacing the one already there. This fixes a couple of bugs in that file.

0.6.0 Configuration

Introduced EMAIL_FROM_TAG config variable. This value is inserted into the From: line of nosy email. If the sending user is “Foo Bar”, the From: line is usually:

"Foo Bar" <issue_tracker@tracker.example>

the EMAIL_FROM_TAG goes inside the “Foo Bar” quotes like so:

"Foo Bar EMAIL_FROM_TAG" <issue_tracker@tracker.example>

I’ve altered the mechanism in the detectors __init__.py module so that it doesn’t cross-import detectors from other trackers (if you run more than one in a single roundup-server). This change means that you’ll need to copy the __init__.py from roundup/templates/classic/detectors/__init__.py to your <tracker home>/detectors/__init__.py. Don’t worry, the “classic” __init__ is a one-size-fits-all, so it’ll work even if you’ve added/removed detectors.

0.6.0 Templating changes

The user.item template (in the tracker home “templates” directory) needs to have the following hidden variable added to its form (between the <form...> and </form> tags:

<input type="hidden" name=":template" value="item">

0.6.0 Form handling changes

Roundup’s form handling capabilities have been significantly expanded. This should not affect users of 0.5 installations - but if you find you’re getting errors from form submissions, please ask for help on the Roundup users mailing list:

http://lists.sourceforge.net/lists/listinfo/roundup-users

See the customisation doc section on Form Values for documentation of the new form variables possible.

0.6.0 Multilingual character set support

Added internationalization support. This is done via encoding all data stored in roundup database to utf-8 (unicode encoding). To support utf-8 in web interface you should add the folowing line to your tracker’s html/page and html/_generic.help files inside <head> tag:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Since latin characters in utf-8 have the same codes as in ASCII table, this modification is optional for users who use only plain latin characters.

After this modification, you will be able to see and enter any world character via web interface. Data received via mail interface also converted to utf-8, however only new messages will be converted. If your roundup database contains some of non-ASCII characters in one of 8-bit encoding, they will not be visible in new unicode environment. Some of such data (e.g. user names, keywords, etc) can be edited by administrator, the others (e.g. messages’ contents) is not editable via web interface. Currently there is no tool for converting such data, the only solution is to close appropriate old issues and create new ones with the same content.

0.6.0 User timezone support

From version 0.6.0 roundup supports displaying of Date data in user’ local timezone if he/she has provided timezone information. To make it possible some modification to tracker’s schema and HTML templates are required. First you must add string property ‘timezone’ to user class in dbinit.py like this:

user = Class(db, "user",
                username=String(),   password=Password(),
                address=String(),    realname=String(),
                phone=String(),      organisation=String(),
                alternate_addresses=String(),
                queries=Multilink('query'), roles=String(),
                timezone=String())

And second - html interface. Add following lines to $TRACKER_HOME/html/user.item template:

<tr>
 <th>Timezone</th>
 <td tal:content="structure context/timezone/field">timezone</td>
</tr>

After that all users should be able to provide their timezone information. Timezone should be a positive or negative integer - offset from GMT.

After providing timezone, roundup will show all dates values, found in web and mail interfaces in local time. It will also accept any Date info in local time, convert and store it in GMT.

0.6.0 Search page structure

In order to accomodate query editing the search page has been restructured. If you want to provide your users with query editing, you should update your search page using the macros detailed in the customisation doc section Searching on categories.

Also, the url field in the query class no longer starts with a ‘?’. You’ll need to remove this question mark from the url field to support queries. There’s a script in the “tools” directory called migrate-queries.py that should automatically change any existing queries for you. As always, make a backup of your database before running such a script.

0.6.0 Notes for metakit backend users

Roundup 0.6.0 introduced searching on ranges of dates and intervals. To support it, some modifications to interval storing routine were made. So if your tracker uses metakit backend and your db schema contains intervals property, searches on that property will not be accurate for db items that was stored before roundup’ upgrade. However all new records should be searchable on intervals.

It is possible to convert your database to new format: you can export and import back all your data (consult “Migrating backends” in “Maintenance” documentation). After this operation all your interval properties should become searchable.

Users of backends others than metakit should not worry about this issue.

0.5.0 Configuration

First up, rename your instance_config.py file to just config.py.

Then edit your tracker’s __init__.py module. It’ll currently look like this:

from instance_config import *
try:
    from dbinit import *
except ImportError:
    pass # in installdir (probably :)
from interfaces import *

and it needs to be:

import config
from dbinit import open, init
from interfaces import Client, MailGW

Due to the new templating having a top-level page that defines links for searching, indexes, adding items etc, the following variables are no longer used:

• HEADER_INDEX_LINKS
• HEADER_ADD_LINKS
• HEADER_SEARCH_LINKS
• SEARCH_FILTERS
• DEFAULT_INDEX
• UNASSIGNED_INDEX
• USER_INDEX
• ISSUE_FILTER

The new security implementation will require additions to the dbinit module, but also removes the need for the following tracker config variables:

• ANONYMOUS_ACCESS
• ANONYMOUS_REGISTER

but requires two new variables which define the Roles assigned to users who register through the web and e-mail interfaces:

• NEW_WEB_USER_ROLES
• NEW_EMAIL_USER_ROLES

in both cases, ‘User’ is a good initial setting. To emulate ANONYMOUS_ACCESS='deny', remove all “View” Permissions from the “Anonymous” Role. To emulate ANONYMOUS_REGISTER='deny', remove the “Web Registration” and/or the “Email Registration” Permission from the “Anonymous” Role. See the section on customising security in the customisation documentation for more information.

Finally, the following config variables have been renamed to make more sense:

• INSTANCE_HOME -> TRACKER_HOME
• INSTANCE_NAME -> TRACKER_NAME
• ISSUE_TRACKER_WEB -> TRACKER_WEB
• ISSUE_TRACKER_EMAIL -> TRACKER_EMAIL

0.5.0 Schema Specification

# WARNING: DO NOT EDIT THIS FILE!!!
from roundup.backends.back_anydbm import Database

# WARNING: DO NOT EDIT THIS FILE!!!
from roundup.backends.back_anydbm import Database, Class, FileClass, IssueClass

import instance_config
from roundup import roundupdb
from select_db import Database

from roundup.roundupdb import Class, FileClass

class Database(roundupdb.Database, select_db.Database):
    ''' Creates a hybrid database from:
         . the selected database back-end from select_db
         . the roundup extensions from roundupdb
    '''
    pass

class IssueClass(roundupdb.IssueClass):
    ''' issues need the email information
    '''
    pass

import config
from select_db import Database, Class, FileClass, IssueClass

msg = FileClass(db, "msg",
                author=Link("user"), recipients=Multilink("user"),
                date=Date(),         summary=String(),
                files=Multilink("file"),
                messageid=String(),  inreplyto=String())

msg = FileClass(db, "msg",
                author=Link("user", do_journal='no'),
                recipients=Multilink("user", do_journal='no'),
                date=Date(),         summary=String(),
                files=Multilink("file"),
                messageid=String(),  inreplyto=String())

issue = IssueClass(db, "issue",
                assignedto=Link("user"), topic=Multilink("keyword"),
                priority=Link("priority"), status=Link("status"))

issue = IssueClass(db, "issue", nosy=Multilink("user", do_journal='yes'),
                assignedto=Link("user"), topic=Multilink("keyword"),
                priority=Link("priority"), status=Link("status"))

user = Class(db, "user",
                username=String(),   password=Password(),
                address=String(),    realname=String(),
                phone=String(),      organisation=String(),
                alternate_addresses=String())
user.setkey("username")

query = Class(db, "query",
                klass=String(),     name=String(),
                url=String())
query.setkey("name")

# Note: roles is a comma-separated string of Role names
user = Class(db, "user",
                username=String(),   password=Password(),
                address=String(),    realname=String(),
                phone=String(),      organisation=String(),
                alternate_addresses=String(),
                queries=Multilink('query'), roles=String())
user.setkey("username")

import detectors
detectors.init(db)

return db

#
# SECURITY SETTINGS
#
# new permissions for this schema
for cl in 'issue', 'file', 'msg', 'user':
    db.security.addPermission(name="Edit", klass=cl,
        description="User is allowed to edit "+cl)
    db.security.addPermission(name="View", klass=cl,
        description="User is allowed to access "+cl)

# Assign the access and edit permissions for issue, file and message
# to regular users now
for cl in 'issue', 'file', 'msg':
    p = db.security.getPermission('View', cl)
    db.security.addPermissionToRole('User', p)
    p = db.security.getPermission('Edit', cl)
    db.security.addPermissionToRole('User', p)
# and give the regular users access to the web and email interface
p = db.security.getPermission('Web Access')
db.security.addPermissionToRole('User', p)
p = db.security.getPermission('Email Access')
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', p)

# Assign the appropriate permissions to the anonymous user's Anonymous
# Role. Choices here are:
# - Allow anonymous users to register through the web
p = db.security.getPermission('Web Registration')
db.security.addPermissionToRole('Anonymous', p)
# - Allow anonymous (new) users to register through the email gateway
p = db.security.getPermission('Email Registration')
db.security.addPermissionToRole('Anonymous', p)
# - Allow anonymous users access to the "issue" class of data
#   Note: this also grants access to related information like files,
#         messages, statuses etc that are linked to issues
#p = db.security.getPermission('View', 'issue')
#db.security.addPermissionToRole('Anonymous', p)
# - Allow anonymous users access to edit the "issue" class of data
#   Note: this also grants access to create related information like
#         files and messages etc that are linked to issues
#p = db.security.getPermission('Edit', 'issue')
#db.security.addPermissionToRole('Anonymous', p)

# oh, g'wan, let anonymous access the web interface too
p = db.security.getPermission('Web Access')
db.security.addPermissionToRole('Anonymous', p)

import detectors
detectors.init(db)

# schema is set up - run any post-initialisation
db.post_init()
return db

roundup-admin create user username=anonymous roles=Anonymous

python tools/fixroles.py -i <tracker home> fixroles

0.5.0 CGI interface changes

The CGI interface code was completely reorganised and largely rewritten. The end result is that this section of your tracker interfaces module will need changing from:

from roundup import cgi_client, mailgw
from roundup.i18n import _

class Client(cgi_client.Client):
    ''' derives basic CGI implementation from the standard module,
        with any specific extensions
    '''
    pass

to:

from roundup import mailgw
from roundup.cgi import client

class Client(client.Client):
    ''' derives basic CGI implementation from the standard module,
        with any specific extensions
    '''
    pass

You will also need to install the new version of roundup.cgi from the source cgi-bin directory if you’re using it.

0.5.0 HTML templating

You’ll want to make a backup of your current tracker html directory. You should then copy the html directory from the Roundup source “classic” template and modify it according to your local schema changes.

If you need help with the new templating system, please ask questions on the roundup-users mailing list (available through the roundup web page on sourceforge, http://www.roundup-tracker.org/.

0.5.0 Detectors

The nosy reactor has been updated to handle the tracker not having an “assignedto” property on issues. You may want to copy it into your tracker’s detectors directory. Chances are you’ve already fixed it though :)

0.4.2 Configuration

The USER_INDEX definition introduced in 0.4.1 was too restrictive in its allowing replacement of ‘assignedto’ with the user’s userid. Users must change the None value of ‘assignedto’ to ‘CURRENT USER’ (the string, in quotes) for the replacement behaviour to occur now.

The new configuration variables are:

• EMAIL_KEEP_QUOTED_TEXT
• EMAIL_LEAVE_BODY_UNCHANGED
• ADD_RECIPIENTS_TO_NOSY

See the sample configuration files in:

<roundup source>/roundup/templates/classic/instance_config.py

and:

<roundup source>/roundup/templates/extended/instance_config.py

and the customisation documentation for information on how they’re used.

0.4.2 Changes to detectors

You will need to copy the detectors from the distribution into your instance home “detectors” directory. If you used the classic schema, the detectors are in:

<roundup source>/roundup/templates/classic/detectors/

If you used the extended schema, the detectors are in:

<roundup source>/roundup/templates/extended/detectors/

The change means that schema-specific code has been removed from the mail gateway and cgi interface and made into auditors:

• nosyreactor.py has now got an updatenosy auditor which updates the nosy list with author, recipient and assignedto information.
• statusauditor.py makes the unread or resolved -> chatting changes and presets the status of an issue to unread.

There’s also a bug or two fixed in the nosyreactor code.

0.4.2 HTML templating changes

The link() htmltemplate function now has a “showid” option for links and multilinks. When true, it only displays the linked item id as the anchor text. The link value is displayed as a tooltip using the title anchor attribute. To use in eg. the superseder field, have something like this:

<td>
 <display call="field('superseder', showid=1)">
 <display call="classhelp('issue', 'id,title', label='list', width=500)">
 <property name="superseder">
  <br>View: <display call="link('superseder', showid=1)">
 </property>
</td>

The stylesheets have been cleaned up too. You may want to use the newer versions in:

<roundup source>/roundup/templates/<template>/html/default.css

0.4.1 Files storage

Messages and files from newly created issues will be put into subdierectories in thousands e.g. msg123 will be put into files/msg/0/msg123, file2003 will go into files/file/2/file2003. Previous messages are still found, but could be put into this structure.

0.4.1 Configuration

To allow more fine-grained access control, the variable used to check permission to auto-register users in the mail gateway is now called ANONYMOUS_REGISTER_MAIL rather than overloading ANONYMOUS_REGISTER. If the variable doesn’t exist, then ANONYMOUS_REGISTER is tested as before.

Configuring the links in the web header is now easier too. The following variables have been added to the classic instance_config.py:

HEADER_INDEX_LINKS   - defines the "index" links to be made available
HEADER_ADD_LINKS     - defines the "add" links
DEFAULT_INDEX        - specifies the index view for DEFAULT
UNASSIGNED_INDEX     - specifies the index view for UNASSIGNED
USER_INDEX           - specifies the index view for USER

See the <roundup source>/roundup/templates/classic/instance_config.py for more information - including how the variables are to be set up. Most users will just be able to copy the variables from the source to their instance home. If you’ve modified the header by changing the source of the interfaces.py file in the instance home, you’ll need to remove that customisation and move it into the appropriate variables in instance_config.py.

The extended schema has similar variables added too - see the source for more info.

0.4.1 Alternate E-Mail Addresses

If you add the property “alternate_addresses” to your user class, your users will be able to register alternate email addresses that they may use to communicate with roundup as. All email from roundup will continue to be sent to their primary address.

If you have not edited the dbinit.py file in your instance home directory, you may simply copy the new dbinit.py file from the core code. If you used the classic schema, the interfaces file is in:

<roundup source>/roundup/templates/classic/dbinit.py

If you used the extended schema, the file is in:

<roundup source>/roundup/templates/extended/dbinit.py

If you have modified your dbinit.py file, you need to edit the dbinit.py file in your instance home directory. Find the lines which define the user class:

user = Class(db, "msg",
                username=String(),   password=Password(),
                address=String(),    realname=String(),
                phone=String(),      organisation=String(),
                alternate_addresses=String())

You will also want to add the property to the user’s details page. The template for this is the “user.item” file in your instance home “html” directory. Similar to above, you may copy the file from the roundup source if you haven’t modified it. Otherwise, add the following to the template:

<display call="multiline('alternate_addresses')">

with appropriate labelling etc. See the standard template for an idea.

0.4.0 Message-ID and In-Reply-To addition

0.4.0 adds the tracking of messages by message-id and allows threading using in-reply-to. Most e-mail clients support threading using this feature, and we hope to add support for it to the web gateway. If you have not edited the dbinit.py file in your instance home directory, you may simply copy the new dbinit.py file from the core code. If you used the classic schema, the interfaces file is in:

<roundup source>/roundup/templates/classic/dbinit.py

If you used the extended schema, the file is in:

<roundup source>/roundup/templates/extended/dbinit.py

If you have modified your dbinit.py file, you need to edit the dbinit.py file in your instance home directory. Find the lines which define the msg class:

msg = FileClass(db, "msg",
                author=Link("user"), recipients=Multilink("user"),
                date=Date(),         summary=String(),
                files=Multilink("file"))

and add the messageid and inreplyto properties like so:

msg = FileClass(db, "msg",
                author=Link("user"), recipients=Multilink("user"),
                date=Date(),         summary=String(),
                files=Multilink("file"),
                messageid=String(),  inreplyto=String())

Also, configuration is being cleaned up. This means that your dbinit.py will also need to be changed in the open function. If you haven’t changed your dbinit.py, the above copy will be enough. If you have, you’ll need to change the line (round line 50):

db = Database(instance_config.DATABASE, name)

to:

db = Database(instance_config, name)

0.4.0 Configuration

TRACKER_NAME and EMAIL_SIGNATURE_POSITION have been added to the instance_config.py. The simplest solution is to copy the default values from template in the core source.

The mail gateway now checks ANONYMOUS_REGISTER to see if unknown users are to be automatically registered with the tracker. If it is set to “deny” then unknown users will not have access. If it is set to “allow” they will be automatically registered with the tracker.

0.4.0 CGI script roundup.cgi

The CGI script has been updated with some features and a bugfix, so you should copy it from the roundup cgi-bin source directory again. Make sure you update the ROUNDUP_INSTANCE_HOMES after the copy.

0.4.0 Nosy reactor

The nosy reactor has also changed - copy the nosyreactor.py file from the core source:

<roundup source>/roundup/templates/<template>/detectors/nosyreactor.py

to your instance home “detectors” directory.

0.4.0 HTML templating

The field() function was incorrectly implemented - links and multilinks now display as text fields when rendered using field(). To display a menu (drop- down or select box) you need to use the menu() function.

0.3.x Cookie Authentication changes

0.3.0 introduces cookie authentication - you will need to copy the interfaces.py file from the roundup source to your instance home to enable authentication. If you used the classic schema, the interfaces file is in:

<roundup source>/roundup/templates/classic/interfaces.py

If you used the extended schema, the file is in:

<roundup source>/roundup/templates/extended/interfaces.py

If you have modified your interfaces.Client class, you will need to take note of the login/logout functionality provided in roundup.cgi_client.Client (classic schema) or roundup.cgi_client.ExtendedClient (extended schema) and modify your instance code apropriately.

0.3.x Password encoding

This release also introduces encoding of passwords in the database. If you have not edited the dbinit.py file in your instance home directory, you may simply copy the new dbinit.py file from the core code. If you used the classic schema, the interfaces file is in:

<roundup source>/roundup/templates/classic/dbinit.py

If you used the extended schema, the file is in:

<roundup source>/roundup/templates/extended/dbinit.py

If you have modified your dbinit.py file, you may use encoded passwords:

1. Edit the dbinit.py file in your instance home directory a. At the first code line of the open() function:

    from roundup.hyperdb import String, Date, Link, Multilink
   
   alter to include Password, as so::
   
    from roundup.hyperdb import String, Password, Date, Link, Multilink

   2. Where the password property is defined (around line 66):

      user = Class(db, "user",
                      username=String(),   password=String(),
                      address=String(),    realname=String(),
                      phone=String(),      organisation=String())
      user.setkey("username")
      

      alter the “password=String()” to “password=Password()”:

      user = Class(db, "user",
                      username=String(),   password=Password(),
                      address=String(),    realname=String(),
                      phone=String(),      organisation=String())
      user.setkey("username")
      

2. Any existing passwords in the database will remain cleartext until they are edited. It is recommended that at a minimum the admin password be changed immediately:

   roundup-admin -i <instance home> set user1 password=<new password>

0.3.x Configuration

FILTER_POSITION, ANONYMOUS_ACCESS, ANONYMOUS_REGISTER have been added to the instance_config.py. Simplest solution is to copy the default values from template in the core source.

MESSAGES_TO_AUTHOR has been added to the IssueClass in dbinit.py. Set to ‘yes’ to send nosy messages to the author. Default behaviour is to not send nosy messages to the author. You will need to add MESSAGES_TO_AUTHOR to your dbinit.py in your instance home.

0.3.x CGI script roundup.cgi

There have been some structural changes to the roundup.cgi script - you will need to install it again from the cgi-bin directory of the source distribution. Make sure you update the ROUNDUP_INSTANCE_HOMES after the copy.