doc/upgrading.txt

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