1 ======================================
2 Upgrading to newer versions of Roundup
3 ======================================
5 Please read each section carefully and edit your tracker home files
6 accordingly. Note that there is information about upgrade procedures in the
7 `administration guide`_.
9 If a specific version transition isn't mentioned here (eg. 0.6.7 to 0.6.8)
10 then you don't need to do anything. If you're upgrading from 0.5.6 to
11 0.6.8 though, you'll need to check the "0.5 to 0.6" and "0.6.x to 0.6.3"
12 steps.
14 .. contents::
16 Migrating from 1.4.x to 1.4.11
17 ==============================
19 Grant the "Register" permission to the Anonymous role
20 -----------------------------------------------------
22 A separate "Register" permission has been introduced to allow
23 anonymous users to register. This means you will need to add the
24 following to your tracker's ``schema.py`` to add the permission and
25 assign it to the Anonymous role (replacing any previously assigned
26 "Create user" permission for the Anonymous role):
28 +db.security.addPermission(name='Register', klass='user',
29 + description='User is allowed to register new user')
31 # Assign the appropriate permissions to the anonymous user's Anonymous
32 # Role. Choices here are:
33 # - Allow anonymous users to register
34 -db.security.addPermissionToRole('Anonymous', 'Create', 'user')
35 +db.security.addPermissionToRole('Anonymous', 'Register', 'user')
37 The lines marked "+" should be added and lines marked "-" should be
38 deleted (minus the "+"/"-" signs).
41 Migrating from 1.4.x to 1.4.9
42 =============================
44 Customized MailGW Class
45 -----------------------
47 If you have customized the MailGW class in your tracker: The new MailGW
48 class opens the database for each message in the method handle_message
49 (instance.open) instead of passing the opened database as a parameter to
50 the MailGW constructor. The old handle_message has been renamed to
51 _handle_message. The new method opens the database and wraps the call to
52 the old method into a try/finally.
54 Your customized MailGW class needs to mirror this behavior.
56 Fix the "remove" button in issue files and messages lists
57 ---------------------------------------------------------
59 The "remove" button(s) in the issue messages list needs to be altered. Find
60 the following in your tracker's ``html/issue.item.html`` template::
62 <td>
63 <form style="padding:0" tal:condition="context/is_edit_ok"
64 tal:attributes="action string:issue${context/id}">
65 <input type="hidden" name="@remove@files" tal:attributes="value file/id">
67 and add ``method="POST"`` as shown below::
69 <td>
70 <form style="padding:0" method="POST" tal:condition="context/is_edit_ok"
71 tal:attributes="action string:issue${context/id}">
72 <input type="hidden" name="@remove@files" tal:attributes="value file/id">
74 Then also find::
76 <td>
77 <form style="padding:0" tal:condition="context/is_edit_ok"
78 tal:attributes="action string:issue${context/id}">
79 <input type="hidden" name="@remove@messages" tal:attributes="value msg/id">
81 and add ``method="POST"`` as shown below::
83 <td>
84 <form style="padding:0" method="POST" tal:condition="context/is_edit_ok"
85 tal:attributes="action string:issue${context/id}">
86 <input type="hidden" name="@remove@messages" tal:attributes="value msg/id">
89 Fixing the "retire" button in user management list
90 --------------------------------------------------
92 If you made the change to the "reture" link in the user management list as
93 listed below in `Migrating from 1.4.x to 1.4.7`_ then you'll need to fix that
94 change by adding ``method="POST"`` to the ``<form>`` tag::
96 <form style="padding:0" method="POST"
97 tal:attributes="action string:user${user/id}">
98 <input type="hidden" name="@template" value="index">
99 <input type="hidden" name="@action" value="retire">
100 <input type="submit" value="retire" i18n:attributes="value">
101 </form>
104 Migrating from 1.4.x to 1.4.7
105 =============================
107 Several security issues were addressed in this release. Some aspects of your
108 trackers may no longer function depending on your local customisations. Core
109 functionality that will need to be modified:
111 Grant the "retire" permission to users for their queries
112 --------------------------------------------------------
114 Users will no longer be able to retire their own queries. To remedy this you
115 will need to add the following to your tracker's ``schema.py`` just under the
116 line that grants them permission to edit their own queries::
118 p = db.security.addPermission(name='Edit', klass='query', check=edit_query,
119 description="User is allowed to edit their queries")
120 db.security.addPermissionToRole('User', p)
121 + p = db.security.addPermission(name='Retire', klass='query', check=edit_query,
122 + description="User is allowed to retire their queries")
123 + db.security.addPermissionToRole('User', p)
124 p = db.security.addPermission(name='Create', klass='query',
125 description="User is allowed to create queries")
126 db.security.addPermissionToRole('User', p)
128 The lines marked "+" should be added, minus the "+" sign.
131 Fix the "retire" link in the users list for admin users
132 -------------------------------------------------------
134 The "retire" link found in the file ``html/users.index.html``::
136 <td tal:condition="context/is_edit_ok">
137 <a tal:attributes="href string:user${user/id}?@action=retire&@template=index"
138 i18n:translate="">retire</a>
140 Should be replaced with::
142 <td tal:condition="context/is_retire_ok">
143 <form style="padding:0" method="POST"
144 tal:attributes="action string:user${user/id}">
145 <input type="hidden" name="@template" value="index">
146 <input type="hidden" name="@action" value="retire">
147 <input type="submit" value="retire" i18n:attributes="value">
148 </form>
151 Fix for Python 2.6+ users
152 -------------------------
154 If you use Python 2.6 you should edit your tracker's
155 ``detectors/nosyreaction.py`` file to change::
157 import sets
159 at the top to::
161 from roundup.anypy.sets_ import set
163 and then all instances of ``sets.Set()`` to ``set()`` in the later code.
167 Trackers currently allowing HTML file uploading
168 -----------------------------------------------
170 Trackers which wish to continue to allow uploading of HTML content against issues
171 will need to set a new configuration variable in the ``[web]`` section of the
172 tracker's ``config.ini`` file:
174 # Setting this option enables Roundup to serve uploaded HTML
175 # file content *as HTML*. This is a potential security risk
176 # and is therefore disabled by default. Set to 'yes' if you
177 # trust *all* users uploading content to your tracker.
178 # Allowed values: yes, no
179 # Default: no
180 allow_html_file = no
184 Migrating from 1.4.2 to 1.4.3
185 =============================
187 If you are using the MySQL backend you will need to replace some indexes
188 that may have been created by version 1.4.2.
190 You should to access your MySQL database directly and remove any indexes
191 with a name ending in "_key_retired_idx". You should then re-add them with
192 the same spec except the key column name needs a size. So an index on
193 "_user (__retired, _name)" should become "_user (__retired, _name(255))".
196 Migrating from 1.4.x to 1.4.2
197 =============================
199 You should run the "roundup-admin migrate" command for your tracker once
200 you've installed the latest codebase.
202 Do this before you use the web, command-line or mail interface and before
203 any users access the tracker.
205 This command will respond with either "Tracker updated" (if you've not
206 previously run it on an RDBMS backend) or "No migration action required"
207 (if you have run it, or have used another interface to the tracker,
208 or are using anydbm).
210 It's safe to run this even if it's not required, so just get into the
211 habit.
214 Migrating from 1.3.3 to 1.4.0
215 =============================
217 Value of the "refwd_re" tracker configuration option (section "mailgw")
218 is treated as UTF-8 string. In previous versions, it was ISO8859-1.
220 If you have running trackers based on the classic template, please
221 update the messagesummary detector as follows::
223 --- detectors/messagesummary.py 17 Apr 2003 03:26:38 -0000 1.1
224 +++ detectors/messagesummary.py 3 Apr 2007 06:47:21 -0000 1.2
225 @@ -8,7 +8,7 @@
226 if newvalues.has_key('summary') or not newvalues.has_key('content'):
227 return
229 - summary, content = parseContent(newvalues['content'], 1, 1)
230 + summary, content = parseContent(newvalues['content'], config=db.config)
231 newvalues['summary'] = summary
233 In the latest version we have added some database indexes to the
234 SQL-backends (mysql, postgresql, sqlite) for speeding up building the
235 roundup-index for full-text search. We recommend that you create the
236 following database indexes on the database by hand::
238 CREATE INDEX words_by_id ON __words (_textid)
239 CREATE UNIQUE INDEX __textids_by_props ON __textids (_class, _itemid, _prop)
241 Migrating from 1.2.x to 1.3.0
242 =============================
244 1.3.0 Web interface changes
245 ---------------------------
247 Some of the HTML files in the "classic" and "minimal" tracker templates
248 were changed to fix some bugs and clean them up. You may wish to compare
249 them to the HTML files in your tracker and apply any changes.
252 Migrating from 1.1.2 to 1.2.0
253 =============================
255 1.2.0 Sorting and grouping by multiple properties
256 -------------------------------------------------
258 Starting with this version, sorting and grouping by multiple properties
259 is possible. This means that request.sort and request.group are now
260 lists. This is reflected in several places:
262 * ``renderWith`` now has list attributes for ``sort`` and ``group``,
263 where you previously wrote::
265 renderWith(... sort=('-', 'activity'), group=('+', 'priority')
267 you write now::
269 renderWith(... sort=[('-', 'activity')], group=[('+', 'priority')]
271 * In templates that permit to edit sorting/grouping, request.sort and
272 request.group are (possibly empty) lists. You can now sort and group
273 by multiple attributes. For an example, see the classic template. You
274 may want search for the variable ``n_sort`` which can be set to the
275 number of sort/group properties.
277 * Templates that diplay new headlines for each group of items with
278 equal group properties can now use the modified ``batch.propchanged``
279 method that can take several properties which are checked for
280 changes. See the example in the classic template which makes use of
281 ``batch.propchanged``.
283 Migrating from 1.1.0 to 1.1.1
284 =============================
286 1.1.1 "Clear this message"
287 --------------------------
289 In 1.1.1, the standard ``page.html`` template includes a "clear this message"
290 link in the green "ok" message bar that appears after a successful edit
291 (or other) action.
293 To include this in your tracker, change the following in your ``page.html``
294 template::
296 <p tal:condition="options/ok_message | nothing" class="ok-message"
297 tal:repeat="m options/ok_message" tal:content="structure m">error</p>
299 to be::
301 <p tal:condition="options/ok_message | nothing" class="ok-message">
302 <span tal:repeat="m options/ok_message"
303 tal:content="structure string:$m <br/ > " />
304 <a class="form-small" tal:attributes="href request/current_url"
305 i18n:translate="">clear this message</a>
306 </p>
309 If you implemented the "clear this message" in your 1.1.0 tracker, then you
310 should change it to the above and it will work much better!
313 Migrating from 1.0.x to 1.1.0
314 =============================
316 1.1 Login "For Session Only"
317 ----------------------------
319 In 1.1, web logins are alive for the length of a session only, *unless* you
320 add the following to the login form in your tracker's ``page.html``::
322 <input type="checkbox" name="remember" id="remember">
323 <label for="remember" i18n:translate="">Remember me?</label><br>
325 See the classic tracker ``page.html`` if you're unsure where this should
326 go.
329 1.1 Query Display Name
330 ----------------------
332 The ``dispname`` web variable has been renamed ``@dispname`` to avoid
333 clashing with other variables of the same name. If you are using the
334 display name feature, you will need to edit your tracker's ``page.html``
335 and ``issue.index.html`` pages to change ``dispname`` to ``@dispname``.
337 A side-effect of this change is that the renderWith method used in the
338 ``home.html`` page may now take a dispname argument.
341 1.1 "Clear this message"
342 ------------------------
344 In 1.1, the standard ``page.html`` template includes a "clear this message"
345 link in the green "ok" message bar that appears after a successful edit
346 (or other) action.
348 To include this in your tracker, change the following in your ``page.html``
349 template::
351 <p tal:condition="options/ok_message | nothing" class="ok-message"
352 tal:repeat="m options/ok_message" tal:content="structure m">error</p>
354 to be::
356 <p tal:condition="options/ok_message | nothing" class="ok-message">
357 <span tal:repeat="m options/ok_message"
358 tal:content="structure string:$m <br/ > " />
359 <a class="form-small" tal:attributes="href string:issue${context/id}"
360 i18n:translate="">clear this message</a>
361 </p>
364 Migrating from 0.8.x to 1.0
365 ===========================
367 1.0 New Query Permissions
368 -------------------------
370 New permissions are defined for query editing and viewing. To include these
371 in your tracker, you need to add these lines to your tracker's
372 ``schema.py``::
374 # Users should be able to edit and view their own queries. They should also
375 # be able to view any marked as not private. They should not be able to
376 # edit others' queries, even if they're not private
377 def view_query(db, userid, itemid):
378 private_for = db.query.get(itemid, 'private_for')
379 if not private_for: return True
380 return userid == private_for
381 def edit_query(db, userid, itemid):
382 return userid == db.query.get(itemid, 'creator')
383 p = db.security.addPermission(name='View', klass='query', check=view_query,
384 description="User is allowed to view their own and public queries")
385 db.security.addPermissionToRole('User', p)
386 p = db.security.addPermission(name='Edit', klass='query', check=edit_query,
387 description="User is allowed to edit their queries")
388 db.security.addPermissionToRole('User', p)
389 p = db.security.addPermission(name='Create', klass='query',
390 description="User is allowed to create queries")
391 db.security.addPermissionToRole('User', p)
393 and then remove 'query' from the line::
395 # Assign the access and edit Permissions for issue, file and message
396 # to regular users now
397 for cl in 'issue', 'file', 'msg', 'query', 'keyword':
399 so it looks like::
401 for cl in 'issue', 'file', 'msg', 'keyword':
404 Migrating from 0.8.0 to 0.8.3
405 =============================
407 0.8.3 Nosy Handling Changes
408 ---------------------------
410 A change was made to fix a bug in the ``nosyreaction.py`` standard
411 detector. To incorporate this fix in your trackers, you will need to copy
412 the ``nosyreaction.py`` file from the ``templates/classic/detectors``
413 directory of the source to your tracker's ``templates`` directory.
415 If you have modified the ``nosyreaction.py`` file from the standard
416 version, you will need to roll your changes into the new file.
419 Migrating from 0.7.1 to 0.8.0
420 =============================
422 You *must* fully uninstall previous Roundup version before installing
423 Roundup 0.8.0. If you don't do that, ``roundup-admin install``
424 command may fail to function properly.
426 0.8.0 Backend changes
427 ---------------------
429 Backends 'bsddb' and 'bsddb3' are removed. If you are using one of these,
430 you *must* migrate to another backend before upgrading.
433 0.8.0 API changes
434 -----------------
436 Class.safeget() was removed from the API. Test your item ids before calling
437 Class.get() instead.
440 0.8.0 New tracker layout
441 ------------------------
443 The ``config.py`` file has been replaced by ``config.ini``. You may use the
444 roundup-admin command "genconfig" to generate a new config file::
446 roundup-admin genconfig <tracker home>/config.ini
448 and modify the values therein based on the contents of your old config.py.
449 In most cases, the names of the config variables are the same.
451 The ``select_db.py`` file has been replaced by a file in the ``db``
452 directory called ``backend_name``. As you might guess, this file contains
453 just the name of the backend. To figure what the contents of yours should
454 be, use the following table:
456 ================================ =========================
457 ``select_db.py`` contents ``backend_name`` contents
458 ================================ =========================
459 from back_anydbm import ... anydbm
460 from back_metakit import ... metakit
461 from back_sqlite import ... sqlite
462 from back_mysql import ... mysql
463 from back_postgresql import ... postgresql
464 ================================ =========================
466 The ``dbinit.py`` file has been split into two new files,
467 ``initial_data.py`` and ``schema.py``. The contents of this file are:
469 ``initial_data.py``
470 You don't need one of these as your tracker is already initialised.
472 ``schema.py``
473 Copy the body of the ``def open(name=None)`` function from your old
474 tracker's ``dbinit.py`` file to this file. As the lines you're copying
475 aren't part of a function definition anymore, one level of indentation
476 needs to be removed (remove only the leading four spaces on each
477 line).
479 The first few lines -- those starting with ``from roundup.hyperdb
480 import ...`` and the ``db = Database(config, name)`` line -- don't
481 need to be copied. Neither do the last few lines -- those starting
482 with ``import detectors``, down to ``return db`` inclusive.
484 You may remove the ``__init__.py`` module from the "detectors" directory as
485 it is no longer used.
487 There's a new way to write extension code for Roundup. If you have code in
488 an ``interfaces.py`` file you should move it. See the `customisation
489 documentation`_ for information about how extensions are now written.
490 Note that some older trackers may use ``interfaces.py`` to customise the
491 mail gateway behaviour. You will need to keep your ``interfaces.py`` file
492 if this is the case.
495 0.8.0 Permissions Changes
496 -------------------------
498 The creation of a new item in the user interfaces is now controlled by the
499 "Create" Permission. You will need to add an assignment of this Permission
500 to your users who are allowed to create items. The most common form of this
501 is the following in your ``schema.py`` added just under the current
502 assignation of the Edit Permission::
504 for cl in 'issue', 'file', 'msg', 'query', 'keyword':
505 p = db.security.getPermission('Create', cl)
506 db.security.addPermissionToRole('User', p)
508 You will need to explicitly let anonymous users access the web interface so
509 that regular users are able to see the login form. Note that almost all
510 trackers will need this Permission. The only situation where it's not
511 required is in a tracker that uses an HTTP Basic Authenticated front-end.
512 It's enabled by adding to your ``schema.py``::
514 p = db.security.getPermission('Web Access')
515 db.security.addPermissionToRole('Anonymous', p)
517 Finally, you will need to enable permission for your users to edit their
518 own details by adding the following to ``schema.py``::
520 # Users should be able to edit their own details. Note that this
521 # permission is limited to only the situation where the Viewed or
522 # Edited item is their own.
523 def own_record(db, userid, itemid):
524 '''Determine whether the userid matches the item being accessed.'''
525 return userid == itemid
526 p = db.security.addPermission(name='View', klass='user', check=own_record,
527 description="User is allowed to view their own user details")
528 p = db.security.addPermission(name='Edit', klass='user', check=own_record,
529 description="User is allowed to edit their own user details")
530 db.security.addPermissionToRole('User', p)
533 0.8.0 Use of TemplatingUtils
534 ----------------------------
536 If you used custom python functions in TemplatingUtils, they must
537 be moved from interfaces.py to a new file in the ``extensions`` directory.
539 Each Function that should be available through TAL needs to be defined
540 as a toplevel function in the newly created file. Furthermore you
541 add an inititialization function, that registers the functions with the
542 tracker.
544 If you find this too tedious, donfu wrote an automatic init function that
545 takes an existing TemplatingUtils class, and registers all class methods
546 that do not start with an underscore. The following hack should be placed
547 in the ``extensions`` directory alongside other extensions::
549 class TemplatingUtils:
550 # copy from interfaces.py
552 def init(tracker):
553 util = TemplatingUtils()
555 def setClient(tu):
556 util.client = tu.client
557 return util
559 def execUtil(name):
560 return lambda tu, *args, **kwargs: \
561 getattr(setClient(tu), name)(*args, **kwargs)
563 for name in dir(util):
564 if callable(getattr(util, name)) and not name.startswith('_'):
565 tracker.registerUtil(name, execUtil(name))
568 0.8.0 Logging Configuration
569 ---------------------------
571 See the `administration guide`_ for information about configuring the new
572 logging implemented in 0.8.0.
575 Migrating from 0.7.2 to 0.7.3
576 =============================
578 0.7.3 Configuration
579 -------------------
581 If you choose, you may specify the directory from which static files are
582 served (those which use the URL component ``@@file``). Currently the
583 directory defaults to the ``TEMPLATES`` configuration variable. You may
584 define a new variable, ``STATIC_FILES`` which overrides this value for
585 static files.
588 Migrating from 0.7.0 to 0.7.2
589 =============================
591 0.7.2 DEFAULT_TIMEZONE is now required
592 --------------------------------------
594 The DEFAULT_TIMEZONE configuration variable is now required. Add the
595 following to your tracker's ``config.py`` file::
597 # You may specify a different default timezone, for use when users do not
598 # choose their own in their settings.
599 DEFAULT_TIMEZONE = 0 # specify as numeric hour offest
602 Migrating from 0.7.0 to 0.7.1
603 =============================
605 0.7.1 Permission assignments
606 ----------------------------
608 If you allow anonymous access to your tracker, you might need to assign
609 some additional View (or Edit if your tracker is that open) permissions
610 to the "anonymous" user. To do so, find the code in your ``dbinit.py`` that
611 says::
613 for cl in 'issue', 'file', 'msg', 'query', 'keyword':
614 p = db.security.getPermission('View', cl)
615 db.security.addPermissionToRole('User', p)
616 p = db.security.getPermission('Edit', cl)
617 db.security.addPermissionToRole('User', p)
618 for cl in 'priority', 'status':
619 p = db.security.getPermission('View', cl)
620 db.security.addPermissionToRole('User', p)
622 Add add a line::
624 db.security.addPermissionToRole('Anonymous', p)
626 next to the existing ``'User'`` lines for the Permissions you wish to
627 assign to the anonymous user.
630 Migrating from 0.6 to 0.7
631 =========================
633 0.7.0 Permission assignments
634 ----------------------------
636 Due to a change in the rendering of web widgets, permissions are now
637 checked on Classes where they previously weren't (this is a good thing).
639 You will need to add some additional Permission assignments for your
640 regular users, or some displays will break. After the following in your
641 tracker's ``dbinit.py``::
643 # Assign the access and edit Permissions for issue, file and message
644 # to regular users now
645 for cl in 'issue', 'file', 'msg', 'query', 'keyword':
646 p = db.security.getPermission('View', cl)
647 db.security.addPermissionToRole('User', p)
648 p = db.security.getPermission('Edit', cl)
649 db.security.addPermissionToRole('User', p)
651 add::
653 for cl in 'priority', 'status':
654 p = db.security.getPermission('View', cl)
655 db.security.addPermissionToRole('User', p)
658 0.7.0 Getting the current user id
659 ---------------------------------
661 The Database.curuserid attribute has been removed.
663 Any code referencing this attribute should be replaced with a
664 call to Database.getuid().
667 0.7.0 ZRoundup changes
668 ----------------------
670 The templates in your tracker's html directory will need updating if you
671 wish to use ZRoundup. If you've not modified those files (or some of them),
672 you may just copy the new versions from the Roundup source in the
673 templates/classic/html directory.
675 If you have modified the html files, then you'll need to manually edit them
676 to change all occurances of special form variables from using the colon ":"
677 special character to the at "@" special character. That is, variables such
678 as::
680 :action :required :template :remove:messages ...
682 should become::
684 @action @required @template @remove@messages ...
686 Note that ``tal:`` statements are unaffected. So are TAL expression type
687 prefixes such as ``python:`` and ``string:``. Please ask on the
688 roundup-users mailing list for help if you're unsure.
691 0.7.0 Edit collision detection
692 ------------------------------
694 Roundup now detects collisions with editing in the web interface (that is,
695 two people editing the same item at the same time).
697 You must copy the ``_generic.collision.html`` file from Roundup source in
698 the ``templates/classic/html`` directory. to your tracker's ``html``
699 directory.
702 Migrating from 0.6.x to 0.6.3
703 =============================
705 0.6.3 Configuration
706 -------------------
708 You will need to copy the file::
710 templates/classic/detectors/__init__.py
712 to your tracker's ``detectors`` directory, replacing the one already there.
713 This fixes a couple of bugs in that file.
717 Migrating from 0.5 to 0.6
718 =========================
721 0.6.0 Configuration
722 -------------------
724 Introduced EMAIL_FROM_TAG config variable. This value is inserted into
725 the From: line of nosy email. If the sending user is "Foo Bar", the
726 From: line is usually::
728 "Foo Bar" <issue_tracker@tracker.example>
730 the EMAIL_FROM_TAG goes inside the "Foo Bar" quotes like so::
732 "Foo Bar EMAIL_FROM_TAG" <issue_tracker@tracker.example>
734 I've altered the mechanism in the detectors __init__.py module so that it
735 doesn't cross-import detectors from other trackers (if you run more than one
736 in a single roundup-server). This change means that you'll need to copy the
737 __init__.py from roundup/templates/classic/detectors/__init__.py to your
738 <tracker home>/detectors/__init__.py. Don't worry, the "classic" __init__ is a
739 one-size-fits-all, so it'll work even if you've added/removed detectors.
741 0.6.0 Templating changes
742 ------------------------
744 The ``user.item`` template (in the tracker home "templates" directory)
745 needs to have the following hidden variable added to its form (between the
746 ``<form...>`` and ``</form>`` tags::
748 <input type="hidden" name=":template" value="item">
751 0.6.0 Form handling changes
752 ---------------------------
754 Roundup's form handling capabilities have been significantly expanded. This
755 should not affect users of 0.5 installations - but if you find you're
756 getting errors from form submissions, please ask for help on the Roundup
757 users mailing list:
759 http://lists.sourceforge.net/lists/listinfo/roundup-users
761 See the customisation doc section on `Form Values`__ for documentation of the
762 new form variables possible.
764 __ customizing.html#form-values
767 0.6.0 Multilingual character set support
768 ----------------------------------------
770 Added internationalization support. This is done via encoding all data
771 stored in roundup database to utf-8 (unicode encoding). To support utf-8 in
772 web interface you should add the folowing line to your tracker's html/page
773 and html/_generic.help files inside <head> tag::
775 <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
777 Since latin characters in utf-8 have the same codes as in ASCII table, this
778 modification is optional for users who use only plain latin characters.
780 After this modification, you will be able to see and enter any world
781 character via web interface. Data received via mail interface also converted
782 to utf-8, however only new messages will be converted. If your roundup
783 database contains some of non-ASCII characters in one of 8-bit encoding,
784 they will not be visible in new unicode environment. Some of such data (e.g.
785 user names, keywords, etc) can be edited by administrator, the others
786 (e.g. messages' contents) is not editable via web interface. Currently there
787 is no tool for converting such data, the only solution is to close
788 appropriate old issues and create new ones with the same content.
791 0.6.0 User timezone support
792 ---------------------------
794 From version 0.6.0 roundup supports displaying of Date data in user' local
795 timezone if he/she has provided timezone information. To make it possible
796 some modification to tracker's schema and HTML templates are required.
797 First you must add string property 'timezone' to user class in dbinit.py
798 like this::
800 user = Class(db, "user",
801 username=String(), password=Password(),
802 address=String(), realname=String(),
803 phone=String(), organisation=String(),
804 alternate_addresses=String(),
805 queries=Multilink('query'), roles=String(),
806 timezone=String())
808 And second - html interface. Add following lines to
809 $TRACKER_HOME/html/user.item template::
811 <tr>
812 <th>Timezone</th>
813 <td tal:content="structure context/timezone/field">timezone</td>
814 </tr>
816 After that all users should be able to provide their timezone information.
817 Timezone should be a positive or negative integer - offset from GMT.
819 After providing timezone, roundup will show all dates values, found in web
820 and mail interfaces in local time. It will also accept any Date info in
821 local time, convert and store it in GMT.
824 0.6.0 Search page structure
825 ---------------------------
827 In order to accomodate query editing the search page has been restructured. If
828 you want to provide your users with query editing, you should update your
829 search page using the macros detailed in the customisation doc section
830 `Searching on categories`__.
832 __ customizing.html#searching-on-categories
834 Also, the url field in the query class no longer starts with a '?'. You'll need
835 to remove this question mark from the url field to support queries. There's
836 a script in the "tools" directory called ``migrate-queries.py`` that should
837 automatically change any existing queries for you. As always, make a backup
838 of your database before running such a script.
841 0.6.0 Notes for metakit backend users
842 -------------------------------------
844 Roundup 0.6.0 introduced searching on ranges of dates and intervals. To
845 support it, some modifications to interval storing routine were made. So if
846 your tracker uses metakit backend and your db schema contains intervals
847 property, searches on that property will not be accurate for db items that
848 was stored before roundup' upgrade. However all new records should be
849 searchable on intervals.
851 It is possible to convert your database to new format: you can export and
852 import back all your data (consult "Migrating backends" in "Maintenance"
853 documentation). After this operation all your interval properties should
854 become searchable.
856 Users of backends others than metakit should not worry about this issue.
859 Migrating from 0.4.x to 0.5.0
860 =============================
862 This has been a fairly major revision of Roundup:
864 1. Brand new, much more powerful, flexible, tasty and nutritious templating.
865 Unfortunately, this means all your current templates are useless. Hopefully
866 the new documentation and examples will be enough to help you make the
867 transition. Please don't hesitate to ask on roundup-users for help (or
868 complete conversions if you're completely stuck)!
869 2. The database backed got a lot more flexible, allowing Metakit and SQL
870 databases! The only decent SQL database implemented at present is sqlite,
871 but others shouldn't be a whole lot more work.
872 3. A brand new, highly flexible and much more robust security system including
873 a system of Permissions, Roles and Role assignments to users. You may now
874 define your own Permissions that may be checked in CGI transactions.
875 4. Journalling has been made less storage-hungry, so has been turned on
876 by default *except* for author, recipient and nosy link/unlink events. You
877 are advised to turn it off in your trackers too.
878 5. We've changed the terminology from "instance" to "tracker", to ease the
879 learning curve/impact for new users.
880 6. Because of the above changes, the tracker configuration has seen some
881 major changes. See below for the details.
883 Please, **back up your database** before you start the migration process. This
884 is as simple as copying the "db" directory and all its contents from your
885 tracker to somewhere safe.
888 0.5.0 Configuration
889 -------------------
891 First up, rename your ``instance_config.py`` file to just ``config.py``.
893 Then edit your tracker's ``__init__.py`` module. It'll currently look
894 like this::
896 from instance_config import *
897 try:
898 from dbinit import *
899 except ImportError:
900 pass # in installdir (probably :)
901 from interfaces import *
903 and it needs to be::
905 import config
906 from dbinit import open, init
907 from interfaces import Client, MailGW
909 Due to the new templating having a top-level ``page`` that defines links for
910 searching, indexes, adding items etc, the following variables are no longer
911 used:
913 - HEADER_INDEX_LINKS
914 - HEADER_ADD_LINKS
915 - HEADER_SEARCH_LINKS
916 - SEARCH_FILTERS
917 - DEFAULT_INDEX
918 - UNASSIGNED_INDEX
919 - USER_INDEX
920 - ISSUE_FILTER
922 The new security implementation will require additions to the dbinit module,
923 but also removes the need for the following tracker config variables:
925 - ANONYMOUS_ACCESS
926 - ANONYMOUS_REGISTER
928 but requires two new variables which define the Roles assigned to users who
929 register through the web and e-mail interfaces:
931 - NEW_WEB_USER_ROLES
932 - NEW_EMAIL_USER_ROLES
934 in both cases, 'User' is a good initial setting. To emulate
935 ``ANONYMOUS_ACCESS='deny'``, remove all "View" Permissions from the
936 "Anonymous" Role. To emulate ``ANONYMOUS_REGISTER='deny'``, remove the "Web
937 Registration" and/or the "Email Registration" Permission from the "Anonymous"
938 Role. See the section on customising security in the `customisation
939 documentation`_ for more information.
941 Finally, the following config variables have been renamed to make more sense:
943 - INSTANCE_HOME -> TRACKER_HOME
944 - INSTANCE_NAME -> TRACKER_NAME
945 - ISSUE_TRACKER_WEB -> TRACKER_WEB
946 - ISSUE_TRACKER_EMAIL -> TRACKER_EMAIL
949 0.5.0 Schema Specification
950 --------------------------
952 0.5.0 Database backend changes
953 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
955 Your select_db module in your tracker has changed a fair bit. Where it used
956 to contain::
958 # WARNING: DO NOT EDIT THIS FILE!!!
959 from roundup.backends.back_anydbm import Database
961 it must now contain::
963 # WARNING: DO NOT EDIT THIS FILE!!!
964 from roundup.backends.back_anydbm import Database, Class, FileClass, IssueClass
966 Yes, I realise the irony of the "DO NOT EDIT THIS FILE" statement :)
967 Note the addition of the Class, FileClass, IssueClass imports. These are very
968 important, as they're going to make the next change work too. You now need to
969 modify the top of the dbinit module in your tracker from::
971 import instance_config
972 from roundup import roundupdb
973 from select_db import Database
975 from roundup.roundupdb import Class, FileClass
977 class Database(roundupdb.Database, select_db.Database):
978 ''' Creates a hybrid database from:
979 . the selected database back-end from select_db
980 . the roundup extensions from roundupdb
981 '''
982 pass
984 class IssueClass(roundupdb.IssueClass):
985 ''' issues need the email information
986 '''
987 pass
989 to::
991 import config
992 from select_db import Database, Class, FileClass, IssueClass
994 Yes, remove the Database and IssueClass definitions and those other imports.
995 They're not needed any more!
997 Look for places in dbinit.py where ``instance_config`` is used too, and
998 rename them ``config``.
1001 0.5.0 Journalling changes
1002 ~~~~~~~~~~~~~~~~~~~~~~~~~
1004 Journalling has been optimised for storage. Journalling of links has been
1005 turned back on by default. If your tracker has a large user base, you may wish
1006 to turn off journalling of nosy list, message author and message recipient
1007 link and unlink events. You do this by adding ``do_journal='no'`` to the Class
1008 initialisation in your dbinit. For example, your *msg* class initialisation
1009 probably looks like this::
1011 msg = FileClass(db, "msg",
1012 author=Link("user"), recipients=Multilink("user"),
1013 date=Date(), summary=String(),
1014 files=Multilink("file"),
1015 messageid=String(), inreplyto=String())
1017 to turn off journalling of author and recipient link events, add
1018 ``do_journal='no'`` to the ``author=Link("user")`` part of the statement,
1019 like so::
1021 msg = FileClass(db, "msg",
1022 author=Link("user", do_journal='no'),
1023 recipients=Multilink("user", do_journal='no'),
1024 date=Date(), summary=String(),
1025 files=Multilink("file"),
1026 messageid=String(), inreplyto=String())
1028 Nosy list link event journalling is actually turned off by default now. If you
1029 want to turn it on, change to your issue class' nosy list, change its
1030 definition from::
1032 issue = IssueClass(db, "issue",
1033 assignedto=Link("user"), topic=Multilink("keyword"),
1034 priority=Link("priority"), status=Link("status"))
1036 to::
1038 issue = IssueClass(db, "issue", nosy=Multilink("user", do_journal='yes'),
1039 assignedto=Link("user"), topic=Multilink("keyword"),
1040 priority=Link("priority"), status=Link("status"))
1042 noting that your definition of the nosy Multilink will override the normal one.
1045 0.5.0 User schema changes
1046 ~~~~~~~~~~~~~~~~~~~~~~~~~
1048 Users have two more properties, "queries" and "roles". You'll have something
1049 like this in your dbinit module now::
1051 user = Class(db, "user",
1052 username=String(), password=Password(),
1053 address=String(), realname=String(),
1054 phone=String(), organisation=String(),
1055 alternate_addresses=String())
1056 user.setkey("username")
1058 and you'll need to add the new properties and the new "query" class to it
1059 like so::
1061 query = Class(db, "query",
1062 klass=String(), name=String(),
1063 url=String())
1064 query.setkey("name")
1066 # Note: roles is a comma-separated string of Role names
1067 user = Class(db, "user",
1068 username=String(), password=Password(),
1069 address=String(), realname=String(),
1070 phone=String(), organisation=String(),
1071 alternate_addresses=String(),
1072 queries=Multilink('query'), roles=String())
1073 user.setkey("username")
1075 The "queries" property is used to store off the user's favourite database
1076 queries. The "roles" property is explained below in `0.5.0 Security
1077 Settings`_.
1080 0.5.0 Security Settings
1081 ~~~~~~~~~~~~~~~~~~~~~~~
1083 See the `security documentation`_ for an explanation of how the new security
1084 system works. In a nutshell though, the security is handled as a four step
1085 process:
1087 1. Permissions are defined as having a name and optionally a hyperdb class
1088 they're specific to,
1089 2. Roles are defined that have one or more Permissions,
1090 3. Users are assigned Roles in their "roles" property, and finally
1091 4. Roundup checks that users have appropriate Permissions at appropriate times
1092 (like editing issues).
1094 Your tracker dbinit module's *open* function now has to define any
1095 Permissions that are specific to your tracker, and also the assignment
1096 of Permissions to Roles. At the moment, your open function
1097 ends with::
1099 import detectors
1100 detectors.init(db)
1102 return db
1104 and what we need to do is insert some commands that will set up the security
1105 parameters. Right above the ``import detectors`` line, you'll want to insert
1106 these lines::
1108 #
1109 # SECURITY SETTINGS
1110 #
1111 # new permissions for this schema
1112 for cl in 'issue', 'file', 'msg', 'user':
1113 db.security.addPermission(name="Edit", klass=cl,
1114 description="User is allowed to edit "+cl)
1115 db.security.addPermission(name="View", klass=cl,
1116 description="User is allowed to access "+cl)
1118 # Assign the access and edit permissions for issue, file and message
1119 # to regular users now
1120 for cl in 'issue', 'file', 'msg':
1121 p = db.security.getPermission('View', cl)
1122 db.security.addPermissionToRole('User', p)
1123 p = db.security.getPermission('Edit', cl)
1124 db.security.addPermissionToRole('User', p)
1125 # and give the regular users access to the web and email interface
1126 p = db.security.getPermission('Web Access')
1127 db.security.addPermissionToRole('User', p)
1128 p = db.security.getPermission('Email Access')
1129 db.security.addPermissionToRole('User', p)
1131 # May users view other user information? Comment these lines out
1132 # if you don't want them to
1133 p = db.security.getPermission('View', 'user')
1134 db.security.addPermissionToRole('User', p)
1136 # Assign the appropriate permissions to the anonymous user's Anonymous
1137 # Role. Choices here are:
1138 # - Allow anonymous users to register through the web
1139 p = db.security.getPermission('Web Registration')
1140 db.security.addPermissionToRole('Anonymous', p)
1141 # - Allow anonymous (new) users to register through the email gateway
1142 p = db.security.getPermission('Email Registration')
1143 db.security.addPermissionToRole('Anonymous', p)
1144 # - Allow anonymous users access to the "issue" class of data
1145 # Note: this also grants access to related information like files,
1146 # messages, statuses etc that are linked to issues
1147 #p = db.security.getPermission('View', 'issue')
1148 #db.security.addPermissionToRole('Anonymous', p)
1149 # - Allow anonymous users access to edit the "issue" class of data
1150 # Note: this also grants access to create related information like
1151 # files and messages etc that are linked to issues
1152 #p = db.security.getPermission('Edit', 'issue')
1153 #db.security.addPermissionToRole('Anonymous', p)
1155 # oh, g'wan, let anonymous access the web interface too
1156 p = db.security.getPermission('Web Access')
1157 db.security.addPermissionToRole('Anonymous', p)
1159 Note in the comments there the places where you might change the permissions
1160 to restrict users or grant users more access. If you've created additional
1161 classes that users should be able to edit and view, then you should add them
1162 to the "new permissions for this schema" section at the start of the security
1163 block. Then add them to the "Assign the access and edit permissions" section
1164 too, so people actually have the new Permission you've created.
1166 One final change is needed that finishes off the security system's
1167 initialisation. We need to add a call to ``db.post_init()`` at the end of the
1168 dbinit open() function. Add it like this::
1170 import detectors
1171 detectors.init(db)
1173 # schema is set up - run any post-initialisation
1174 db.post_init()
1175 return db
1177 You may verify the setup of Permissions and Roles using the new
1178 "``roundup-admin security``" command.
1181 0.5.0 User changes
1182 ~~~~~~~~~~~~~~~~~~
1184 To support all those schema changes, you'll need to massage your user database
1185 a little too, to:
1187 1. make sure there's an "anonymous" user - this user is mandatory now and is
1188 the one that unknown users are logged in as.
1189 2. make sure all users have at least one Role.
1191 If you don't have the "anonymous" user, create it now with the command::
1193 roundup-admin create user username=anonymous roles=Anonymous
1195 making sure the capitalisation is the same as above. Once you've done that,
1196 you'll need to set the roles property on all users to a reasonable default.
1197 The admin user should get "Admin", the anonymous user "Anonymous"
1198 and all other users "User". The ``fixroles.py`` script in the tools directory
1199 will do this. Run it like so (where python is your python 2+ binary)::
1201 python tools/fixroles.py -i <tracker home> fixroles
1205 0.5.0 CGI interface changes
1206 ---------------------------
1208 The CGI interface code was completely reorganised and largely rewritten. The
1209 end result is that this section of your tracker interfaces module will need
1210 changing from::
1212 from roundup import cgi_client, mailgw
1213 from roundup.i18n import _
1215 class Client(cgi_client.Client):
1216 ''' derives basic CGI implementation from the standard module,
1217 with any specific extensions
1218 '''
1219 pass
1221 to::
1223 from roundup import mailgw
1224 from roundup.cgi import client
1226 class Client(client.Client):
1227 ''' derives basic CGI implementation from the standard module,
1228 with any specific extensions
1229 '''
1230 pass
1232 You will also need to install the new version of roundup.cgi from the source
1233 cgi-bin directory if you're using it.
1236 0.5.0 HTML templating
1237 ---------------------
1239 You'll want to make a backup of your current tracker html directory. You
1240 should then copy the html directory from the Roundup source "classic" template
1241 and modify it according to your local schema changes.
1243 If you need help with the new templating system, please ask questions on the
1244 roundup-users mailing list (available through the roundup project page on
1245 sourceforge, http://roundup.sf.net/)
1248 0.5.0 Detectors
1249 ---------------
1251 The nosy reactor has been updated to handle the tracker not having an
1252 "assignedto" property on issues. You may want to copy it into your tracker's
1253 detectors directory. Chances are you've already fixed it though :)
1256 Migrating from 0.4.1 to 0.4.2
1257 =============================
1259 0.4.2 Configuration
1260 -------------------
1261 The USER_INDEX definition introduced in 0.4.1 was too restrictive in its
1262 allowing replacement of 'assignedto' with the user's userid. Users must change
1263 the None value of 'assignedto' to 'CURRENT USER' (the string, in quotes) for
1264 the replacement behaviour to occur now.
1266 The new configuration variables are:
1268 - EMAIL_KEEP_QUOTED_TEXT
1269 - EMAIL_LEAVE_BODY_UNCHANGED
1270 - ADD_RECIPIENTS_TO_NOSY
1272 See the sample configuration files in::
1274 <roundup source>/roundup/templates/classic/instance_config.py
1276 and::
1278 <roundup source>/roundup/templates/extended/instance_config.py
1280 and the `customisation documentation`_ for information on how they're used.
1283 0.4.2 Changes to detectors
1284 --------------------------
1285 You will need to copy the detectors from the distribution into your instance
1286 home "detectors" directory. If you used the classic schema, the detectors
1287 are in::
1289 <roundup source>/roundup/templates/classic/detectors/
1291 If you used the extended schema, the detectors are in::
1293 <roundup source>/roundup/templates/extended/detectors/
1295 The change means that schema-specific code has been removed from the
1296 mail gateway and cgi interface and made into auditors:
1298 - nosyreactor.py has now got an updatenosy auditor which updates the nosy
1299 list with author, recipient and assignedto information.
1300 - statusauditor.py makes the unread or resolved -> chatting changes and
1301 presets the status of an issue to unread.
1303 There's also a bug or two fixed in the nosyreactor code.
1305 0.4.2 HTML templating changes
1306 -----------------------------
1307 The link() htmltemplate function now has a "showid" option for links and
1308 multilinks. When true, it only displays the linked item id as the anchor
1309 text. The link value is displayed as a tooltip using the title anchor
1310 attribute. To use in eg. the superseder field, have something like this::
1312 <td>
1313 <display call="field('superseder', showid=1)">
1314 <display call="classhelp('issue', 'id,title', label='list', width=500)">
1315 <property name="superseder">
1316 <br>View: <display call="link('superseder', showid=1)">
1317 </property>
1318 </td>
1320 The stylesheets have been cleaned up too. You may want to use the newer
1321 versions in::
1323 <roundup source>/roundup/templates/<template>/html/default.css
1327 Migrating from 0.4.0 to 0.4.1
1328 =============================
1330 0.4.1 Files storage
1331 -------------------
1333 Messages and files from newly created issues will be put into subdierectories
1334 in thousands e.g. msg123 will be put into files/msg/0/msg123, file2003
1335 will go into files/file/2/file2003. Previous messages are still found, but
1336 could be put into this structure.
1338 0.4.1 Configuration
1339 -------------------
1341 To allow more fine-grained access control, the variable used to check
1342 permission to auto-register users in the mail gateway is now called
1343 ANONYMOUS_REGISTER_MAIL rather than overloading ANONYMOUS_REGISTER. If the
1344 variable doesn't exist, then ANONYMOUS_REGISTER is tested as before.
1346 Configuring the links in the web header is now easier too. The following
1347 variables have been added to the classic instance_config.py::
1349 HEADER_INDEX_LINKS - defines the "index" links to be made available
1350 HEADER_ADD_LINKS - defines the "add" links
1351 DEFAULT_INDEX - specifies the index view for DEFAULT
1352 UNASSIGNED_INDEX - specifies the index view for UNASSIGNED
1353 USER_INDEX - specifies the index view for USER
1355 See the <roundup source>/roundup/templates/classic/instance_config.py for more
1356 information - including how the variables are to be set up. Most users will
1357 just be able to copy the variables from the source to their instance home. If
1358 you've modified the header by changing the source of the interfaces.py file in
1359 the instance home, you'll need to remove that customisation and move it into
1360 the appropriate variables in instance_config.py.
1362 The extended schema has similar variables added too - see the source for more
1363 info.
1365 0.4.1 Alternate E-Mail Addresses
1366 --------------------------------
1368 If you add the property "alternate_addresses" to your user class, your users
1369 will be able to register alternate email addresses that they may use to
1370 communicate with roundup as. All email from roundup will continue to be sent
1371 to their primary address.
1373 If you have not edited the dbinit.py file in your instance home directory,
1374 you may simply copy the new dbinit.py file from the core code. If you used
1375 the classic schema, the interfaces file is in::
1377 <roundup source>/roundup/templates/classic/dbinit.py
1379 If you used the extended schema, the file is in::
1381 <roundup source>/roundup/templates/extended/dbinit.py
1383 If you have modified your dbinit.py file, you need to edit the dbinit.py
1384 file in your instance home directory. Find the lines which define the user
1385 class::
1387 user = Class(db, "msg",
1388 username=String(), password=Password(),
1389 address=String(), realname=String(),
1390 phone=String(), organisation=String(),
1391 alternate_addresses=String())
1393 You will also want to add the property to the user's details page. The
1394 template for this is the "user.item" file in your instance home "html"
1395 directory. Similar to above, you may copy the file from the roundup source if
1396 you haven't modified it. Otherwise, add the following to the template::
1398 <display call="multiline('alternate_addresses')">
1400 with appropriate labelling etc. See the standard template for an idea.
1404 Migrating from 0.3.x to 0.4.0
1405 =============================
1407 0.4.0 Message-ID and In-Reply-To addition
1408 -----------------------------------------
1409 0.4.0 adds the tracking of messages by message-id and allows threading
1410 using in-reply-to. Most e-mail clients support threading using this
1411 feature, and we hope to add support for it to the web gateway. If you
1412 have not edited the dbinit.py file in your instance home directory, you may
1413 simply copy the new dbinit.py file from the core code. If you used the
1414 classic schema, the interfaces file is in::
1416 <roundup source>/roundup/templates/classic/dbinit.py
1418 If you used the extended schema, the file is in::
1420 <roundup source>/roundup/templates/extended/dbinit.py
1422 If you have modified your dbinit.py file, you need to edit the dbinit.py
1423 file in your instance home directory. Find the lines which define the msg
1424 class::
1426 msg = FileClass(db, "msg",
1427 author=Link("user"), recipients=Multilink("user"),
1428 date=Date(), summary=String(),
1429 files=Multilink("file"))
1431 and add the messageid and inreplyto properties like so::
1433 msg = FileClass(db, "msg",
1434 author=Link("user"), recipients=Multilink("user"),
1435 date=Date(), summary=String(),
1436 files=Multilink("file"),
1437 messageid=String(), inreplyto=String())
1439 Also, configuration is being cleaned up. This means that your dbinit.py will
1440 also need to be changed in the open function. If you haven't changed your
1441 dbinit.py, the above copy will be enough. If you have, you'll need to change
1442 the line (round line 50)::
1444 db = Database(instance_config.DATABASE, name)
1446 to::
1448 db = Database(instance_config, name)
1451 0.4.0 Configuration
1452 --------------------
1453 ``TRACKER_NAME`` and ``EMAIL_SIGNATURE_POSITION`` have been added to the
1454 instance_config.py. The simplest solution is to copy the default values
1455 from template in the core source.
1457 The mail gateway now checks ``ANONYMOUS_REGISTER`` to see if unknown users
1458 are to be automatically registered with the tracker. If it is set to "deny"
1459 then unknown users will not have access. If it is set to "allow" they will be
1460 automatically registered with the tracker.
1463 0.4.0 CGI script roundup.cgi
1464 ----------------------------
1465 The CGI script has been updated with some features and a bugfix, so you should
1466 copy it from the roundup cgi-bin source directory again. Make sure you update
1467 the ROUNDUP_INSTANCE_HOMES after the copy.
1470 0.4.0 Nosy reactor
1471 ------------------
1472 The nosy reactor has also changed - copy the nosyreactor.py file from the core
1473 source::
1475 <roundup source>/roundup/templates/<template>/detectors/nosyreactor.py
1477 to your instance home "detectors" directory.
1480 0.4.0 HTML templating
1481 ---------------------
1482 The field() function was incorrectly implemented - links and multilinks now
1483 display as text fields when rendered using field(). To display a menu (drop-
1484 down or select box) you need to use the menu() function.
1488 Migrating from 0.2.x to 0.3.x
1489 =============================
1491 0.3.x Cookie Authentication changes
1492 -----------------------------------
1493 0.3.0 introduces cookie authentication - you will need to copy the
1494 interfaces.py file from the roundup source to your instance home to enable
1495 authentication. If you used the classic schema, the interfaces file is in::
1497 <roundup source>/roundup/templates/classic/interfaces.py
1499 If you used the extended schema, the file is in::
1501 <roundup source>/roundup/templates/extended/interfaces.py
1503 If you have modified your interfaces.Client class, you will need to take
1504 note of the login/logout functionality provided in roundup.cgi_client.Client
1505 (classic schema) or roundup.cgi_client.ExtendedClient (extended schema) and
1506 modify your instance code apropriately.
1509 0.3.x Password encoding
1510 -----------------------
1511 This release also introduces encoding of passwords in the database. If you
1512 have not edited the dbinit.py file in your instance home directory, you may
1513 simply copy the new dbinit.py file from the core code. If you used the
1514 classic schema, the interfaces file is in::
1516 <roundup source>/roundup/templates/classic/dbinit.py
1518 If you used the extended schema, the file is in::
1520 <roundup source>/roundup/templates/extended/dbinit.py
1523 If you have modified your dbinit.py file, you may use encoded passwords:
1525 1. Edit the dbinit.py file in your instance home directory
1526 a. At the first code line of the open() function::
1528 from roundup.hyperdb import String, Date, Link, Multilink
1530 alter to include Password, as so::
1532 from roundup.hyperdb import String, Password, Date, Link, Multilink
1534 b. Where the password property is defined (around line 66)::
1536 user = Class(db, "user",
1537 username=String(), password=String(),
1538 address=String(), realname=String(),
1539 phone=String(), organisation=String())
1540 user.setkey("username")
1542 alter the "password=String()" to "password=Password()"::
1544 user = Class(db, "user",
1545 username=String(), password=Password(),
1546 address=String(), realname=String(),
1547 phone=String(), organisation=String())
1548 user.setkey("username")
1550 2. Any existing passwords in the database will remain cleartext until they
1551 are edited. It is recommended that at a minimum the admin password be
1552 changed immediately::
1554 roundup-admin -i <instance home> set user1 password=<new password>
1557 0.3.x Configuration
1558 -------------------
1559 FILTER_POSITION, ANONYMOUS_ACCESS, ANONYMOUS_REGISTER have been added to
1560 the instance_config.py. Simplest solution is to copy the default values from
1561 template in the core source.
1563 MESSAGES_TO_AUTHOR has been added to the IssueClass in dbinit.py. Set to 'yes'
1564 to send nosy messages to the author. Default behaviour is to not send nosy
1565 messages to the author. You will need to add MESSAGES_TO_AUTHOR to your
1566 dbinit.py in your instance home.
1569 0.3.x CGI script roundup.cgi
1570 ----------------------------
1571 There have been some structural changes to the roundup.cgi script - you will
1572 need to install it again from the cgi-bin directory of the source
1573 distribution. Make sure you update the ROUNDUP_INSTANCE_HOMES after the
1574 copy.
1577 .. _`customisation documentation`: customizing.html
1578 .. _`security documentation`: security.html
1579 .. _`administration guide`: admin_guide.html