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