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