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 were the last to support Python v2.5 and v2.6. Starting with the v1.6 releases of Roundup Python version 2.7 that is newer than 2.7.2 is required to run roundup. Starting with Roundup version 2.0.0 we also support Python 3 versions newer than 3.4.
Contents:
- Migrating from 2.1.0 to 2.x.y
- Update your
config.ini
(required) - Rdbms version change from 6 to 7 (required)
- Check new login_empty_passwords setting (required)
- Check allowed_api_origins setting (optional)
- Check compression settings (optional)
- Search added to user index page (optional)
- Enhanced full-text search (optional)
- Adding error reporting templates (optional)
- Change passwords using crypt module (optional)
- Update your
- Migrating from 2.0.0 to 2.1.0
- Migrating from 1.6.X to 2.0.0
- Python 2 MYSQL users MUST READ
- Upgrade tracker’s config.ini file
- Python 3 support
- Rate Limit New User Registration
- PGP mail processing
- MySQL client module
- XMLRPC Access Role
- New values for db.tx_Source
- CSV export changes
- Update userauditor.py to restrict usernames
- Consider reindexing if you use European languages
- Merge improvements in statusauditor.py
- Responsive template changes
- Jinja template changes
- Migrating from 1.5.1 to 1.6.0
- Update tracker config file
- Make sure that user can view labelprop on classes (REQUIRED)
- Cross Site Request Forgery Detection Added
- Support for SameSite cookie option for session cookie
- Fix for path traversal changes template resolution
- Database back end specified in config.ini (REQUIRED)
- New config file option ‘indexer’ added
- Stemming improved in Xapian Indexer
- New config file option ‘replyto_address’ added
- Login from a search or after logout works better (REQUIRED)
- Option to make adding multiple keywords more convenient
- Helper popups trigger change events on the original page
- html/_generic.404.html in trackers use page template
- Organize templates into subdirectories
- Properly quote query dispname (displayed name) in page.html
- Allow “Show Unassigned” issues link to work for Anonymous user
- Improvements in Classic Tracker query.edit.html template
- Fix security issues in query.item.html template
- Enhancement to check command for Permissions
- Changes to property permissions
- Improve query editing
- New -L (loghttpvialogger) option to roundup-server
- Migrating from 1.5.0 to 1.5.1
- Migrating from 1.4.20 to 1.4.21
- Migrating from 1.4.19 to 1.4.20
- Migrating from 1.4.17 to 1.4.18
- Migrating from 1.4.x to 1.4.17
- Migrating from 1.4.x to 1.4.12
- Migrating from 1.4.x to 1.4.11
- Migrating from 1.4.x to 1.4.9
- Migrating from 1.4.x to 1.4.7
- Migrating from 1.4.2 to 1.4.3
- Migrating from 1.4.x to 1.4.2
- Migrating from 1.3.3 to 1.4.0
- Migrating from 1.2.x to 1.3.0
- Migrating from 1.1.2 to 1.2.0
- Migrating from 1.1.0 to 1.1.1
- Migrating from 1.0.x to 1.1.0
- Migrating from 0.8.x to 1.0
- Migrating from 0.8.0 to 0.8.3
- Migrating from 0.7.1 to 0.8.0
- Migrating from 0.7.2 to 0.7.3
- Migrating from 0.7.0 to 0.7.2
- Migrating from 0.7.0 to 0.7.1
- Migrating from 0.6 to 0.7
- Migrating from 0.6.x to 0.6.3
- Migrating from 0.5 to 0.6
- Migrating from 0.4.x to 0.5.0
- Migrating from 0.4.1 to 0.4.2
- Migrating from 0.4.0 to 0.4.1
- Migrating from 0.3.x to 0.4.0
- Migrating from 0.2.x to 0.3.x
Migrating from 2.1.0 to 2.x.y¶
Update your config.ini
(required)¶
Upgrade tracker’s config.ini file. Use:
roundup-admin -i /path/to/tracker updateconfig newconfig.ini
to generate a new ini file preserving all your settings. You
can then merge any local comments from the tracker’s
config.ini
into newconfig.ini
. You can then merge
comments from config.ini
to newconfig.ini
and
replace config.ini
with newconfig.ini
.
Rdbms version change from 6 to 7 (required)¶
This release includes two changes that require updates to the database schema:
- The size of words included in the Roundup FTS indexers have been increased from 25 to 50. This requires changes to the database columns used by the native indexer. This also affect the whoosh and xapian indexers.
- Some databases that include native full-text search (native-fts indexer) searching are now supported.
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.
If successful, 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).
See below for directions on enabling native-fts.
The increase in indexed word length also affects whoosh and xapian
backends. You may want to run roundup-admin -i tracker_home
reindex
if you want to index or search for longer words in your full
text searches. Re-indexing make take some time.
Check new login_empty_passwords setting (required)¶
In this version of Roundup, users with a blank password are not
allowed to login. Blank passwords have been allowed since 2002, but
2022 is a different time. If you have a use case that requires a user
to login without a password, set the login_empty_passwords
setting
in the web
section of config.ini
to yes
. In
general this should be left at its default value of no
.
Check allowed_api_origins setting (optional)¶
If you are using the REST or xmlrpc api’s from an origin
that is different from your roundup tracker, you will need
to add your allowed origins to the allowed_api_origins in
your updated config.ini
. Upgrade your config.ini
as
described above then read the documentation for the setting
in config.ini
.
Check compression settings (optional)¶
Read the administration guide section on Configuring Compression.
Upgrade your tracker’s config.ini as described
above. Compare the old and new files and configure new
compression settings as you want. Then replace
config.ini
with the newconfig.ini
file.
Search added to user index page (optional)¶
A search form and count of number of hits has been added to the
user.index.html
template page in the classic template. You may
want to merge the search form and footer into your template.
Enhanced full-text search (optional)¶
SQLite’s FTS5 full-text search engine is available as is PostgreSQL’s full text search. Both require a schema upgrade so you should run:
roundup-admin -i tracker_home migrate
to create FTS specific tables before restarting the roundup-web or email interfaces.
SQLite 3.9.0+ or PostgreSQL 11.0+ are required to use this feature.
When using SQLite, all full text search fields will allow searching
using the MATCH query format described at:
https://www.sqlite.org/fts5.html#full_text_query_syntax. When using
PostgreSQL either the websearch_to_tsquery or to_tsquery formats
described on
https://www.postgresql.org/docs/14/textsearch-controls.html#TEXTSEARCH-PARSING-QUERIES
can be used. The default is websearch. Prefixing the search with
ts:
enables tsquery mode.
A list of words behaves almost the same as the default text search (native). So the search string fts search will find all issues that have both of those words (an AND search) in a text-field (like title) or in a message (or file) attached to the issue.
One thing to note is that native-fts searches do not ignore words longer than 50 characters or less than 2 characters. Also SQLite does not filter out common words (i.e. there is no stopword list). So words like “and”, “or”, “then”, “with” … are included in the FTS5 search.
You must explicitly enable this search mechanism by changing the
indexer
setting in config.ini
to native-fts
. Native-fts
must be explicitly chosen. This is different from Xapian or Whoosh
indexers, which are chosen if they are installed in the Python
environment. This prevents the existing native indexing from being
discarded if indexer
is not set.
Next re-index your data with roundup-admin -i tracker_home
reindex
. This can take a while depending on the size of the tracker.
You may want to update your config.ini
by following the directions
above to get the latest documentation.
See the administration guide notes on native-fts for further details.
Adding error reporting templates (optional)¶
Currently some internal errors result in a bare html page with an error message. The usual chrome supplied by page.html is not shown. For example query language syntax errors for full text search methods will display a bare HTML error page.
If you add an _generic.400.html
template to the html directory, you
can display the error inside of the layout provided by the page.html
template. This can make fixing the error and navigation easier. You
can use the _generic.404.html
template to create a
_generic.400.html
by modifying the title and body text. You can test
the 400 template by appending @template=400
to the url for the
tracker.
Change passwords using crypt module (optional)¶
The crypt module is being removed from the standard library. Any stored password using crypt encoding will fail to verify once the crypt module is removed (expected in Python 3.13 see pep-0594). Automatic migration of passwords (if enabled in config.ini) re-encrypts old passwords using something other than crypt if a user logs in using the web interface.
You can find users with passwords still encrypted using crypt by running:
roundup-admin -i <tracker_home> table password,id,username
Look for lines starting with {CRYPT}
. You can reset the user’s
password using:
roundup-admin -i <tracker_home>
roundup> set user16 password=somenewpassword
changing 16
to the id in the second column of the table output.
The example uses interactive mode (indicated by the roundup>
prompt). This prevents the new password from showing up in the output
of ps or shell history. The new password will be encrypted using the
default encryption method (usually pbkdf2).
Migrating from 2.0.0 to 2.1.0¶
Rdbms version change from 5 to 6 (**)¶
To fix an issue with importing databases, the database has to be upgraded for rdbms backends.
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.
If successful, 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).
This only changes the schema for the mysql backend. It has no effect other than upgrading the revision on other rdbms backends.
On the mysql backend it creates the database index that makes sure the key field for your class is unique.
If your update/migration fails, you will see an:
IntegrityError: (1062, "Duplicate entry '0-NULL' for key '_user_key_retired_idx'")
it means you have two non-retired members of the class with the same key field. E.G. two non-retired users with the same username.
Debug this using roundup-admin using the list command. For
example dump the user class by the key field username
:
$ roundup-admin -i <tracker_home> list user username
1: admin
2: anonymous
3: demo
4: agent
5: provisional
6: foo@example.com
7: dupe
8: dupe
...
then search the usernames for duplicates. Once you have
identified the duplicate username (dupe
above), you should
retire the other active duplicates or change the username for the
duplicate. To retire 7: dupe
, you run:
roundup-admin -i <tracker_home> retire user7
(use restore user7
if you retired the wrong item). If you
want to rename the entry use:
roundup-admin -i <tracker_home> set user7 username=dupe1
Keep doing this until you have no more duplicates. Then run the update/migrate again.
If you have duplicate non-retired entries in your database, please email roundup-users at lists.sourceforge.net. We are interested in how many issues this has caused. Duplicate creation should occur only when two or more mysql processes run in parallel and both of them creating an item with the same key. So this should be a rare event. The internal duplicate prevention checks should work in other cases.
For the nerds: if you had a new installation that was created at version 5, the uniqueness of a key was not enforced at the database level. If you had a database that was at version 4 and then upgraded to version 5 you have the uniqueness enforcing constraint. Running migrate updates to schema version 6 and installs the unique index constraint if it is missing.
Setuptools is now required to install¶
Roundup install now uses setuptools rather than distutils. You must
install setuptools. Use the version packgaged by your OS vendor. If
your OS vendor doesn’t supply setuptools use pip install
setuptools
. (You may need pip3 rather than pip if using python3.)
Define Authentication Header¶
The web server in front of roundup (apache, nginx) can perform user
authentication. It can pass the authenticated username to the backend
in a variable. By default roundup looks for the REMOTE_USER
variable. This can be changed by setting the parameter
http_auth_header
in the [web]
section of the tracker’s
config.ini
file to a different value. The value is case sensitive.
If the value is unset (the default) the REMOTE_USER variable is used.
If you are running roundup using roundup-server
behind a proxy
that authenticates the user you need to configure roundup-server
to pass the HTTP header with the authenticated username to the
tracker. By default roundup-server
looks for the REMOTE_USER
header for the authenticated user. You can copy an arbitrary header
variable to the tracker using the -I
option to roundup-server (or
the equivalent option in the roundup-server config file).
For example to use the uid_variable
header, two configuration
changes are needed: First configure roundup-server
to pass the
header to the tracker using:
roundup-server -I uid_variable ....
note that the header is passed exactly as supplied by the upstream
server. It is not prefixed with HTTP_
like other headers since
you are explicitly allowing the header. Multiple comma separated
headers can be passed to the -I
option. These could be used in a
detector or other tracker extensions, but only one header can be used
by the tracker as an authentication header.
To make the tracker honor the new variable changing the tracker
config.ini
to read:
[web]
...
http_auth_header = uid_variable
At the time this is written, support is experimental. If you use it you should notify the roundup maintainers using the roundup-users at lists.sourceforge.net mailing list.
Classname Format Enforced¶
Check schema.py and look at all Class(), IssueClass(), FileClass() calls. The second argument is the classname. All classnames must:
- start with an alphabetic character
- consist of alphanumerics and ‘_’
- not end with a digit
this was not enforced before. Using non-standard classnames could lead to other issues.
jQuery updated with updates to user.help.html¶
The devel and responsive templates shipped with an old version of
jQuery with some security issues. It has been updated to the current
version: 3.5.1. If your tracker is based on one of these templates
(see the TEMPLATE-INFO.txt
file in your tracker), remove the old
html/jquery.js
file from your tracker and copy the new
jquery-3.5.1.js
file from the template directory to your tracker’s
html
directory. Also copy in the new user.help.html
file. It now
references the new jquery-3.5.1.js
file and also fixes a bug that
prevented applying the change from the helper to the field on the main
form.
Roundup-admin security stops on incorrect properties¶
The roundup-admin ... security
command used to continue
running through the rest of the security roles after reporting a
property error. Now it stops after reporting the incorrect property.
If run non-interactively, it exits with status 1. It can now be used in a startup script to detect permission errors.
Futureproof devel and responsive timezone selection extension¶
The devel and responsive (derived from devel) templates use a select
control to list all available timezones when pytz is used. It
sanitizes the data using cgi.escape. Cgi.escape is deprecated and
removed in newer pythons. Change your extensions/timezone.py
file by applying the following patch manually:
-import cgi
+try:
+ from html import escape
+except ImportError:
+ from cgi import escape
try:
import pytz
@@ -25,7 +28,7 @@
s = ' '
if zone == value:
s = 'selected=selected '
- z = cgi.escape(zone)
+ z = escape(zone)
See https://issues.roundup-tracker.org/issue2551136 for more details.
Migrating from 1.6.X to 2.0.0¶
Python 2 MYSQL users MUST READ¶
To fix issues with encoding of data and text searching, roundup now explicitly sets the database connection character set. Roundup prior to 2.0 used the default character set which was not always utf-8. All roundup data is manipulated in utf-8. This mismatch causes issues with searches and result in corrupted data in the database if it was not properly represented across the charset conversions.
This issue exists when running roundup under python 2. Note that there are more changes required for running roundup 2.0 if you choose to use python3. See Python 3 support.
In an upgraded config.ini
(see next section) the [rdbms]
section has a key mysql_charset
set by default to utf8mb4
.
It should be possible to change utf8mb4
to any mysql charset. So
if you know what charset is enabled (e.g. via a setting in ~roundup/.my.cnf,
or the default charset for the database) you can set it in
config.ini
and not need to covert the database. However the
underlying issues with misconverted data and bad searches will still
exist if they did before.
None of the roundup developers run mysql, so the exact steps to take during the upgrade were tested with test and not production databases.
Before doing anything else:
Backup the mysql database using mysql dump or other mysql supported tool.
Backup roundup using your current backup tool and take the roundup instance offline.
Then the following steps (similar to the conversion in needed for Python 3) should work:
Export the tracker database using your current 1.6 instance:
roundup-admin -i <trackerdir> exporttables <export_dir>
replacing tracker_dir and export_dir as appropriate.
Import the exported database using the new 2.0 roundup:
roundup-admin -i <trackerdir> importtables <export_dir>
replacing tracker_dir and export_dir as appropriate.
The imported data should overwrite the original data. Note it is
critically important that the exporttables
be done with the old
tracker and the importtables
be done with the new tracker. An
import/export cycle between roundup 1.6.0 and roundup 2.0 has been
done successfully. So the export format for 1.6 and 2.0 should be
compatible.
Note that importtables
is new in roundup-2.0, so you will not be
able to import the result of exporttables
using any 1.x version of
roundup.
Following the same sequence as above using export
and import
should also work, but it will export all the files and messages. This
will take longer but may be worth trying if the exporttables
and
importtables
method fails for some reason.
Another way that should be faster, but is untested is to use mysql dump to dump the database. https://makandracards.com/makandra/595-dumping-and-importing-from-to-mysql-in-an-utf-8-safe-way recommends:
Note that when your MySQL server is not set to UTF-8 you need to do
mysqldump --default-character-set=latin1 (!) to get a correctly
encoded dump. In that case you will also need to remove the SET
NAMES='latin1' comment at the top of the dump, so the target machine
won't change its UTF-8 charset when sourcing.
Then import the dump. Removing SET NAMES
should allow the import
to use UTF-8.
Please report success or issues with this conversion to the roundup-users AT lists.sourceforge.net mailing list.
As people report successful or unsuccessful conversions, we will update the errata page at: https://wiki.roundup-tracker.org/ReleaseErrata.
Upgrade tracker’s config.ini file¶
Once you have installed the new roundup, use:
roundup-admin -i /path/to/tracker updateconfig newconfig.ini
to generate a new ini file preserving all your settings. You can then
merge any local comments from the tracker’s config.ini
into
newconfig.ini
. Compare the old and new files and configure any new
settings as you want. Then replace config.ini
with the
newconfig.ini
file.
Python 3 support¶
Many of the .html
and .py
files from Roundup that are copied
into tracker directories have changed for Python 3 support. If you
wish to move an existing tracker to Python 3, you need to merge in
those changes. Also you need to make sure that locally created python
code in the tracker is correct for Python 3.
If your tracker uses the anydbm
or mysql
backends, you also
need to export the tracker contents using roundup-admin export
running under Python 2, and them import them using roundup-admin
import
running under Python 3. This is detailed in the documention
for migrating to a different backend. If using the sqlite
backend,
you do not need to export and import, but need to delete the
db/otks
and db/sessions
files when changing Python version.
If using the postgresql
backend, you do not need to export and
import and no other special database-related steps are needed.
If you use the whoosh indexer, you will need to reindex. It looks like a database created with Python 2 leads to Unicode decode errors when accessed by Python 3. Reindexing can take a while (see details below look for “reindexing”).
Octal values in config.ini change from the Python 2 representation
with a leading 0
(022
). They now use a leading 0o
(0o22
). Note that the 0o
format is properly handled under
python 2. You can use the newconfig.ini
generated using python3
roundup-admin -i ... updateconfig newconfig.ini
if you want to go
back to using python 2. (Note going back to Python 2 will require
the same steps as moving from 2 to 3 except using Python 3 to perform
the export.)
Rate Limit New User Registration¶
The new user registration form can be abused by bots to allow
automated registration for spamming. This can be limited by using the
new config.ini
[web]
option called
registration_delay
. The default is 4 and is the number of seconds
between the time the form was generated and the time the form is
processed.
If you do not modify the user.register.html
template in your
tracker’s html directory, you must set this to 0. Otherwise you will
see the error:
Form is corrupted, missing: opaqueregister.
If set to 0, the rate limit check is disabled.
If you want to use this, you can change your user.register.html
file to include:
<input type="hidden" name="opaqueregister" tal:attributes="value python: utils.timestamp()">
The hidden input field can be placed right after the form declaration that starts with:
<form method="POST" onSubmit="return submit_once()"
If you have applied Erik Forsberg’s tracker level patch to implement
(see: https://hg.python.org/tracker/python-dev/rev/83477f735132), you
can back the code out of the tracker. You must change the name of the
field in the html template to opaqueregistration
from opaque
in order to use the core code.
PGP mail processing¶
Roundup now uses the gpg
module instead of pyme
to process PGP
mail. If you have PGP processing enabled, make sure the gpg
module is installed.
MySQL client module¶
Although the MySQLdb
module from
https://pypi.org/project/MySQL-python/ is still supported, it is
recommended to switch to the updated module from
https://pypi.org/project/mysqlclient/.
XMLRPC Access Role¶
A new permission has been added to control access to the XMLRPC endpoint. If the user doesn’t have the new “Xmlrpc Access” permission, they will not be able to log in using the /xmlrpc end point. To add this new permission to the “User” role you should change your tracker’s schema.py and add:
db.security.addPermissionToRole('User', 'Xmlrpc Access')
This is usually included near where other permissions like “Web Access” or “Email Access” are assigned.
New values for db.tx_Source¶
The database attribute tx_Source reports “xmlrpc” and “rest” when the /xmlrpc and /rest web endpoints are used. Check all code (extensions, detectors, lib) in trackers looking for tx_Source. If you have code like:
if db.tx_Source == "web":
or:
if db.tx_Source in ['web', 'email-sig-openpgp', 'cli' ]:
you may need to change these to include matches to “rest” and “xmlrpc”. For example:
if db.tx_Source in [ "web", "rest", "xmlrpc" ]
or:
if db.tx_Source in ['web', 'rest', 'xmlrpc', 'email-sig-openpgp', 'cli' ]:
CSV export changes¶
The original Roundup CSV export function for indexes reported id
numbers for links. The wiki had a version that resolved the id’s to
names, so it would report open
rather than 2
or
user2;user3
rather than [2,3]
.
Many people added the enhanced version to their extensions directory.
The enhanced version was made the default in roundup 2.0. If you want
to use the old version (that returns id’s), you can replace references
to export_csv
with export_csv_id
in templates.
Both core csv export functions have been changed to force quoting of all exported fields. To incorporate this change in any CSV export extension you may have added, change references in your code from:
writer = csv.writer(wfile)
to:
writer = csv.writer(wfile, quoting=csv.QUOTE_NONNUMERIC)
this forces all (non-numeric) fields to be quoted and empty quotes to be added for missing parameters.
This turns exported values that may look like formulas into strings so some versions of Excel won’t try to interpret them as a formula.
Update userauditor.py to restrict usernames¶
A username can be created with embedded commas and < and > characters. Even though the < and > are usually escaped when displayed, the embedded comma makes it difficult to edit lists of users as they are comma separated.
If you have not modified your tracker’s userauditor.py, you can just copy the userauditor.py from the classic template into your tracker’s detectors directory. Otherwise merge the changes from the template userauditor.py. https://issues.roundup-tracker.org/issue2550921 may be helpful.
Consider reindexing if you use European languages¶
A couple of bugs dealing with incorrect indexing of European languages (Russian and German were reported) have been fixed. Note reindexing all your data may take a long time. See: https://issues.roundup-tracker.org/issue1195739 and https://issues.roundup-tracker.org/issue1344046 for a description of the problem. If you determine that this a problem for your tracker, you can use:
roundup-admin -i /path/to/tracker reindex
to rewrite your full text indexes. The tracker used for reindex timing had 140MB of file/message data and 2500 issues with a slow 5400RPM SATA drive. Using native indexing with sqlite took about 45 minutes. Using whoosh took about 2 hours. Using xapian took about 6 hours. All examples were with Python 2. Anecdotal evidence shows Python 3 is faster, but YMMV.
Merge improvements in statusauditor.py¶
By default the detector statusauditor.py will change the status from
“unread” to “chatting” when a second message is added to an issue.
The distributed classic and jinja templates implement this feature in
their copies of detectors/statusauditor.py
.
This can be a problem. Consider a person sending email to create an issue. Then the person sends a followup message to add some additional information to the issue. The followup message will trigger the status change from “unread” to “chatting”. This is misleading since the person is “chatting” with themselves.
Statusauditor.py has been enhanced to prevent the status from changing
to “chatting” until a second user (person) adds a message. If you
want this functionality, you need to merge the distributed
statusauditor.py with your tracker’s statusauditor.py. If you have not
customized your tracker’s statusauditor.py, copy the one from the
distibuted template. In addition to the python file, you also must
copy/merge the distributed detectors/config.ini
into your
tracker’s detectors directory. Most people can copy
detectors/config.ini
from the distributed templates as they won’t
have a detectors/config.ini
file. (Note this is
detectors/config.ini
do not confuse it with the main
config.ini
file at the root of the tracker home.)
This enhancement is disabled by default. Enable it by changing the
value in detectors/config.ini
from:
chatting_requires_two_users = False
to
chatting_requires_two_users = True
(the values no
and yes
can also be used). Restart the tracker
to enable the change.
If you don’t do this quite right you will see one of two error messages in the web interface when you try to update an issue with a message:
Edit Error: Unsupported configuration option: Option
STATUSAUDITOR_CHATTING_REQUIRES_TWO_USERS not found in
detectors/config.ini.
Contact tracker admin to fix.
This happens if detectors/config.ini is not found or is missing the
chatting_requires_two_users
option in the statusauditor
section.
If you have an incorrect value (say you use T
rather than
True
) you see a different error:
Edit Error: Invalid value for
DETECTOR::STATUSAUDITOR_CHATTING_REQUIRES_TWO_USERS: 'T'
Allowed values: yes, no
to fix this set the value to yes
(True) or no
(False).
Responsive template changes¶
There have been some changes to the responsive template. You can diff/merge these changes into your responsive template based tracker.
Jinja template changes¶
Auto escaping has been enabled in the jinja template engine, this means it is no longer necessary to manually escape dynamic strings with “|e”, but strings that should not be escaped need to be marked with “|safe” (e.g. “{{ context.history()|u|safe }}”). Also, the i18n extension has been enabled and the template has been updated to use the extension for translatable text instead of explicit “i18n.gettext” calls:
{% trans %}List of issues{% endtrans %}
instead of:
{{ i18n.gettext(‘List of issues’)|u }}
The jinja template has been upgraded to use bootstrap 4.1.3 (from 2.2.2). You can diff/merge changes into your jinja template based tracker.
Also search _generic.index.html, navigation.html and file.index.html in the html directory of your tracker. Look for:
<input type="hidden" name="@action"
where the value is a jinja expression that calls i18n.gettext. Set the value to the argument of the gettext call. E.G. replace:
<input type="hidden" name="@action" value="{{ i18n.gettext('editCSV')|u }}">
with:
<input type="hidden" name="@action" value="editCSV">
The action keywords should not be translated.
Migrating from 1.5.1 to 1.6.0¶
Update tracker config file¶
After installing the new version of roundup, you should
update the config.ini
file for your tracker. To do this:
backup your existing
config.ini
fileusing the newly installed code, run:
roundup-admin -i /path/to/tracker updateconfig config.ini.newto create the file config.ini.new. Replace
/path/to/tracker
with the path to your tracker.replace your tracker’s config.ini with config.ini.new
Using updateconfig keeps all the settings from your tracker’s config.ini file and adds settings for all the new options.
If you have added comments to your original config.ini file, merge the added comments into the config.ini.new file. Then replace your tracker’s config.ini with config.ini.new.
Read the new config.ini and configure it to enable new features. Details on using these features can be found in this section.
Make sure that user can view labelprop on classes (REQUIRED)¶
If you have View permissions that use `properties=...`
,
make sure that the labelprop for the class is listed in the
properties list.
The first one of these that exists must must be in the list:
- the property set by a call to setlabelprop for the class
- the key of the class (as set by setkey())
- the “name” property (if it exists)
- the “title” property (if it exists)
if none of those apply, you must allow
- the “id” property
E.G. If your class does a setlabelprop(“foo”) you must include “foo” in the properties list even if the class has name or title properties.
See: https://www.roundup-tracker.org/docs/customizing.html#setlabelprop-property for further details on the labelprop.
If you don’t do this, you will find that multilinks (and possibly links) may not be displayed properly. E.G. templates that iterate over a mutlilink field (with tal:repeat for example) may not show any content.
See: https://sourceforge.net/p/roundup/mailman/message/35763294/ for the initial discussion of the issue.
Cross Site Request Forgery Detection Added¶
Roundup 1.6. supports a number of defenses against CSRF.
Http header verification against the tracker’s web
setting in the [tracker]
section of config.ini for the
following headers:
- Analyze the
Referer
HTTP header to make sure it includes the web setting.- Analyze the
Origin
HTTP header to make sure the schema://host matches the web setting.- Analyze the
X-Forwarded-Host
header set by a proxy running in front of roundup to make sure it agrees with the host part of the web setting.- Analyze the
Host
header to make sure it agrees with the host part of the web setting. This is not done ifX-Forwarded-Host
is set.
By default roundup 1.6 does not require any specific header
to be present. However at least one of the headers above
must pass validation checks (usually Host
or
Referer
) or the submission is rejected with an error.
If any header fails validation, the submission is
rejected. (Note the user’s form keeps all the data they
entered if it was rejected.)
Also the admin can include unique csrf tokens for all forms submitted using the POST method. (Delete and put methods are also included, but not currently used by roundup.) The csrf token (nonce) is tied to the user’s session. When the user submits the form and nonce, the nonce is checked to make sure it was issued to the user and the same session. If this is not true the post is rejected and the user is notified.
The standard context/submit templating item creates CSRF tokens by default. If you have forms using the POST method that are not using the standard submit routine, you should add the following field to all forms:
- <input name=”@csrf” type=”hidden”
- tal:attributes=”value python:utils.anti_csrf_nonce()”>
A unique random token is generated by every call to utils.anti_csrf_nonce() and is put in a database to be retreived if the token is used. Token lifetimes are 2 weeks by default but can be configured in config.ini. Roundup will automatically prune old tokens. Calling anti_csrf_nonce with an integer lifetime, for example:
- <input name=”@csrf” type=”hidden”
- tal:attributes=”value python:utils.anti_csrf_nonce(lifetime=10)”>
sets the lifetime of that nonce to 10 minutes.
If you want to change the default settings, you have to update the web section in your tracker’s config.ini file. Follow the section above to generate an updated config.ini file. Then look for settings that start with csrf. The updated config.ini file includes detailed descriptions of the settings.
In general one of four values can be set for these
settings. The default is yes
, which validates the header
or nonce and blocks access if the validation fails. If the
field/header is missing it allows access. Setting these
fields to required
blocks access if the header/nonce is
missing.
It is recommended that you change your templates so every form that is not submitted via GET has an @csrf field. Then change the csrf_enforce_token setting to ‘required’.
Errors and Troubleshooting - @csrf in url¶
If you see the @csrf nonce in the URL, you have added the value to a form that uses the GET method. You should remove the @csrf token from these forms as it is not needed.
Errors and Troubleshooting - AttributeError list object no attribute value¶
If you get an error:
AttributeError: ‘list’ object has no attribute ‘value’
in handle_csrf, you have more than one @csrf token for the form. This usually occurs because the form uses the standard context/submit element but you also added an explicit @csrf statement. Simply remove the @csrf element for that form.
Errors and Troubleshooting - xmlrpc Required Header Missing¶
When performing and xmlrpc call, if you see something like:
- xmlrpclib.Fault: <Fault 1: “<class
- ‘roundup.exceptions.UsageError’>:Required Header Missing”>
change the setting of csrf_enforce_header_x-requested-with in config.ini to no. So it looks like:
csrf_enforce_header_x-requested-with = no
Alternatively change your xmlrpc client to add appropriate headers to the request including the:
X-Requested-With:
header as well as any other required csrf headers (e.g. referer, origin) configured in config.ini. See the advanced python client at the end of the xmlrpc guide.
Support for SameSite cookie option for session cookie¶
Support for serving the session cookie using the SameSite cookie option has been added. By default it is set to lax to provide a better user experience. But this can be changed to strict or the option can be removed entirely.
Using the process for merging config.ini changes described in
Cross Site Request Forgery Detection Added you can add the
samesite_cookie_setting
to the [web]
section of the config
file.
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 (REQUIRED)¶
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
.
Note 2: if you are using the anydbm back end, you still set it using the backend option in the rdbms section of the config.ini file.
New config file option ‘indexer’ added¶
This release added support for the Whoosh indexer, so 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 =
Errors and Troubleshooting - Full text searching not working¶
If after the upgrade full text searching is not working try changing the indexer value. If this is failing most likely you need to set ‘’’indexer = native’’’ to use the rdbms or db text indexing systems.
Alternatively you can do a ‘’’roundup-admin -i /path/to/tracker reindex’’’ to generate a new index using roundup’s preferred indexer from the list above.
Xapian error with flint when reindexing¶
If you reindex and are using xapian, you may get the error that “flint” is not supported (looks like flint was removed after xapian 1.2.x). To fix this, you can delete the full text search database located in the tracker home directory in the file ‘’’db/text-index’’’ and then perform a reindex.
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 (REQUIRED)¶
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”):
<input type="hidden" name="__came_from" tal:attributes="value string:${request/base}${request/env/PATH_INFO}">
with the following:
<input type="hidden" name="__came_from"
tal:condition="exists:request/env/QUERY_STRING"
tal:attributes="value string:${request/base}${request/env/PATH_INFO}?${request/env/QUERY_STRING}">
<input type="hidden" name="__came_from"
tal:condition="not:exists:request/env/QUERY_STRING"
tal:attributes="value string:${request/base}${request/env/PATH_INFO}">
Now search backwards for the nearest form statement before the code that sets __came_from. If it looks like:
<form method="post" action="#">
replace it with:
<form method="post" tal:attributes="action request/base">
or with:
<form method="post" tal:attributes="action string:${request/env/PATH_INFO}">
the important part is that the action field must not include any query parameters (‘#’ includes query params).
Errors and Troubleshooting - Unrecognized scheme in …¶
One symptom of failing to do this is getting an error:
Unrecognized scheme in ….
where the …. changes depending on the url path. You can see this when logging in from any screen other than the main index.
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 in html/keyword.item.html:
<tr>
<th i18n:translate="">Keyword</th>
<td tal:content="structure context/name/field">name</td>
+ <td tal:condition="not:context/id">
+ <tal:comment tal:replace="nothing">
+ 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.
+ </tal:comment>
+ <input type="checkbox" id="continue_new_keyword"
+ name="__redirect_to"
+ tal:attributes="value
+ string:${request/base}${request/env/PATH_INFO}?@template=item;
+ checked python:True" />
+ <label for="continue_new_keyword" i18n:translate="">Continue adding keywords.</label>
+ </td>
</tr>
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 start with 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):
<tal:block tal:repeat="qs request/user/queries">
- <a href="#" tal:attributes="href string:${qs/klass}?${qs/url}&@dispname=${qs/name}"
+ <a href="#" tal:attributes="href string:${qs/klass}?${qs/url}&@dispname=${qs/name/url_quote}"
tal:content="qs/name">link</a><br>
</tal:block>
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.
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.
Errors and Troubleshooting - Unassigned issues for anonymous¶
If you notice that the “Unassigned Issues” search on page.html is displaying assigned issues for users with the Anonymous role, you need to allow search permissions for the user class.
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.
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 four lines are the ones you need to add.
Usually you can add this to your User role. If all users have the User role in common then all logged in users should be ok. If you have users who do not include the User role (e.g. they may only have a Provisional role), you should add the search permission to that role (e.g. Provisional) as well if you allow them to edit their list of queries.
Also see the new search permissions for query in 1.4.17 section discussing search permission requirements for editing queries. The fixes in this release require the ability to search the creator of all queries to work correctly.
If the test script for the new search permissions for query in 1.4.17 doesn’t report that a role has the ability to search queries or at least search the creator property for queries, add the following permissions to your schema.py:
s = db.security.addPermission(name='Search', klass='query',
properties=['creator'],
description="User is allowed to Search queries for creator")
db.security.addPermissionToRole('User', s)
Errors and Troubleshooting - Public queries listed twice when editing¶
If you do not do this, public queries will be listed twice in the edit
interface. Once in the “Queries I created” section and again in the
“Queries others created” section of the query edit page
(http..../query?@template=edit
).
Fix security issues in query.item.html template¶
The default query.item.html template allows anybody to view all queries.
This has been updated in the classic, devel and responsive templates to only allow people to view queries they creates or queries that are publicly viewable.
If you haven’t modified you query.item.html template, simply copy the query.item.html template from one of the above default templates to your tracker’s html directory.
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.
Changes to property permissions¶
If you create a permission:
- db.security.addPermission(name=’View’, klass=’user’,
- properties=[‘theme’], check=own_record, description=”User is allowed to view their own theme”)
that combines checks and properties, the permission also matches a permission check for the View permission on the user class. So this also allows the user to see their user record. It is unexpected that checking for access without a property would match this permission.
This release adds support for making a permission like above only be
used during property permission tests. See customizing.txt
and
search for props_only and set_props_only_default in the section
‘Adding a new Permission’
Improve query editing¶
If a user creates a query with the same name as one of their existing queries, the query editing interface will now report an error. By default the query editing page (issue.search.html) displays the index page when the search is triggered. This is usually correct since the user expects to see the results of the query. 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 issue.search.html page, add the following line after the hidden field @old-queryname:
<input type=”hidden” name=”@template” value=”index|search”/>
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.
New -L (loghttpvialogger) option to roundup-server¶
Http request logs from roundup-server are sent to stderr or can be recorded in a log file (if -l or the logfile options is used). However there is no way to rotate the logfile without shutting down and restarting the roundup-server.
If the -L flag is used, the python logging module is used for logging the http requests. The name for the log (qualname) is ‘roundup.http’. You can direct these messages to a rotating log file by putting the following:
[loggers]
keys=roundup.http
[logger_roundup.http]
level=INFO
handlers=rotate_weblog
qualname=roundup.http
propagate=0
[handlers]
keys=rotate_weblog
[handler_rotate_weblog]
class=logging.handlers.RotatingFileHandler
args=('httpd.log','a', 512000, 2)
formatter=plain
[formatters]
keys=plain
[formatter_plain]
format=%(message)s
into a file (e.g. logging.ini). Then reference this file in the ‘config’ value of the [logging] section in the trackers config.ini file.
Note the log configuration above is an example and can be merged into a more full featured logging config file for your tracker if you wish. It will create a new file in the current working directory called ‘httpd.log’ and will rotate the log file at 500K and keep two old copies of the file.
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
<meta name="robots" content="noindex, nofollow" />
. 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:
you need to change the url to read:
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 <br> tags for multi-line messages, you now should use newlines instead, these will be replaced with <br/> 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.keys())))
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
from __future__ import print_function
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).getprops(protected=True).keys()):
print(" Property:", p)
roles = []
for role in sorted(db.security.role.keys()):
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</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.
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:
<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.
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
:
<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
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 forsort
andgroup
, 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 ofbatch.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:
<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!
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
:
<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>
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 <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
contentsbackend_name
contentsfrom 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’sdbinit.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 thedb = Database(config, name)
line – don’t need to be copied. Neither do the last few lines – those starting withimport detectors
, down toreturn 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" <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:
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.
Migrating from 0.4.x to 0.5.0¶
This has been a fairly major revision of Roundup:
- 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)!
- 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.
- 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.
- 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.
- We’ve changed the terminology from “instance” to “tracker”, to ease the learning curve/impact for new users.
- 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:
- Permissions are defined as having a name and optionally a hyperdb class they’re specific to,
- Roles are defined that have one or more Permissions,
- Users are assigned Roles in their “roles” property, and finally
- 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:
- make sure there’s an “anonymous” user - this user is mandatory now and is the one that unknown users are logged in as.
- 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 <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, https://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 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
Migrating from 0.4.0 to 0.4.1¶
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.
Migrating from 0.3.x to 0.4.0¶
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.
Migrating from 0.2.x to 0.3.x¶
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:
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
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")
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.