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