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