![[tokkee]](http://tokkee.org/images/avatar.png){kind=avatar}
diff --git a/doc/upgrading.txt b/doc/upgrading.txt
index 13f4613dbaffa50cfd3ec130a3f87b73c325bd49..8b722239d65adcc0c914912c625b237d1792634b 100644 (file)
--- a/doc/upgrading.txt
+++ b/doc/upgrading.txt
.. contents::
+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>
+
+0.6.0 Form handling changes
+---------------------------
+
+XXX Form handling changed significantly! Document it!
+
+lose :multilink
+name:confirm -> :confirm:name
+
+
+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 has 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 should 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.
+
+ However you are not forced to make these modifications. By default roundup
+ will assume timezone=0 and will work as previous versions did.
+
Migrating from 0.4.x to 0.5.0
=============================
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 SQL database implemented at present is gadfly, but
- others shouldn't be a whole lot more work.
+ 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.
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
--------------------------
messageid=String(), inreplyto=String())
Nosy list link event journalling is actually turned off by default now. If you
-want to turn it onn, change to your issue class' nosy list, change its
+want to turn it on, change to your issue class' nosy list, change its
definition from::
issue = IssueClass(db, "issue",
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>
+ python tools/fixroles.py -i <tracker home> fixroles
end result is that this section of your tracker interfaces module will need
changing from::
- from roundup import mailgw
- from roundup.cgi import client
+ from roundup import cgi_client, mailgw
+ from roundup.i18n import _
- class Client(client.Client):
+ class Client(cgi_client.Client):
''' derives basic CGI implementation from the standard module,
with any specific extensions
'''
to::
- from roundup import cgi_client, mailgw
- from roundup.i18n import _
+ from roundup import mailgw
+ from roundup.cgi import client
- class Client(cgi_client.Client):
+ class Client(client.Client):
''' derives basic CGI implementation from the standard module,
with any specific extensions
'''
0.4.0 Configuration
--------------------
-``INSTANCE_NAME`` and ``EMAIL_SIGNATURE_POSITION`` have been added to the
+``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.