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