1 ======================================
2 Upgrading to newer versions of Roundup
3 ======================================
5 Please read each section carefully and edit your tracker home files
6 accordingly. Note that there is information about upgrade procedures in the
7 `administration guide`_.
9 .. contents::
11 Migrating from 0.6 to 0.7
12 =========================
14 0.7.0 Extending the cgi interface
15 ---------------------------------
17 Before 0.7.0 adding or extending web actions was done by overriding or adding
18 methods on the Client class. Though this approach still works to provide
19 backwards compatibility, it is recommended you upgrade to the new approach, as
20 described in the `Defining new web actions`__ section of the customization
21 documentation. You might also want to take a look at the `Using an external
22 password validation source`__ example.
24 __ customizing.html#defining-new-web-actions
25 __ customizing.html#using-an-external-password-validation-source
27 0.7.0 Getting the current user id
28 ---------------------------------
30 Removed Database.curuserid attribute. Any code referencing this attribute
31 should be replaced with a call to Database.getuid().
34 0.7.0 Email character set
35 -------------------------
37 The default character set for sending email is UTF-8 (ie. Unicode). If you
38 have users whose email clients can't handle UTF-8 (eg. Eudora) then you
39 will need to edit the new config.py variable ``EMAIL_CHARSET``.
42 0.7.0 ZRoundup changes
43 ----------------------
45 The templates in your tracker's html directory will need updating if you
46 wish to use ZRoundup. If you've not modified those files (or some of them),
47 you may just copy the new versions from the Roundup source in the
48 templates/classic/html directory.
50 If you have modified the html files, then you'll need to manually edit them
51 to change all occurances of special form variables from using the colon ":"
52 special character to the at "@" special character. That is, variables such
53 as::
55 :action :required :template :remove:messages ...
57 should become:
59 @action @required @template @remove@messages ...
61 Note that ``tal:`` statements are unaffected. So are TAL expression type
62 prefixes such as ``python:`` and ``string:``. Please ask on the
63 roundup-users mailing list for help if you're unsure.
66 Migrating from 0.6.x to 0.6.3
67 =============================
69 0.6.3 Configuration
70 -------------------
72 You will need to copy the file::
74 templates/classic/detectors/__init__.py
76 to your tracker's ``detectors`` directory, replacing the one already there.
77 This fixes a couple of bugs in that file.
81 Migrating from 0.5 to 0.6
82 =========================
85 0.6.0 Configuration
86 -------------------
88 Introduced EMAIL_FROM_TAG config variable. This value is inserted into
89 the From: line of nosy email. If the sending user is "Foo Bar", the
90 From: line is usually::
92 "Foo Bar" <issue_tracker@tracker.example>
94 the EMAIL_FROM_TAG goes inside the "Foo Bar" quotes like so::
96 "Foo Bar EMAIL_FROM_TAG" <issue_tracker@tracker.example>
98 I've altered the mechanism in the detectors __init__.py module so that it
99 doesn't cross-import detectors from other trackers (if you run more than one
100 in a single roundup-server). This change means that you'll need to copy the
101 __init__.py from roundup/templates/classic/detectors/__init__.py to your
102 <tracker home>/detectors/__init__.py. Don't worry, the "classic" __init__ is a
103 one-size-fits-all, so it'll work even if you've added/removed detectors.
105 0.6.0 Templating changes
106 ------------------------
108 The ``user.item`` template (in the tracker home "templates" directory)
109 needs to have the following hidden variable added to its form (between the
110 ``<form...>`` and ``</form>`` tags::
112 <input type="hidden" name=":template" value="item">
115 0.6.0 Form handling changes
116 ---------------------------
118 Roundup's form handling capabilities have been significantly expanded. This
119 should not affect users of 0.5 installations - but if you find you're
120 getting errors from form submissions, please ask for help on the Roundup
121 users mailing list:
123 http://lists.sourceforge.net/lists/listinfo/roundup-users
125 See the customisation doc section on `Form Values`__ for documentation of the
126 new form variables possible.
128 __ customizing.html#form-values
131 0.6.0 Multilingual character set support
132 ----------------------------------------
134 Added internationalization support. This is done via encoding all data
135 stored in roundup database to utf-8 (unicode encoding). To support utf-8 in
136 web interface you should add the folowing line to your tracker's html/page
137 and html/_generic.help files inside <head> tag::
139 <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
141 Since latin characters in utf-8 have the same codes as in ASCII table, this
142 modification is optional for users who use only plain latin characters.
144 After this modification, you will be able to see and enter any world
145 character via web interface. Data received via mail interface also converted
146 to utf-8, however only new messages will be converted. If your roundup
147 database contains some of non-ASCII characters in one of 8-bit encoding,
148 they will not be visible in new unicode environment. Some of such data (e.g.
149 user names, keywords, etc) can be edited by administrator, the others
150 (e.g. messages' contents) is not editable via web interface. Currently there
151 is no tool for converting such data, the only solution is to close
152 appropriate old issues and create new ones with the same content.
155 0.6.0 User timezone support
156 ---------------------------
158 From version 0.6.0 roundup supports displaying of Date data in user' local
159 timezone if he/she has provided timezone information. To make it possible
160 some modification to tracker's schema and HTML templates are required.
161 First you must add string property 'timezone' to user class in dbinit.py
162 like this::
164 user = Class(db, "user",
165 username=String(), password=Password(),
166 address=String(), realname=String(),
167 phone=String(), organisation=String(),
168 alternate_addresses=String(),
169 queries=Multilink('query'), roles=String(),
170 timezone=String())
172 And second - html interface. Add following lines to
173 $TRACKER_HOME/html/user.item template::
175 <tr>
176 <th>Timezone</th>
177 <td tal:content="structure context/timezone/field">timezone</td>
178 </tr>
180 After that all users should be able to provide their timezone information.
181 Timezone should be a positive or negative integer - offset from GMT.
183 After providing timezone, roundup will show all dates values, found in web
184 and mail interfaces in local time. It will also accept any Date info in
185 local time, convert and store it in GMT.
188 0.6.0 Search page structure
189 ---------------------------
191 In order to accomodate query editing the search page has been restructured. If
192 you want to provide your users with query editing, you should update your
193 search page using the macros detailed in the customisation doc section
194 `Searching on categories`__.
196 __ customizing.html#searching-on-categories
198 Also, the url field in the query class no longer starts with a '?'. You'll need
199 to remove this question mark from the url field to support queries. There's
200 a script in the "tools" directory called ``migrate-queries.py`` that should
201 automatically change any existing queries for you. As always, make a backup
202 of your database before running such a script.
205 0.6.0 Notes for metakit backend users
206 -------------------------------------
208 Roundup 0.6.0 introduced searching on ranges of dates and intervals. To
209 support it, some modifications to interval storing routine were made. So if
210 your tracker uses metakit backend and your db schema contains intervals
211 property, searches on that property will not be accurate for db items that
212 was stored before roundup' upgrade. However all new records should be
213 searchable on intervals.
215 It is possible to convert your database to new format: you can export and
216 import back all your data (consult "Migrating backends" in "Maintenance"
217 documentation). After this operation all your interval properties should
218 become searchable.
220 Users of backends others than metakit should not worry about this issue.
223 Migrating from 0.4.x to 0.5.0
224 =============================
226 This has been a fairly major revision of Roundup:
228 1. Brand new, much more powerful, flexible, tasty and nutritious templating.
229 Unfortunately, this means all your current templates are useless. Hopefully
230 the new documentation and examples will be enough to help you make the
231 transition. Please don't hesitate to ask on roundup-users for help (or
232 complete conversions if you're completely stuck)!
233 2. The database backed got a lot more flexible, allowing Metakit and SQL
234 databases! The only decent SQL database implemented at present is sqlite,
235 but others shouldn't be a whole lot more work.
236 3. A brand new, highly flexible and much more robust security system including
237 a system of Permissions, Roles and Role assignments to users. You may now
238 define your own Permissions that may be checked in CGI transactions.
239 4. Journalling has been made less storage-hungry, so has been turned on
240 by default *except* for author, recipient and nosy link/unlink events. You
241 are advised to turn it off in your trackers too.
242 5. We've changed the terminology from "instance" to "tracker", to ease the
243 learning curve/impact for new users.
244 6. Because of the above changes, the tracker configuration has seen some
245 major changes. See below for the details.
247 Please, **back up your database** before you start the migration process. This
248 is as simple as copying the "db" directory and all its contents from your
249 tracker to somewhere safe.
252 0.5.0 Configuration
253 -------------------
255 First up, rename your ``instance_config.py`` file to just ``config.py``.
257 Then edit your tracker's ``__init__.py`` module. It'll currently look
258 like this::
260 from instance_config import *
261 try:
262 from dbinit import *
263 except ImportError:
264 pass # in installdir (probably :)
265 from interfaces import *
267 and it needs to be::
269 import config
270 from dbinit import open, init
271 from interfaces import Client, MailGW
273 Due to the new templating having a top-level ``page`` that defines links for
274 searching, indexes, adding items etc, the following variables are no longer
275 used:
277 - HEADER_INDEX_LINKS
278 - HEADER_ADD_LINKS
279 - HEADER_SEARCH_LINKS
280 - SEARCH_FILTERS
281 - DEFAULT_INDEX
282 - UNASSIGNED_INDEX
283 - USER_INDEX
284 - ISSUE_FILTER
286 The new security implementation will require additions to the dbinit module,
287 but also removes the need for the following tracker config variables:
289 - ANONYMOUS_ACCESS
290 - ANONYMOUS_REGISTER
292 but requires two new variables which define the Roles assigned to users who
293 register through the web and e-mail interfaces:
295 - NEW_WEB_USER_ROLES
296 - NEW_EMAIL_USER_ROLES
298 in both cases, 'User' is a good initial setting. To emulate
299 ``ANONYMOUS_ACCESS='deny'``, remove all "View" Permissions from the
300 "Anonymous" Role. To emulate ``ANONYMOUS_REGISTER='deny'``, remove the "Web
301 Registration" and/or the "Email Registration" Permission from the "Anonymous"
302 Role. See the section on customising security in the `customisation
303 documentation`_ for more information.
305 Finally, the following config variables have been renamed to make more sense:
307 - INSTANCE_HOME -> TRACKER_HOME
308 - INSTANCE_NAME -> TRACKER_NAME
309 - ISSUE_TRACKER_WEB -> TRACKER_WEB
310 - ISSUE_TRACKER_EMAIL -> TRACKER_EMAIL
313 0.5.0 Schema Specification
314 --------------------------
316 0.5.0 Database backend changes
317 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
319 Your select_db module in your tracker has changed a fair bit. Where it used
320 to contain::
322 # WARNING: DO NOT EDIT THIS FILE!!!
323 from roundup.backends.back_anydbm import Database
325 it must now contain::
327 # WARNING: DO NOT EDIT THIS FILE!!!
328 from roundup.backends.back_anydbm import Database, Class, FileClass, IssueClass
330 Yes, I realise the irony of the "DO NOT EDIT THIS FILE" statement :)
331 Note the addition of the Class, FileClass, IssueClass imports. These are very
332 important, as they're going to make the next change work too. You now need to
333 modify the top of the dbinit module in your tracker from::
335 import instance_config
336 from roundup import roundupdb
337 from select_db import Database
339 from roundup.roundupdb import Class, FileClass
341 class Database(roundupdb.Database, select_db.Database):
342 ''' Creates a hybrid database from:
343 . the selected database back-end from select_db
344 . the roundup extensions from roundupdb
345 '''
346 pass
348 class IssueClass(roundupdb.IssueClass):
349 ''' issues need the email information
350 '''
351 pass
353 to::
355 import config
356 from select_db import Database, Class, FileClass, IssueClass
358 Yes, remove the Database and IssueClass definitions and those other imports.
359 They're not needed any more!
361 Look for places in dbinit.py where ``instance_config`` is used too, and
362 rename them ``config``.
365 0.5.0 Journalling changes
366 ~~~~~~~~~~~~~~~~~~~~~~~~~
368 Journalling has been optimised for storage. Journalling of links has been
369 turned back on by default. If your tracker has a large user base, you may wish
370 to turn off journalling of nosy list, message author and message recipient
371 link and unlink events. You do this by adding ``do_journal='no'`` to the Class
372 initialisation in your dbinit. For example, your *msg* class initialisation
373 probably looks like this::
375 msg = FileClass(db, "msg",
376 author=Link("user"), recipients=Multilink("user"),
377 date=Date(), summary=String(),
378 files=Multilink("file"),
379 messageid=String(), inreplyto=String())
381 to turn off journalling of author and recipient link events, add
382 ``do_journal='no'`` to the ``author=Link("user")`` part of the statement,
383 like so::
385 msg = FileClass(db, "msg",
386 author=Link("user", do_journal='no'),
387 recipients=Multilink("user", do_journal='no'),
388 date=Date(), summary=String(),
389 files=Multilink("file"),
390 messageid=String(), inreplyto=String())
392 Nosy list link event journalling is actually turned off by default now. If you
393 want to turn it on, change to your issue class' nosy list, change its
394 definition from::
396 issue = IssueClass(db, "issue",
397 assignedto=Link("user"), topic=Multilink("keyword"),
398 priority=Link("priority"), status=Link("status"))
400 to::
402 issue = IssueClass(db, "issue", nosy=Multilink("user", do_journal='yes'),
403 assignedto=Link("user"), topic=Multilink("keyword"),
404 priority=Link("priority"), status=Link("status"))
406 noting that your definition of the nosy Multilink will override the normal one.
409 0.5.0 User schema changes
410 ~~~~~~~~~~~~~~~~~~~~~~~~~
412 Users have two more properties, "queries" and "roles". You'll have something
413 like this in your dbinit module now::
415 user = Class(db, "user",
416 username=String(), password=Password(),
417 address=String(), realname=String(),
418 phone=String(), organisation=String(),
419 alternate_addresses=String())
420 user.setkey("username")
422 and you'll need to add the new properties and the new "query" class to it
423 like so::
425 query = Class(db, "query",
426 klass=String(), name=String(),
427 url=String())
428 query.setkey("name")
430 # Note: roles is a comma-separated string of Role names
431 user = Class(db, "user",
432 username=String(), password=Password(),
433 address=String(), realname=String(),
434 phone=String(), organisation=String(),
435 alternate_addresses=String(),
436 queries=Multilink('query'), roles=String())
437 user.setkey("username")
439 The "queries" property is used to store off the user's favourite database
440 queries. The "roles" property is explained below in `0.5.0 Security
441 Settings`_.
444 0.5.0 Security Settings
445 ~~~~~~~~~~~~~~~~~~~~~~~
447 See the `security documentation`_ for an explanation of how the new security
448 system works. In a nutshell though, the security is handled as a four step
449 process:
451 1. Permissions are defined as having a name and optionally a hyperdb class
452 they're specific to,
453 2. Roles are defined that have one or more Permissions,
454 3. Users are assigned Roles in their "roles" property, and finally
455 4. Roundup checks that users have appropriate Permissions at appropriate times
456 (like editing issues).
458 Your tracker dbinit module's *open* function now has to define any
459 Permissions that are specific to your tracker, and also the assignment
460 of Permissions to Roles. At the moment, your open function
461 ends with::
463 import detectors
464 detectors.init(db)
466 return db
468 and what we need to do is insert some commands that will set up the security
469 parameters. Right above the ``import detectors`` line, you'll want to insert
470 these lines::
472 #
473 # SECURITY SETTINGS
474 #
475 # new permissions for this schema
476 for cl in 'issue', 'file', 'msg', 'user':
477 db.security.addPermission(name="Edit", klass=cl,
478 description="User is allowed to edit "+cl)
479 db.security.addPermission(name="View", klass=cl,
480 description="User is allowed to access "+cl)
482 # Assign the access and edit permissions for issue, file and message
483 # to regular users now
484 for cl in 'issue', 'file', 'msg':
485 p = db.security.getPermission('View', cl)
486 db.security.addPermissionToRole('User', p)
487 p = db.security.getPermission('Edit', cl)
488 db.security.addPermissionToRole('User', p)
489 # and give the regular users access to the web and email interface
490 p = db.security.getPermission('Web Access')
491 db.security.addPermissionToRole('User', p)
492 p = db.security.getPermission('Email Access')
493 db.security.addPermissionToRole('User', p)
495 # May users view other user information? Comment these lines out
496 # if you don't want them to
497 p = db.security.getPermission('View', 'user')
498 db.security.addPermissionToRole('User', p)
500 # Assign the appropriate permissions to the anonymous user's Anonymous
501 # Role. Choices here are:
502 # - Allow anonymous users to register through the web
503 p = db.security.getPermission('Web Registration')
504 db.security.addPermissionToRole('Anonymous', p)
505 # - Allow anonymous (new) users to register through the email gateway
506 p = db.security.getPermission('Email Registration')
507 db.security.addPermissionToRole('Anonymous', p)
508 # - Allow anonymous users access to the "issue" class of data
509 # Note: this also grants access to related information like files,
510 # messages, statuses etc that are linked to issues
511 #p = db.security.getPermission('View', 'issue')
512 #db.security.addPermissionToRole('Anonymous', p)
513 # - Allow anonymous users access to edit the "issue" class of data
514 # Note: this also grants access to create related information like
515 # files and messages etc that are linked to issues
516 #p = db.security.getPermission('Edit', 'issue')
517 #db.security.addPermissionToRole('Anonymous', p)
519 # oh, g'wan, let anonymous access the web interface too
520 p = db.security.getPermission('Web Access')
521 db.security.addPermissionToRole('Anonymous', p)
523 Note in the comments there the places where you might change the permissions
524 to restrict users or grant users more access. If you've created additional
525 classes that users should be able to edit and view, then you should add them
526 to the "new permissions for this schema" section at the start of the security
527 block. Then add them to the "Assign the access and edit permissions" section
528 too, so people actually have the new Permission you've created.
530 One final change is needed that finishes off the security system's
531 initialisation. We need to add a call to ``db.post_init()`` at the end of the
532 dbinit open() function. Add it like this::
534 import detectors
535 detectors.init(db)
537 # schema is set up - run any post-initialisation
538 db.post_init()
539 return db
541 You may verify the setup of Permissions and Roles using the new
542 "``roundup-admin security``" command.
545 0.5.0 User changes
546 ~~~~~~~~~~~~~~~~~~
548 To support all those schema changes, you'll need to massage your user database
549 a little too, to:
551 1. make sure there's an "anonymous" user - this user is mandatory now and is
552 the one that unknown users are logged in as.
553 2. make sure all users have at least one Role.
555 If you don't have the "anonymous" user, create it now with the command::
557 roundup-admin create user username=anonymous roles=Anonymous
559 making sure the capitalisation is the same as above. Once you've done that,
560 you'll need to set the roles property on all users to a reasonable default.
561 The admin user should get "Admin", the anonymous user "Anonymous"
562 and all other users "User". The ``fixroles.py`` script in the tools directory
563 will do this. Run it like so (where python is your python 2+ binary)::
565 python tools/fixroles.py -i <tracker home> fixroles
569 0.5.0 CGI interface changes
570 ---------------------------
572 The CGI interface code was completely reorganised and largely rewritten. The
573 end result is that this section of your tracker interfaces module will need
574 changing from::
576 from roundup import cgi_client, mailgw
577 from roundup.i18n import _
579 class Client(cgi_client.Client):
580 ''' derives basic CGI implementation from the standard module,
581 with any specific extensions
582 '''
583 pass
585 to::
587 from roundup import mailgw
588 from roundup.cgi import client
590 class Client(client.Client):
591 ''' derives basic CGI implementation from the standard module,
592 with any specific extensions
593 '''
594 pass
596 You will also need to install the new version of roundup.cgi from the source
597 cgi-bin directory if you're using it.
600 0.5.0 HTML templating
601 ---------------------
603 You'll want to make a backup of your current tracker html directory. You
604 should then copy the html directory from the Roundup source "classic" template
605 and modify it according to your local schema changes.
607 If you need help with the new templating system, please ask questions on the
608 roundup-users mailing list (available through the roundup project page on
609 sourceforge, http://roundup.sf.net/)
612 0.5.0 Detectors
613 ---------------
615 The nosy reactor has been updated to handle the tracker not having an
616 "assignedto" property on issues. You may want to copy it into your tracker's
617 detectors directory. Chances are you've already fixed it though :)
620 Migrating from 0.4.1 to 0.4.2
621 =============================
623 0.4.2 Configuration
624 -------------------
625 The USER_INDEX definition introduced in 0.4.1 was too restrictive in its
626 allowing replacement of 'assignedto' with the user's userid. Users must change
627 the None value of 'assignedto' to 'CURRENT USER' (the string, in quotes) for
628 the replacement behaviour to occur now.
630 The new configuration variables are:
632 - EMAIL_KEEP_QUOTED_TEXT
633 - EMAIL_LEAVE_BODY_UNCHANGED
634 - ADD_RECIPIENTS_TO_NOSY
636 See the sample configuration files in::
638 <roundup source>/roundup/templates/classic/instance_config.py
640 and::
642 <roundup source>/roundup/templates/extended/instance_config.py
644 and the `customisation documentation`_ for information on how they're used.
647 0.4.2 Changes to detectors
648 --------------------------
649 You will need to copy the detectors from the distribution into your instance
650 home "detectors" directory. If you used the classic schema, the detectors
651 are in::
653 <roundup source>/roundup/templates/classic/detectors/
655 If you used the extended schema, the detectors are in::
657 <roundup source>/roundup/templates/extended/detectors/
659 The change means that schema-specific code has been removed from the
660 mail gateway and cgi interface and made into auditors:
662 - nosyreactor.py has now got an updatenosy auditor which updates the nosy
663 list with author, recipient and assignedto information.
664 - statusauditor.py makes the unread or resolved -> chatting changes and
665 presets the status of an issue to unread.
667 There's also a bug or two fixed in the nosyreactor code.
669 0.4.2 HTML templating changes
670 -----------------------------
671 The link() htmltemplate function now has a "showid" option for links and
672 multilinks. When true, it only displays the linked item id as the anchor
673 text. The link value is displayed as a tooltip using the title anchor
674 attribute. To use in eg. the superseder field, have something like this::
676 <td>
677 <display call="field('superseder', showid=1)">
678 <display call="classhelp('issue', 'id,title', label='list', width=500)">
679 <property name="superseder">
680 <br>View: <display call="link('superseder', showid=1)">
681 </property>
682 </td>
684 The stylesheets have been cleaned up too. You may want to use the newer
685 versions in::
687 <roundup source>/roundup/templates/<template>/html/default.css
691 Migrating from 0.4.0 to 0.4.1
692 =============================
694 0.4.1 Files storage
695 -------------------
697 Messages and files from newly created issues will be put into subdierectories
698 in thousands e.g. msg123 will be put into files/msg/0/msg123, file2003
699 will go into files/file/2/file2003. Previous messages are still found, but
700 could be put into this structure.
702 0.4.1 Configuration
703 -------------------
705 To allow more fine-grained access control, the variable used to check
706 permission to auto-register users in the mail gateway is now called
707 ANONYMOUS_REGISTER_MAIL rather than overloading ANONYMOUS_REGISTER. If the
708 variable doesn't exist, then ANONYMOUS_REGISTER is tested as before.
710 Configuring the links in the web header is now easier too. The following
711 variables have been added to the classic instance_config.py::
713 HEADER_INDEX_LINKS - defines the "index" links to be made available
714 HEADER_ADD_LINKS - defines the "add" links
715 DEFAULT_INDEX - specifies the index view for DEFAULT
716 UNASSIGNED_INDEX - specifies the index view for UNASSIGNED
717 USER_INDEX - specifies the index view for USER
719 See the <roundup source>/roundup/templates/classic/instance_config.py for more
720 information - including how the variables are to be set up. Most users will
721 just be able to copy the variables from the source to their instance home. If
722 you've modified the header by changing the source of the interfaces.py file in
723 the instance home, you'll need to remove that customisation and move it into
724 the appropriate variables in instance_config.py.
726 The extended schema has similar variables added too - see the source for more
727 info.
729 0.4.1 Alternate E-Mail Addresses
730 --------------------------------
732 If you add the property "alternate_addresses" to your user class, your users
733 will be able to register alternate email addresses that they may use to
734 communicate with roundup as. All email from roundup will continue to be sent
735 to their primary address.
737 If you have not edited the dbinit.py file in your instance home directory,
738 you may simply copy the new dbinit.py file from the core code. If you used
739 the classic schema, the interfaces file is in::
741 <roundup source>/roundup/templates/classic/dbinit.py
743 If you used the extended schema, the file is in::
745 <roundup source>/roundup/templates/extended/dbinit.py
747 If you have modified your dbinit.py file, you need to edit the dbinit.py
748 file in your instance home directory. Find the lines which define the user
749 class::
751 user = Class(db, "msg",
752 username=String(), password=Password(),
753 address=String(), realname=String(),
754 phone=String(), organisation=String(),
755 alternate_addresses=String())
757 You will also want to add the property to the user's details page. The
758 template for this is the "user.item" file in your instance home "html"
759 directory. Similar to above, you may copy the file from the roundup source if
760 you haven't modified it. Otherwise, add the following to the template::
762 <display call="multiline('alternate_addresses')">
764 with appropriate labelling etc. See the standard template for an idea.
768 Migrating from 0.3.x to 0.4.0
769 =============================
771 0.4.0 Message-ID and In-Reply-To addition
772 -----------------------------------------
773 0.4.0 adds the tracking of messages by message-id and allows threading
774 using in-reply-to. Most e-mail clients support threading using this
775 feature, and we hope to add support for it to the web gateway. If you
776 have not edited the dbinit.py file in your instance home directory, you may
777 simply copy the new dbinit.py file from the core code. If you used the
778 classic schema, the interfaces file is in::
780 <roundup source>/roundup/templates/classic/dbinit.py
782 If you used the extended schema, the file is in::
784 <roundup source>/roundup/templates/extended/dbinit.py
786 If you have modified your dbinit.py file, you need to edit the dbinit.py
787 file in your instance home directory. Find the lines which define the msg
788 class::
790 msg = FileClass(db, "msg",
791 author=Link("user"), recipients=Multilink("user"),
792 date=Date(), summary=String(),
793 files=Multilink("file"))
795 and add the messageid and inreplyto properties like so::
797 msg = FileClass(db, "msg",
798 author=Link("user"), recipients=Multilink("user"),
799 date=Date(), summary=String(),
800 files=Multilink("file"),
801 messageid=String(), inreplyto=String())
803 Also, configuration is being cleaned up. This means that your dbinit.py will
804 also need to be changed in the open function. If you haven't changed your
805 dbinit.py, the above copy will be enough. If you have, you'll need to change
806 the line (round line 50)::
808 db = Database(instance_config.DATABASE, name)
810 to::
812 db = Database(instance_config, name)
815 0.4.0 Configuration
816 --------------------
817 ``TRACKER_NAME`` and ``EMAIL_SIGNATURE_POSITION`` have been added to the
818 instance_config.py. The simplest solution is to copy the default values
819 from template in the core source.
821 The mail gateway now checks ``ANONYMOUS_REGISTER`` to see if unknown users
822 are to be automatically registered with the tracker. If it is set to "deny"
823 then unknown users will not have access. If it is set to "allow" they will be
824 automatically registered with the tracker.
827 0.4.0 CGI script roundup.cgi
828 ----------------------------
829 The CGI script has been updated with some features and a bugfix, so you should
830 copy it from the roundup cgi-bin source directory again. Make sure you update
831 the ROUNDUP_INSTANCE_HOMES after the copy.
834 0.4.0 Nosy reactor
835 ------------------
836 The nosy reactor has also changed - copy the nosyreactor.py file from the core
837 source::
839 <roundup source>/roundup/templates/<template>/detectors/nosyreactor.py
841 to your instance home "detectors" directory.
844 0.4.0 HTML templating
845 ---------------------
846 The field() function was incorrectly implemented - links and multilinks now
847 display as text fields when rendered using field(). To display a menu (drop-
848 down or select box) you need to use the menu() function.
852 Migrating from 0.2.x to 0.3.x
853 =============================
855 0.3.x Cookie Authentication changes
856 -----------------------------------
857 0.3.0 introduces cookie authentication - you will need to copy the
858 interfaces.py file from the roundup source to your instance home to enable
859 authentication. If you used the classic schema, the interfaces file is in::
861 <roundup source>/roundup/templates/classic/interfaces.py
863 If you used the extended schema, the file is in::
865 <roundup source>/roundup/templates/extended/interfaces.py
867 If you have modified your interfaces.Client class, you will need to take
868 note of the login/logout functionality provided in roundup.cgi_client.Client
869 (classic schema) or roundup.cgi_client.ExtendedClient (extended schema) and
870 modify your instance code apropriately.
873 0.3.x Password encoding
874 -----------------------
875 This release also introduces encoding of passwords in the database. If you
876 have not edited the dbinit.py file in your instance home directory, you may
877 simply copy the new dbinit.py file from the core code. If you used the
878 classic schema, the interfaces file is in::
880 <roundup source>/roundup/templates/classic/dbinit.py
882 If you used the extended schema, the file is in::
884 <roundup source>/roundup/templates/extended/dbinit.py
887 If you have modified your dbinit.py file, you may use encoded passwords:
889 1. Edit the dbinit.py file in your instance home directory
890 a. At the first code line of the open() function::
892 from roundup.hyperdb import String, Date, Link, Multilink
894 alter to include Password, as so::
896 from roundup.hyperdb import String, Password, Date, Link, Multilink
898 b. Where the password property is defined (around line 66)::
900 user = Class(db, "user",
901 username=String(), password=String(),
902 address=String(), realname=String(),
903 phone=String(), organisation=String())
904 user.setkey("username")
906 alter the "password=String()" to "password=Password()"::
908 user = Class(db, "user",
909 username=String(), password=Password(),
910 address=String(), realname=String(),
911 phone=String(), organisation=String())
912 user.setkey("username")
914 2. Any existing passwords in the database will remain cleartext until they
915 are edited. It is recommended that at a minimum the admin password be
916 changed immediately::
918 roundup-admin -i <instance home> set user1 password=<new password>
921 0.3.x Configuration
922 -------------------
923 FILTER_POSITION, ANONYMOUS_ACCESS, ANONYMOUS_REGISTER have been added to
924 the instance_config.py. Simplest solution is to copy the default values from
925 template in the core source.
927 MESSAGES_TO_AUTHOR has been added to the IssueClass in dbinit.py. Set to 'yes'
928 to send nosy messages to the author. Default behaviour is to not send nosy
929 messages to the author. You will need to add MESSAGES_TO_AUTHOR to your
930 dbinit.py in your instance home.
933 0.3.x CGI script roundup.cgi
934 ----------------------------
935 There have been some structural changes to the roundup.cgi script - you will
936 need to install it again from the cgi-bin directory of the source
937 distribution. Make sure you update the ROUNDUP_INSTANCE_HOMES after the
938 copy.
941 .. _`customisation documentation`: customizing.html
942 .. _`security documentation`: security.html
943 .. _`administration guide`: admin.html