"Fossies" - the Fresh Open Source Software Archive  

Source code changes of the file "share/doc/roundup/html/_sources/upgrading.txt" between
roundup-1.6.1.tar.gz and roundup-2.0.0.tar.gz

About: Roundup is an highly customisable issue-tracking system with command-line, web and e-mail interfaces (written in Python).

upgrading.txt  (roundup-1.6.1):upgrading.txt  (roundup-2.0.0)
.. index:: Upgrading
====================================== ======================================
Upgrading to newer versions of Roundup Upgrading to newer versions of Roundup
====================================== ======================================
Please read each section carefully and edit your tracker home files Please read each section carefully and edit your tracker home files
accordingly. Note that there is information about upgrade procedures in the accordingly. Note that there is information about upgrade procedures in the
`administration guide`_. `administration guide`_.
If a specific version transition isn't mentioned here (eg. 0.6.7 to 0.6.8) 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 then you don't need to do anything. If you're upgrading from 0.5.6 to
skipping to change at line 23 skipping to change at line 25
**IMPORTANT** The v1.5.x releases of Roundup were the last to support **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 v2.5 and v2.6. Starting with the v1.6 releases of Roundup
v2.7.2 is required to run newer releases of Roundup. v2.7.2 is required to run newer releases of Roundup.
Contents: Contents:
.. contents:: .. contents::
:local: :local:
.. index:: Upgrading; 1.6.x to 2.0.0
Migrating from 1.6.X to 2.0.0
=============================
.. index:: roundup-admin; updateconfig subcommand
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 ``utf-8``.
It should be possible to change utf-8 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:
1. 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.
2. 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.
.. index:: Upgrading; 1.5.1 to 1.6.0
Migrating from 1.5.1 to 1.6.0 Migrating from 1.5.1 to 1.6.0
============================= =============================
Update tracker config file Update tracker config file
-------------------------- --------------------------
After installing the new version of roundup, you should After installing the new version of roundup, you should
update the ``config.ini`` file for your tracker. To do this: update the ``config.ini`` file for your tracker. To do this:
1. backup your existing ``config.ini`` file 1. backup your existing ``config.ini`` file
skipping to change at line 283 skipping to change at line 681
Errors and Troubleshooting - Full text searching not working Errors and Troubleshooting - Full text searching not working
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If after the upgrade full text searching is not working try changing 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 the indexer value. If this is failing most likely you need to set
'''indexer = native''' to use the rdbms or db text indexing systems. '''indexer = native''' to use the rdbms or db text indexing systems.
Alternatively you can do a Alternatively you can do a
'''roundup-admin -i /path/to/tracker reindex''' '''roundup-admin -i /path/to/tracker reindex'''
to generate a new index using roundup's preferred indexer from the list above. 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 improved in Xapian Indexer
----------------------------------- -----------------------------------
Stemming allows a search for "silent" also match silently. The Porter Stemming allows a search for "silent" also match silently. The Porter
stemmer in Xapian works with lowercase English text. In this release we stemmer in Xapian works with lowercase English text. In this release we
lowercase the documents as they are put into the indexer. lowercase the documents as they are put into the indexer.
This means capitalization is not preserved, but produces more hits by This means capitalization is not preserved, but produces more hits by
using the stemmer. using the stemmer.
skipping to change at line 741 skipping to change at line 1148
into a file (e.g. logging.ini). Then reference this file in into a file (e.g. logging.ini). Then reference this file in
the 'config' value of the [logging] section in the trackers the 'config' value of the [logging] section in the trackers
config.ini file. config.ini file.
Note the log configuration above is an example and can be Note the log configuration above is an example and can be
merged into a more full featured logging config file for merged into a more full featured logging config file for
your tracker if you wish. It will create a new file in the your tracker if you wish. It will create a new file in the
current working directory called 'httpd.log' and will rotate current working directory called 'httpd.log' and will rotate
the log file at 500K and keep two old copies of the file. the log file at 500K and keep two old copies of the file.
.. index:: Upgrading; 1.5.0 to 1.5.1
Migrating from 1.5.0 to 1.5.1 Migrating from 1.5.0 to 1.5.1
============================= =============================
User data visibility User data visibility
-------------------- --------------------
For security reasons you should change the permissions on the user For security reasons you should change the permissions on the user
class. We previously shipped a configuration that allowed users to see class. We previously shipped a configuration that allowed users to see
too many of other users details, including hashed passwords under too many of other users details, including hashed passwords under
certain circumstances. In schema.py in your tracker, replace the line:: certain circumstances. In schema.py in your tracker, replace the line::
skipping to change at line 790 skipping to change at line 1199
self.client.error_message.append(...) self.client.error_message.append(...)
vs.:: vs.::
self.client.add_error_message(...) self.client.add_error_message(...)
The new calls escape the passed string by default and avoid XSS security The new calls escape the passed string by default and avoid XSS security
issues. issues.
.. index:: Upgrading; 1.4.20 to 1.4.21
Migrating from 1.4.20 to 1.4.21 Migrating from 1.4.20 to 1.4.21
=============================== ===============================
The ``_generic.calendar.html`` page of the instance has been updated to include The ``_generic.calendar.html`` page of the instance has been updated to include
``<meta name="robots" content="noindex, nofollow" />``. This prevents ``<meta name="robots" content="noindex, nofollow" />``. This prevents
robots to follow all the links in the calendar. If you haven't modified the 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 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, ``share/roundup/templates/classic/html/_generic.calendar.html``; if you did,
you can add the tag manually. See issue2550765 and changeset a099ff2ceff3. you can add the tag manually. See issue2550765 and changeset a099ff2ceff3.
skipping to change at line 815 skipping to change at line 1226
http://myroundup.com/roundup http://myroundup.com/roundup
you need to change the url to read: you need to change the url to read:
http://myroundup.com/roundup/xmlrpc http://myroundup.com/roundup/xmlrpc
to invoke the xmlrpc handler. This allows us to send xml to invoke the xmlrpc handler. This allows us to send xml
data to roundup for other handlers (e.g. REST, SOAP ...) data to roundup for other handlers (e.g. REST, SOAP ...)
in the future. in the future.
.. index:: upgrading; 1.4.19 to 1.4.20
Migrating from 1.4.19 to 1.4.20 Migrating from 1.4.19 to 1.4.20
=============================== ===============================
Roundup used to allow certain HTML-Tags in OK- and Error-messages. Since 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 these messages are passed via the URL (due to roundup redirecting after
an edit), we did have security-issues (see issue2550724). an edit), we did have security-issues (see issue2550724).
If you have customized the OK or Error messages in your If you have customized the OK or Error messages in your
roundup-installation and you were using features like bold or italic roundup-installation and you were using features like bold or italic
in the message, you will have to do without this highlighting and in the message, you will have to do without this highlighting and
skipping to change at line 840 skipping to change at line 1253
Note that the previous implementation also allowed links inside Note that the previous implementation also allowed links inside
messages. Since these links could be set by an attacker, no links in messages. Since these links could be set by an attacker, no links in
roundup messages are supported anymore. This does *not* affect the roundup messages are supported anymore. This does *not* affect the
"clear this message" link in OK-messages as it is generated by the "clear this message" link in OK-messages as it is generated by the
template and is not part of the OK-message. template and is not part of the OK-message.
If you have not modified any roundup messages, you need not do anything, 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 the templates shipped with roundup did not use HTML tags in messages for
highlighting. highlighting.
.. index:: upgrading; 1.4.17 to 1.4.18
Migrating from 1.4.17 to 1.4.18 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 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 mail without attachment was received via the mail interface. The
following script will list likely issues being affected by the bug. 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 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 installed 1.4.17 later than this date, you can change the date
appropriately to your installation date. Run the script in the directory appropriately to your installation date. Run the script in the directory
of your tracker:: of your tracker::
skipping to change at line 881 skipping to change at line 1296
print(', '.join(sorted(affected.keys()))) print(', '.join(sorted(affected.keys())))
To find out which files where attached before you can look in the 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 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 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 list of files attached to an issue should be files 5, 17, 23 for issue42
you will set this using you will set this using
roundup-admin -i /path/to/your/tracker set issue42 files=5,17,23 roundup-admin -i /path/to/your/tracker set issue42 files=5,17,23
.. index:: upgrading; 1.4.x to 1.4.17
Migrating from 1.4.x to 1.4.17 Migrating from 1.4.x to 1.4.17
============================== ==============================
There is a new config-option `migrate_passwords` in section `web` to There is a new config-option `migrate_passwords` in section `web` to
auto-migrate passwords at web-login time to a more secure storage 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 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 passwords are auto-migrated to a more secure password scheme on user
login, set this to "no" before running your tracker(s) after the login, set this to "no" before running your tracker(s) after the
upgrade. upgrade.
skipping to change at line 939 skipping to change at line 1356
for cl in sorted(db.getclasses()): for cl in sorted(db.getclasses()):
print("Class:", cl) print("Class:", cl)
for p in sorted(db.getclass(cl).getprops(protected=True).keys()): for p in sorted(db.getclass(cl).getprops(protected=True).keys()):
print(" Property:", p) print(" Property:", p)
roles = [] roles = []
for role in sorted(db.security.role.keys()): for role in sorted(db.security.role.keys()):
if db.security.roleHasSearchPermission(cl,p,role): if db.security.roleHasSearchPermission(cl,p,role):
roles.append(role) roles.append(role)
print(" roles may search:", ', '.join(roles)) print(" roles may search:", ', '.join(roles))
.. index:: upgrading; 1.4.x to 1.4.12
Migrating from 1.4.x to 1.4.12 Migrating from 1.4.x to 1.4.12
============================== ==============================
Item creation now checks the "Create" permission instead of the "Edit" Item creation now checks the "Create" permission instead of the "Edit"
permission for individual properties. If you have modified your tracker permission for individual properties. If you have modified your tracker
permissions from the default distribution, you should check that permissions from the default distribution, you should check that
"Create" permissions exist for all properties you want users to be able "Create" permissions exist for all properties you want users to be able
to create. to create.
Fixing some potential security holes Fixing some potential security holes
skipping to change at line 984 skipping to change at line 1403
Some HTML interface tweaks Some HTML interface tweaks
-------------------------- --------------------------
You may wish to copy the ``user_utils.js`` and ``style.css` files from the 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 source distribution ``share/roundup/templates/classic/html/`` directory to the
``html`` directory of your trackers as it includes a small improvement. ``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 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. the differences in to your versions or ignore the changes.
.. index:: upgrading; 1.4.x to 1.4.11
Migrating from 1.4.x to 1.4.11 Migrating from 1.4.x to 1.4.11
============================== ==============================
Close potential security hole Close potential security hole
----------------------------- -----------------------------
If your tracker has untrusted users you should examine its ``schema.py`` 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. file and look for the section granting the "Edit" permission to your users.
This should look something like:: This should look something like::
skipping to change at line 1042 skipping to change at line 1463
-tal:condition="python:request.user.hasPermission('Create', 'user')" -tal:condition="python:request.user.hasPermission('Create', 'user')"
+tal:condition="python:request.user.hasPermission('Register', 'user')" +tal:condition="python:request.user.hasPermission('Register', 'user')"
Generic class editor may now restore retired items Generic class editor may now restore retired items
-------------------------------------------------- --------------------------------------------------
The instructions for doing so won't be present in your tracker unless you copy 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 the ``_generic.index.html`` template from the roundup distribution in
``share/roundup/templates/classic/html`` to your tracker's ``html`` directory. ``share/roundup/templates/classic/html`` to your tracker's ``html`` directory.
.. index:: upgrading; 1.4.x to 1.4.9
Migrating from 1.4.x to 1.4.9 Migrating from 1.4.x to 1.4.9
============================= =============================
Customized MailGW Class Customized MailGW Class
----------------------- -----------------------
If you have customized the MailGW class in your tracker: The new MailGW 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 class opens the database for each message in the method handle_message
(instance.open) instead of passing the opened database as a parameter to (instance.open) instead of passing the opened database as a parameter to
the MailGW constructor. The old handle_message has been renamed to the MailGW constructor. The old handle_message has been renamed to
skipping to change at line 1097 skipping to change at line 1520
<input type="hidden" name="@remove@messages" tal:attributes="value msg/id"> <input type="hidden" name="@remove@messages" tal:attributes="value msg/id">
Fixing the "retire" button in user management list Fixing the "retire" button in user management list
-------------------------------------------------- --------------------------------------------------
Some previous versions of this upgrading document missed ``method="POST"`` Some previous versions of this upgrading document missed ``method="POST"``
in the change to the "retire" link in the user management list in the change to the "retire" link in the user management list
in section `Migrating from 1.4.x to 1.4.7`_. in section `Migrating from 1.4.x to 1.4.7`_.
Make sure the change is done as listed below in this document. Make sure the change is done as listed below in this document.
.. index:: upgrading; 1.4.x to 1.4.7
Migrating from 1.4.x to 1.4.7 Migrating from 1.4.x to 1.4.7
============================= =============================
Several security issues were addressed in this release. Some aspects of your Several security issues were addressed in this release. Some aspects of your
trackers may no longer function depending on your local customisations. Core trackers may no longer function depending on your local customisations. Core
functionality that will need to be modified: functionality that will need to be modified:
Grant the "retire" permission to users for their queries Grant the "retire" permission to users for their queries
-------------------------------------------------------- --------------------------------------------------------
skipping to change at line 1171 skipping to change at line 1596
tracker's ``config.ini`` file: tracker's ``config.ini`` file:
# Setting this option enables Roundup to serve uploaded HTML # Setting this option enables Roundup to serve uploaded HTML
# file content *as HTML*. This is a potential security risk # file content *as HTML*. This is a potential security risk
# and is therefore disabled by default. Set to 'yes' if you # and is therefore disabled by default. Set to 'yes' if you
# trust *all* users uploading content to your tracker. # trust *all* users uploading content to your tracker.
# Allowed values: yes, no # Allowed values: yes, no
# Default: no # Default: no
allow_html_file = no allow_html_file = no
.. index:: upgrading; 1.4.2 to 1.4.3
Migrating from 1.4.2 to 1.4.3 Migrating from 1.4.2 to 1.4.3
============================= =============================
If you are using the MySQL backend you will need to replace some indexes If you are using the MySQL backend you will need to replace some indexes
that may have been created by version 1.4.2. that may have been created by version 1.4.2.
You should to access your MySQL database directly and remove any indexes 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 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 the same spec except the key column name needs a size. So an index on
"_user (__retired, _name)" should become "_user (__retired, _name(255))". "_user (__retired, _name)" should become "_user (__retired, _name(255))".
.. index:: upgrading; 1.4.x to 1.4.2
Migrating from 1.4.x to 1.4.2 Migrating from 1.4.x to 1.4.2
============================= =============================
.. index:: roundup-admin; migrate subcommand
You should run the "roundup-admin migrate" command for your tracker once You should run the "roundup-admin migrate" command for your tracker once
you've installed the latest codebase. you've installed the latest codebase.
Do this before you use the web, command-line or mail interface and before Do this before you use the web, command-line or mail interface and before
any users access the tracker. any users access the tracker.
This command will respond with either "Tracker updated" (if you've not This command will respond with either "Tracker updated" (if you've not
previously run it on an RDBMS backend) or "No migration action required" 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, (if you have run it, or have used another interface to the tracker,
or are using anydbm). or are using anydbm).
It's safe to run this even if it's not required, so just get into the It's safe to run this even if it's not required, so just get into the
habit. habit.
.. index:: upgrading; 1.3.3 to 1.4.0
Migrating from 1.3.3 to 1.4.0 Migrating from 1.3.3 to 1.4.0
============================= =============================
Value of the "refwd_re" tracker configuration option (section "mailgw") Value of the "refwd_re" tracker configuration option (section "mailgw")
is treated as UTF-8 string. In previous versions, it was ISO8859-1. is treated as UTF-8 string. In previous versions, it was ISO8859-1.
If you have running trackers based on the classic template, please If you have running trackers based on the classic template, please
update the messagesummary detector as follows:: update the messagesummary detector as follows::
--- detectors/messagesummary.py 17 Apr 2003 03:26:38 -0000 1.1 --- detectors/messagesummary.py 17 Apr 2003 03:26:38 -0000 1.1
skipping to change at line 1226 skipping to change at line 1659
newvalues['summary'] = summary newvalues['summary'] = summary
In the latest version we have added some database indexes to the In the latest version we have added some database indexes to the
SQL-backends (mysql, postgresql, sqlite) for speeding up building the SQL-backends (mysql, postgresql, sqlite) for speeding up building the
roundup-index for full-text search. We recommend that you create the roundup-index for full-text search. We recommend that you create the
following database indexes on the database by hand:: following database indexes on the database by hand::
CREATE INDEX words_by_id ON __words (_textid); CREATE INDEX words_by_id ON __words (_textid);
CREATE UNIQUE INDEX __textids_by_props ON __textids (_class, _itemid, _prop); CREATE UNIQUE INDEX __textids_by_props ON __textids (_class, _itemid, _prop);
.. index:: upgrading; 1.2.x to 1.3.0
Migrating from 1.2.x to 1.3.0 Migrating from 1.2.x to 1.3.0
============================= =============================
1.3.0 Web interface changes 1.3.0 Web interface changes
--------------------------- ---------------------------
Some of the HTML files in the "classic" and "minimal" tracker templates 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 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. them to the HTML files in your tracker and apply any changes.
.. index:: upgrading; 1.1.2 to 1.2.0
Migrating from 1.1.2 to 1.2.0 Migrating from 1.1.2 to 1.2.0
============================= =============================
1.2.0 Sorting and grouping by multiple properties 1.2.0 Sorting and grouping by multiple properties
------------------------------------------------- -------------------------------------------------
Starting with this version, 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 is possible. This means that request.sort and request.group are now
lists. This is reflected in several places: lists. This is reflected in several places:
skipping to change at line 1267 skipping to change at line 1704
by multiple attributes. For an example, see the classic template. You 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 may want search for the variable ``n_sort`` which can be set to the
number of sort/group properties. number of sort/group properties.
* Templates that diplay new headlines for each group of items with * Templates that diplay new headlines for each group of items with
equal group properties can now use the modified ``batch.propchanged`` equal group properties can now use the modified ``batch.propchanged``
method that can take several properties which are checked for method that can take several properties which are checked for
changes. See the example in the classic template which makes use of changes. See the example in the classic template which makes use of
``batch.propchanged``. ``batch.propchanged``.
.. index:: upgrading; 1.1.0 to 1.1.1
Migrating from 1.1.0 to 1.1.1 Migrating from 1.1.0 to 1.1.1
============================= =============================
1.1.1 "Clear this message" 1.1.1 "Clear this message"
-------------------------- --------------------------
In 1.1.1, the standard ``page.html`` template includes a "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 link in the green "ok" message bar that appears after a successful edit
(or other) action. (or other) action.
skipping to change at line 1295 skipping to change at line 1734
<p tal:condition="options/ok_message | nothing" class="ok-message"> <p tal:condition="options/ok_message | nothing" class="ok-message">
<span tal:repeat="m options/ok_message" <span tal:repeat="m options/ok_message"
tal:content="structure string:$m <br/ > " /> tal:content="structure string:$m <br/ > " />
<a class="form-small" tal:attributes="href request/current_url" <a class="form-small" tal:attributes="href request/current_url"
i18n:translate="">clear this message</a> i18n:translate="">clear this message</a>
</p> </p>
If you implemented the "clear this message" in your 1.1.0 tracker, then you 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! should change it to the above and it will work much better!
.. index:: upgrading; 1.0.x to 1.1.0
Migrating from 1.0.x to 1.1.0 Migrating from 1.0.x to 1.1.0
============================= =============================
1.1 Login "For Session Only" 1.1 Login "For Session Only"
---------------------------- ----------------------------
In 1.1, web logins are alive for the length of a session only, *unless* you 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``:: add the following to the login form in your tracker's ``page.html``::
<input type="checkbox" name="remember" id="remember"> <input type="checkbox" name="remember" id="remember">
skipping to change at line 1343 skipping to change at line 1784
to be:: to be::
<p tal:condition="options/ok_message | nothing" class="ok-message"> <p tal:condition="options/ok_message | nothing" class="ok-message">
<span tal:repeat="m options/ok_message" <span tal:repeat="m options/ok_message"
tal:content="structure string:$m <br/ > " /> tal:content="structure string:$m <br/ > " />
<a class="form-small" tal:attributes="href string:issue${context/id}" <a class="form-small" tal:attributes="href string:issue${context/id}"
i18n:translate="">clear this message</a> i18n:translate="">clear this message</a>
</p> </p>
.. index:: upgrading; 0.8.x to 1.0
Migrating from 0.8.x to 1.0 Migrating from 0.8.x to 1.0
=========================== ===========================
1.0 New Query Permissions 1.0 New Query Permissions
------------------------- -------------------------
New permissions are defined for query editing and viewing. To include these 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 in your tracker, you need to add these lines to your tracker's
``schema.py``:: ``schema.py``::
skipping to change at line 1382 skipping to change at line 1825
and then remove 'query' from the line:: and then remove 'query' from the line::
# Assign the access and edit Permissions for issue, file and message # Assign the access and edit Permissions for issue, file and message
# to regular users now # to regular users now
for cl in 'issue', 'file', 'msg', 'query', 'keyword': for cl in 'issue', 'file', 'msg', 'query', 'keyword':
so it looks like:: so it looks like::
for cl in 'issue', 'file', 'msg', 'keyword': for cl in 'issue', 'file', 'msg', 'keyword':
.. index:: upgrading; 0.8.0 to 0.8.3
Migrating from 0.8.0 to 0.8.3 Migrating from 0.8.0 to 0.8.3
============================= =============================
0.8.3 Nosy Handling Changes 0.8.3 Nosy Handling Changes
--------------------------- ---------------------------
A change was made to fix a bug in the ``nosyreaction.py`` standard 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 detector. To incorporate this fix in your trackers, you will need to copy
the ``nosyreaction.py`` file from the ``templates/classic/detectors`` the ``nosyreaction.py`` file from the ``templates/classic/detectors``
directory of the source to your tracker's ``templates`` directory. directory of the source to your tracker's ``templates`` directory.
If you have modified the ``nosyreaction.py`` file from the standard If you have modified the ``nosyreaction.py`` file from the standard
version, you will need to roll your changes into the new file. version, you will need to roll your changes into the new file.
.. index:: upgrading; 0.7.1 to 0.8.0
Migrating from 0.7.1 to 0.8.0 Migrating from 0.7.1 to 0.8.0
============================= =============================
You *must* fully uninstall previous Roundup version before installing You *must* fully uninstall previous Roundup version before installing
Roundup 0.8.0. If you don't do that, ``roundup-admin install`` Roundup 0.8.0. If you don't do that, ``roundup-admin install``
command may fail to function properly. command may fail to function properly.
0.8.0 Backend changes 0.8.0 Backend changes
--------------------- ---------------------
skipping to change at line 1546 skipping to change at line 1993
for name in dir(util): for name in dir(util):
if callable(getattr(util, name)) and not name.startswith('_'): if callable(getattr(util, name)) and not name.startswith('_'):
tracker.registerUtil(name, execUtil(name)) tracker.registerUtil(name, execUtil(name))
0.8.0 Logging Configuration 0.8.0 Logging Configuration
--------------------------- ---------------------------
See the `administration guide`_ for information about configuring the new See the `administration guide`_ for information about configuring the new
logging implemented in 0.8.0. logging implemented in 0.8.0.
.. index:: upgrading; 0.7.2 to 0.7.3
Migrating from 0.7.2 to 0.7.3 Migrating from 0.7.2 to 0.7.3
============================= =============================
0.7.3 Configuration 0.7.3 Configuration
------------------- -------------------
If you choose, you may specify the directory from which static files are If you choose, you may specify the directory from which static files are
served (those which use the URL component ``@@file``). Currently the served (those which use the URL component ``@@file``). Currently the
directory defaults to the ``TEMPLATES`` configuration variable. You may directory defaults to the ``TEMPLATES`` configuration variable. You may
define a new variable, ``STATIC_FILES`` which overrides this value for define a new variable, ``STATIC_FILES`` which overrides this value for
static files. static files.
.. index:: upgrading; 0.7.0 to 0.7.2
Migrating from 0.7.0 to 0.7.2 Migrating from 0.7.0 to 0.7.2
============================= =============================
0.7.2 DEFAULT_TIMEZONE is now required 0.7.2 DEFAULT_TIMEZONE is now required
-------------------------------------- --------------------------------------
The DEFAULT_TIMEZONE configuration variable is now required. Add the The DEFAULT_TIMEZONE configuration variable is now required. Add the
following to your tracker's ``config.py`` file:: following to your tracker's ``config.py`` file::
# You may specify a different default timezone, for use when users do not # You may specify a different default timezone, for use when users do not
# choose their own in their settings. # choose their own in their settings.
DEFAULT_TIMEZONE = 0 # specify as numeric hour offest DEFAULT_TIMEZONE = 0 # specify as numeric hour offest
.. index:: upgrading; 0.7.0 to 0.7.1
Migrating from 0.7.0 to 0.7.1 Migrating from 0.7.0 to 0.7.1
============================= =============================
0.7.1 Permission assignments 0.7.1 Permission assignments
---------------------------- ----------------------------
If you allow anonymous access to your tracker, you might need to assign 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 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 to the "anonymous" user. To do so, find the code in your ``dbinit.py`` that
says:: says::
skipping to change at line 1598 skipping to change at line 2051
p = db.security.getPermission('View', cl) p = db.security.getPermission('View', cl)
db.security.addPermissionToRole('User', p) db.security.addPermissionToRole('User', p)
Add add a line:: Add add a line::
db.security.addPermissionToRole('Anonymous', p) db.security.addPermissionToRole('Anonymous', p)
next to the existing ``'User'`` lines for the Permissions you wish to next to the existing ``'User'`` lines for the Permissions you wish to
assign to the anonymous user. assign to the anonymous user.
.. index:: upgrading; versions earlier than 0.7
Migrating from 0.6 to 0.7 Migrating from 0.6 to 0.7
========================= =========================
0.7.0 Permission assignments 0.7.0 Permission assignments
---------------------------- ----------------------------
Due to a change in the rendering of web widgets, permissions are now 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). checked on Classes where they previously weren't (this is a good thing).
You will need to add some additional Permission assignments for your You will need to add some additional Permission assignments for your
 End of changes. 27 change blocks. 
1 lines changed or deleted 458 lines changed or added

Home  |  About  |  Features  |  All  |  Newest  |  Dox  |  Diffs  |  RSS Feeds  |  Screenshots  |  Comments  |  Imprint  |  Privacy  |  HTTP(S)