Mercurial Repository: p/roundup/code: doc/upgrading.txt comparison

comparison doc/upgrading.txt @ 7281:194093011cb7

Move upgrade directions for version < 1.5.0 to history document The upgrading doc is huge. Most people don't need docs more than 10 years old. Move docs for versions less than 1.5.0 (July 2013) to upgrading-history.txt. Probably could cut this back to 5 years (1.6.0 release in 2018) but lets go with 10 for now.

author	John Rouillard <rouilj@ieee.org>
date	Tue, 25 Apr 2023 17:24:32 -0400
parents	41b2a0e12899
children	c3b0fd62b0b8

comparison

equal deleted inserted replaced

-:2a735d785836
+:194093011cb7
 self.client.add_error_message(...)
 The new calls escape the passed string by default and avoid XSS security
 issues.
-.. index:: Upgrading; 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
-``<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:
-\http://myroundup.com/roundup
-you need to change the url to read:
-\http://myroundup.com/roundup/xmlrpc
-to invoke the xmlrpc handler. This allows us to send xml
-data to roundup for other handlers (e.g. REST, SOAP ...)
-in the future.
-.. index:: upgrading; 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
-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.
-.. index:: upgrading; 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
-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
-.. index:: upgrading; 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
-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`.
-.. _new search permissions for query in 1.4.17:
-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))
-.. index:: upgrading; 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"
-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.
-.. index:: upgrading; 1.4.x to 1.4.11
-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.
-.. index:: upgrading; 1.4.x to 1.4.9
-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.
-.. index:: upgrading; 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
-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
-.. index:: upgrading; 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
-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))".
-.. index:: upgrading; 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'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.
-.. index:: upgrading; 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")
-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);
-.. index:: upgrading; 1.2.x to 1.3.0
-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.
-.. index:: upgrading; 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
--------------------------------------------------
-Starting with this version, sorting and grouping by multiple properties
-is possible. This means that request.sort and request.group are now
-lists. This is reflected in several places:
-* ``renderWith`` now has list attributes for ``sort`` and ``group``,
-where you previously wrote::
-renderWith(... sort=('-', 'activity'), group=('+', 'priority')
-you write now::
-renderWith(... sort=[('-', 'activity')], group=[('+', 'priority')]
-* In templates that permit to edit sorting/grouping, request.sort and
-request.group are (possibly empty) lists. You can now sort and group
-by multiple attributes. For an example, see the classic template. You
-may want search for the variable ``n_sort`` which can be set to the
-number of sort/group properties.
-* Templates that diplay new headlines for each group of items with
-equal group properties can now use the modified ``batch.propchanged``
-method that can take several properties which are checked for
-changes. See the example in the classic template which makes use of
-``batch.propchanged``.
-.. index:: upgrading; 1.1.0 to 1.1.1
-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!
-.. index:: upgrading; 1.0.x to 1.1.0
-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>
-.. index:: upgrading; 0.8.x to 1.0
-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':
-.. index:: upgrading; 0.8.0 to 0.8.3
-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.
-.. index:: upgrading; 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
-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`` contents        ``backend_name`` contents
-================================ =========================
-from back_anydbm import ...      anydbm
-from back_metakit import ...     metakit
-from back_sqlite import ...      sqlite
-from back_mysql import ...       mysql
-from back_postgresql import ...  postgresql
-================================ =========================
-The ``dbinit.py`` file has been split into two new files,
-``initial_data.py`` and ``schema.py``. The contents of this file are:
-``initial_data.py``
-You don't need one of these as your tracker is already initialised.
-``schema.py``
-Copy the body of the ``def open(name=None)`` function from your old
-tracker's ``dbinit.py`` file to this file. As the lines you're copying
-aren't part of a function definition anymore, one level of indentation
-needs to be removed (remove only the leading four spaces on each
-line).
-The first few lines -- those starting with ``from roundup.hyperdb
-import ...`` and the ``db = Database(config, name)`` line -- don't
-need to be copied. Neither do the last few lines -- those starting
-with ``import detectors``, down to ``return db`` inclusive.
-You may remove the ``__init__.py`` module from the "detectors" directory as
-it is no longer used.
-There's a new way to write extension code for Roundup. If you have code in
-an ``interfaces.py`` file you should move it. See the `customisation
-documentation`_ for information about how extensions are now written.
-Note that some older trackers may use ``interfaces.py`` to customise the
-mail gateway behaviour. You will need to keep your ``interfaces.py`` file
-if this is the case.
-0.8.0 Permissions Changes
--------------------------
-The creation of a new item in the user interfaces is now controlled by the
-"Create" Permission. You will need to add an assignment of this Permission
-to your users who are allowed to create items. The most common form of this
-is the following in your ``schema.py`` added just under the current
-assignation of the Edit Permission::
-for cl in 'issue', 'file', 'msg', 'query', 'keyword':
-p = db.security.getPermission('Create', cl)
-db.security.addPermissionToRole('User', p)
-You will need to explicitly let anonymous users access the web interface so
-that regular users are able to see the login form. Note that almost all
-trackers will need this Permission. The only situation where it's not
-required is in a tracker that uses an HTTP Basic Authenticated front-end.
-It's enabled by adding to your ``schema.py``::
-p = db.security.getPermission('Web Access')
-db.security.addPermissionToRole('Anonymous', p)
-Finally, you will need to enable permission for your users to edit their
-own details by adding the following to ``schema.py``::
-# Users should be able to edit their own details. Note that this
-# permission is limited to only the situation where the Viewed or
-# Edited item is their own.
-def own_record(db, userid, itemid):
-'''Determine whether the userid matches the item being accessed.'''
-return userid == itemid
-p = db.security.addPermission(name='View', klass='user', check=own_record,
-description="User is allowed to view their own user details")
-p = db.security.addPermission(name='Edit', klass='user', check=own_record,
-description="User is allowed to edit their own user details")
-db.security.addPermissionToRole('User', p)
-0.8.0 Use of TemplatingUtils
-----------------------------
-If you used custom python functions in TemplatingUtils, they must
-be moved from interfaces.py to a new file in the ``extensions`` directory.
-Each Function that should be available through TAL needs to be defined
-as a toplevel function in the newly created file. Furthermore you
-add an inititialization function, that registers the functions with the
-tracker.
-If you find this too tedious, donfu wrote an automatic init function that
-takes an existing TemplatingUtils class, and registers all class methods
-that do not start with an underscore. The following hack should be placed
-in the ``extensions`` directory alongside other extensions::
-class TemplatingUtils:
-# copy from interfaces.py
-def init(tracker):
-util = TemplatingUtils()
-def setClient(tu):
-util.client = tu.client
-return util
-def execUtil(name):
-return lambda tu, *args, **kwargs: \
-getattr(setClient(tu), name)(*args, **kwargs)
-for name in dir(util):
-if callable(getattr(util, name)) and not name.startswith('_'):
-tracker.registerUtil(name, execUtil(name))
-0.8.0 Logging Configuration
----------------------------
-See the `administration guide`_ for information about configuring the new
-logging implemented in 0.8.0.
-.. index:: upgrading; 0.7.2 to 0.7.3
-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.
-.. index:: upgrading; 0.7.0 to 0.7.2
-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
-.. index:: upgrading; 0.7.0 to 0.7.1
-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.
-.. index:: upgrading; versions earlier than 0.7
-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:
-https://sourceforge.net/projects/roundup/lists/roundup-users
-See the customisation doc section on `Form Values`__ for documentation of the
-new form variables possible.
-__ customizing.html#form-values
-0.6.0 Multilingual character set support
-----------------------------------------
-Added internationalization support. This is done via encoding all data
-stored in roundup database to utf-8 (unicode encoding). To support utf-8 in
-web interface you should add the folowing line to your tracker's html/page
-and html/_generic.help files inside <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`__.
-__ customizing.html#searching-on-categories
-Also, the url field in the query class no longer starts with a '?'. You'll need
-to remove this question mark from the url field to support queries. There's
-a script in the "tools" directory called ``migrate-queries.py`` that should
-automatically change any existing queries for you. As always, make a backup
-of your database before running such a script.
-0.6.0 Notes for metakit backend users
--------------------------------------
-Roundup 0.6.0 introduced searching on ranges of dates and intervals. To
-support it, some modifications to interval storing routine were made. So if
-your tracker uses metakit backend and your db schema contains intervals
-property, searches on that property will not be accurate for db items that
-was stored before roundup' upgrade. However all new records should be
-searchable on intervals.
-It is possible to convert your database to new format: you can export and
-import back all your data (consult "Migrating backends" in "Maintenance"
-documentation). After this operation all your interval properties should
-become searchable.
-Users of backends others than metakit should not worry about this issue.
-Migrating from 0.4.x to 0.5.0
-=============================
-This has been a fairly major revision of Roundup:
-1. Brand new, much more powerful, flexible, tasty and nutritious templating.
-Unfortunately, this means all your current templates are useless. Hopefully
-the new documentation and examples will be enough to help you make the
-transition. Please don't hesitate to ask on roundup-users for help (or
-complete conversions if you're completely stuck)!
-2. The database backed got a lot more flexible, allowing Metakit and SQL
-databases! The only decent SQL database implemented at present is sqlite,
-but others shouldn't be a whole lot more work.
-3. A brand new, highly flexible and much more robust security system including
-a system of Permissions, Roles and Role assignments to users. You may now
-define your own Permissions that may be checked in CGI transactions.
-4. Journalling has been made less storage-hungry, so has been turned on
-by default *except* for author, recipient and nosy link/unlink events. You
-are advised to turn it off in your trackers too.
-5. We've changed the terminology from "instance" to "tracker", to ease the
-learning curve/impact for new users.
-6. Because of the above changes, the tracker configuration has seen some
-major changes. See below for the details.
-Please, **back up your database** before you start the migration process. This
-is as simple as copying the "db" directory and all its contents from your
-tracker to somewhere safe.
-0.5.0 Configuration
--------------------
-First up, rename your ``instance_config.py`` file to just ``config.py``.
-Then edit your tracker's ``__init__.py`` module. It'll currently look
-like this::
-from instance_config import *
-try:
-from dbinit import *
-except ImportError:
-pass # in installdir (probably :)
-from interfaces import *
-and it needs to be::
-import config
-from dbinit import open, init
-from interfaces import Client, MailGW
-Due to the new templating having a top-level ``page`` that defines links for
-searching, indexes, adding items etc, the following variables are no longer
-used:
-- HEADER_INDEX_LINKS
-- HEADER_ADD_LINKS
-- HEADER_SEARCH_LINKS
-- SEARCH_FILTERS
-- DEFAULT_INDEX
-- UNASSIGNED_INDEX
-- USER_INDEX
-- ISSUE_FILTER
-The new security implementation will require additions to the dbinit module,
-but also removes the need for the following tracker config variables:
-- ANONYMOUS_ACCESS
-- ANONYMOUS_REGISTER
-but requires two new variables which define the Roles assigned to users who
-register through the web and e-mail interfaces:
-- NEW_WEB_USER_ROLES
-- NEW_EMAIL_USER_ROLES
-in both cases, 'User' is a good initial setting. To emulate
-``ANONYMOUS_ACCESS='deny'``, remove all "View" Permissions from the
-"Anonymous" Role. To emulate ``ANONYMOUS_REGISTER='deny'``, remove the "Web
-Registration" and/or the "Email Registration" Permission from the "Anonymous"
-Role. See the section on customising security in the `customisation
-documentation`_ for more information.
-Finally, the following config variables have been renamed to make more sense:
-- INSTANCE_HOME -> TRACKER_HOME
-- INSTANCE_NAME -> TRACKER_NAME
-- ISSUE_TRACKER_WEB -> TRACKER_WEB
-- ISSUE_TRACKER_EMAIL -> TRACKER_EMAIL
-0.5.0 Schema Specification
---------------------------
-0.5.0 Database backend changes
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Your select_db module in your tracker has changed a fair bit. Where it used
-to contain::
-# WARNING: DO NOT EDIT THIS FILE!!!
-from roundup.backends.back_anydbm import Database
-it must now contain::
-# WARNING: DO NOT EDIT THIS FILE!!!
-from roundup.backends.back_anydbm import Database, Class, FileClass, IssueClass
-Yes, I realise the irony of the "DO NOT EDIT THIS FILE" statement :)
-Note the addition of the Class, FileClass, IssueClass imports. These are very
-important, as they're going to make the next change work too. You now need to
-modify the top of the dbinit module in your tracker from::
-import instance_config
-from roundup import roundupdb
-from select_db import Database
-from roundup.roundupdb import Class, FileClass
-class Database(roundupdb.Database, select_db.Database):
-''' Creates a hybrid database from:
-. the selected database back-end from select_db
-. the roundup extensions from roundupdb
-'''
-pass
-class IssueClass(roundupdb.IssueClass):
-''' issues need the email information
-'''
-pass
-to::
-import config
-from select_db import Database, Class, FileClass, IssueClass
-Yes, remove the Database and IssueClass definitions and those other imports.
-They're not needed any more!
-Look for places in dbinit.py where ``instance_config`` is used too, and
-rename them ``config``.
-0.5.0 Journalling changes
-~~~~~~~~~~~~~~~~~~~~~~~~~
-Journalling has been optimised for storage. Journalling of links has been
-turned back on by default. If your tracker has a large user base, you may wish
-to turn off journalling of nosy list, message author and message recipient
-link and unlink events. You do this by adding ``do_journal='no'`` to the Class
-initialisation in your dbinit. For example, your *msg* class initialisation
-probably looks like this::
-msg = FileClass(db, "msg",
-author=Link("user"), recipients=Multilink("user"),
-date=Date(),         summary=String(),
-files=Multilink("file"),
-messageid=String(),  inreplyto=String())
-to turn off journalling of author and recipient link events, add
-``do_journal='no'`` to the ``author=Link("user")`` part of the statement,
-like so::
-msg = FileClass(db, "msg",
-author=Link("user", do_journal='no'),
-recipients=Multilink("user", do_journal='no'),
-date=Date(),         summary=String(),
-files=Multilink("file"),
-messageid=String(),  inreplyto=String())
-Nosy list link event journalling is actually turned off by default now. If you
-want to turn it on, change to your issue class' nosy list, change its
-definition from::
-issue = IssueClass(db, "issue",
-assignedto=Link("user"), topic=Multilink("keyword"),
-priority=Link("priority"), status=Link("status"))
-to::
-issue = IssueClass(db, "issue", nosy=Multilink("user", do_journal='yes'),
-assignedto=Link("user"), topic=Multilink("keyword"),
-priority=Link("priority"), status=Link("status"))
-noting that your definition of the nosy Multilink will override the normal one.
-0.5.0 User schema changes
-~~~~~~~~~~~~~~~~~~~~~~~~~
-Users have two more properties, "queries" and "roles". You'll have something
-like this in your dbinit module now::
-user = Class(db, "user",
-username=String(),   password=Password(),
-address=String(),    realname=String(),
-phone=String(),      organisation=String(),
-alternate_addresses=String())
-user.setkey("username")
-and you'll need to add the new properties and the new "query" class to it
-like so::
-query = Class(db, "query",
-klass=String(),     name=String(),
-url=String())
-query.setkey("name")
-# Note: roles is a comma-separated string of Role names
-user = Class(db, "user",
-username=String(),   password=Password(),
-address=String(),    realname=String(),
-phone=String(),      organisation=String(),
-alternate_addresses=String(),
-queries=Multilink('query'), roles=String())
-user.setkey("username")
-The "queries" property is used to store off the user's favourite database
-queries. The "roles" property is explained below in `0.5.0 Security
-Settings`_.
-0.5.0 Security Settings
-~~~~~~~~~~~~~~~~~~~~~~~
-See the `security documentation`_ for an explanation of how the new security
-system works. In a nutshell though, the security is handled as a four step
-process:
-1. Permissions are defined as having a name and optionally a hyperdb class
-they're specific to,
-2. Roles are defined that have one or more Permissions,
-3. Users are assigned Roles in their "roles" property, and finally
-4. Roundup checks that users have appropriate Permissions at appropriate times
-(like editing issues).
-Your tracker dbinit module's *open* function now has to define any
-Permissions that are specific to your tracker, and also the assignment
-of Permissions to Roles. At the moment, your open function
-ends with::
-import detectors
-detectors.init(db)
-return db
-and what we need to do is insert some commands that will set up the security
-parameters. Right above the ``import detectors`` line, you'll want to insert
-these lines::
-#
-# SECURITY SETTINGS
-#
-# new permissions for this schema
-for cl in 'issue', 'file', 'msg', 'user':
-db.security.addPermission(name="Edit", klass=cl,
-description="User is allowed to edit "+cl)
-db.security.addPermission(name="View", klass=cl,
-description="User is allowed to access "+cl)
-# Assign the access and edit permissions for issue, file and message
-# to regular users now
-for cl in 'issue', 'file', 'msg':
-p = db.security.getPermission('View', cl)
-db.security.addPermissionToRole('User', p)
-p = db.security.getPermission('Edit', cl)
-db.security.addPermissionToRole('User', p)
-# and give the regular users access to the web and email interface
-p = db.security.getPermission('Web Access')
-db.security.addPermissionToRole('User', p)
-p = db.security.getPermission('Email Access')
-db.security.addPermissionToRole('User', p)
-# May users view other user information? Comment these lines out
-# if you don't want them to
-p = db.security.getPermission('View', 'user')
-db.security.addPermissionToRole('User', p)
-# Assign the appropriate permissions to the anonymous user's Anonymous
-# Role. Choices here are:
-# - Allow anonymous users to register through the web
-p = db.security.getPermission('Web Registration')
-db.security.addPermissionToRole('Anonymous', p)
-# - Allow anonymous (new) users to register through the email gateway
-p = db.security.getPermission('Email Registration')
-db.security.addPermissionToRole('Anonymous', p)
-# - Allow anonymous users access to the "issue" class of data
-#   Note: this also grants access to related information like files,
-#         messages, statuses etc that are linked to issues
-#p = db.security.getPermission('View', 'issue')
-#db.security.addPermissionToRole('Anonymous', p)
-# - Allow anonymous users access to edit the "issue" class of data
-#   Note: this also grants access to create related information like
-#         files and messages etc that are linked to issues
-#p = db.security.getPermission('Edit', 'issue')
-#db.security.addPermissionToRole('Anonymous', p)
-# oh, g'wan, let anonymous access the web interface too
-p = db.security.getPermission('Web Access')
-db.security.addPermissionToRole('Anonymous', p)
-Note in the comments there the places where you might change the permissions
-to restrict users or grant users more access. If you've created additional
-classes that users should be able to edit and view, then you should add them
-to the "new permissions for this schema" section at the start of the security
-block. Then add them to the "Assign the access and edit permissions" section
-too, so people actually have the new Permission you've created.
-One final change is needed that finishes off the security system's
-initialisation. We need to add a call to ``db.post_init()`` at the end of the
-dbinit open() function. Add it like this::
-import detectors
-detectors.init(db)
-# schema is set up - run any post-initialisation
-db.post_init()
-return db
-You may verify the setup of Permissions and Roles using the new
-"``roundup-admin security``" command.
-0.5.0 User changes
-~~~~~~~~~~~~~~~~~~
-To support all those schema changes, you'll need to massage your user database
-a little too, to:
-1. make sure there's an "anonymous" user - this user is mandatory now and is
-the one that unknown users are logged in as.
-2. make sure all users have at least one Role.
-If you don't have the "anonymous" user, create it now with the command::
-roundup-admin create user username=anonymous roles=Anonymous
-making sure the capitalisation is the same as above. Once you've done that,
-you'll need to set the roles property on all users to a reasonable default.
-The admin user should get "Admin", the anonymous user "Anonymous"
-and all other users "User". The ``fixroles.py`` script in the tools directory
-will do this. Run it like so (where python is your python 2+ binary)::
-python tools/fixroles.py -i <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:
-1. Edit the dbinit.py file in your instance home directory
-a. At the first code line of the open() function::
-from roundup.hyperdb import String, Date, Link, Multilink
-alter to include Password, as so::
-from roundup.hyperdb import String, Password, Date, Link, Multilink
-b. Where the password property is defined (around line 66)::
-user = Class(db, "user",
-username=String(),   password=String(),
-address=String(),    realname=String(),
-phone=String(),      organisation=String())
-user.setkey("username")
-alter the "password=String()" to "password=Password()"::
-user = Class(db, "user",
-username=String(),   password=Password(),
-address=String(),    realname=String(),
-phone=String(),      organisation=String())
-user.setkey("username")
-2. Any existing passwords in the database will remain cleartext until they
-are edited. It is recommended that at a minimum the admin password be
-changed immediately::
-roundup-admin -i <instance home> set user1 password=<new password>
-0.3.x Configuration
--------------------
-FILTER_POSITION, ANONYMOUS_ACCESS, ANONYMOUS_REGISTER have been added to
-the instance_config.py. Simplest solution is to copy the default values from
-template in the core source.
-MESSAGES_TO_AUTHOR has been added to the IssueClass in dbinit.py. Set to 'yes'
-to send nosy messages to the author. Default behaviour is to not send nosy
-messages to the author. You will need to add MESSAGES_TO_AUTHOR to your
-dbinit.py in your instance home.
-0.3.x CGI script roundup.cgi
-----------------------------
-There have been some structural changes to the roundup.cgi script - you will
-need to install it again from the cgi-bin directory of the source
-distribution. Make sure you update the ROUNDUP_INSTANCE_HOMES after the
-copy.
 .. _`customisation documentation`: customizing.html
 .. _`security documentation`: security-history.html
 .. _`administration guide`: admin_guide.html
 .. _`xmlrpc guide`: xmlrpc.html
 .. _FTS5 full-text search engine: https://www.sqlite.org/fts5.html
 .. _PostgreSQL's full text search: https://www.postgresql.org/docs/current/textsearch.html
 .. _`administration guide notes on native-fts`: admin_guide.html#configuring-native-fts-full-text-search
 .. _Configuring Compression: admin_guide.html#configuring-compression
 .. _Software Upgrade: admin_guide.html#software-upgrade
+.. _new search permissions for query in 1.4.17:
+upgrading-history.html#new-search-permissions-for-query-in-1-4-17

Mercurial > p > roundup > code

comparison doc/upgrading.txt @ 7281:194093011cb7