====================================== 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. **IMPORTANT** The v1.5.x releases of Roundup will be the last to support Python v2.5. Support for Python v2.5 will be dropped with the v1.6 release of Roundup, at which point users will need to run Roundup using either Python v2.6 or v2.7. Contents: .. contents:: :local: Migrating from 1.5.1 to 1.6.0 ============================= Fix for path traversal changes template resolution -------------------------------------------------- The templates in the tracker's html subdirectory must not be symbolic links that lead outside of the html directory. If you don't use symbolic links for templates in your html subdirectory you don't have to make any changes. Otherwise you need to replace the symbolic links with hard links to the files or replace the symbolic links with the files. This is a side effect of fixing a path traversal security issue. The security issue required a directory with a specific unusual name. This made it difficult to exploit. However allowing the use of subdirectories to organize the templates required that it be fixed. Database back end specified in config.ini ----------------------------------------- The ``db/backend_name`` file is no longer used to configure the database backend being used for a tracker. The backend is now configured in the ``config.ini`` file using the ``backend`` option located in the ``[rdbms]`` section. For example if ``db/backend_name`` file contains ``sqlite``, a new entry in the tracker's ``config.ini`` will need to be created:: [rdbms] ... # Database backend. # Default: backend = sqlite Once the ``config.ini`` file has been updated with the new ``backend`` option, you can safely delete the ``db/backend_name`` file. Note: the ``backend_name`` file may be located in a directory other than ``db/`` if you have configured the ``database`` option in the ``[main]`` section of the ``config.ini`` file to be something other than ``db``. New config file option 'indexer' added -------------------------------------- With support for the Whoosh indexer, a new config file option has been added. You can force Roundup to use a particular text indexer by setting this value in the [main] section of the tracker's ``config.ini`` file (usually placed right before indexer_stopwords):: [main] ... # Force Roundup to use a particular text indexer. # If no indexer is supplied, the first available indexer # will be used in the following order: # Possible values: xapian, whoosh, native (internal). indexer = Stemming improved in Xapian Indexer ----------------------------------- Stemming allows a search for "silent" also match silently. The Porter stemmer in Xapian works with lowercase English text. In this release we lowercase the documents as they are put into the indexer. This means capitalization is not preserved, but produces more hits by using the stemmer. You will need to do a roundup-admin reindex if you are using the Xapian full text indexer on your tracker. New config file option 'replyto_address' added ---------------------------------------------- A new config file option has been added to let you control the Reply-To header on nosy messages. Edit your tracker's ``config.ini`` and place the following after the email entry in the tracker section:: [tracker] ... # Controls the reply-to header address used when sending # nosy messages. # If the value is unset (default) the roundup tracker's # email address (above) is used. # If set to "AUTHOR" then the primary email address of the # author of the change will be used as the reply-to # address. This allows email exchanges to occur outside of # the view of roundup and exposes the address of the person # who updated the issue, but it could be useful in some # unusual circumstances. # If set to some other value, the value is used as the reply-to # address. It must be a valid RFC2822 address or people will not be # able to reply. # Default: replyto_address = Login from a search or after logout works better ------------------------------------------------ The login form has been improved to work with some back end code changes. Now when a user logs in they stay on the same page where they started the login. To make this work, you must change the tal that is used to set the ``__came_from`` form variable. Note that the url assigned to __came_from must be url encoded/quoted and be under the tracker's base url. If the base_url uses http, you can set the url to https. Replace the existing code in the tracker's html/page.html page that looks similar to (look for name="__came_from"):: with the following:: Now search backwards for the nearest form statement before the code that sets __came_from. If it looks like::
replace it with:: or with:: the important part is that the action field **must not** include any query parameters ('#' includes query params). Option to make adding multiple keywords more convenient ------------------------------------------------------- In the classic tracker, after adding a new keyword you are redirected to the page for the new keyword so you can change the keyword's name. This is usually not desirable as you usually correctly set the keyword's name when creating the keyword. The new classic tracker has a new checkbox (checked by default) that keeps you on the same page so you can add a new keywords one after the other. To add this to your own tracker, add the following code (prefixed with a +) after the entry box for the new keyword:: Keyword name + + + If we get here and do not have an id, we are creating a new + keyword. It would be nice to provide some mechanism to + determine the preferred state of the "Continue adding keywords" + checkbox. By default it is enabled. + + + + Note remove the leading '+' when adding this to the templates. The key component here is support for the '__redirect_to' query property. It is a url which can be used when creating any new item (issue, user, keyword ....). It controls the next page displayed after creating the item. If '__redirect_to' is not set, then you end up on the page for the newly created item. The url value assigned to __redirect_to must be under the tracker's base url and must be properly url encoded. Helper popups trigger change events on the original page -------------------------------------------------------- The helper popups used to set dates (from a calendar), change lists of users or lists of issues did not notify the browser that the fields had been changed. This release adds code to trigger the change event. To add the change event to the calendar popup, you don't need to do any changes to the tracker. It is all done in the roundup python code in templating.py. To add the change event when updating users using the help-submit template, copy share/roundup/templates/devel/html/_generic.help-submit.html and replace your tracker's html/_generic.help-submit.html. If you have done local changes to this file, change your file to include the code that defines the onclick event for the input field with id="btn_apply". To add the change event when updating lists of issues copy share/roundup/templates/devel/html/help_controls.js to your tracer's html directory. If you have made local changes to the javascript file, merge the two if/else blocks labeled:: /* trigger change event on the field we changed */ into your help_controls.js html/_generic.404.html in trackers use page template ---------------------------------------------------- The original generic 404 error pages for many trackers did not use the standard page layout. This change replaces the html/_generic.404.html page with one that uses the page template. If your deployed tracker is based on: classic, minimal, responsive or devel templates and has not changed the html/_generic.404.html file, you can copy in the new file to get this additional functionality. Organize templates into subdirectories -------------------------------------- The @template parameter to the web interface allows the use of subdirectories. So a setting of @template=view/view for an issue would use the template in the tracker's html/view/issue.view.html. Similarly for a caller class, you could put all the templates under the html/caller directory with names like: html/caller/caller.item.html, html/caller/caller.index.html etc. You may want to symbolically link the html/_generic* templates into your subdirectory so that missing templates (e.g. a missing caller.edit.html template) can be satisfied by the _generic.edit.html template. Properly quote query dispname (displayed name) in page.html ----------------------------------------------------------- A new method has been added to HTMLStringProperty called url_quote. The default templates have been updated to use this in the "Your Query" section of the trackers html/page.html file. You will want to change your template. Lines starting with - are the original line and you want to change it to match the line starting with the + (remove the + from the line):: - link
 Find the tal:repeat line that loops over all queries. Then change the value assigned to @dispname in the href attribute from ${qs/name} to ${qs/name/url_quote}. Note that you should *not* change the value for tal:content. Schema change to allow "Show Unassigned" issues link to work for Anonymous user ------------------------------------------------------------------------------- In this release the anonymous user is allowed to search the user class. The following was added to the schema for all templates that provide the search option:: p = db.security.addPermission(name='Search', klass='user') db.security.addPermissionToRole ('Anonymous', p) If you are running a tracker that **does not** allow read access for anonymous, you should remove this entry as it can be used to perform a username guessing attack against a roundup install. Improvements in Classic Tracker query.edit.html template -------------------------------------------------------- There is a new query editing template included in the distribution at: ``share/roundup/templates/classic/html/query.edit.html`` This template fixes: * public query could not be removed from "Your Queries" once it was added. Trying to do so would cause a permissions error. * private yes/no dropdown always showed "yes" regardless of underlying state * query Delete button did not work. * same query being displayed multiple times It also adds: * the table layout displays queries created by the user first, then available public queries. * public query owners are shown * better support for deleted queries. When a query is deleted, it is still available for those who added it to their query list. If you are the query owner, you can restore (undelete) the query. If you are not the owner you can remove it from your query list. (If a query is deleted and nobody had it in their query list, it will not show up in the "Active retired queries" section. You will have to use the class editor or roundup_admin command line to restore it.) * notifies the user that delete/restore requires javascript. It always did, but that requirement wasn't displayed. To use the new template, you must add Restore permission on queries to allow the user to restore queries (see below). If you have not modified the query.edit.html template in your tracker, you should be able to copy the new version from the location above. Otherwise you will have to merge the changes into your modified template. You will need to add the query Restore permission for the User role to your tracker's schema.py file. Place it right after the query retire permission for the user role. After the change it should look like:: 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='Restore', klass='query', check=edit_query, description="User is allowed to restore their queries") db.security.addPermissionToRole('User', p) where the last three lines are the ones you need to add. Enhancement to check command for Permissions -------------------------------------------- A new form of check function is permitted in permission definitions. The three argument form is still supported and will work the same as it always has (although it may be depricated in the future). If the check function is defined as:: check(db, userid, itemid, **ctx) the ctx variable will have the context to use when determining access rights:: ctx['property'] the name of the property being checked or None if it's a class check. ctx['classname'] the name of the class that is being checked (issue, query ....). ctx['permission'] the name of the permission (e.g. View, Edit...). This should make defining complex permissions much easier. Consider:: def issue_private_access(db, userid, itemid, **ctx): if not db.issue.get(itemid, 'private'): # allow access to everything if not private return True # It is a private issue hide nosy list # Note that the nosy property *must* be listed # in permissions argument to the addPermission # definition otherwise this check command # is not run. if ctx['property'] == 'nosy': return False # deny access to this property # allow access for editing, viewing etc. of the class return True e = db.security.addPermission(name='Edit', klass='issue', check=issue_private_access, properties=['nosy'], description="Edit issue checks") It is suggested that you change your checks to use the ``**ctx`` parameter. This is expected to be the preferred form in the future. You do not need to use the ``ctx`` parameter in the function if you do not need it. Improve query editing --------------------- The query editing interface will now report an error if the user creates a new query that they are already using. By default the query editing page (issue.search.html) displays the index page when the search is triggered. Since the user expects to see the results of the query, this is usually the right thing. But now that the code properly checks for duplicate search names, the user should stay on the search page if there is an error. To add this to your existing index.search.html page, add the following line after the hidden field @old-queryname: With this addition, the index template is displayed if there is no error, and the user stays on the search template if there is an error. Migrating from 1.5.0 to 1.5.1 ============================= User data visibility -------------------- For security reasons you should change the permissions on the user class. We previously shipped a configuration that allowed users to see too many of other users details, including hashed passwords under certain circumstances. In schema.py in your tracker, replace the line:: db.security.addPermissionToRole('User', 'View', 'user') with:: p = db.security.addPermission(name='View', klass='user', properties=('id', 'organisation', 'phone', 'realname', 'timezone', 'username')) db.security.addPermissionToRole('User', p) Note that this removes visibility of user emails, if you want emails to be visible you can add 'address' and 'alternate_addresses' to the list above. XSS protection for custom actions --------------------------------- If you have defined your own cgi actions in your tracker instance (e.g. in a custom ``extensions/spambayes.py`` file) you need to modify all cases where client.error_message or client.ok_message are modified directly. Instead of:: self.client.ok_message.append(...) you need to call:: self.client.add_ok_message(...) and the same for:: self.client.error_message.append(...) vs.:: self.client.add_error_message(...) The new calls escape the passed string by default and avoid XSS security issues. Migrating from 1.4.20 to 1.4.21 =============================== The ``_generic.calendar.html`` page of the instance has been updated to include ````. This prevents robots to follow all the links in the calendar. If you haven't modified the page on your local instance, you can simply replace it with the one in ``share/roundup/templates/classic/html/_generic.calendar.html``; if you did, you can add the tag manually. See issue2550765 and changeset a099ff2ceff3. If you are using the xml-rpc interface, there is a change in accessing it. You can not send text/xml data to any roundup url and get a response, you must use the /xmlrpc url. For example, if you used to send your xmlrpc request to: http://myroundup.com/roundup you need to change the url to read: http://myroundup.com/roundup/xmlrpc to invoke the xmlrpc handler. This allows us to send xml data to roundup for other handlers (e.g. REST, SOAP ...) in the future. Migrating from 1.4.19 to 1.4.20 =============================== Roundup used to allow certain HTML-Tags in OK- and Error-messages. Since these messages are passed via the URL (due to roundup redirecting after an edit), we did have security-issues (see issue2550724). If you have customized the OK or Error messages in your roundup-installation and you were using features like bold or italic in the message, you will have to do without this highlighting and remove HTML tags from messages. If you were using
