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