doc/upgrading.txt

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