tags for multi-line messages, you now should use newlines instead, these will be replaced with
during formatting. Note that the previous implementation also allowed links inside messages. Since these links could be set by an attacker, no links in roundup messages are supported anymore. This does *not* affect the "clear this message" link in OK-messages as it is generated by the template and is not part of the OK-message. If you have not modified any roundup messages, you need not do anything, the templates shipped with roundup did not use HTML tags in messages for highlighting. Migrating from 1.4.17 to 1.4.18 =============================== There was a bug in 1.4.17 where files were unlinked from issues if a mail without attachment was received via the mail interface. The following script will list likely issues being affected by the bug. The date in the script is the date of the 1.4.17 release. If you have installed 1.4.17 later than this date, you can change the date appropriately to your installation date. Run the script in the directory of your tracker:: #!/usr/bin/python import os from roundup import instance from roundup.date import Date dir = os.getcwd () tracker = instance.open (dir) db = tracker.open ('admin') # you may want to change this to your install date to find less candidates last_release = Date('2011-05-13') affected = {} for i in db.issue.getnodeids(): for j in db.issue.history(i): if i in affected: break if j[1] < last_release or j[3] != 'set' or 'files' not in j[4]: continue for op, p in j[4]['files']: if op == '-': affected [i] = 1 break print ', '.join(sorted(affected.iterkeys())) To find out which files where attached before you can look in the history of the affected issue. For fixing issues you can re-attach the files in question using the "set" command of roundup-admin, e.g., if the list of files attached to an issue should be files 5, 17, 23 for issue42 you will set this using roundup-admin -i /path/to/your/tracker set issue42 files=5,17,23 Migrating from 1.4.x to 1.4.17 ============================== There is a new config-option `migrate_passwords` in section `web` to auto-migrate passwords at web-login time to a more secure storage scheme. Default for the new option is "yes" so if you don't want that passwords are auto-migrated to a more secure password scheme on user login, set this to "no" before running your tracker(s) after the upgrade. The standalone roundup-server now defaults to listening on localhost (no longer on all network interfaces). This will not affect you if you're already using a configuration file for roundup-server. If you are using an empty setting for the `host` parameter in the config-file you should explicitly put 0.0.0.0 there as the use of an empty string to specify listening to all interfaces is deprecated and will go away in a future version. If you are starting the server without a configuration file and want to explicitly listen to all network interface, you should specify the -n option with the address `0.0.0.0`. Searching now requires either read-permission without a check method, or you will have to add a "Search" permission for a class or a list of properties for a class (if you want to allow searching). For the classic template (or other templates derived from it) you want to add the following lines to your `schema.py` file:: p = db.security.addPermission(name='Search', klass='query') db.security.addPermissionToRole('User', p) This is needed, because for the `query` class users may view only their own queries (or public queries). This is implemented with a `check` method, therefore the default search permissions will not allow searching and you'll have to add an explicit search permission. If you have modified your schema, you can check if you're missing any search permissions with the following script, run it in your tracker directory, it will list for each Class and Property the roles that may search for this property:: #!/usr/bin/python import os from roundup import instance tracker = instance.open(os.getcwd ()) db = tracker.open('admin') for cl in sorted(db.getclasses()): print "Class:", cl for p in sorted(db.getclass(cl).properties.keys()): print " Property:", p roles = [] for role in sorted(db.security.role.iterkeys()): if db.security.roleHasSearchPermission(cl,p,role): roles.append(role) print " roles may search:", ', '.join(roles) 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 ------------------------------------ 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
+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). 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. 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.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. 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:: and add ``method="POST"`` as shown below:: Then also find:: and add ``method="POST"`` as shown below:: 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. Migrating from 1.4.x to 1.4.7 ============================= Several security issues were addressed in this release. Some aspects of your trackers may no longer function depending on your local customisations. Core functionality that will need to be modified: 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``:: retire Should be replaced with::
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 Migrating from 1.4.2 to 1.4.3 ============================= If you are using the MySQL backend you will need to replace some indexes that may have been created by version 1.4.2. You should to access your MySQL database directly and remove any indexes with a name ending in "_key_retired_idx". You should then re-add them with the same spec except the key column name needs a size. So an index on "_user (__retired, _name)" should become "_user (__retired, _name(255))". Migrating from 1.4.x to 1.4.2 ============================= You should run the "roundup-admin migrate" command for your tracker once you've installed the latest codebase. Do this before you use the web, command-line or mail interface and before any users access the tracker. This command will respond with either "Tracker updated" (if you've not previously run it on an RDBMS backend) or "No migration action required" (if you have run it, or have used another interface to the tracker, or are using anydbm). It's safe to run this even if it's not required, so just get into the habit. Migrating from 1.3.3 to 1.4.0 ============================= Value of the "refwd_re" tracker configuration option (section "mailgw") is treated as UTF-8 string. In previous versions, it was ISO8859-1. If you have running trackers based on the classic template, please update the messagesummary detector as follows:: --- detectors/messagesummary.py 17 Apr 2003 03:26:38 -0000 1.1 +++ detectors/messagesummary.py 3 Apr 2007 06:47:21 -0000 1.2 @@ -8,7 +8,7 @@ if newvalues.has_key('summary') or not newvalues.has_key('content'): return - summary, content = parseContent(newvalues['content'], 1, 1) + summary, content = parseContent(newvalues['content'], config=db.config) newvalues['summary'] = summary In the latest version we have added some database indexes to the SQL-backends (mysql, postgresql, sqlite) for speeding up building the roundup-index for full-text search. We recommend that you create the following database indexes on the database by hand:: CREATE INDEX words_by_id ON __words (_textid); CREATE UNIQUE INDEX __textids_by_props ON __textids (_class, _itemid, _prop); Migrating from 1.2.x to 1.3.0 ============================= 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. Migrating from 1.1.2 to 1.2.0 ============================= 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``. Migrating from 1.1.0 to 1.1.1 ============================= 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::

