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