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