error

to be::

clear this message

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! Migrating from 1.0.x to 1.1.0 ============================= 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``::
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::

error

to be::

clear this message

Migrating from 0.8.x to 1.0 =========================== 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': Migrating from 0.8.0 to 0.8.3 ============================= 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. Migrating from 0.7.1 to 0.8.0 ============================= You *must* fully uninstall previous Roundup version before installing Roundup 0.8.0. If you don't do that, ``roundup-admin install`` command may fail to function properly. 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 /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. Migrating from 0.7.2 to 0.7.3 ============================= 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. Migrating from 0.7.0 to 0.7.2 ============================= 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 Migrating from 0.7.0 to 0.7.1 ============================= 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. Migrating from 0.6 to 0.7 ========================= 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. Migrating from 0.6.x to 0.6.3 ============================= 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. Migrating from 0.5 to 0.6 ========================= 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" the EMAIL_FROM_TAG goes inside the "Foo Bar" quotes like so:: "Foo Bar EMAIL_FROM_TAG" 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 /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 ```` and ```` tags:: 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. __ customizing.html#form-values 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 tag:: 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:: Timezone timezone 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`__. __ customizing.html#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. Migrating from 0.4.x to 0.5.0 ============================= This has been a fairly major revision of Roundup: 1. Brand new, much more powerful, flexible, tasty and nutritious templating. Unfortunately, this means all your current templates are useless. Hopefully the new documentation and examples will be enough to help you make the transition. Please don't hesitate to ask on roundup-users for help (or complete conversions if you're completely stuck)! 2. The database backed got a lot more flexible, allowing Metakit and SQL databases! The only decent SQL database implemented at present is sqlite, but others shouldn't be a whole lot more work. 3. A brand new, highly flexible and much more robust security system including a system of Permissions, Roles and Role assignments to users. You may now define your own Permissions that may be checked in CGI transactions. 4. Journalling has been made less storage-hungry, so has been turned on by default *except* for author, recipient and nosy link/unlink events. You are advised to turn it off in your trackers too. 5. We've changed the terminology from "instance" to "tracker", to ease the learning curve/impact for new users. 6. Because of the above changes, the tracker configuration has seen some major changes. See below for the details. Please, **back up your database** before you start the migration process. This is as simple as copying the "db" directory and all its contents from your tracker to somewhere safe. 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 -------------------------- 0.5.0 Database backend changes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Your select_db module in your tracker has changed a fair bit. Where it used to contain:: # WARNING: DO NOT EDIT THIS FILE!!! from roundup.backends.back_anydbm import Database it must now contain:: # WARNING: DO NOT EDIT THIS FILE!!! from roundup.backends.back_anydbm import Database, Class, FileClass, IssueClass Yes, I realise the irony of the "DO NOT EDIT THIS FILE" statement :) Note the addition of the Class, FileClass, IssueClass imports. These are very important, as they're going to make the next change work too. You now need to modify the top of the dbinit module in your tracker from:: 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 to:: import config from select_db import Database, Class, FileClass, IssueClass Yes, remove the Database and IssueClass definitions and those other imports. They're not needed any more! Look for places in dbinit.py where ``instance_config`` is used too, and rename them ``config``. 0.5.0 Journalling changes ~~~~~~~~~~~~~~~~~~~~~~~~~ Journalling has been optimised for storage. Journalling of links has been turned back on by default. If your tracker has a large user base, you may wish to turn off journalling of nosy list, message author and message recipient link and unlink events. You do this by adding ``do_journal='no'`` to the Class initialisation in your dbinit. For example, your *msg* class initialisation probably looks like this:: msg = FileClass(db, "msg", author=Link("user"), recipients=Multilink("user"), date=Date(), summary=String(), files=Multilink("file"), messageid=String(), inreplyto=String()) to turn off journalling of author and recipient link events, add ``do_journal='no'`` to the ``author=Link("user")`` part of the statement, like so:: 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()) Nosy list link event journalling is actually turned off by default now. If you want to turn it on, change to your issue class' nosy list, change its definition from:: issue = IssueClass(db, "issue", assignedto=Link("user"), topic=Multilink("keyword"), priority=Link("priority"), status=Link("status")) to:: issue = IssueClass(db, "issue", nosy=Multilink("user", do_journal='yes'), assignedto=Link("user"), topic=Multilink("keyword"), priority=Link("priority"), status=Link("status")) noting that your definition of the nosy Multilink will override the normal one. 0.5.0 User schema changes ~~~~~~~~~~~~~~~~~~~~~~~~~ Users have two more properties, "queries" and "roles". You'll have something like this in your dbinit module now:: user = Class(db, "user", username=String(), password=Password(), address=String(), realname=String(), phone=String(), organisation=String(), alternate_addresses=String()) user.setkey("username") and you'll need to add the new properties and the new "query" class to it like so:: 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") The "queries" property is used to store off the user's favourite database queries. The "roles" property is explained below in `0.5.0 Security Settings`_. 0.5.0 Security Settings ~~~~~~~~~~~~~~~~~~~~~~~ See the `security documentation`_ for an explanation of how the new security system works. In a nutshell though, the security is handled as a four step process: 1. Permissions are defined as having a name and optionally a hyperdb class they're specific to, 2. Roles are defined that have one or more Permissions, 3. Users are assigned Roles in their "roles" property, and finally 4. Roundup checks that users have appropriate Permissions at appropriate times (like editing issues). Your tracker dbinit module's *open* function now has to define any Permissions that are specific to your tracker, and also the assignment of Permissions to Roles. At the moment, your open function ends with:: import detectors detectors.init(db) return db and what we need to do is insert some commands that will set up the security parameters. Right above the ``import detectors`` line, you'll want to insert these lines:: # # 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) Note in the comments there the places where you might change the permissions to restrict users or grant users more access. If you've created additional classes that users should be able to edit and view, then you should add them to the "new permissions for this schema" section at the start of the security block. Then add them to the "Assign the access and edit permissions" section too, so people actually have the new Permission you've created. One final change is needed that finishes off the security system's initialisation. We need to add a call to ``db.post_init()`` at the end of the dbinit open() function. Add it like this:: import detectors detectors.init(db) # schema is set up - run any post-initialisation db.post_init() return db You may verify the setup of Permissions and Roles using the new "``roundup-admin security``" command. 0.5.0 User changes ~~~~~~~~~~~~~~~~~~ To support all those schema changes, you'll need to massage your user database a little too, to: 1. make sure there's an "anonymous" user - this user is mandatory now and is the one that unknown users are logged in as. 2. make sure all users have at least one Role. If you don't have the "anonymous" user, create it now with the command:: roundup-admin create user username=anonymous roles=Anonymous making sure the capitalisation is the same as above. Once you've done that, you'll need to set the roles property on all users to a reasonable default. The admin user should get "Admin", the anonymous user "Anonymous" and all other users "User". The ``fixroles.py`` script in the tools directory will do this. Run it like so (where python is your python 2+ binary):: python tools/fixroles.py -i 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 :) Migrating from 0.4.1 to 0.4.2 ============================= 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/templates/classic/instance_config.py and:: /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/templates/classic/detectors/ If you used the extended schema, the detectors are in:: /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::
View: The stylesheets have been cleaned up too. You may want to use the newer versions in:: /roundup/templates/