Mercurial > p > roundup > code
diff 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 |
line wrap: on
line diff
--- a/doc/upgrading.txt Tue Apr 25 17:20:37 2023 -0400 +++ b/doc/upgrading.txt Tue Apr 25 17:24:32 2023 -0400 @@ -1969,1842 +1969,6 @@ 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 @@ -3814,3 +1978,5 @@ .. _`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