======================================
Upgrading to newer versions of Roundup
======================================
Please read each section carefully and edit your tracker home files
accordingly. Note that there is information about upgrade procedures in the
`administration guide`_.
If a specific version transition isn't mentioned here (eg. 0.6.7 to 0.6.8)
then you don't need to do anything. If you're upgrading from 0.5.6 to
0.6.8 though, you'll need to check the "0.5 to 0.6" and "0.6.x to 0.6.3"
steps.
.. contents::
Migrating from 1.4.x to 1.4.12
==============================
Item creation now checks the "Create" permission instead of the "Edit"
permission for individual properties. If you have modified your tracker
permissions from the default distribution, you should check that
"Create" permissions exist for all properties you want users to be able
to create.
Fixing some potential security holes
------------------------------------
Some HTML templates were found to have formatting security problems:
``html/page.html``::
-tal:replace="request/user/username">username
+tal:replace="python:request.user.username.plain(escape=1)">username
``html/_generic.help-list.html``::
-tal:content="structure python:item[prop]">
+tal:content="python:item[prop]">
The lines marked "+" should be added and lines marked "-" should be
deleted (minus the "+"/"-" signs).
Migrating from 1.4.x to 1.4.11
==============================
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.py`` 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.
Migrating from 1.4.x to 1.4.9
=============================
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::