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::
12 Migrating from 0.6 to 0.7
13 =========================
15 0.7.0 Saving and sharing of user queries
16 ----------------------------------------
18 Due to popular demand, the user query saving mechanisms have been
19 overhauled. This means that queries remember the user that created them
20 and they may be marked as being private for a particular user.
22 You *are not required* to make these changes. You only need to make them
23 if you wish to use the new query editing features. It's highly
24 recommended, as the effort is minimal.
26 1. You will need to edit your tracker's ``dbinit.py`` to change the way
27 queries are stored. Change the lines::
29 query = Class(db, "query",
30 klass=String(), name=String(),
31 url=String())
32 query.setkey("name")
34 to::
36 query = Class(db, "query",
37 klass=String(), name=String(),
38 url=String(), private_for=Link('user'))
40 That is, add the "private_for" property, and remove the line that says
41 ``query.setkey("name")``. The latter is the most important edit here.
43 2. You will also need to copy the ``query.edit.html`` template page from the
44 ``templates/classic/html/`` directory of the source to your tracker's
45 ``html`` directory.
47 3. Once you've done that, edit the tracker's ``page.html`` template to
48 change::
50 <td rowspan="2" valign="top" class="sidebar">
51 <p class="classblock" tal:condition="request/user/queries">
52 <b>Your Queries</b><br>
53 <tal:block tal:repeat="qs request/user/queries">
55 to::
57 <td rowspan="2" valign="top" class="sidebar">
58 <p class="classblock">
59 <b>Your Queries</b> (<a href="query?@template=edit">edit</a>)<br>
60 <tal:block tal:repeat="qs request/user/queries">
62 That is, you're removing the ``tal:condition`` and adding a link to the
63 new edit page.
65 4. You might also wish to remove the redundant query editing section from the
66 ``user.item.html`` page.
69 0.7.0 Added Dispatcher role
70 ---------------------------
72 A new config option has been added that specifies the email address of
73 a "dispatcher" role. This email address acts as a central sentinel for
74 issues coming into the system. You can configure it so that all e-mail
75 error messages get bounced to them, them and the user in question, or
76 just the user (default).
78 To toggle these switches, add the "DISPATCHER_EMAIL" and
79 "ERROR_MESSAGES_TO" configuration values to your tracker's ``config.py``.
80 See the `customisation documentation`_ for how to use them.
83 0.7.0 Added CSV export action
84 -----------------------------
86 A new action has been added which exports the current index page or search
87 result as a comma-separated-value (CSV) file.
89 To use it, add this to your "index" templates:
91 <a tal:attributes="href python:request.indexargs_url('issue',
92 {'@action':'csv_export'})">Download as CSV</a>
94 Making sure that the ``'issue'`` part matches the class name of the page
95 you're editing.
98 0.7.0 Typed columns in MySQL backend
99 ------------------------------------
101 The MySQL (and Postgresql for that matter) backend now creates tables with
102 appropriate column datatypes (not just varchar).
104 Your database will be automatically migrated to use the new schemas, but
105 it will take time. It's probably a good idea to make sure you do this as
106 part of the upgrade when users are not expected to be using the system.
109 0.7.0 Permission setup
110 ----------------------
112 0.7 automatically sets up the Edit and View Permissions for all classes,
113 thus you don't need to do so. Feel free to remove the code::
115 # Add new Permissions for this schema
116 for cl in 'issue', 'file', 'msg', 'user', 'query', 'keyword':
117 db.security.addPermission(name="Edit", klass=cl,
118 description="User is allowed to edit "+cl)
119 db.security.addPermission(name="View", klass=cl,
120 description="User is allowed to access "+cl)
122 from your ``dbinit.py``.
125 0.7.0 Permission assignments
126 ----------------------------
128 Due to a change in the rendering of web widgets, permissions are now
129 checked on Classes where they previously weren't (this is a good thing).
131 You will need to add some additional Permission assignments for your
132 regular users, or some displays will break. After the following in your
133 tracker's ``dbinit.py``::
135 # Assign the access and edit Permissions for issue, file and message
136 # to regular users now
137 for cl in 'issue', 'file', 'msg', 'query', 'keyword':
138 p = db.security.getPermission('View', cl)
139 db.security.addPermissionToRole('User', p)
140 p = db.security.getPermission('Edit', cl)
141 db.security.addPermissionToRole('User', p)
143 add::
145 for cl in 'priority', 'status':
146 p = db.security.getPermission('View', cl)
147 db.security.addPermissionToRole('User', p)
150 0.7.0 New "actor" property
151 --------------------------
153 Roundup's database has a new per-item property "actor" which reflects the
154 user performing the last "actvitiy". See the classic template for ways to
155 integrate this new property into your interface.
157 The property will be automatically added to your existing database.
160 0.7.0 Extending the cgi interface
161 ---------------------------------
163 Before 0.7.0 adding or extending web actions was done by overriding or adding
164 methods on the Client class. Though this approach still works to provide
165 backwards compatibility, it is recommended you upgrade to the new approach, as
166 described in the `Defining new web actions`__ section of the customization
167 documentation. You might also want to take a look at the `Using an external
168 password validation source`__ example.
170 __ customizing.html#defining-new-web-actions
171 __ customizing.html#using-an-external-password-validation-source
174 0.7.0 Getting the current user id
175 ---------------------------------
177 Removed Database.curuserid attribute. Any code referencing this attribute
178 should be replaced with a call to Database.getuid().
181 0.7.0 Email character set
182 -------------------------
184 The default character set for sending email is UTF-8 (ie. Unicode). If you
185 have users whose email clients can't handle UTF-8 (eg. Eudora) then you
186 will need to edit the new config.py variable ``EMAIL_CHARSET``.
189 0.7.0 ZRoundup changes
190 ----------------------
192 The templates in your tracker's html directory will need updating if you
193 wish to use ZRoundup. If you've not modified those files (or some of them),
194 you may just copy the new versions from the Roundup source in the
195 templates/classic/html directory.
197 If you have modified the html files, then you'll need to manually edit them
198 to change all occurances of special form variables from using the colon ":"
199 special character to the at "@" special character. That is, variables such
200 as::
202 :action :required :template :remove:messages ...
204 should become:
206 @action @required @template @remove@messages ...
208 Note that ``tal:`` statements are unaffected. So are TAL expression type
209 prefixes such as ``python:`` and ``string:``. Please ask on the
210 roundup-users mailing list for help if you're unsure.
213 Migrating from 0.6.x to 0.6.3
214 =============================
216 0.6.3 Configuration
217 -------------------
219 You will need to copy the file::
221 templates/classic/detectors/__init__.py
223 to your tracker's ``detectors`` directory, replacing the one already there.
224 This fixes a couple of bugs in that file.
228 Migrating from 0.5 to 0.6
229 =========================
232 0.6.0 Configuration
233 -------------------
235 Introduced EMAIL_FROM_TAG config variable. This value is inserted into
236 the From: line of nosy email. If the sending user is "Foo Bar", the
237 From: line is usually::
239 "Foo Bar" <issue_tracker@tracker.example>
241 the EMAIL_FROM_TAG goes inside the "Foo Bar" quotes like so::
243 "Foo Bar EMAIL_FROM_TAG" <issue_tracker@tracker.example>
245 I've altered the mechanism in the detectors __init__.py module so that it
246 doesn't cross-import detectors from other trackers (if you run more than one
247 in a single roundup-server). This change means that you'll need to copy the
248 __init__.py from roundup/templates/classic/detectors/__init__.py to your
249 <tracker home>/detectors/__init__.py. Don't worry, the "classic" __init__ is a
250 one-size-fits-all, so it'll work even if you've added/removed detectors.
252 0.6.0 Templating changes
253 ------------------------
255 The ``user.item`` template (in the tracker home "templates" directory)
256 needs to have the following hidden variable added to its form (between the
257 ``<form...>`` and ``</form>`` tags::
259 <input type="hidden" name=":template" value="item">
262 0.6.0 Form handling changes
263 ---------------------------
265 Roundup's form handling capabilities have been significantly expanded. This
266 should not affect users of 0.5 installations - but if you find you're
267 getting errors from form submissions, please ask for help on the Roundup
268 users mailing list:
270 http://lists.sourceforge.net/lists/listinfo/roundup-users
272 See the customisation doc section on `Form Values`__ for documentation of the
273 new form variables possible.
275 __ customizing.html#form-values
278 0.6.0 Multilingual character set support
279 ----------------------------------------
281 Added internationalization support. This is done via encoding all data
282 stored in roundup database to utf-8 (unicode encoding). To support utf-8 in
283 web interface you should add the folowing line to your tracker's html/page
284 and html/_generic.help files inside <head> tag::
286 <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
288 Since latin characters in utf-8 have the same codes as in ASCII table, this
289 modification is optional for users who use only plain latin characters.
291 After this modification, you will be able to see and enter any world
292 character via web interface. Data received via mail interface also converted
293 to utf-8, however only new messages will be converted. If your roundup
294 database contains some of non-ASCII characters in one of 8-bit encoding,
295 they will not be visible in new unicode environment. Some of such data (e.g.
296 user names, keywords, etc) can be edited by administrator, the others
297 (e.g. messages' contents) is not editable via web interface. Currently there
298 is no tool for converting such data, the only solution is to close
299 appropriate old issues and create new ones with the same content.
302 0.6.0 User timezone support
303 ---------------------------
305 From version 0.6.0 roundup supports displaying of Date data in user' local
306 timezone if he/she has provided timezone information. To make it possible
307 some modification to tracker's schema and HTML templates are required.
308 First you must add string property 'timezone' to user class in dbinit.py
309 like this::
311 user = Class(db, "user",
312 username=String(), password=Password(),
313 address=String(), realname=String(),
314 phone=String(), organisation=String(),
315 alternate_addresses=String(),
316 queries=Multilink('query'), roles=String(),
317 timezone=String())
319 And second - html interface. Add following lines to
320 $TRACKER_HOME/html/user.item template::
322 <tr>
323 <th>Timezone</th>
324 <td tal:content="structure context/timezone/field">timezone</td>
325 </tr>
327 After that all users should be able to provide their timezone information.
328 Timezone should be a positive or negative integer - offset from GMT.
330 After providing timezone, roundup will show all dates values, found in web
331 and mail interfaces in local time. It will also accept any Date info in
332 local time, convert and store it in GMT.
335 0.6.0 Search page structure
336 ---------------------------
338 In order to accomodate query editing the search page has been restructured. If
339 you want to provide your users with query editing, you should update your
340 search page using the macros detailed in the customisation doc section
341 `Searching on categories`__.
343 __ customizing.html#searching-on-categories
345 Also, the url field in the query class no longer starts with a '?'. You'll need
346 to remove this question mark from the url field to support queries. There's
347 a script in the "tools" directory called ``migrate-queries.py`` that should
348 automatically change any existing queries for you. As always, make a backup
349 of your database before running such a script.
352 0.6.0 Notes for metakit backend users
353 -------------------------------------
355 Roundup 0.6.0 introduced searching on ranges of dates and intervals. To
356 support it, some modifications to interval storing routine were made. So if
357 your tracker uses metakit backend and your db schema contains intervals
358 property, searches on that property will not be accurate for db items that
359 was stored before roundup' upgrade. However all new records should be
360 searchable on intervals.
362 It is possible to convert your database to new format: you can export and
363 import back all your data (consult "Migrating backends" in "Maintenance"
364 documentation). After this operation all your interval properties should
365 become searchable.
367 Users of backends others than metakit should not worry about this issue.
370 Migrating from 0.4.x to 0.5.0
371 =============================
373 This has been a fairly major revision of Roundup:
375 1. Brand new, much more powerful, flexible, tasty and nutritious templating.
376 Unfortunately, this means all your current templates are useless. Hopefully
377 the new documentation and examples will be enough to help you make the
378 transition. Please don't hesitate to ask on roundup-users for help (or
379 complete conversions if you're completely stuck)!
380 2. The database backed got a lot more flexible, allowing Metakit and SQL
381 databases! The only decent SQL database implemented at present is sqlite,
382 but others shouldn't be a whole lot more work.
383 3. A brand new, highly flexible and much more robust security system including
384 a system of Permissions, Roles and Role assignments to users. You may now
385 define your own Permissions that may be checked in CGI transactions.
386 4. Journalling has been made less storage-hungry, so has been turned on
387 by default *except* for author, recipient and nosy link/unlink events. You
388 are advised to turn it off in your trackers too.
389 5. We've changed the terminology from "instance" to "tracker", to ease the
390 learning curve/impact for new users.
391 6. Because of the above changes, the tracker configuration has seen some
392 major changes. See below for the details.
394 Please, **back up your database** before you start the migration process. This
395 is as simple as copying the "db" directory and all its contents from your
396 tracker to somewhere safe.
399 0.5.0 Configuration
400 -------------------
402 First up, rename your ``instance_config.py`` file to just ``config.py``.
404 Then edit your tracker's ``__init__.py`` module. It'll currently look
405 like this::
407 from instance_config import *
408 try:
409 from dbinit import *
410 except ImportError:
411 pass # in installdir (probably :)
412 from interfaces import *
414 and it needs to be::
416 import config
417 from dbinit import open, init
418 from interfaces import Client, MailGW
420 Due to the new templating having a top-level ``page`` that defines links for
421 searching, indexes, adding items etc, the following variables are no longer
422 used:
424 - HEADER_INDEX_LINKS
425 - HEADER_ADD_LINKS
426 - HEADER_SEARCH_LINKS
427 - SEARCH_FILTERS
428 - DEFAULT_INDEX
429 - UNASSIGNED_INDEX
430 - USER_INDEX
431 - ISSUE_FILTER
433 The new security implementation will require additions to the dbinit module,
434 but also removes the need for the following tracker config variables:
436 - ANONYMOUS_ACCESS
437 - ANONYMOUS_REGISTER
439 but requires two new variables which define the Roles assigned to users who
440 register through the web and e-mail interfaces:
442 - NEW_WEB_USER_ROLES
443 - NEW_EMAIL_USER_ROLES
445 in both cases, 'User' is a good initial setting. To emulate
446 ``ANONYMOUS_ACCESS='deny'``, remove all "View" Permissions from the
447 "Anonymous" Role. To emulate ``ANONYMOUS_REGISTER='deny'``, remove the "Web
448 Registration" and/or the "Email Registration" Permission from the "Anonymous"
449 Role. See the section on customising security in the `customisation
450 documentation`_ for more information.
452 Finally, the following config variables have been renamed to make more sense:
454 - INSTANCE_HOME -> TRACKER_HOME
455 - INSTANCE_NAME -> TRACKER_NAME
456 - ISSUE_TRACKER_WEB -> TRACKER_WEB
457 - ISSUE_TRACKER_EMAIL -> TRACKER_EMAIL
460 0.5.0 Schema Specification
461 --------------------------
463 0.5.0 Database backend changes
464 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
466 Your select_db module in your tracker has changed a fair bit. Where it used
467 to contain::
469 # WARNING: DO NOT EDIT THIS FILE!!!
470 from roundup.backends.back_anydbm import Database
472 it must now contain::
474 # WARNING: DO NOT EDIT THIS FILE!!!
475 from roundup.backends.back_anydbm import Database, Class, FileClass, IssueClass
477 Yes, I realise the irony of the "DO NOT EDIT THIS FILE" statement :)
478 Note the addition of the Class, FileClass, IssueClass imports. These are very
479 important, as they're going to make the next change work too. You now need to
480 modify the top of the dbinit module in your tracker from::
482 import instance_config
483 from roundup import roundupdb
484 from select_db import Database
486 from roundup.roundupdb import Class, FileClass
488 class Database(roundupdb.Database, select_db.Database):
489 ''' Creates a hybrid database from:
490 . the selected database back-end from select_db
491 . the roundup extensions from roundupdb
492 '''
493 pass
495 class IssueClass(roundupdb.IssueClass):
496 ''' issues need the email information
497 '''
498 pass
500 to::
502 import config
503 from select_db import Database, Class, FileClass, IssueClass
505 Yes, remove the Database and IssueClass definitions and those other imports.
506 They're not needed any more!
508 Look for places in dbinit.py where ``instance_config`` is used too, and
509 rename them ``config``.
512 0.5.0 Journalling changes
513 ~~~~~~~~~~~~~~~~~~~~~~~~~
515 Journalling has been optimised for storage. Journalling of links has been
516 turned back on by default. If your tracker has a large user base, you may wish
517 to turn off journalling of nosy list, message author and message recipient
518 link and unlink events. You do this by adding ``do_journal='no'`` to the Class
519 initialisation in your dbinit. For example, your *msg* class initialisation
520 probably looks like this::
522 msg = FileClass(db, "msg",
523 author=Link("user"), recipients=Multilink("user"),
524 date=Date(), summary=String(),
525 files=Multilink("file"),
526 messageid=String(), inreplyto=String())
528 to turn off journalling of author and recipient link events, add
529 ``do_journal='no'`` to the ``author=Link("user")`` part of the statement,
530 like so::
532 msg = FileClass(db, "msg",
533 author=Link("user", do_journal='no'),
534 recipients=Multilink("user", do_journal='no'),
535 date=Date(), summary=String(),
536 files=Multilink("file"),
537 messageid=String(), inreplyto=String())
539 Nosy list link event journalling is actually turned off by default now. If you
540 want to turn it on, change to your issue class' nosy list, change its
541 definition from::
543 issue = IssueClass(db, "issue",
544 assignedto=Link("user"), topic=Multilink("keyword"),
545 priority=Link("priority"), status=Link("status"))
547 to::
549 issue = IssueClass(db, "issue", nosy=Multilink("user", do_journal='yes'),
550 assignedto=Link("user"), topic=Multilink("keyword"),
551 priority=Link("priority"), status=Link("status"))
553 noting that your definition of the nosy Multilink will override the normal one.
556 0.5.0 User schema changes
557 ~~~~~~~~~~~~~~~~~~~~~~~~~
559 Users have two more properties, "queries" and "roles". You'll have something
560 like this in your dbinit module now::
562 user = Class(db, "user",
563 username=String(), password=Password(),
564 address=String(), realname=String(),
565 phone=String(), organisation=String(),
566 alternate_addresses=String())
567 user.setkey("username")
569 and you'll need to add the new properties and the new "query" class to it
570 like so::
572 query = Class(db, "query",
573 klass=String(), name=String(),
574 url=String())
575 query.setkey("name")
577 # Note: roles is a comma-separated string of Role names
578 user = Class(db, "user",
579 username=String(), password=Password(),
580 address=String(), realname=String(),
581 phone=String(), organisation=String(),
582 alternate_addresses=String(),
583 queries=Multilink('query'), roles=String())
584 user.setkey("username")
586 The "queries" property is used to store off the user's favourite database
587 queries. The "roles" property is explained below in `0.5.0 Security
588 Settings`_.
591 0.5.0 Security Settings
592 ~~~~~~~~~~~~~~~~~~~~~~~
594 See the `security documentation`_ for an explanation of how the new security
595 system works. In a nutshell though, the security is handled as a four step
596 process:
598 1. Permissions are defined as having a name and optionally a hyperdb class
599 they're specific to,
600 2. Roles are defined that have one or more Permissions,
601 3. Users are assigned Roles in their "roles" property, and finally
602 4. Roundup checks that users have appropriate Permissions at appropriate times
603 (like editing issues).
605 Your tracker dbinit module's *open* function now has to define any
606 Permissions that are specific to your tracker, and also the assignment
607 of Permissions to Roles. At the moment, your open function
608 ends with::
610 import detectors
611 detectors.init(db)
613 return db
615 and what we need to do is insert some commands that will set up the security
616 parameters. Right above the ``import detectors`` line, you'll want to insert
617 these lines::
619 #
620 # SECURITY SETTINGS
621 #
622 # new permissions for this schema
623 for cl in 'issue', 'file', 'msg', 'user':
624 db.security.addPermission(name="Edit", klass=cl,
625 description="User is allowed to edit "+cl)
626 db.security.addPermission(name="View", klass=cl,
627 description="User is allowed to access "+cl)
629 # Assign the access and edit permissions for issue, file and message
630 # to regular users now
631 for cl in 'issue', 'file', 'msg':
632 p = db.security.getPermission('View', cl)
633 db.security.addPermissionToRole('User', p)
634 p = db.security.getPermission('Edit', cl)
635 db.security.addPermissionToRole('User', p)
636 # and give the regular users access to the web and email interface
637 p = db.security.getPermission('Web Access')
638 db.security.addPermissionToRole('User', p)
639 p = db.security.getPermission('Email Access')
640 db.security.addPermissionToRole('User', p)
642 # May users view other user information? Comment these lines out
643 # if you don't want them to
644 p = db.security.getPermission('View', 'user')
645 db.security.addPermissionToRole('User', p)
647 # Assign the appropriate permissions to the anonymous user's Anonymous
648 # Role. Choices here are:
649 # - Allow anonymous users to register through the web
650 p = db.security.getPermission('Web Registration')
651 db.security.addPermissionToRole('Anonymous', p)
652 # - Allow anonymous (new) users to register through the email gateway
653 p = db.security.getPermission('Email Registration')
654 db.security.addPermissionToRole('Anonymous', p)
655 # - Allow anonymous users access to the "issue" class of data
656 # Note: this also grants access to related information like files,
657 # messages, statuses etc that are linked to issues
658 #p = db.security.getPermission('View', 'issue')
659 #db.security.addPermissionToRole('Anonymous', p)
660 # - Allow anonymous users access to edit the "issue" class of data
661 # Note: this also grants access to create related information like
662 # files and messages etc that are linked to issues
663 #p = db.security.getPermission('Edit', 'issue')
664 #db.security.addPermissionToRole('Anonymous', p)
666 # oh, g'wan, let anonymous access the web interface too
667 p = db.security.getPermission('Web Access')
668 db.security.addPermissionToRole('Anonymous', p)
670 Note in the comments there the places where you might change the permissions
671 to restrict users or grant users more access. If you've created additional
672 classes that users should be able to edit and view, then you should add them
673 to the "new permissions for this schema" section at the start of the security
674 block. Then add them to the "Assign the access and edit permissions" section
675 too, so people actually have the new Permission you've created.
677 One final change is needed that finishes off the security system's
678 initialisation. We need to add a call to ``db.post_init()`` at the end of the
679 dbinit open() function. Add it like this::
681 import detectors
682 detectors.init(db)
684 # schema is set up - run any post-initialisation
685 db.post_init()
686 return db
688 You may verify the setup of Permissions and Roles using the new
689 "``roundup-admin security``" command.
692 0.5.0 User changes
693 ~~~~~~~~~~~~~~~~~~
695 To support all those schema changes, you'll need to massage your user database
696 a little too, to:
698 1. make sure there's an "anonymous" user - this user is mandatory now and is
699 the one that unknown users are logged in as.
700 2. make sure all users have at least one Role.
702 If you don't have the "anonymous" user, create it now with the command::
704 roundup-admin create user username=anonymous roles=Anonymous
706 making sure the capitalisation is the same as above. Once you've done that,
707 you'll need to set the roles property on all users to a reasonable default.
708 The admin user should get "Admin", the anonymous user "Anonymous"
709 and all other users "User". The ``fixroles.py`` script in the tools directory
710 will do this. Run it like so (where python is your python 2+ binary)::
712 python tools/fixroles.py -i <tracker home> fixroles
716 0.5.0 CGI interface changes
717 ---------------------------
719 The CGI interface code was completely reorganised and largely rewritten. The
720 end result is that this section of your tracker interfaces module will need
721 changing from::
723 from roundup import cgi_client, mailgw
724 from roundup.i18n import _
726 class Client(cgi_client.Client):
727 ''' derives basic CGI implementation from the standard module,
728 with any specific extensions
729 '''
730 pass
732 to::
734 from roundup import mailgw
735 from roundup.cgi import client
737 class Client(client.Client):
738 ''' derives basic CGI implementation from the standard module,
739 with any specific extensions
740 '''
741 pass
743 You will also need to install the new version of roundup.cgi from the source
744 cgi-bin directory if you're using it.
747 0.5.0 HTML templating
748 ---------------------
750 You'll want to make a backup of your current tracker html directory. You
751 should then copy the html directory from the Roundup source "classic" template
752 and modify it according to your local schema changes.
754 If you need help with the new templating system, please ask questions on the
755 roundup-users mailing list (available through the roundup project page on
756 sourceforge, http://roundup.sf.net/)
759 0.5.0 Detectors
760 ---------------
762 The nosy reactor has been updated to handle the tracker not having an
763 "assignedto" property on issues. You may want to copy it into your tracker's
764 detectors directory. Chances are you've already fixed it though :)
767 Migrating from 0.4.1 to 0.4.2
768 =============================
770 0.4.2 Configuration
771 -------------------
772 The USER_INDEX definition introduced in 0.4.1 was too restrictive in its
773 allowing replacement of 'assignedto' with the user's userid. Users must change
774 the None value of 'assignedto' to 'CURRENT USER' (the string, in quotes) for
775 the replacement behaviour to occur now.
777 The new configuration variables are:
779 - EMAIL_KEEP_QUOTED_TEXT
780 - EMAIL_LEAVE_BODY_UNCHANGED
781 - ADD_RECIPIENTS_TO_NOSY
783 See the sample configuration files in::
785 <roundup source>/roundup/templates/classic/instance_config.py
787 and::
789 <roundup source>/roundup/templates/extended/instance_config.py
791 and the `customisation documentation`_ for information on how they're used.
794 0.4.2 Changes to detectors
795 --------------------------
796 You will need to copy the detectors from the distribution into your instance
797 home "detectors" directory. If you used the classic schema, the detectors
798 are in::
800 <roundup source>/roundup/templates/classic/detectors/
802 If you used the extended schema, the detectors are in::
804 <roundup source>/roundup/templates/extended/detectors/
806 The change means that schema-specific code has been removed from the
807 mail gateway and cgi interface and made into auditors:
809 - nosyreactor.py has now got an updatenosy auditor which updates the nosy
810 list with author, recipient and assignedto information.
811 - statusauditor.py makes the unread or resolved -> chatting changes and
812 presets the status of an issue to unread.
814 There's also a bug or two fixed in the nosyreactor code.
816 0.4.2 HTML templating changes
817 -----------------------------
818 The link() htmltemplate function now has a "showid" option for links and
819 multilinks. When true, it only displays the linked item id as the anchor
820 text. The link value is displayed as a tooltip using the title anchor
821 attribute. To use in eg. the superseder field, have something like this::
823 <td>
824 <display call="field('superseder', showid=1)">
825 <display call="classhelp('issue', 'id,title', label='list', width=500)">
826 <property name="superseder">
827 <br>View: <display call="link('superseder', showid=1)">
828 </property>
829 </td>
831 The stylesheets have been cleaned up too. You may want to use the newer
832 versions in::
834 <roundup source>/roundup/templates/<template>/html/default.css
838 Migrating from 0.4.0 to 0.4.1
839 =============================
841 0.4.1 Files storage
842 -------------------
844 Messages and files from newly created issues will be put into subdierectories
845 in thousands e.g. msg123 will be put into files/msg/0/msg123, file2003
846 will go into files/file/2/file2003. Previous messages are still found, but
847 could be put into this structure.
849 0.4.1 Configuration
850 -------------------
852 To allow more fine-grained access control, the variable used to check
853 permission to auto-register users in the mail gateway is now called
854 ANONYMOUS_REGISTER_MAIL rather than overloading ANONYMOUS_REGISTER. If the
855 variable doesn't exist, then ANONYMOUS_REGISTER is tested as before.
857 Configuring the links in the web header is now easier too. The following
858 variables have been added to the classic instance_config.py::
860 HEADER_INDEX_LINKS - defines the "index" links to be made available
861 HEADER_ADD_LINKS - defines the "add" links
862 DEFAULT_INDEX - specifies the index view for DEFAULT
863 UNASSIGNED_INDEX - specifies the index view for UNASSIGNED
864 USER_INDEX - specifies the index view for USER
866 See the <roundup source>/roundup/templates/classic/instance_config.py for more
867 information - including how the variables are to be set up. Most users will
868 just be able to copy the variables from the source to their instance home. If
869 you've modified the header by changing the source of the interfaces.py file in
870 the instance home, you'll need to remove that customisation and move it into
871 the appropriate variables in instance_config.py.
873 The extended schema has similar variables added too - see the source for more
874 info.
876 0.4.1 Alternate E-Mail Addresses
877 --------------------------------
879 If you add the property "alternate_addresses" to your user class, your users
880 will be able to register alternate email addresses that they may use to
881 communicate with roundup as. All email from roundup will continue to be sent
882 to their primary address.
884 If you have not edited the dbinit.py file in your instance home directory,
885 you may simply copy the new dbinit.py file from the core code. If you used
886 the classic schema, the interfaces file is in::
888 <roundup source>/roundup/templates/classic/dbinit.py
890 If you used the extended schema, the file is in::
892 <roundup source>/roundup/templates/extended/dbinit.py
894 If you have modified your dbinit.py file, you need to edit the dbinit.py
895 file in your instance home directory. Find the lines which define the user
896 class::
898 user = Class(db, "msg",
899 username=String(), password=Password(),
900 address=String(), realname=String(),
901 phone=String(), organisation=String(),
902 alternate_addresses=String())
904 You will also want to add the property to the user's details page. The
905 template for this is the "user.item" file in your instance home "html"
906 directory. Similar to above, you may copy the file from the roundup source if
907 you haven't modified it. Otherwise, add the following to the template::
909 <display call="multiline('alternate_addresses')">
911 with appropriate labelling etc. See the standard template for an idea.
915 Migrating from 0.3.x to 0.4.0
916 =============================
918 0.4.0 Message-ID and In-Reply-To addition
919 -----------------------------------------
920 0.4.0 adds the tracking of messages by message-id and allows threading
921 using in-reply-to. Most e-mail clients support threading using this
922 feature, and we hope to add support for it to the web gateway. If you
923 have not edited the dbinit.py file in your instance home directory, you may
924 simply copy the new dbinit.py file from the core code. If you used the
925 classic schema, the interfaces file is in::
927 <roundup source>/roundup/templates/classic/dbinit.py
929 If you used the extended schema, the file is in::
931 <roundup source>/roundup/templates/extended/dbinit.py
933 If you have modified your dbinit.py file, you need to edit the dbinit.py
934 file in your instance home directory. Find the lines which define the msg
935 class::
937 msg = FileClass(db, "msg",
938 author=Link("user"), recipients=Multilink("user"),
939 date=Date(), summary=String(),
940 files=Multilink("file"))
942 and add the messageid and inreplyto properties like so::
944 msg = FileClass(db, "msg",
945 author=Link("user"), recipients=Multilink("user"),
946 date=Date(), summary=String(),
947 files=Multilink("file"),
948 messageid=String(), inreplyto=String())
950 Also, configuration is being cleaned up. This means that your dbinit.py will
951 also need to be changed in the open function. If you haven't changed your
952 dbinit.py, the above copy will be enough. If you have, you'll need to change
953 the line (round line 50)::
955 db = Database(instance_config.DATABASE, name)
957 to::
959 db = Database(instance_config, name)
962 0.4.0 Configuration
963 --------------------
964 ``TRACKER_NAME`` and ``EMAIL_SIGNATURE_POSITION`` have been added to the
965 instance_config.py. The simplest solution is to copy the default values
966 from template in the core source.
968 The mail gateway now checks ``ANONYMOUS_REGISTER`` to see if unknown users
969 are to be automatically registered with the tracker. If it is set to "deny"
970 then unknown users will not have access. If it is set to "allow" they will be
971 automatically registered with the tracker.
974 0.4.0 CGI script roundup.cgi
975 ----------------------------
976 The CGI script has been updated with some features and a bugfix, so you should
977 copy it from the roundup cgi-bin source directory again. Make sure you update
978 the ROUNDUP_INSTANCE_HOMES after the copy.
981 0.4.0 Nosy reactor
982 ------------------
983 The nosy reactor has also changed - copy the nosyreactor.py file from the core
984 source::
986 <roundup source>/roundup/templates/<template>/detectors/nosyreactor.py
988 to your instance home "detectors" directory.
991 0.4.0 HTML templating
992 ---------------------
993 The field() function was incorrectly implemented - links and multilinks now
994 display as text fields when rendered using field(). To display a menu (drop-
995 down or select box) you need to use the menu() function.
999 Migrating from 0.2.x to 0.3.x
1000 =============================
1002 0.3.x Cookie Authentication changes
1003 -----------------------------------
1004 0.3.0 introduces cookie authentication - you will need to copy the
1005 interfaces.py file from the roundup source to your instance home to enable
1006 authentication. If you used the classic schema, the interfaces file is in::
1008 <roundup source>/roundup/templates/classic/interfaces.py
1010 If you used the extended schema, the file is in::
1012 <roundup source>/roundup/templates/extended/interfaces.py
1014 If you have modified your interfaces.Client class, you will need to take
1015 note of the login/logout functionality provided in roundup.cgi_client.Client
1016 (classic schema) or roundup.cgi_client.ExtendedClient (extended schema) and
1017 modify your instance code apropriately.
1020 0.3.x Password encoding
1021 -----------------------
1022 This release also introduces encoding of passwords in the database. If you
1023 have not edited the dbinit.py file in your instance home directory, you may
1024 simply copy the new dbinit.py file from the core code. If you used the
1025 classic schema, the interfaces file is in::
1027 <roundup source>/roundup/templates/classic/dbinit.py
1029 If you used the extended schema, the file is in::
1031 <roundup source>/roundup/templates/extended/dbinit.py
1034 If you have modified your dbinit.py file, you may use encoded passwords:
1036 1. Edit the dbinit.py file in your instance home directory
1037 a. At the first code line of the open() function::
1039 from roundup.hyperdb import String, Date, Link, Multilink
1041 alter to include Password, as so::
1043 from roundup.hyperdb import String, Password, Date, Link, Multilink
1045 b. Where the password property is defined (around line 66)::
1047 user = Class(db, "user",
1048 username=String(), password=String(),
1049 address=String(), realname=String(),
1050 phone=String(), organisation=String())
1051 user.setkey("username")
1053 alter the "password=String()" to "password=Password()"::
1055 user = Class(db, "user",
1056 username=String(), password=Password(),
1057 address=String(), realname=String(),
1058 phone=String(), organisation=String())
1059 user.setkey("username")
1061 2. Any existing passwords in the database will remain cleartext until they
1062 are edited. It is recommended that at a minimum the admin password be
1063 changed immediately::
1065 roundup-admin -i <instance home> set user1 password=<new password>
1068 0.3.x Configuration
1069 -------------------
1070 FILTER_POSITION, ANONYMOUS_ACCESS, ANONYMOUS_REGISTER have been added to
1071 the instance_config.py. Simplest solution is to copy the default values from
1072 template in the core source.
1074 MESSAGES_TO_AUTHOR has been added to the IssueClass in dbinit.py. Set to 'yes'
1075 to send nosy messages to the author. Default behaviour is to not send nosy
1076 messages to the author. You will need to add MESSAGES_TO_AUTHOR to your
1077 dbinit.py in your instance home.
1080 0.3.x CGI script roundup.cgi
1081 ----------------------------
1082 There have been some structural changes to the roundup.cgi script - you will
1083 need to install it again from the cgi-bin directory of the source
1084 distribution. Make sure you update the ROUNDUP_INSTANCE_HOMES after the
1085 copy.
1088 .. _`customisation documentation`: customizing.html
1089 .. _`security documentation`: security.html
1090 .. _`administration guide`: admin.html