code-0e2a0c2c8142/doc/.cvsignore0000644000000000000000000000045210062724152014377 0ustar 00000000000000announcement.html customizing.html developers.html implementation.html index.html installation.html user_guide.html FAQ.html security.html features.html upgrading.html glossary.html design.html admin_guide.html overview.html mysql.html postgresql.html tracker_templates.html whatsnew-0.7.html *.ht code-0e2a0c2c8142/doc/FAQ.txt0000644000000000000000000001154710062724152013556 0ustar 00000000000000=========== Roundup FAQ =========== :Version: $Revision: 1.18 $ .. contents:: Installation ------------ Living without a mailserver ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Remove the nosy reactor, means delete the tracker file ``detectors/nosyreactor.py`` from your tracker home. The cgi-bin is very slow! ~~~~~~~~~~~~~~~~~~~~~~~~~ Yep, it sure is. It has to start up Python and load all of the support libraries for *every* request. The solution is to use the built in server. To make Roundup more seamless with your website, you may place the built in server behind apache and link it into your web tree How do I put Roundup behind Apache ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We have a project (foo) running on ``tracker.example:8080``. We want ``http://tracker.example/issues`` to use the roundup server, so we set that up on port 8080 on ``tracker.example`` with the ``config.py`` line:: TRACKER_WEB = 'http://tracker.example/issues/' We have a "foo_issues" tracker and we run the server with:: roundup-server -p 8080 issues=/home/roundup/trackers/issues Then, on the Apache machine (eg. redhat 7.3 with apache 1.3), in ``/etc/httpd/conf/httpd.conf`` uncomment:: LoadModule proxy_module modules/libproxy.so and:: AddModule mod_proxy.c Then add:: # roundup stuff (added manually) # proxy through one tracker ProxyPass /issues/ http://tracker.example:8080/issues/ # proxy through all tracker(*) #ProxyPass /roundup/ http://tracker.example:8080/ Then restart Apache. Now Apache will proxy the request on to the roundup-server. Note that if you're proxying multiple trackers, you'll need to use the second ProxyPass rule described above. It will mean that your TRACKER_WEB will change to:: TRACKER_WEB = 'http://tracker.example/roundup/issues/' Once you're done, you can firewall off port 8080 from the rest of the world. Note that in some situations (eg. virtual hosting) you might need to use a more complex rewrite rule instead of the simpler ProxyPass above. The following should be useful as a starting template:: # roundup stuff (added manually) RewriteEngine on # General Roundup RewriteRule ^/roundup$ roundup/ [R] RewriteRule ^/roundup/(.*)$ http://tracker.example:8080/$1 [P,L] # Handle Foo Issues RewriteRule ^/issues$ issues/ [R] RewriteRule ^/issues/(.*)$ http://tracker.example:8080/issues/$1 [P,L] Roundup runs very slowly on my XP machine when accessed from the Internet ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The issue is probably related to host name resolution for the client performing the request. You can turn off the resolution of the names when it's so slow like this. To do so, edit the module roundup/scripts/roundup_server.py around line 77 to add the following to the RoundupRequestHandler class: def address_string(self): return self.client_address[0] Templates --------- What is that stuff in the tracker html directory? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is the template code that Roundup uses to display the various pages. This is based upon the template markup language in Zope called, oddly enough "Zope Page Templates". There's documentation in the Roundup customisation_ documentation. For more information have a look at: http://www.zope.org/Documentation/Books/ZopeBook/current/contents specifically chapter 5 "Using Zope Page Templates" and chapter 9 "Advanced Page Templates". But I just want a select/option list for .... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Really easy... edit ``html/issue.item``. For 'nosy', change line 53 from:: to:: For 'assigned to', change line 61 from:: assignedto menu to:: assignedto menu Great! But now the select/option list is too big ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thats a little harder (but only a little ;^) Again, edit ``html/issue.item``. For nosy, change line 53 from: to:: for more information, go and read about Zope Page Templates. Using Roundup ------------- I got an error and I cant reload it! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you're using Netscape/Mozilla, try holding shift and pressing reload. If you're using IE then install Mozilla and try again ;^) I keep getting logged out ~~~~~~~~~~~~~~~~~~~~~~~~~ Make sure that the TRACKER_WEB setting in your tracker's config.py is set to the URL of the tracker. ----------------- Back to `Table of Contents`_ .. _`Table of Contents`: index.html .. _`customisation`: customizing.html code-0e2a0c2c8142/doc/Makefile0000644000000000000000000000114310062724152014035 0ustar 00000000000000STXTOHTML = rst2html STXTOHT = rst2ht.py WEBDIR = ../../htdocs/htdocs/doc-0.7 SOURCE = announcement.txt customizing.txt developers.txt FAQ.txt features.txt \ glossary.txt implementation.txt index.txt design.txt mysql.txt \ installation.txt upgrading.txt user_guide.txt admin_guide.txt \ postgresql.txt tracker_templates.txt whatsnew-0.7.txt COMPILED := $(SOURCE:.txt=.html) WEBHT := $(SOURCE:.txt=.ht) all: ${COMPILED} ${WEBHT} website: ${WEBHT} cp *.ht ${WEBDIR} %.html: %.txt ${STXTOHTML} --report=warning -d $< $@ %.ht: %.txt ${STXTOHT} --report=warning -d $< $@ clean: rm -f ${COMPILED} code-0e2a0c2c8142/doc/ZPL.txt0000644000000000000000000000447610062724152013617 0ustar 00000000000000Zope Public License (ZPL) Version 2.0 ----------------------------------------------- This software is Copyright (c) Zope Corporation (tm) and Contributors. All rights reserved. This license has been certified as open source. It has also been designated as GPL compatible by the Free Software Foundation (FSF). Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions in source code must retain the above copyright notice, this list of conditions, and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name Zope Corporation (tm) must not be used to endorse or promote products derived from this software without prior written permission from Zope Corporation. 4. The right to distribute this software or to use it for any purpose does not give you the right to use Servicemarks (sm) or Trademarks (tm) of Zope Corporation. Use of them is covered in a separate agreement (see http://www.zope.com/Marks). 5. If any files are modified, you must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. Disclaimer THIS SOFTWARE IS PROVIDED BY ZOPE CORPORATION ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL ZOPE CORPORATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This software consists of contributions made by Zope Corporation and many individuals on behalf of Zope Corporation. Specific attributions are listed in the accompanying credits file. code-0e2a0c2c8142/doc/admin_guide.txt0000644000000000000000000001634210062724152015412 0ustar 00000000000000==================== Administration Guide ==================== :Version: $Revision: 1.7 $ .. contents:: What does Roundup install? ========================== There's two "installations" that we talk about when using Roundup: 1. The installation of the software and its support files. This uses the standard Python mechanism called "distutils" and thus Roundup's core code, executable scripts and support data files are installed in Python's directories. On Windows, this is typically: Scripts ``\scripts\...`` Core code ``\lib\site-packages\roundup\...`` Support files ``\share\roundup\...`` and on Unix-like systems (eg. Linux): Scripts ``/bin/...`` Core code ``/lib-/site-packages/roundup/...`` Support files ``/share/roundup/...`` 2. The installation of a specific tracker. When invoking the roundup-admin "inst" (and "init") commands, you're creating a new Roundup tracker. This installs configuration files, HTML templates, detector code and a new database. You have complete control over where this stuff goes through both choosing your "tracker home" and the DATABASE variable in config.py. Users and Security ================== Roundup holds its own user database which primarily contains a username, password and email address for the user. Roundup *must* have its own user listing, in order to maintain internal consistency of its data. It is a relatively simple exercise to update this listing on a regular basis, or on demand, so that it matches an external listing (eg. unix passwd file, LDAP, etc.) Roundup identifies users in a number of ways: 1. Through the web, users may be identified by either HTTP Basic Authentication or cookie authentication. If you are running the web server (roundup-server) through another HTTP server (eg. apache or IIS) then that server may require HTTP Basic Authentication, and it will pass the ``REMOTE_USER`` variable through to Roundup. If this variable is not present, then Roundup defaults to using its own cookie-based login mechanism. 2. In email messages handled by roundup-mailgw, users are identified by the From address in the message. In both cases, Roundup's behaviour when dealing with unknown users is controlled by Permissions defined in the "SECURITY SETTINGS" section of the tracker's ``dbinit.py`` module: Web Registration If granted to the Anonymous Role, then anonymous users will be able to register through the web. Email Registration If granted to the Anonymous Role, then email messages from unknown users will result in those users being registered with the tracker. More information about how to customise your tracker's security settings may be found in the `customisation documentation`_. Tasks ===== Maintenance of Roundup can involve one of the following: 1. `tracker backup`_ 2. `software upgrade`_ 3. `migrating backends`_ 4. `moving a tracker`_ Tracker Backup -------------- Stop the web and email frontends and to copy the contents of the tracker home directory to some other place using standard backup tools. Software Upgrade ---------------- Always make a backup of your tracker before upgrading software. Steps you may take: 1. Ensure that the unit tests run on your system. 2. If you're using an RDBMS backend, make a backup of its contents now. 3. Copy your tracker home to a new directory. Now, working in that copied tracker home: 1. Follow the steps in the `upgrading documentation`_ for the new version of the software in the copied. 2. Test each of the admin tool, web interface and mail gateway using the new version of the software. To do this, invoke the scripts directly in the source directory with:: PYTHONPATH=. python roundup/scripts/roundup_server.py PYTHONPATH=. python roundup/scripts/roundup_admin.py PYTHONPATH=. python roundup/scripts/roundup_mailgw.py Once you're comfortable that the upgrade will work using that copy, you should upgrade the live version: 1. Stop the production web and email frontends. 2. Perform the upgrade steps on the existing tracker directory. 3. Upgrade the software. 4. Restart your tracker. Migrating Backends ------------------ 1. stop the existing tracker web and email frontends (preventing changes) 2. use the roundup-admin tool "export" command to export the contents of your tracker to disk 3. copy the tracker home to a new directory 4. change the backend used in the tracker home ``select_db.py`` file 5. delete the "db" directory from the new directory 6. use the roundup-admin "import" command to import the previous export with the new tracker home 7. test each of the admin tool, web interface and mail gateway using the new backend 8. move the old tracker home out of the way (rename to "tracker.old") and move the new tracker home into its place 9. restart web and email frontends Moving a Tracker ---------------- If you're moving the tracker to a similar machine, you should: 1. install Roundup on the new machine and test that it works there, 2. stop the existing tracker web and email frontends (preventing changes), 3. copy the tracker home directory over to the new machine, and 4. start the tracker web and email frontends on the new machine. Most of the backends are actually portable across platforms (ie. from Unix to Windows to Mac). If this isn't the case (ie. the tracker doesn't work when moved using the above steps) then you'll need to: 1. install Roundup on the new machine and test that it works there, 2. stop the existing tracker web and email frontends (preventing changes), 3. use the roundup-admin tool "export" command to export the contents of the existing tracker, 4. copy the export to the new machine, 5. use the roundup-admin "import" command to import the tracker on the new machine, and 6. start the tracker web and email frontends on the new machine. Running the Servers =================== Unix ---- On Unix systems, use the scripts/server-ctl script to control the roundup-server server. Copy it somewhere and edit the variables at the top to reflect your specific installation. Windows ------- On Windows, the roundup-server program runs as a Windows Service, and therefore may be controlled through the Services control panel. The roundup-server program may also control the service directly: **install the service** ``roundup-server -c install`` **start the service** ``roundup-server -c start`` **stop the service** ``roundup-server -c stop`` To bring up the services panel: Windows 2000 and later Start/Control Panel/Administrative Tools/Services Windows NT4 Start/Control Panel/Services Running the Mail Gateway Script ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The mail gateway script should be scheduled to run regularly on your Windows server. Normally this will result in a window popping up. The solution to this is to: 1. Create a new local account on the Roundup server 2. Set the scheduled task to run in the context of this user instead of your normal login ------------------- Back to `Table of Contents`_ .. _`Table of Contents`: index.html .. _`customisation documentation`: customizing.html .. _`upgrading documentation`: upgrading.html code-0e2a0c2c8142/doc/announcement.txt0000644000000000000000000000475210062724152015641 0ustar 00000000000000I'm proud to release this 7th major feature release of Roundup. Version 0.7 introduces far too many features to list here so I've put together a What's New page: http://roundup.sourceforge.net/doc-0.7/whatsnew-0.7.html Some highlights: - added postgresql backend - trackers using postgresql or mysql backends may have many users - new "actor" automatic property (user who caused the last "activity") - RDBMS backends have data typed columns and indexes on several columns - registration may be concluded by replying to the confirmation email - HTML templating permission checks are greatly simplified - database exports now include full journals - IMAP support in the mail gateway Known issues: - the metakit import feature currently has a bug and should not be used If you're upgrading from an older version of Roundup you *must* follow the "Software Upgrade" guidelines given in the maintenance documentation. Roundup requires python 2.1.3 or later for correct operation. To give Roundup a try, just download (see below), unpack and run:: python demo.py Source and documentation is available at the website: http://roundup.sourceforge.net/ Release Info (via download page): http://sourceforge.net/projects/roundup Mailing lists - the place to ask questions: http://sourceforge.net/mail/?group_id=31577 About Roundup ============= Roundup is a simple-to-use and -install issue-tracking system with command-line, web and e-mail interfaces. It is based on the winning design from Ka-Ping Yee in the Software Carpentry "Track" design competition. Note: Ping is not responsible for this project. The contact for this project is richard@users.sourceforge.net. Roundup manages a number of issues (with flexible properties such as "description", "priority", and so on) and provides the ability to: (a) submit new issues, (b) find and edit existing issues, and (c) discuss issues with other participants. The system will facilitate communication among the participants by managing discussions and notifying interested parties when issues are edited. One of the major design goals for Roundup that it be simple to get going. Roundup is therefore usable "out of the box" with any python 2.1+ installation. It doesn't even need to be "installed" to be operational, though a disutils-based install script is provided. It comes with two issue tracker templates (a classic bug/feature tracker and a minimal skeleton) and seven database back-ends (anydbm, bsddb, bsddb3, sqlite, metakit, mysql and postgresql). code-0e2a0c2c8142/doc/customizing.txt0000644000000000000000000045533610062724152015532 0ustar 00000000000000=================== Customising Roundup =================== :Version: $Revision: 1.138 $ .. This document borrows from the ZopeBook section on ZPT. The original is at: http://www.zope.org/Documentation/Books/ZopeBook/current/ZPT.stx .. contents:: :depth: 1 What You Can Do =============== Before you get too far, it's probably worth having a quick read of the Roundup `design documentation`_. Customisation of Roundup can take one of six forms: 1. `tracker configuration`_ file changes 2. database, or `tracker schema`_ changes 3. "definition" class `database content`_ changes 4. behavioural changes, through detectors_ 5. `security / access controls`_ 6. change the `web interface`_ The third case is special because it takes two distinctly different forms depending upon whether the tracker has been initialised or not. The other two may be done at any time, before or after tracker initialisation. Yes, this includes adding or removing properties from classes. Trackers in a Nutshell ====================== Trackers have the following structure: =================== ======================================================== Tracker File Description =================== ======================================================== config.py Holds the basic `tracker configuration`_ dbinit.py Holds the `tracker schema`_ interfaces.py Defines the Web and E-Mail interfaces for the tracker select_db.py Selects the database back-end for the tracker db/ Holds the tracker's database db/files/ Holds the tracker's upload files and messages detectors/ Auditors and reactors for this tracker html/ Web interface templates, images and style sheets =================== ======================================================== Tracker Configuration ===================== The ``config.py`` located in your tracker home contains the basic configuration for the web and e-mail components of roundup's interfaces. As the name suggests, this file is a Python module. This means that any valid python expression may be used in the file. Mostly though, you'll be setting the configuration variables to string values. Python string values must be quoted with either single or double quotes:: 'this is a string' "this is also a string - use it when the value has 'single quotes'" this is not a string - it's not quoted Python strings may use formatting that's almost identical to C string formatting. The ``%`` operator is used to perform the formatting, like so:: 'roundup-admin@%s'%MAIL_DOMAIN this will create a string ``'roundup-admin@tracker.domain.example'`` if MAIL_DOMAIN is set to ``'tracker.domain.example'``. You'll also note some values are set to:: os.path.join(TRACKER_HOME, 'db') or similar. This creates a new string which holds the path to the ``'db'`` directory in the TRACKER_HOME directory. This is just a convenience so if the TRACKER_HOME changes you don't have to edit multiple valoues. The configuration variables available are: **TRACKER_HOME** - ``os.path.split(__file__)[0]`` The tracker home directory. The above default code will automatically determine the tracker home for you, so you can just leave it alone. **MAILHOST** - ``'localhost'`` The SMTP mail host that roundup will use to send e-mail. **MAILUSER** - ``()`` If your SMTP mail host requires a username and password for access, then specify them here. eg. ``MAILUSER = ('username', 'password')`` **MAILHOST_TLS** - ``'no'`` If your SMTP mail host provides or requires TLS (Transport Layer Security) then set ``MAILHOST_TLS = 'yes'`` **MAILHOST_TLS_KEYFILE** - ``''`` If you're using TLS, you may also set MAILHOST_TLS_KEYFILE to the name of a PEM formatted file that contains your private key. **MAILHOST_TLS_CERTFILE** - ``''`` If you're using TLS and have specified a MAILHOST_TLS_KEYFILE, you may also set MAILHOST_TLS_CERTFILE to the name of a PEM formatted certificate chain file. **MAIL_DOMAIN** - ``'tracker.domain.example'`` The domain name used for email addresses. **DATABASE** - ``os.path.join(TRACKER_HOME, 'db')`` This is the directory that the database is going to be stored in. By default it is in the tracker home. **TEMPLATES** - ``os.path.join(TRACKER_HOME, 'html')`` This is the directory that the HTML templates reside in. By default they are in the tracker home. **TRACKER_NAME** - ``'Roundup issue tracker'`` A descriptive name for your roundup tracker. This is sent out in e-mails and appears in the heading of CGI pages. **TRACKER_EMAIL** - ``'issue_tracker@%s'%MAIL_DOMAIN`` The email address that e-mail sent to roundup should go to. Think of it as the tracker's personal e-mail address. **TRACKER_WEB** - ``'http://tracker.example/cgi-bin/roundup.cgi/bugs/'`` The web address that the tracker is viewable at. This will be included in information sent to users of the tracker. The URL **must** include the cgi-bin part or anything else that is required to get to the home page of the tracker. You **must** include a trailing '/' in the URL. **ADMIN_EMAIL** - ``'roundup-admin@%s'%MAIL_DOMAIN`` The email address that roundup will complain to if it runs into trouble. **EMAIL_FROM_TAG** - ``''`` Additional text to include in the "name" part of the ``From:`` address used in nosy messages. If the sending user is "Foo Bar", the ``From:`` line is usually:: "Foo Bar" The EMAIL_FROM_TAG goes inside the "Foo Bar" quotes like so:: "Foo Bar EMAIL_FROM_TAG" **ERROR_MESSAGES_TO** - ``'user'``, ``'dispatcher'`` or ``'both'`` Sends error messages to the dispatcher, user, or both. It will use the ``DISPATCHER_EMAIL`` address if set, otherwise it'll use the ``ADMIN_EMAIL`` address. **DISPATCHER_EMAIL** - ``''`` The email address that Roundup will issue all error messages to. This is also useful if you want to switch your 'new message' notification to a central user. **LOGGGING_CONFIG** - ``os.path.join(TRACKER_HOME, 'logging.ini')`` This variable activates logging of Roundup's internal messages using the standard python ``logging`` module. The module is configured using the indicated configuration file. **LOGGING_FILENAME** - ``'/path/to/log file'`` This variable activates logging of Roundup's internal messages using a built-in minimal logging service which appends messages to the indicated file. **LOGGING_LEVEL** - ``'DEBUG'``, ``'INFO'``, ``'WARNING'`` or ``'ERROR'`` This variable determines the level of messages logged by the built-in logging service - messages of the level named and higher will be sent to the ``LOGGING_FILENAME`` file. Not used when the ``LOGGGING_CONFIG`` variable is set. **MESSAGES_TO_AUTHOR** - ``'new'``, ``'yes'`` or``'no'`` Send nosy messages to the author of the message? If 'new' is used, then the author will only be sent the message when the message creates a new issue. If 'yes' then the author will always be sent a copy of the message they wrote. **ADD_AUTHOR_TO_NOSY** - ``'new'``, ``'yes'`` or ``'no'`` Does the author of a message get placed on the nosy list automatically? If ``'new'`` is used, then the author will only be added when a message creates a new issue. If ``'yes'``, then the author will be added on followups too. If ``'no'``, they're never added to the nosy. **ADD_RECIPIENTS_TO_NOSY** - ``'new'``, ``'yes'`` or ``'no'`` Do the recipients (To:, Cc:) of a message get placed on the nosy list? If ``'new'`` is used, then the recipients will only be added when a message creates a new issue. If ``'yes'``, then the recipients will be added on followups too. If ``'no'``, they're never added to the nosy. **EMAIL_SIGNATURE_POSITION** - ``'top'``, ``'bottom'`` or ``'none'`` Where to place the email signature in messages that Roundup generates. **EMAIL_KEEP_QUOTED_TEXT** - ``'yes'`` or ``'no'`` Keep email citations. Citations are the part of e-mail which the sender has quoted in their reply to previous e-mail with ``>`` or ``|`` characters at the start of the line. **EMAIL_LEAVE_BODY_UNCHANGED** - ``'no'`` Preserve the email body as is. Enabiling this will cause the entire message body to be stored, including all citations, signatures and Outlook-quoted sections (ie. "Original Message" blocks). It should be either ``'yes'`` or ``'no'``. **MAIL_DEFAULT_CLASS** - ``'issue'`` or ``''`` Default class to use in the mailgw if one isn't supplied in email subjects. To disable, comment out the variable below or leave it blank. **HTML_VERSION** - ``'html4'`` or ``'xhtml'`` HTML version to generate. The templates are html4 by default. If you wish to make them xhtml, then you'll need to change this var to 'xhtml' too so all auto-generated HTML is compliant. **EMAIL_CHARSET** - ``utf-8`` (or ``iso-8859-1`` for Eudora users) Character set to encode email headers with. We use utf-8 by default, as it's the most flexible. Some mail readers (eg. Eudora) can't cope with that, so you might need to specify a more limited character set (eg. 'iso-8859-1'. **DEFAULT_TIMEZONE** - ``0`` Numeric hour timezone offest to be used when displaying local times. The default timezone is used when users do not choose their own in their settings. The default config.py is given below - as you can see, the MAIL_DOMAIN must be edited before any interaction with the tracker is attempted.:: # roundup home is this package's directory TRACKER_HOME=os.path.split(__file__)[0] # The SMTP mail host that roundup will use to send mail MAILHOST = 'localhost' # The domain name used for email addresses. MAIL_DOMAIN = 'your.tracker.email.domain.example' # This is the directory that the database is going to be stored in DATABASE = os.path.join(TRACKER_HOME, 'db') # This is the directory that the HTML templates reside in TEMPLATES = os.path.join(TRACKER_HOME, 'html') # A descriptive name for your roundup tracker TRACKER_NAME = 'Roundup issue tracker' # The email address that mail to roundup should go to TRACKER_EMAIL = 'issue_tracker@%s'%MAIL_DOMAIN # The web address that the tracker is viewable at. This will be # included in information sent to users of the tracker. The URL MUST # include the cgi-bin part or anything else that is required to get # to the home page of the tracker. You MUST include a trailing '/' # in the URL. TRACKER_WEB = 'http://tracker.example/cgi-bin/roundup.cgi/bugs/' # The email address that roundup will complain to if it runs into # trouble ADMIN_EMAIL = 'roundup-admin@%s'%MAIL_DOMAIN # These variables define where to log Roundup's internal messages to. # You have two choices - either using the standard Python logging module # or a minimal logging facility built into Roundup. The former is activated # when you provide a LOGGING_CONFIG variable below which contains the # configuration of the logging module. The latter is activated when you # provide the LOGGING_FILENAME and optionally LOGGING_LEVEL variables. If # none of these variables are defined then only errors will be logged, and # they will go to stderr. # LOGGGING_CONFIG = os.path.join(TRACKER_HOME, 'logging.ini') # or, # LOGGING_FILENAME = '/path/to/log file' # LOGGING_LEVEL = 'INFO' # one of 'DEBUG', 'INFO', 'WARNING', 'ERROR' # Additional text to include in the "name" part of the From: address # used in nosy messages. If the sending user is "Foo Bar", the From: # line is usually: "Foo Bar" # the EMAIL_FROM_TAG goes inside the "Foo Bar" quotes like so: # "Foo Bar EMAIL_FROM_TAG" EMAIL_FROM_TAG = "" # Send nosy messages to the author of the message MESSAGES_TO_AUTHOR = 'no' # either 'yes' or 'no' # Does the author of a message get placed on the nosy list # automatically? If 'new' is used, then the author will only be # added when a message creates a new issue. If 'yes', then the # author will be added on followups too. If 'no', they're never # added to the nosy. ADD_AUTHOR_TO_NOSY = 'new' # one of 'yes', 'no', 'new' # Do the recipients (To:, Cc:) of a message get placed on the nosy # list? If 'new' is used, then the recipients will only be added # when a message creates a new issue. If 'yes', then the recipients # will be added on followups too. If 'no', they're never added to # the nosy. ADD_RECIPIENTS_TO_NOSY = 'new' # either 'yes', 'no', 'new' # Where to place the email signature EMAIL_SIGNATURE_POSITION = 'bottom' # one of 'top', 'bottom', 'none' # Keep email citations EMAIL_KEEP_QUOTED_TEXT = 'no' # either 'yes' or 'no' # Preserve the email body as is EMAIL_LEAVE_BODY_UNCHANGED = 'no' # either 'yes' or 'no' # Default class to use in the mailgw if one isn't supplied in email # subjects. To disable, comment out the variable below or leave it # blank. Examples: MAIL_DEFAULT_CLASS = 'issue' # use "issue" class by default #MAIL_DEFAULT_CLASS = '' # disable (or just comment the var out) # HTML version to generate. The templates are html4 by default. If you # wish to make them xhtml, then you'll need to change this var to 'xhtml' # too so all auto-generated HTML is compliant. HTML_VERSION = 'html4' # either 'html4' or 'xhtml' # Character set to encode email headers with. We use utf-8 by default, as # it's the most flexible. Some mail readers (eg. Eudora) can't cope with # that, so you might need to specify a more limited character set (eg. # 'iso-8859-1'. EMAIL_CHARSET = 'utf-8' #EMAIL_CHARSET = 'iso-8859-1' # use this instead for Eudora users # You may specify a different default timezone, for use when users do not # choose their own in their settings. DEFAULT_TIMEZONE = 0 # specify as numeric hour offest # # SECURITY DEFINITIONS # # define the Roles that a user gets when they register with the # tracker these are a comma-separated string of role names (e.g. # 'Admin,User') NEW_WEB_USER_ROLES = 'User' NEW_EMAIL_USER_ROLES = 'User' Tracker Schema ============== Note: if you modify the schema, you'll most likely need to edit the `web interface`_ HTML template files and `detectors`_ to reflect your changes. A tracker schema defines what data is stored in the tracker's database. Schemas are defined using Python code in the ``dbinit.py`` module of your tracker. The ``dbinit.py`` module ------------------------ The ``dbinit.py`` module contains two functions: **open** This function defines what your tracker looks like on the inside, the **schema** of the tracker. It defines the **Classes** and **properties** on each class. It also defines the **security** for those Classes. The next few sections describe how schemas work and what you can do with them. **init** This function is responsible for setting up the initial state of your tracker. It's called exactly once - but the ``roundup-admin initialise`` command. See the start of the section on `database content`_ for more info about how this works. The "classic" schema -------------------- The "classic" schema looks like this (see below for the meaning of ``'setkey'``):: pri = Class(db, "priority", name=String(), order=String()) pri.setkey("name") stat = Class(db, "status", name=String(), order=String()) stat.setkey("name") keyword = Class(db, "keyword", name=String()) keyword.setkey("name") user = Class(db, "user", username=String(), organisation=String(), password=String(), address=String(), realname=String(), phone=String()) user.setkey("username") msg = FileClass(db, "msg", author=Link("user"), summary=String(), date=Date(), recipients=Multilink("user"), files=Multilink("file")) file = FileClass(db, "file", name=String(), type=String()) issue = IssueClass(db, "issue", topic=Multilink("keyword"), status=Link("status"), assignedto=Link("user"), priority=Link("priority")) issue.setkey('title') What you can't do to the schema ------------------------------- You must never: **Remove the users class** This class is the only *required* class in Roundup. Similarly, its username, password and address properties must never be removed. **Change the type of a property** Property types must *never* be changed - the database simply doesn't take this kind of action into account. Note that you can't just remove a property and re-add it as a new type either. If you wanted to make the assignedto property a Multilink, you'd need to create a new property assignedto_list and remove the old assignedto property. What you can do to the schema ----------------------------- Your schema may be changed at any time before or after the tracker has been initialised (or used). You may: **Add new properties to classes, or add whole new classes** This is painless and easy to do - there are generally no repurcussions from adding new information to a tracker's schema. **Remove properties** Removing properties is a little more tricky - you need to make sure that the property is no longer used in the `web interface`_ *or* by the detectors_. Classes and Properties - creating a new information store --------------------------------------------------------- In the tracker above, we've defined 7 classes of information: priority Defines the possible levels of urgency for issues. status Defines the possible states of processing the issue may be in. keyword Initially empty, will hold keywords useful for searching issues. user Initially holding the "admin" user, will eventually have an entry for all users using roundup. msg Initially empty, will hold all e-mail messages sent to or generated by roundup. file Initially empty, will hold all files attached to issues. issue Initially empty, this is where the issue information is stored. We define the "priority" and "status" classes to allow two things: reduction in the amount of information stored on the issue and more powerful, accurate searching of issues by priority and status. By only requiring a link on the issue (which is stored as a single number) we reduce the chance that someone mis-types a priority or status - or simply makes a new one up. Class and Items ~~~~~~~~~~~~~~~ A Class defines a particular class (or type) of data that will be stored in the database. A class comprises one or more properties, which gives the information about the class items. The actual data entered into the database, using ``class.create()``, are called items. They have a special immutable property called ``'id'``. We sometimes refer to this as the *itemid*. Properties ~~~~~~~~~~ A Class is comprised of one or more properties of the following types: * String properties are for storing arbitrary-length strings. * Password properties are for storing encoded arbitrary-length strings. The default encoding is defined on the ``roundup.password.Password`` class. * Date properties store date-and-time stamps. Their values are Timestamp objects. * Number properties store numeric values. * Boolean properties store on/off, yes/no, true/false values. * A Link property refers to a single other item selected from a specified class. The class is part of the property; the value is an integer, the id of the chosen item. * A Multilink property refers to possibly many items in a specified class. The value is a list of integers. FileClass ~~~~~~~~~ FileClasses save their "content" attribute off in a separate file from the rest of the database. This reduces the number of large entries in the database, which generally makes databases more efficient, and also allows us to use command-line tools to operate on the files. They are stored in the files sub-directory of the ``'db'`` directory in your tracker. IssueClass ~~~~~~~~~~ IssueClasses automatically include the "messages", "files", "nosy", and "superseder" properties. The messages and files properties list the links to the messages and files related to the issue. The nosy property is a list of links to users who wish to be informed of changes to the issue - they get "CC'ed" e-mails when messages are sent to or generated by the issue. The nosy reactor (in the ``'detectors'`` directory) handles this action. The superseder link indicates an issue which has superseded this one. They also have the dynamically generated "creation", "activity" and "creator" properties. The value of the "creation" property is the date when an item was created, and the value of the "activity" property is the date when any property on the item was last edited (equivalently, these are the dates on the first and last records in the item's journal). The "creator" property holds a link to the user that created the issue. setkey(property) ~~~~~~~~~~~~~~~~ Select a String property of the class to be the key property. The key property must be unique, and allows references to the items in the class by the content of the key property. That is, we can refer to users by their username: for example, let's say that there's an issue in roundup, issue 23. There's also a user, richard, who happens to be user 2. To assign an issue to him, we could do either of:: roundup-admin set issue23 assignedto=2 or:: roundup-admin set issue23 assignedto=richard Note, the same thing can be done in the web and e-mail interfaces. If a class does not have an "order" property, the key is also used to sort instances of the class when it is rendered in the user interface. (If a class has no "order" property, sorting is by the labelproperty of the class. This is computed, in order of precedence, as the key, the "name", the "title", or the first property alphabetically.) create(information) ~~~~~~~~~~~~~~~~~~~ Create an item in the database. This is generally used to create items in the "definitional" classes like "priority" and "status". Examples of adding to your schema --------------------------------- TODO Detectors - adding behaviour to your tracker ============================================ .. _detectors: Detectors are initialised every time you open your tracker database, so you're free to add and remove them any time, even after the database is initialised via the "roundup-admin initialise" command. The detectors in your tracker fire *before* (**auditors**) and *after* (**reactors**) changes to the contents of your database. They are Python modules that sit in your tracker's ``detectors`` directory. You will have some installed by default - have a look. You can write new detectors or modify the existing ones. The existing detectors installed for you are: **nosyreaction.py** This provides the automatic nosy list maintenance and email sending. The nosy reactor (``nosyreaction``) fires when new messages are added to issues. The nosy auditor (``updatenosy``) fires when issues are changed, and figures out what changes need to be made to the nosy list (such as adding new authors, etc.) **statusauditor.py** This provides the ``chatty`` auditor which changes the issue status from ``unread`` or ``closed`` to ``chatting`` if new messages appear. It also provides the ``presetunread`` auditor which pre-sets the status to ``unread`` on new items if the status isn't explicitly defined. **messagesummary.py** Generates the ``summary`` property for new messages based on the message content. **userauditor.py** Verifies the content of some of the user fields (email addresses and roles lists). If you don't want this default behaviour, you're completely free to change or remove these detectors. See the detectors section in the `design document`__ for details of the interface for detectors. __ design.html Detector API ------------ Auditors are called with the arguments:: audit(db, cl, itemid, newdata) where ``db`` is the database, ``cl`` is an instance of Class or IssueClass within the database, and ``newdata`` is a dictionary mapping property names to values. For a ``create()`` operation, the ``itemid`` argument is None and newdata contains all of the initial property values with which the item is about to be created. For a ``set()`` operation, newdata contains only the names and values of properties that are about to be changed. For a ``retire()`` or ``restore()`` operation, newdata is None. Reactors are called with the arguments:: react(db, cl, itemid, olddata) where ``db`` is the database, ``cl`` is an instance of Class or IssueClass within the database, and ``olddata`` is a dictionary mapping property names to values. For a ``create()`` operation, the ``itemid`` argument is the id of the newly-created item and ``olddata`` is None. For a ``set()`` operation, ``olddata`` contains the names and previous values of properties that were changed. For a ``retire()`` or ``restore()`` operation, ``itemid`` is the id of the retired or restored item and ``olddata`` is None. Additional Detectors Ready For Use ---------------------------------- Sample additional detectors that have been found useful will appear in the ``'detectors'`` directory of the Roundup distribution. If you want to use one, copy it to the ``'detectors'`` of your tracker instance: **newissuecopy.py** This detector sends an email to a team address whenever a new issue is created. The address is hard-coded into the detector, so edit it before you use it (look for the text 'team@team.host') or you'll get email errors! **creator_resolution.py** Catch attempts to set the status to "resolved" - if the assignedto user isn't the creator, then set the status to "confirm-done". Note that "classic" Roundup doesn't have that status, so you'll have to add it. If you don't want to though, it'll just use "in-progress" instead. **email_auditor.py** If a file added to an issue is of type message/rfc822, we tack on the extension .eml. The reason for this is that Microsoft Internet Explorer will not open things with a .eml attachment, as they deem it 'unsafe'. Worse yet, they'll just give you an incomprehensible error message. For more information, see the detector code - it has a length explanation. Auditor or Reactor? ------------------- Generally speaking, the following rules should be observed: **Auditors** Are used for `vetoing creation of or changes to items`_. They might also make automatic changes to item properties. **Reactors** Detect changes in the database and react accordingly. They should avoid making changes to the database where possible, as this could create detector loops. Vetoing creation of or changes to items --------------------------------------- Auditors may raise the ``Reject`` exception to prevent the creation of or changes to items in the database. The mail gateway, for example, will not attach files or messages to issues when the creation of those files or messages are prevented through the ``Reject`` exception. It'll also not create users if that creation is ``Reject``'ed too. To use, simply add at the top of your auditor:: from roundup.exceptions import Reject And then when your rejection criteria have been detected, simply:: raise Reject Generating email from Roundup ----------------------------- The module ``roundup.mailer`` contains most of the nuts-n-bolts required to generate email messages from Roundup. In addition, the ``IssueClass`` methods ``nosymessage()`` and ``send_message()`` are used to generate nosy messages, and may generate messages which only consist of a change note (ie. the message id parameter is not required). Database Content ================ Note: if you modify the content of definitional classes, you'll most likely need to edit the tracker `detectors`_ to reflect your changes. Customisation of the special "definitional" classes (eg. status, priority, resolution, ...) may be done either before or after the tracker is initialised. The actual method of doing so is completely different in each case though, so be careful to use the right one. **Changing content before tracker initialisation** Edit the dbinit module in your tracker to alter the items created in using the ``create()`` methods. **Changing content after tracker initialisation** As the "admin" user, click on the "class list" link in the web interface to bring up a list of all database classes. Click on the name of the class you wish to change the content of. You may also use the ``roundup-admin`` interface's create, set and retire methods to add, alter or remove items from the classes in question. See "`adding a new field to the classic schema`_" for an example that requires database content changes. Security / Access Controls ========================== A set of Permissions is built into the security module by default: - Edit (everything) - View (everything) Every Class you define in your tracker's schema also gets an Edit and View Permission of its own. The default interfaces define: - Web Registration - Web Access - Web Roles - Email Registration - Email Access These are hooked into the default Roles: - Admin (Edit everything, View everything, Web Roles) - User (Web Access, Email Access) - Anonymous (Web Registration, Email Registration) And finally, the "admin" user gets the "Admin" Role, and the "anonymous" user gets "Anonymous" assigned when the database is initialised on installation. The two default schemas then define: - Edit issue, View issue (both) - Edit file, View file (both) - Edit msg, View msg (both) - Edit support, View support (extended only) and assign those Permissions to the "User" Role. Put together, these settings appear in the ``open()`` function of the tracker ``dbinit.py`` (the following is taken from the "minimal" template's ``dbinit.py``):: # # SECURITY SETTINGS # # and give the regular users access to the web and email interface p = db.security.getPermission('Web Access') db.security.addPermissionToRole('User', p) p = db.security.getPermission('Email Access') db.security.addPermissionToRole('User', p) # May users view other user information? Comment these lines out # if you don't want them to p = db.security.getPermission('View', 'user') db.security.addPermissionToRole('User', p) # Assign the appropriate permissions to the anonymous user's # Anonymous role. Choices here are: # - Allow anonymous users to register through the web p = db.security.getPermission('Web Registration') db.security.addPermissionToRole('Anonymous', p) # - Allow anonymous (new) users to register through the email # gateway p = db.security.getPermission('Email Registration') db.security.addPermissionToRole('Anonymous', p) New User Roles -------------- New users are assigned the Roles defined in the config file as: - NEW_WEB_USER_ROLES - NEW_EMAIL_USER_ROLES Changing Access Controls ------------------------ You may alter the configuration variables to change the Role that new web or email users get, for example to not give them access to the web interface if they register through email. You may use the ``roundup-admin`` "``security``" command to display the current Role and Permission configuration in your tracker. Adding a new Permission ~~~~~~~~~~~~~~~~~~~~~~~ When adding a new Permission, you will need to: 1. add it to your tracker's dbinit so it is created, using ``security.addPermission``, for example:: self.security.addPermission(name="View", klass='frozzle', description="User is allowed to access frozzles") will set up a new "View" permission on the Class "frozzle". 2. enable it for the Roles that should have it (verify with "``roundup-admin security``") 3. add it to the relevant HTML interface templates 4. add it to the appropriate xxxPermission methods on in your tracker interfaces module Example Scenarios ~~~~~~~~~~~~~~~~~ **automatic registration of users in the e-mail gateway** By giving the "anonymous" user the "Email Registration" Role, any unidentified user will automatically be registered with the tracker (with no password, so they won't be able to log in through the web until an admin sets their password). Note: this is the default behaviour in the tracker templates that ship with Roundup. **anonymous access through the e-mail gateway** Give the "anonymous" user the "Email Access" and ("Edit", "issue") Roles but do not not give them the "Email Registration" Role. This means that when an unknown user sends email into the tracker, they're automatically logged in as "anonymous". Since they don't have the "Email Registration" Role, they won't be automatically registered, but since "anonymous" has permission to use the gateway, they'll still be able to submit issues. Note that the Sender information - their email address - will not be available - they're *anonymous*. **only developers may be assigned issues** Create a new Permission called "Fixer" for the "issue" class. Create a new Role "Developer" which has that Permission, and assign that to the appropriate users. Filter the list of users available in the assignedto list to include only those users. Enforce the Permission with an auditor. See the example `restricting the list of users that are assignable to a task`_. **only managers may sign off issues as complete** Create a new Permission called "Closer" for the "issue" class. Create a new Role "Manager" which has that Permission, and assign that to the appropriate users. In your web interface, only display the "resolved" issue state option when the user has the "Closer" Permissions. Enforce the Permission with an auditor. This is very similar to the previous example, except that the web interface check would look like:: **don't give web access to users who register through email** Create a new Role called "Email User" which has all the Permissions of the normal "User" Role minus the "Web Access" Permission. This will allow users to send in emails to the tracker, but not access the web interface. **let some users edit the details of all users** Create a new Role called "User Admin" which has the Permission for editing users:: db.security.addRole(name='User Admin', description='Managing users') p = db.security.getPermission('Edit', 'user') db.security.addPermissionToRole('User Admin', p) and assign the Role to the users who need the permission. Web Interface ============= .. contents:: :local: The web interface is provided by the ``roundup.cgi.client`` module and is used by ``roundup.cgi``, ``roundup-server`` and ``ZRoundup`` (``ZRoundup`` is broken, until further notice). In all cases, we determine which tracker is being accessed (the first part of the URL path inside the scope of the CGI handler) and pass control on to the tracker ``interfaces.Client`` class - which uses the ``Client`` class from ``roundup.cgi.client`` - which handles the rest of the access through its ``main()`` method. This means that you can do pretty much anything you want as a web interface to your tracker. Repercussions of changing the tracker schema --------------------------------------------- If you choose to change the `tracker schema`_ you will need to ensure the web interface knows about it: 1. Index, item and search pages for the relevant classes may need to have properties added or removed, 2. The "page" template may require links to be changed, as might the "home" page's content arguments. How requests are processed -------------------------- The basic processing of a web request proceeds as follows: 1. figure out who we are, defaulting to the "anonymous" user 2. figure out what the request is for - we call this the "context" 3. handle any requested action (item edit, search, ...) 4. render the template requested by the context, resulting in HTML output In some situations, exceptions occur: - HTTP Redirect (generally raised by an action) - SendFile (generally raised by ``determine_context``) here we serve up a FileClass "content" property - SendStaticFile (generally raised by ``determine_context``) here we serve up a file from the tracker "html" directory - Unauthorised (generally raised by an action) here the action is cancelled, the request is rendered and an error message is displayed indicating that permission was not granted for the action to take place - NotFound (raised wherever it needs to be) this exception percolates up to the CGI interface that called the client Determining web context ----------------------- To determine the "context" of a request, we look at the URL and the special request variable ``@template``. The URL path after the tracker identifier is examined. Typical URL paths look like: 1. ``/tracker/issue`` 2. ``/tracker/issue1`` 3. ``/tracker/@file/style.css`` 4. ``/cgi-bin/roundup.cgi/tracker/file1`` 5. ``/cgi-bin/roundup.cgi/tracker/file1/kitten.png`` where the "tracker identifier" is "tracker" in the above cases. That means we're looking at "issue", "issue1", "@file/style.css", "file1" and "file1/kitten.png" in the cases above. The path is generally only one entry long - longer paths are handled differently. a. if there is no path, then we are in the "home" context. See `the "home" context`_ below for more information about how it may be used. b. if the path starts with "@file" (as in example 3, "/tracker/@file/style.css"), then the additional path entry, "style.css" specifies the filename of a static file we're to serve up from the tracker "html" directory. Raises a SendStaticFile exception. c. if there is something in the path (as in example 1, "issue"), it identifies the tracker class we're to display. d. if the path is an item designator (as in examples 2 and 4, "issue1" and "file1"), then we're to display a specific item. e. if the path starts with an item designator and is longer than one entry (as in example 5, "file1/kitten.png"), then we're assumed to be handling an item of a ``FileClass``, and the extra path information gives the filename that the client is going to label the download with (i.e. "file1/kitten.png" is nicer to download than "file1"). This raises a ``SendFile`` exception. Both b. and e. stop before we bother to determine the template we're going to use. That's because they don't actually use templates. The template used is specified by the ``@template`` CGI variable, which defaults to: - only classname suplied: "index" - full item designator supplied: "item" The "home" Context ------------------ The "home" context is special because it allows you to add templated pages to your tracker that don't rely on a class or item (ie. an issues list or specific issue). Let's say you wish to add frames to control the layout of your tracker's interface. You'd probably have: - A top-level frameset page. This page probably wouldn't be templated, so it could be served as a static file (see `serving static content`_) - A sidebar frame that is templated. Let's call this page "home.navigation.html" in your tracker's "html" directory. To load that page up, you use the URL: /home?@template=navigation Serving static content ---------------------- See the previous section `determining web context`_ where it describes ``@file`` paths. Performing actions in web requests ---------------------------------- When a user requests a web page, they may optionally also request for an action to take place. As described in `how requests are processed`_, the action is performed before the requested page is generated. Actions are triggered by using a ``@action`` CGI variable, where the value is one of: **login** Attempt to log a user in. **logout** Log the user out - make them "anonymous". **register** Attempt to create a new user based on the contents of the form and then log them in. **edit** Perform an edit of an item in the database. There are some `special form variables`_ you may use. **new** Add a new item to the database. You may use the same `special form variables`_ as in the "edit" action. **retire** Retire the item in the database. **editCSV** Performs an edit of all of a class' items in one go. See also the *class*.csv templating method which generates the CSV data to be edited, and the ``'_generic.index'`` template which uses both of these features. **search** Mangle some of the form variables: - Set the form ":filter" variable based on the values of the filter variables - if they're set to anything other than "dontcare" then add them to :filter. - Also handle the ":queryname" variable and save off the query to the user's query list. Each of the actions is implemented by a corresponding ``*XxxAction*`` (where "Xxx" is the name of the action) class in the ``roundup.cgi.actions`` module. These classes are registered with ``roundup.cgi.client.Client`` which also happens to be available in your tracker instance as ``interfaces.Client``. So if you need to define new actions, you may add them there (see `defining new web actions`_). Each action class also has a ``*permission*`` method which determines whether the action is permissible given the current user. The base permission checks are: **login** Determine whether the user has permission to log in. Base behaviour is to check the user has "Web Access". **logout** No permission checks are made. **register** Determine whether the user has permission to register. Base behaviour is to check the user has the "Web Registration" Permission. **edit** Determine whether the user has permission to edit this item. Base behaviour is to check whether the user can edit this class. If we're editing the "user" class, users are allowed to edit their own details - unless they try to edit the "roles" property, which requires the special Permission "Web Roles". **new** Determine whether the user has permission to create (or edit) this item. Base behaviour is to check the user can edit this class. No additional property checks are made. Additionally, new user items may be created if the user has the "Web Registration" Permission. **editCSV** Determine whether the user has permission to edit this class. Base behaviour is to check whether the user may edit this class. **search** Determine whether the user has permission to search this class. Base behaviour is to check whether the user may view this class. Special form variables ---------------------- Item properties and their values are edited with html FORM variables and their values. You can: - Change the value of some property of the current item. - Create a new item of any class, and edit the new item's properties, - Attach newly created items to a multilink property of the current item. - Remove items from a multilink property of the current item. - Specify that some properties are required for the edit operation to be successful. In the following, values are variable, "@" may be either ":" or "@", and other text "required" is fixed. Most properties are specified as form variables: ```` property on the current context item ``"@"`` property on the indicated item (for editing related information) Designators name a specific item of a class. ```` Name an existing item of class . ``"-"`` Name the th new item of class . If the form submission is successful, a new item of is created. Within the submitted form, a particular designator of this form always refers to the same new item. Once we have determined the "propname", we look at it to see if it's special: ``@required`` The associated form value is a comma-separated list of property names that must be specified when the form is submitted for the edit operation to succeed. When the is missing, the properties are for the current context item. When is present, they are for the item specified by . The "@required" specifier must come before any of the properties it refers to are assigned in the form. ``@remove@=id(s)`` or ``@add@=id(s)`` The "@add@" and "@remove@" edit actions apply only to Multilink properties. The form value must be a comma-separate list of keys for the class specified by the simple form variable. The listed items are added to (respectively, removed from) the specified property. ``@link@=`` If the edit action is "@link@", the simple form variable must specify a Link or Multilink property. The form value is a comma-separated list of designators. The item corresponding to each designator is linked to the property given by simple form variable. None of the above (ie. just a simple form value) The value of the form variable is converted appropriately, depending on the type of the property. For a Link('klass') property, the form value is a single key for 'klass', where the key field is specified in dbinit.py. For a Multilink('klass') property, the form value is a comma-separated list of keys for 'klass', where the key field is specified in dbinit.py. Note that for simple-form-variables specifiying Link and Multilink properties, the linked-to class must have a key field. For a String() property specifying a filename, the file named by the form value is uploaded. This means we try to set additional properties "filename" and "type" (if they are valid for the class). Otherwise, the property is set to the form value. For Date(), Interval(), Boolean(), and Number() properties, the form value is converted to the appropriate Any of the form variables may be prefixed with a classname or designator. Two special form values are supported for backwards compatibility: @note This is equivalent to:: @link@messages=msg-1 msg-1@content=value except that in addition, the "author" and "date" properties of "msg-1" are set to the userid of the submitter, and the current time, respectively. @file This is equivalent to:: @link@files=file-1 file-1@content=value The String content value is handled as described above for file uploads. If both the "@note" and "@file" form variables are specified, the action:: @link@msg-1@files=file-1 is also performed. We also check that FileClass items have a "content" property with actual content, otherwise we remove them from all_props before returning. Default templates ----------------- The default templates are html4 compliant. If you wish to change them to be xhtml compliant, you'll need to change the ``HTML_VERSION`` configuration variable in ``config.py`` to ``'xhtml'`` instead of ``'html4'``. Most customisation of the web view can be done by modifying the templates in the tracker ``'html'`` directory. There are several types of files in there. The *minimal* template includes: **page.html** This template usually defines the overall look of your tracker. When you view an issue, it appears inside this template. When you view an index, it also appears inside this template. This template defines a macro called "icing" which is used by almost all other templates as a coating for their content, using its "content" slot. It also defines the "head_title" and "body_title" slots to allow setting of the page title. **home.html** the default page displayed when no other page is indicated by the user **home.classlist.html** a special version of the default page that lists the classes in the tracker **classname.item.html** displays an item of the *classname* class **classname.index.html** displays a list of *classname* items **classname.search.html** displays a search page for *classname* items **_generic.index.html** used to display a list of items where there is no ``*classname*.index`` available **_generic.help.html** used to display a "class help" page where there is no ``*classname*.help`` **user.register.html** a special page just for the user class, that renders the registration page **style.css.html** a static file that is served up as-is The *classic* template has a number of additional templates. Note: Remember that you can create any template extension you want to, so if you just want to play around with the templating for new issues, you can copy the current "issue.item" template to "issue.test", and then access the test template using the "@template" URL argument:: http://your.tracker.example/tracker/issue?@template=test and it won't affect your users using the "issue.item" template. How the templates work ---------------------- Basic Templating Actions ~~~~~~~~~~~~~~~~~~~~~~~~ Roundup's templates consist of special attributes on the HTML tags. These attributes form the `Template Attribute Language`_, or TAL. The basic TAL commands are: **tal:define="variable expression; variable expression; ..."** Define a new variable that is local to this tag and its contents. For example:: In this example, the variable "title" is defined as the result of the expression "request/description". The "tal:content" command inside the tag may then use the "title" variable. **tal:condition="expression"** Only keep this tag and its contents if the expression is true. For example::

Display some issue information.

In the example, the

tag and its contents are only displayed if the user has the "View" permission for issues. We consider the number zero, a blank string, an empty list, and the built-in variable nothing to be false values. Nearly every other value is true, including non-zero numbers, and strings with anything in them (even spaces!). **tal:repeat="variable expression"** Repeat this tag and its contents for each element of the sequence that the expression returns, defining a new local variable and a special "repeat" variable for each element. For example:: The example would iterate over the sequence of users returned by "user/list" and define the local variable "u" for each entry. **tal:replace="expression"** Replace this tag with the result of the expression. For example:: The example would replace the tag and its contents with the user's realname. If the user's realname was "Bruce", then the resultant output would be "Bruce". **tal:content="expression"** Replace the contents of this tag with the result of the expression. For example:: user's name appears here The example would replace the contents of the tag with the user's realname. If the user's realname was "Bruce" then the resultant output would be "Bruce". **tal:attributes="attribute expression; attribute expression; ..."** Set attributes on this tag to the results of expressions. For example:: My Details In the example, the "href" attribute of the tag is set to the value of the "string:user${request/user/id}" expression, which will be something like "user123". **tal:omit-tag="expression"** Remove this tag (but not its contents) if the expression is true. For example:: Hello, world! would result in output of:: Hello, world! Note that the commands on a given tag are evaulated in the order above, so *define* comes before *condition*, and so on. Additionally, you may include tags such as , which are removed from output. Its content is kept, but the tag itself is not (so don't go using any "tal:attributes" commands on it). This is useful for making arbitrary blocks of HTML conditional or repeatable (very handy for repeating multiple table rows, which would othewise require an illegal tag placement to effect the repeat). .. _TAL: .. _Template Attribute Language: http://dev.zope.org/Wikis/DevSite/Projects/ZPT/TAL%20Specification%201.4 Templating Expressions ~~~~~~~~~~~~~~~~~~~~~~ Templating Expressions are covered by `Template Attribute Language Expression Syntax`_, or TALES. The expressions you may use in the attribute values may be one of the following forms: **Path Expressions** - eg. ``item/status/checklist`` These are object attribute / item accesses. Roughly speaking, the path ``item/status/checklist`` is broken into parts ``item``, ``status`` and ``checklist``. The ``item`` part is the root of the expression. We then look for a ``status`` attribute on ``item``, or failing that, a ``status`` item (as in ``item['status']``). If that fails, the path expression fails. When we get to the end, the object we're left with is evaluated to get a string - if it is a method, it is called; if it is an object, it is stringified. Path expressions may have an optional ``path:`` prefix, but they are the default expression type, so it's not necessary. If an expression evaluates to ``default``, then the expression is "cancelled" - whatever HTML already exists in the template will remain (tag content in the case of ``tal:content``, attributes in the case of ``tal:attributes``). If an expression evaluates to ``nothing`` then the target of the expression is removed (tag content in the case of ``tal:content``, attributes in the case of ``tal:attributes`` and the tag itself in the case of ``tal:replace``). If an element in the path may not exist, then you can use the ``|`` operator in the expression to provide an alternative. So, the expression ``request/form/foo/value | default`` would simply leave the current HTML in place if the "foo" form variable doesn't exist. You may use the python function ``path``, as in ``path("item/status")``, to embed path expressions in Python expressions. **String Expressions** - eg. ``string:hello ${user/name}`` These expressions are simple string interpolations - though they can be just plain strings with no interpolation if you want. The expression in the ``${ ... }`` is just a path expression as above. **Python Expressions** - eg. ``python: 1+1`` These expressions give the full power of Python. All the "root level" variables are available, so ``python:item.status.checklist()`` would be equivalent to ``item/status/checklist``, assuming that ``checklist`` is a method. Modifiers: **structure** - eg. ``structure python:msg.content.plain(hyperlink=1)`` The result of expressions are normally *escaped* to be safe for HTML display (all "<", ">" and "&" are turned into special entities). The ``structure`` expression modifier turns off this escaping - the result of the expression is now assumed to be HTML, which is passed to the web browser for rendering. **not:** - eg. ``not:python:1=1`` This simply inverts the logical true/false value of another expression. .. _TALES: .. _Template Attribute Language Expression Syntax: http://dev.zope.org/Wikis/DevSite/Projects/ZPT/TALES%20Specification%201.3 Template Macros ~~~~~~~~~~~~~~~ Macros are used in Roundup to save us from repeating the same common page stuctures over and over. The most common (and probably only) macro you'll use is the "icing" macro defined in the "page" template. Macros are generated and used inside your templates using special attributes similar to the `basic templating actions`_. In this case, though, the attributes belong to the `Macro Expansion Template Attribute Language`_, or METAL. The macro commands are: **metal:define-macro="macro name"** Define that the tag and its contents are now a macro that may be inserted into other templates using the *use-macro* command. For example:: ... defines a macro called "page" using the ```` tag and its contents. Once defined, macros are stored on the template they're defined on in the ``macros`` attribute. You can access them later on through the ``templates`` variable, eg. the most common ``templates/page/macros/icing`` to access the "page" macro of the "page" template. **metal:use-macro="path expression"** Use a macro, which is identified by the path expression (see above). This will replace the current tag with the identified macro contents. For example:: ... will replace the tag and its contents with the "page" macro of the "page" template. **metal:define-slot="slot name"** and **metal:fill-slot="slot name"** To define *dynamic* parts of the macro, you define "slots" which may be filled when the macro is used with a *use-macro* command. For example, the ``templates/page/macros/icing`` macro defines a slot like so:: title goes here In your *use-macro* command, you may now use a *fill-slot* command like this:: My Title where the tag that fills the slot completely replaces the one defined as the slot in the macro. Note that you may not mix `METAL`_ and `TAL`_ commands on the same tag, but TAL commands may be used freely inside METAL-using tags (so your *fill-slots* tags may have all manner of TAL inside them). .. _METAL: .. _Macro Expansion Template Attribute Language: http://dev.zope.org/Wikis/DevSite/Projects/ZPT/METAL%20Specification%201.0 Information available to templates ---------------------------------- Note: this is implemented by ``roundup.cgi.templating.RoundupPageTemplate`` The following variables are available to templates. **context** The current context. This is either None, a `hyperdb class wrapper`_ or a `hyperdb item wrapper`_ **request** Includes information about the current request, including: - the current index information (``filterspec``, ``filter`` args, ``properties``, etc) parsed out of the form. - methods for easy filterspec link generation - *user*, the current user item as an HTMLItem instance - *form* The current CGI form information as a mapping of form argument name to value **config** This variable holds all the values defined in the tracker config.py file (eg. TRACKER_NAME, etc.) **db** The current database, used to access arbitrary database items. **templates** Access to all the tracker templates by name. Used mainly in *use-macro* commands. **utils** This variable makes available some utility functions like batching. **nothing** This is a special variable - if an expression evaluates to this, then the tag (in the case of a ``tal:replace``), its contents (in the case of ``tal:content``) or some attributes (in the case of ``tal:attributes``) will not appear in the the output. So, for example:: Hello, World! would result in:: Hello, World! **default** Also a special variable - if an expression evaluates to this, then the existing HTML in the template will not be replaced or removed, it will remain. So:: Hello, World! would result in:: Hello, World! The context variable ~~~~~~~~~~~~~~~~~~~~ The *context* variable is one of three things based on the current context (see `determining web context`_ for how we figure this out): 1. if we're looking at a "home" page, then it's None 2. if we're looking at a specific hyperdb class, it's a `hyperdb class wrapper`_. 3. if we're looking at a specific hyperdb item, it's a `hyperdb item wrapper`_. If the context is not None, we can access the properties of the class or item. The only real difference between cases 2 and 3 above are: 1. the properties may have a real value behind them, and this will appear if the property is displayed through ``context/property`` or ``context/property/field``. 2. the context's "id" property will be a false value in the second case, but a real, or true value in the third. Thus we can determine whether we're looking at a real item from the hyperdb by testing "context/id". Hyperdb class wrapper ::::::::::::::::::::: Note: this is implemented by the ``roundup.cgi.templating.HTMLClass`` class. This wrapper object provides access to a hyperb class. It is used primarily in both index view and new item views, but it's also usable anywhere else that you wish to access information about a class, or the items of a class, when you don't have a specific item of that class in mind. We allow access to properties. There will be no "id" property. The value accessed through the property will be the current value of the same name from the CGI form. There are several methods available on these wrapper objects: =========== ============================================================= Method Description =========== ============================================================= properties return a `hyperdb property wrapper`_ for all of this class's properties. list lists all of the active (not retired) items in the class. csv return the items of this class as a chunk of CSV text. propnames lists the names of the properties of this class. filter lists of items from this class, filtered and sorted by the current *request* filterspec/filter/sort/group args classhelp display a link to a javascript popup containing this class' "help" template. submit generate a submit button (and action hidden element) renderWith render this class with the given template. history returns 'New node - no history' :) is_edit_ok is the user allowed to Edit the current class? is_view_ok is the user allowed to View the current class? =========== ============================================================= Note that if you have a property of the same name as one of the above methods, you'll need to access it using a python "item access" expression. For example:: python:context['list'] will access the "list" property, rather than the list method. Hyperdb item wrapper :::::::::::::::::::: Note: this is implemented by the ``roundup.cgi.templating.HTMLItem`` class. This wrapper object provides access to a hyperb item. We allow access to properties. There will be no "id" property. The value accessed through the property will be the current value of the same name from the CGI form. There are several methods available on these wrapper objects: =============== ======================================================== Method Description =============== ======================================================== submit generate a submit button (and action hidden element) journal return the journal of the current item (**not implemented**) history render the journal of the current item as HTML renderQueryForm specific to the "query" class - render the search form for the query hasPermission specific to the "user" class - determine whether the user has a Permission is_edit_ok is the user allowed to Edit the current item? is_view_ok is the user allowed to View the current item? is_retired is the item retired? download_url generates a url-quoted link for download of FileClass item contents (ie. file/) =============== ======================================================== Note that if you have a property of the same name as one of the above methods, you'll need to access it using a python "item access" expression. For example:: python:context['journal'] will access the "journal" property, rather than the journal method. Hyperdb property wrapper :::::::::::::::::::::::: Note: this is implemented by subclasses of the ``roundup.cgi.templating.HTMLProperty`` class (``HTMLStringProperty``, ``HTMLNumberProperty``, and so on). This wrapper object provides access to a single property of a class. Its value may be either: 1. if accessed through a `hyperdb item wrapper`_, then it's a value from the hyperdb 2. if access through a `hyperdb class wrapper`_, then it's a value from the CGI form The property wrapper has some useful attributes: =============== ======================================================== Attribute Description =============== ======================================================== _name the name of the property _value the value of the property if any - this is the actual value retrieved from the hyperdb for this property =============== ======================================================== There are several methods available on these wrapper objects: =========== ================================================================ Method Description =========== ================================================================ plain render a "plain" representation of the property. This method may take two arguments: escape If true, escape the text so it is HTML safe (default: no). The reason this defaults to off is that text is usually escaped at a later stage by the TAL commands, unless the "structure" option is used in the template. The following ``tal:content`` expressions are all equivalent:: "structure python:msg.content.plain(escape=1)" "python:msg.content.plain()" "msg/content/plain" "msg/content" Usually you'll only want to use the escape option in a complex expression. hyperlink If true, turn URLs, email addresses and hyperdb item designators in the text into hyperlinks (default: no). Note that you'll need to use the "structure" TAL option if you want to use this ``tal:content`` expression:: "structure python:msg.content.plain(hyperlink=1)" Note also that the text is automatically HTML-escaped before the hyperlinking transformation. hyperlinked The same as msg.content.plain(hyperlink=1), but nicer:: "structure msg/content/hyperlinked" field render an appropriate form edit field for the property - for most types this is a text entry box, but for Booleans it's a tri-state yes/no/neither selection. stext only on String properties - render the value of the property as StructuredText (requires the StructureText module to be installed separately) multiline only on String properties - render a multiline form edit field for the property email only on String properties - render the value of the property as an obscured email address confirm only on Password properties - render a second form edit field for the property, used for confirmation that the user typed the password correctly. Generates a field with name "name:confirm". now only on Date properties - return the current date as a new property reldate only on Date properties - render the interval between the date and now local only on Date properties - return this date as a new property with some timezone offset, for example:: python:context.creation.local(10) will render the date with a +10 hour offset. pretty Date properties - render the date as "dd Mon YYYY" (eg. "19 Mar 2004"). Takes an optional format argument, for example:: python:context.activity.pretty('%Y-%m-%d') Will format as "2004-03-19" instead. Interval properties - render the interval in a pretty format (eg. "yesterday") menu only on Link and Multilink properties - render a form select list for this property reverse only on Multilink properties - produce a list of the linked items in reverse order isset returns True if the property has been set to a value =========== ================================================================ All of the above functions perform checks for permissions required to display or edit the data they are manipulating. The simplest case is editing an issue title. Including the expression:: context/title/field Will present the user with an edit field, if they have edit permission. If not, then they will be presented with a static display if they have view permission. If they don't even have view permission, then an error message is raised, preventing the display of the page, indicating that they don't have permission to view the information. The request variable ~~~~~~~~~~~~~~~~~~~~ Note: this is implemented by the ``roundup.cgi.templating.HTMLRequest`` class. The request variable is packed with information about the current request. .. taken from ``roundup.cgi.templating.HTMLRequest`` docstring =========== ============================================================ Variable Holds =========== ============================================================ form the CGI form as a cgi.FieldStorage env the CGI environment variables base the base URL for this tracker user a HTMLUser instance for this user classname the current classname (possibly None) template the current template (suffix, also possibly None) form the current CGI form variables in a FieldStorage =========== ============================================================ **Index page specific variables (indexing arguments)** =========== ============================================================ Variable Holds =========== ============================================================ columns dictionary of the columns to display in an index page show a convenience access to columns - request/show/colname will be true if the columns should be displayed, false otherwise sort index sort column (direction, column name) group index grouping property (direction, column name) filter properties to filter the index on filterspec values to filter the index on search_text text to perform a full-text search on for an index =========== ============================================================ There are several methods available on the request variable: =============== ======================================================== Method Description =============== ======================================================== description render a description of the request - handle for the page title indexargs_form render the current index args as form elements indexargs_url render the current index args as a URL base_javascript render some javascript that is used by other components of the templating batch run the current index args through a filter and return a list of items (see `hyperdb item wrapper`_, and `batching`_) =============== ======================================================== The form variable ::::::::::::::::: The form variable is a bit special because it's actually a python FieldStorage object. That means that you have two ways to access its contents. For example, to look up the CGI form value for the variable "name", use the path expression:: request/form/name/value or the python expression:: python:request.form['name'].value Note the "item" access used in the python case, and also note the explicit "value" attribute we have to access. That's because the form variables are stored as MiniFieldStorages. If there's more than one "name" value in the form, then the above will break since ``request/form/name`` is actually a *list* of MiniFieldStorages. So it's best to know beforehand what you're dealing with. The db variable ~~~~~~~~~~~~~~~ Note: this is implemented by the ``roundup.cgi.templating.HTMLDatabase`` class. Allows access to all hyperdb classes as attributes of this variable. If you want access to the "user" class, for example, you would use:: db/user python:db.user Also, the current id of the current user is available as ``db.getuid()``. This isn't so useful in templates (where you have ``request/user``), but it can be useful in detectors or interfaces. The access results in a `hyperdb class wrapper`_. The templates variable ~~~~~~~~~~~~~~~~~~~~~~ Note: this is implemented by the ``roundup.cgi.templating.Templates`` class. This variable doesn't have any useful methods defined. It supports being used in expressions to access the templates, and consequently the template macros. You may access the templates using the following path expression:: templates/name or the python expression:: templates[name] where "name" is the name of the template you wish to access. The template has one useful attribute, namely "macros". To access a specific macro (called "macro_name"), use the path expression:: templates/name/macros/macro_name or the python expression:: templates[name].macros[macro_name] The utils variable ~~~~~~~~~~~~~~~~~~ Note: this is implemented by the ``roundup.cgi.templating.TemplatingUtils`` class, but it may be extended as described below. =============== ======================================================== Method Description =============== ======================================================== Batch return a batch object using the supplied list url_quote quote some text as safe for a URL (ie. space, %, ...) html_quote quote some text as safe in HTML (ie. <, >, ...) =============== ======================================================== You may add additional utility methods by writing them in your tracker ``interfaces.py`` module's ``TemplatingUtils`` class. See `adding a time log to your issues`_ for an example. The TemplatingUtils class itself will have a single attribute, ``client``, which may be used to access the ``client.db`` when you need to perform arbitrary database queries. Batching :::::::: Use Batch to turn a list of items, or item ids of a given class, into a series of batches. Its usage is:: python:utils.Batch(sequence, size, start, end=0, orphan=0, overlap=0) or, to get the current index batch:: request/batch The parameters are: ========= ============================================================== Parameter Usage ========= ============================================================== sequence a list of HTMLItems size how big to make the sequence. start where to start (0-indexed) in the sequence. end where to end (0-indexed) in the sequence. orphan if the next batch would contain less items than this value, then it is combined with this batch overlap the number of items shared between adjacent batches ========= ============================================================== All of the parameters are assigned as attributes on the batch object. In addition, it has several more attributes: =============== ======================================================== Attribute Description =============== ======================================================== start indicates the start index of the batch. *Note: unlike the argument, is a 1-based index (I know, lame)* first indicates the start index of the batch *as a 0-based index* length the actual number of elements in the batch sequence_length the length of the original, unbatched, sequence. =============== ======================================================== And several methods: =============== ======================================================== Method Description =============== ======================================================== previous returns a new Batch with the previous batch settings next returns a new Batch with the next batch settings propchanged detect if the named property changed on the current item when compared to the last item =============== ======================================================== An example of batching::
Existing Keywords
keyword here
... which will produce a table with four columns containing the items of the "keyword" class (well, their "name" anyway). Displaying Properties --------------------- Properties appear in the user interface in three contexts: in indices, in editors, and as search arguments. For each type of property, there are several display possibilities. For example, in an index view, a string property may just be printed as a plain string, but in an editor view, that property may be displayed in an editable field. Index Views ----------- This is one of the class context views. It is also the default view for classes. The template used is "*classname*.index". Index View Specifiers ~~~~~~~~~~~~~~~~~~~~~ An index view specifier (URL fragment) looks like this (whitespace has been added for clarity):: /issue?status=unread,in-progress,resolved& topic=security,ui& :group=+priority& :sort==activity& :filters=status,topic& :columns=title,status,fixer The index view is determined by two parts of the specifier: the layout part and the filter part. The layout part consists of the query parameters that begin with colons, and it determines the way that the properties of selected items are displayed. The filter part consists of all the other query parameters, and it determines the criteria by which items are selected for display. The filter part is interactively manipulated with the form widgets displayed in the filter section. The layout part is interactively manipulated by clicking on the column headings in the table. The filter part selects the union of the sets of items with values matching any specified Link properties and the intersection of the sets of items with values matching any specified Multilink properties. The example specifies an index of "issue" items. Only items with a "status" of either "unread" or "in-progress" or "resolved" are displayed, and only items with "topic" values including both "security" and "ui" are displayed. The items are grouped by priority, arranged in ascending order; and within groups, sorted by activity, arranged in descending order. The filter section shows filters for the "status" and "topic" properties, and the table includes columns for the "title", "status", and "fixer" properties. Searching Views --------------- Note: if you add a new column to the ``:columns`` form variable potentials then you will need to add the column to the appropriate `index views`_ template so that it is actually displayed. This is one of the class context views. The template used is typically "*classname*.search". The form on this page should have "search" as its ``@action`` variable. The "search" action: - sets up additional filtering, as well as performing indexed text searching - sets the ``:filter`` variable correctly - saves the query off if ``:query_name`` is set. The search page should lay out any fields that you wish to allow the user to search on. If your schema contains a large number of properties, you should be wary of making all of those properties available for searching, as this can cause confusion. If the additional properties are Strings, consider having their value indexed, and then they will be searchable using the full text indexed search. This is both faster, and more useful for the end user. The two special form values on search pages which are handled by the "search" action are: :search_text Text with which to perform a search of the text index. Results from that search will be used to limit the results of other filters (using an intersection operation) :query_name If supplied, the search parameters (including :search_text) will be saved off as a the query item and registered against the user's queries property. Note that the *classic* template schema has this ability, but the *minimal* template schema does not. Item Views ---------- The basic view of a hyperdb item is provided by the "*classname*.item" template. It generally has three sections; an "editor", a "spool" and a "history" section. Editor Section ~~~~~~~~~~~~~~ The editor section is used to manipulate the item - it may be a static display if the user doesn't have permission to edit the item. Here's an example of a basic editor template (this is the default "classic" template issue item edit form - from the "issue.item.html" template)::
Title title
Priority priority Status status
Superseder
View: 		Nosy List
Assigned To assignedto menu    
Change Note
File
  submit button will go here
When a change is submitted, the system automatically generates a message describing the changed properties. As shown in the example, the editor template can use the ":note" and ":file" fields, which are added to the standard changenote message generated by Roundup. Form values ::::::::::: We have a number of ways to pull properties out of the form in order to meet the various needs of: 1. editing the current item (perhaps an issue item) 2. editing information related to the current item (eg. messages or attached files) 3. creating new information to be linked to the current item (eg. time spent on an issue) In the following, ```` values are variable, ":" may be one of ":" or "@", and other text ("required") is fixed. Properties are specified as form variables: ```` property on the current context item ``:`` property on the indicated item (for editing related information) ``-:`` property on the Nth new item of classname (generally for creating new items to attach to the current item) Once we have determined the "propname", we check to see if it is one of the special form values: ``@required`` The named property values must be supplied or a ValueError will be raised. ``@remove@=id(s)`` The ids will be removed from the multilink property. ``:add:=id(s)`` The ids will be added to the multilink property. ``:link:=`` Used to add a link to new items created during edit. These are collected and returned in ``all_links``. This will result in an additional linking operation (either Link set or Multilink append) after the edit/create is done using ``all_props`` in ``_editnodes``. The on the current item will be set/appended the id of the newly created item of class (where must be -). Any of the form variables may be prefixed with a classname or designator. Two special form values are supported for backwards compatibility: ``:note`` create a message (with content, author and date), linked to the context item. This is ALWAYS designated "msg-1". ``:file`` create a file, attached to the current item and any message created by :note. This is ALWAYS designated "file-1". Spool Section ~~~~~~~~~~~~~ The spool section lists related information like the messages and files of an issue. TODO History Section ~~~~~~~~~~~~~~~ The final section displayed is the history of the item - its database journal. This is generally generated with the template:: *To be done:* *The actual history entries of the item may be accessed for manual templating through the "journal" method of the item*:: a journal entry *where each journal entry is an HTMLJournalEntry.* Defining new web actions ------------------------ You may define new actions to be triggered by the ``@action`` form variable. These are added to the tracker ``interfaces.py`` as ``Action`` classes that get called by the the ``Client`` class. Adding action classes takes three steps; first you `define the new action class`_, then you `register the action class`_ with the cgi interface so it may be triggered by the ``@action`` form variable. Finally you `use the new action`_ in your HTML form. See "`setting up a "wizard" (or "druid") for controlled adding of issues`_" for an example. Define the new action class ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The action classes have the following interface:: class MyAction(Action): def handle(self): ''' Perform some action. No return value is required. ''' The *self.client* attribute is an instance of your tracker ``instance.Client`` class - thus it's mostly implemented by ``roundup.cgi.client.Client``. See the docstring of that class for details of what it can do. The method will typically check the ``self.form`` variable's contents. It may then: - add information to ``self.client.ok_message`` or ``self.client.error_message`` - change the ``self.client.template`` variable to alter what the user will see next - raise Unauthorised, SendStaticFile, SendFile, NotFound or Redirect exceptions (import them from roundup.cgi.exceptions) Register the action class ~~~~~~~~~~~~~~~~~~~~~~~~~~ The class is now written, but isn't available to the user until you add it to the ``instance.Client`` class ``actions`` variable, like so:: actions = client.Client.actions + ( ('myaction', myActionClass), ) This maps the action name "myaction" to the action class we defined. Use the new action ~~~~~~~~~~~~~~~~~~ In your HTML form, add a hidden form element like so:: where "myaction" is the name you registered in the previous step. Actions may return content to the user ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Actions generally perform some database manipulation and then pass control on to the rendering of a template in the current context (see `Determining web context`_ for how that works.) Some actions will want to generate the actual content returned to the user. Action methods may return their own content string to be displayed to the user, overriding the templating step. In this situation, we assume that the content is HTML by default. You may override the content type indicated to the user by calling ``setHeader``:: self.client.setHeader('Content-Type', 'text/csv') This example indicates that the value sent back to the user is actually comma-separated value content (eg. something to be loaded into a spreadsheet or database). Examples ======== .. contents:: :local: :depth: 2 Changing what's stored in the database -------------------------------------- The following examples illustrate ways to change the information stored in the database. Adding a new field to the classic schema ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This example shows how to add a new constrained property (i.e. a selection of distinct values) to your tracker. Introduction :::::::::::: To make the classic schema of roundup useful as a TODO tracking system for a group of systems administrators, it needed an extra data field per issue: a category. This would let sysadmins quickly list all TODOs in their particular area of interest without having to do complex queries, and without relying on the spelling capabilities of other sysadmins (a losing proposition at best). Adding a field to the database :::::::::::::::::::::::::::::: This is the easiest part of the change. The category would just be a plain string, nothing fancy. To change what is in the database you need to add some lines to the ``open()`` function in ``dbinit.py``. Under the comment:: # add any additional database schema configuration here add:: category = Class(db, "category", name=String()) category.setkey("name") Here we are setting up a chunk of the database which we are calling "category". It contains a string, which we are refering to as "name" for lack of a more imaginative title. (Since "name" is one of the properties that Roundup looks for on items if you do not set a key for them, it's probably a good idea to stick with it for new classes if at all appropriate.) Then we are setting the key of this chunk of the database to be that "name". This is equivalent to an index for database types. This also means that there can only be one category with a given name. Adding the above lines allows us to create categories, but they're not tied to the issues that we are going to be creating. It's just a list of categories off on its own, which isn't much use. We need to link it in with the issues. To do that, find the lines in the ``open()`` function in ``dbinit.py`` which set up the "issue" class, and then add a link to the category:: issue = IssueClass(db, "issue", ... , category=Multilink("category"), ... ) The ``Multilink()`` means that each issue can have many categories. If you were adding something with a one-to-one relationship to issues (such as the "assignedto" property), use ``Link()`` instead. That is all you need to do to change the schema. The rest of the effort is fiddling around so you can actually use the new category. Populating the new category class ::::::::::::::::::::::::::::::::: If you haven't initialised the database with the roundup-admin "initialise" command, then you can add the following to the tracker ``dbinit.py`` in the ``init()`` function under the comment:: # add any additional database create steps here - but only if you # haven't initialised the database with the admin "initialise" command Add:: category = db.getclass('category') category.create(name="scipy", order="1") category.create(name="chaco", order="2") category.create(name="weave", order="3") If the database has already been initalised, then you need to use the ``roundup-admin`` tool:: % roundup-admin -i Roundup ready for input. Type "help" for help. roundup> create category name=scipy order=1 1 roundup> create category name=chaco order=1 2 roundup> create category name=weave order=1 3 roundup> exit... There are unsaved changes. Commit them (y/N)? y TODO: explain why order=1 in each case. Setting up security on the new objects :::::::::::::::::::::::::::::::::::::: By default only the admin user can look at and change objects. This doesn't suit us, as we want any user to be able to create new categories as required, and obviously everyone needs to be able to view the categories of issues for it to be useful. We therefore need to change the security of the category objects. This is also done in the ``open()`` function of ``dbinit.py``. There are currently two loops which set up permissions and then assign them to various roles. Simply add the new "category" to both lists:: # new permissions for this schema for cl in 'issue', 'file', 'msg', 'user', 'category': db.security.addPermission(name="Edit", klass=cl, description="User is allowed to edit "+cl) db.security.addPermission(name="View", klass=cl, description="User is allowed to access "+cl) # Assign the access and edit permissions for issue, file and message # to regular users now for cl in 'issue', 'file', 'msg', 'category': p = db.security.getPermission('View', cl) db.security.addPermissionToRole('User', p) p = db.security.getPermission('Edit', cl) db.security.addPermissionToRole('User', p) So you are in effect doing the following (with 'cl' substituted by its value):: db.security.addPermission(name="Edit", klass='category', description="User is allowed to edit "+'category') db.security.addPermission(name="View", klass='category', description="User is allowed to access "+'category') which is creating two permission types; that of editing and viewing "category" objects respectively. Then the following lines assign those new permissions to the "User" role, so that normal users can view and edit "category" objects:: p = db.security.getPermission('View', 'category') db.security.addPermissionToRole('User', p) p = db.security.getPermission('Edit', 'category') db.security.addPermissionToRole('User', p) This is all the work that needs to be done for the database. It will store categories, and let users view and edit them. Now on to the interface stuff. Changing the web left hand frame :::::::::::::::::::::::::::::::: We need to give the users the ability to create new categories, and the place to put the link to this functionality is in the left hand function bar, under the "Issues" area. The file that defines how this area looks is ``html/page``, which is what we are going to be editing next. If you look at this file you can see that it contains a lot of "classblock" sections which are chunks of HTML that will be included or excluded in the output depending on whether the condition in the classblock is met. Under the end of the classblock for issue is where we are going to add the category code::

Categories
New Category

The first two lines is the classblock definition, which sets up a condition that only users who have "View" permission for the "category" object will have this section included in their output. Next comes a plain "Categories" header in bold. Everyone who can view categories will get that. Next comes the link to the editing area of categories. This link will only appear if the condition - that the user has "Edit" permissions for the "category" objects - is matched. If they do have permission then they will get a link to another page which will let the user add new categories. Note that if you have permission to *view* but not to *edit* categories, then all you will see is a "Categories" header with nothing underneath it. This is obviously not very good interface design, but will do for now. I just claim that it is so I can add more links in this section later on. However to fix the problem you could change the condition in the classblock statement, so that only users with "Edit" permission would see the "Categories" stuff. Setting up a page to edit categories :::::::::::::::::::::::::::::::::::: We defined code in the previous section which let users with the appropriate permissions see a link to a page which would let them edit conditions. Now we have to write that page. The link was for the *item* template of the *category* object. This translates into Roundup looking for a file called ``category.item.html`` in the ``html`` tracker directory. This is the file that we are going to write now. First we add an info tag in a comment which doesn't affect the outcome of the code at all, but is useful for debugging. If you load a page in a browser and look at the page source, you can see which sections come from which files by looking for these comments:: Next we need to add in the METAL macro stuff so we get the normal page trappings:: Category editing

Category editing

Next we need to setup up a standard HTML form, which is the whole purpose of this file. We link to some handy javascript which sends the form through only once. This is to stop users hitting the send button multiple times when they are impatient and thus having the form sent multiple times::
Next we define some code which sets up the minimum list of fields that we require the user to enter. There will be only one field - "name" - so they better put something in it, otherwise the whole form is pointless:: To get everything to line up properly we will put everything in a table, and put a nice big header on it so the user has an idea what is happening:: Next, we need the field into which the user is going to enter the new category. The "context.name.field(size=60)" bit tells Roundup to generate a normal HTML field of size 60, and the contents of that field will be the "name" variable of the current context (which is "category"). The upshot of this is that when the user types something in to the form, a new category will be created with that name:: Then a submit button so that the user can submit the new category:: Finally we finish off the tags we used at the start to do the METAL stuff:: So putting it all together, and closing the table and form we get:: Category editing This is quite a lot to just ask the user one simple question, but there is a lot of setup for basically one line (the form line) to do its work. To add another field to "category" would involve one more line (well, maybe a few extra to get the formatting correct). Adding the category to the issue :::::::::::::::::::::::::::::::: We now have the ability to create issues to our heart's content, but that is pointless unless we can assign categories to issues. Just like the ``html/category.item.html`` file was used to define how to add a new category, the ``html/issue.item.html`` is used to define how a new issue is created. Just like ``category.issue.html`` this file defines a form which has a table to lay things out. It doesn't matter where in the table we add new stuff, it is entirely up to your sense of aesthetics:: First, we define a nice header so that the user knows what the next section is, then the middle line does what we are most interested in. This ``context/category/field`` gets replaced by a field which contains the category in the current context (the current context being the new issue). The classhelp lines generate a link (labelled "list") to a popup window which contains the list of currently known categories. Searching on categories ::::::::::::::::::::::: We can add categories, and create issues with categories. The next obvious thing that we would like to be able to do, would be to search for issues based on their category, so that, for example, anyone working on the web server could look at all issues in the category "Web". If you look for "Search Issues" in the 'html/page.html' file, you will find that it looks something like ``Search Issues``. This shows us that when you click on "Search Issues" it will be looking for a ``issue.search.html`` file to display. So that is the file that we will change. If you look at this file it should be starting to seem familiar, although it does use some new macros. You can add the new category search code anywhere you like within that form:: The definitions in the opening tag are used by the macros: - search_select expands to a drop-down box with all categories using db_klass and db_content. - column_input expands to a checkbox for selecting what columns should be displayed. - sort_input expands to a radio button for selecting what property should be sorted on. - group_input expands to a radio button for selecting what property should be group on. The category search code above would expand to the following:: Adding category to the default view ::::::::::::::::::::::::::::::::::: We can now add categories, add issues with categories, and search for issues based on categories. This is everything that we need to do; however, there is some more icing that we would like. I think the category of an issue is important enough that it should be displayed by default when listing all the issues. Unfortunately, this is a bit less obvious than the previous steps. The code defining how the issues look is in ``html/issue.index.html``. This is a large table with a form down at the bottom for redisplaying and so forth. Firstly we need to add an appropriate header to the start of the table:: The *condition* part of this statement is to avoid displaying the Category column if the user has selected not to see it. The rest of the table is a loop which will go through every issue that matches the display criteria. The loop variable is "i" - which means that every issue gets assigned to "i" in turn. The new part of code to display the category will look like this:: The condition is the same as above: only display the condition when the user hasn't asked for it to be hidden. The next part is to set the content of the cell to be the category part of "i" - the current issue. Finally we have to edit ``html/page.html`` again. This time, we need to tell it that when the user clicks on "Unasigned Issues" or "All Issues", the category column should be included in the resulting list. If you scroll down the page file, you can see the links with lots of options. The option that we are interested in is the ``:columns=`` one which tells roundup which fields of the issue to display. Simply add "category" to that list and it all should work. Adding a time log to your issues ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We want to log the dates and amount of time spent working on issues, and be able to give a summary of the total time spent on a particular issue. 1. Add a new class to your tracker ``dbinit.py``:: # storage for time logging timelog = Class(db, "timelog", period=Interval()) Note that we automatically get the date of the time log entry creation through the standard property "creation". 2. Link to the new class from your issue class (again, in ``dbinit.py``):: issue = IssueClass(db, "issue", assignedto=Link("user"), topic=Multilink("keyword"), priority=Link("priority"), status=Link("status"), times=Multilink("timelog")) the "times" property is the new link to the "timelog" class. 3. We'll need to let people add in times to the issue, so in the web interface we'll have a new entry field. This is a special field because unlike the other fields in the issue.item template, it affects a different item (a timelog item) and not the template's item, an issue. We have a special syntax for form fields that affect items other than the template default item (see the cgi documentation on `special form variables`_). In particular, we add a field to capture a new timelog item's perdiod:: and another hidden field that links that new timelog item (new because it's marked as having id "-1") to the issue item. It looks like this:: On submission, the "-1" timelog item will be created and assigned a real item id. The "times" property of the issue will have the new id added to it. 4. We want to display a total of the time log times that have been accumulated for an issue. To do this, we'll need to actually write some Python code, since it's beyond the scope of PageTemplates to perform such calculations. We do this by adding a method to the TemplatingUtils class in our tracker ``interfaces.py`` module:: class TemplatingUtils: ''' Methods implemented on this class will be available to HTML templates through the 'utils' variable. ''' def totalTimeSpent(self, times): ''' Call me with a list of timelog items (which have an Interval "period" property) ''' total = Interval('0d') for time in times: total += time.period._value return total Replace the ``pass`` line if one appears in your TemplatingUtils class. As indicated in the docstrings, we will be able to access the ``totalTimeSpent`` method via the ``utils`` variable in our templates. 5. Display the time log for an issue::
Category
Name name
  submit button will go here

Category editing
Category
Name name
  submit button will go here
Category
Priority:
Category:
Category
Time Log
(enter as '3y 1m 4d 2:40:02' or parts thereof)
Time Log
DatePeriodLogged By
I put this just above the Messages log in my issue display. Note our use of the ``totalTimeSpent`` method which will total up the times for the issue and return a new Interval. That will be automatically displayed in the template as text like "+ 1y 2:40" (1 year, 2 hours and 40 minutes). 8. If you're using a persistent web server - roundup-server or mod_python for example - then you'll need to restart that to pick up the code changes. When that's done, you'll be able to use the new time logging interface. Tracking different types of issues ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sometimes you will want to track different types of issues - developer, customer support, systems, sales leads, etc. A single Roundup tracker is able to support multiple types of issues. This example demonstrates adding a customer support issue class to a tracker. 1. Figure out what information you're going to want to capture. OK, so this is obvious, but sometimes it's better to actually sit down for a while and think about the schema you're going to implement. 2. Add the new issue class to your tracker's ``dbinit.py`` - in this example, we're adding a "system support" class. Just after the "issue" class definition in the "open" function, add:: support = IssueClass(db, "support", assignedto=Link("user"), topic=Multilink("keyword"), status=Link("status"), deadline=Date(), affects=Multilink("system")) 3. Copy the existing "issue.*" (item, search and index) templates in the tracker's "html" to "support.*". Edit them so they use the properties defined in the "support" class. Be sure to check for hidden form variables like "required" to make sure they have the correct set of required properties. 4. Edit the modules in the "detectors", adding lines to their "init" functions where appropriate. Look for "audit" and "react" registrations on the "issue" class, and duplicate them for "support". 5. Create a new sidebar box for the new support class. Duplicate the existing issues one, changing the "issue" class name to "support". 6. Re-start your tracker and start using the new "support" class. Optionally, you might want to restrict the users able to access this new class to just the users with a new "SysAdmin" Role. To do this, we add some security declarations:: p = db.security.getPermission('View', 'support') db.security.addPermissionToRole('SysAdmin', p) p = db.security.getPermission('Edit', 'support') db.security.addPermissionToRole('SysAdmin', p) You would then (as an "admin" user) edit the details of the appropriate users, and add "SysAdmin" to their Roles list. Alternatively, you might want to change the Edit/View permissions granted for the "issue" class so that it's only available to users with the "System" or "Developer" Role, and then the new class you're adding is available to all with the "User" Role. Using External User Databases ----------------------------- Using an external password validation source ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We have a centrally-managed password changing system for our users. This results in a UN*X passwd-style file that we use for verification of users. Entries in the file consist of ``name:password`` where the password is encrypted using the standard UN*X ``crypt()`` function (see the ``crypt`` module in your Python distribution). An example entry would be:: admin:aamrgyQfDFSHw Each user of Roundup must still have their information stored in the Roundup database - we just use the passwd file to check their password. To do this, we need to override the standard ``verifyPassword`` method defined in ``roundup.cgi.actions.LoginAction`` and register the new class with our ``Client`` class in the tracker home ``interfaces.py`` module:: from roundup.cgi.actions import LoginAction class ExternalPasswordLoginAction(LoginAction): def verifyPassword(self, userid, password): # get the user's username username = self.db.user.get(userid, 'username') # the passwords are stored in the "passwd.txt" file in the # tracker home file = os.path.join(self.db.config.TRACKER_HOME, 'passwd.txt') # see if we can find a match for ent in [line.strip().split(':') for line in open(file).readlines()]: if ent[0] == username: return crypt.crypt(password, ent[1][:2]) == ent[1] # user doesn't exist in the file return 0 class Client(client.Client): actions = client.Client.actions + ( ('login', ExternalPasswordLoginAction) ) What this does is look through the file, line by line, looking for a name that matches. We also remove the redundant password fields from the ``user.item`` template. Using a UN*X passwd file as the user database ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On some systems the primary store of users is the UN*X passwd file. It holds information on users such as their username, real name, password and primary user group. Roundup can use this store as its primary source of user information, but it needs additional information too - email address(es), roundup Roles, vacation flags, roundup hyperdb item ids, etc. Also, "retired" users must still exist in the user database, unlike some passwd files in which the users are removed when they no longer have access to a system. To make use of the passwd file, we therefore synchronise between the two user stores. We also use the passwd file to validate the user logins, as described in the previous example, `using an external password validation source`_. We keep the users lists in sync using a fairly simple script that runs once a day, or several times an hour if more immediate access is needed. In short, it: 1. parses the passwd file, finding usernames, passwords and real names, 2. compares that list to the current roundup user list: a. entries no longer in the passwd file are *retired* b. entries with mismatching real names are *updated* c. entries only exist in the passwd file are *created* 3. send an email to administrators to let them know what's been done. The retiring and updating are simple operations, requiring only a call to ``retire()`` or ``set()``. The creation operation requires more information though - the user's email address and their roundup Roles. We're going to assume that the user's email address is the same as their login name, so we just append the domain name to that. The Roles are determined using the passwd group identifier - mapping their UN*X group to an appropriate set of Roles. The script to perform all this, broken up into its main components, is as follows. Firstly, we import the necessary modules and open the tracker we're to work on:: import sys, os, smtplib from roundup import instance, date # open the tracker tracker_home = sys.argv[1] tracker = instance.open(tracker_home) Next we read in the *passwd* file from the tracker home:: # read in the users file = os.path.join(tracker_home, 'users.passwd') users = [x.strip().split(':') for x in open(file).readlines()] Handle special users (those to ignore in the file, and those who don't appear in the file):: # users to not keep ever, pre-load with the users I know aren't # "real" users ignore = ['ekmmon', 'bfast', 'csrmail'] # users to keep - pre-load with the roundup-specific users keep = ['comment_pool', 'network_pool', 'admin', 'dev-team', 'cs_pool', 'anonymous', 'system_pool', 'automated'] Now we map the UN*X group numbers to the Roles that users should have:: roles = { '501': 'User,Tech', # tech '502': 'User', # finance '503': 'User,CSR', # customer service reps '504': 'User', # sales '505': 'User', # marketing } Now we do all the work. Note that the body of the script (where we have the tracker database open) is wrapped in a ``try`` / ``finally`` clause, so that we always close the database cleanly when we're finished. So, we now do all the work:: # open the database db = tracker.open('admin') try: # store away messages to send to the tracker admins msg = [] # loop over the users list read in from the passwd file for user,passw,uid,gid,real,home,shell in users: if user in ignore: # this user shouldn't appear in our tracker continue keep.append(user) try: # see if the user exists in the tracker uid = db.user.lookup(user) # yes, they do - now check the real name for correctness if real != db.user.get(uid, 'realname'): db.user.set(uid, realname=real) msg.append('FIX %s - %s'%(user, real)) except KeyError: # nope, the user doesn't exist db.user.create(username=user, realname=real, address='%s@ekit-inc.com'%user, roles=roles[gid]) msg.append('ADD %s - %s (%s)'%(user, real, roles[gid])) # now check that all the users in the tracker are also in our # "keep" list - retire those who aren't for uid in db.user.list(): user = db.user.get(uid, 'username') if user not in keep: db.user.retire(uid) msg.append('RET %s'%user) # if we did work, then send email to the tracker admins if msg: # create the email msg = '''Subject: %s user database maintenance %s '''%(db.config.TRACKER_NAME, '\n'.join(msg)) # send the email smtp = smtplib.SMTP(db.config.MAILHOST) addr = db.config.ADMIN_EMAIL smtp.sendmail(addr, addr, msg) # now we're done - commit the changes db.commit() finally: # always close the database cleanly db.close() And that's it! Using an LDAP database for user information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A script that reads users from an LDAP store using http://python-ldap.sf.net/ and then compares the list to the users in the roundup user database would be pretty easy to write. You'd then have it run once an hour / day (or on demand if you can work that into your LDAP store workflow). See the example `Using a UN*X passwd file as the user database`_ for more information about doing this. To authenticate off the LDAP store (rather than using the passwords in the roundup user database) you'd use the same python-ldap module inside an extension to the cgi interface. You'd do this by overriding the method called "verifyPassword" on the LoginAction class in your tracker's interfaces.py module (see `using an external password validation source`_). The method is implemented by default as:: def verifyPassword(self, userid, password): ''' Verify the password that the user has supplied ''' stored = self.db.user.get(self.userid, 'password') if password == stored: return 1 if not password and not stored: return 1 return 0 So you could reimplement this as something like:: def verifyPassword(self, userid, password): ''' Verify the password that the user has supplied ''' # look up some unique LDAP information about the user username = self.db.user.get(self.userid, 'username') # now verify the password supplied against the LDAP store Changes to Tracker Behaviour ---------------------------- Stop "nosy" messages going to people on vacation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When users go on vacation and set up vacation email bouncing, you'll start to see a lot of messages come back through Roundup "Fred is on vacation". Not very useful, and relatively easy to stop. 1. add a "vacation" flag to your users:: user = Class(db, "user", username=String(), password=Password(), address=String(), realname=String(), phone=String(), organisation=String(), alternate_addresses=String(), roles=String(), queries=Multilink("query"), vacation=Boolean()) 2. So that users may edit the vacation flags, add something like the following to your ``user.item`` template:: On Vacation vacation 3. edit your detector ``nosyreactor.py`` so that the ``nosyreaction()`` consists of:: def nosyreaction(db, cl, nodeid, oldvalues): users = db.user messages = db.msg # send a copy of all new messages to the nosy list for msgid in determineNewMessages(cl, nodeid, oldvalues): try: # figure the recipient ids sendto = [] seen_message = {} recipients = messages.get(msgid, 'recipients') for recipid in messages.get(msgid, 'recipients'): seen_message[recipid] = 1 # figure the author's id, and indicate they've received # the message authid = messages.get(msgid, 'author') # possibly send the message to the author, as long as # they aren't anonymous if (db.config.MESSAGES_TO_AUTHOR == 'yes' and users.get(authid, 'username') != 'anonymous'): sendto.append(authid) seen_message[authid] = 1 # now figure the nosy people who weren't recipients nosy = cl.get(nodeid, 'nosy') for nosyid in nosy: # Don't send nosy mail to the anonymous user (that # user shouldn't appear in the nosy list, but just # in case they do...) if users.get(nosyid, 'username') == 'anonymous': continue # make sure they haven't seen the message already if not seen_message.has_key(nosyid): # send it to them sendto.append(nosyid) recipients.append(nosyid) # generate a change note if oldvalues: note = cl.generateChangeNote(nodeid, oldvalues) else: note = cl.generateCreateNote(nodeid) # we have new recipients if sendto: # filter out the people on vacation sendto = [i for i in sendto if not users.get(i, 'vacation', 0)] # map userids to addresses sendto = [users.get(i, 'address') for i in sendto] # update the message's recipients list messages.set(msgid, recipients=recipients) # send the message cl.send_message(nodeid, msgid, note, sendto) except roundupdb.MessageSendError, message: raise roundupdb.DetectorError, message Note that this is the standard nosy reaction code, with the small addition of:: # filter out the people on vacation sendto = [i for i in sendto if not users.get(i, 'vacation', 0)] which filters out the users that have the vacation flag set to true. Adding in state transition control ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sometimes tracker admins want to control the states that users may move issues to. You can do this by following these steps: 1. make "status" a required variable. This is achieved by adding the following to the top of the form in the ``issue.item.html`` template:: this will force users to select a status. 2. add a Multilink property to the status class:: stat = Class(db, "status", ... , transitions=Multilink('status'), ...) and then edit the statuses already created, either: a. through the web using the class list -> status class editor, or b. using the roundup-admin "set" command. 3. add an auditor module ``checktransition.py`` in your tracker's ``detectors`` directory, for example:: def checktransition(db, cl, nodeid, newvalues): ''' Check that the desired transition is valid for the "status" property. ''' if not newvalues.has_key('status'): return current = cl.get(nodeid, 'status') new = newvalues['status'] if new == current: return ok = db.status.get(current, 'transitions') if new not in ok: raise ValueError, 'Status not allowed to move from "%s" to "%s"'%( db.status.get(current, 'name'), db.status.get(new, 'name')) def init(db): db.issue.audit('set', checktransition) 4. in the ``issue.item.html`` template, change the status editing bit from:: Status status to:: Status which displays only the allowed status to transition to. Blocking issues that depend on other issues ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We needed the ability to mark certain issues as "blockers" - that is, they can't be resolved until another issue (the blocker) they rely on is resolved. To achieve this: 1. Create a new property on the issue Class, ``blockers=Multilink("issue")``. Edit your tracker's dbinit.py file. Where the "issue" class is defined, something like:: issue = IssueClass(db, "issue", assignedto=Link("user"), topic=Multilink("keyword"), priority=Link("priority"), status=Link("status")) add the blockers entry like so:: issue = IssueClass(db, "issue", blockers=Multilink("issue"), assignedto=Link("user"), topic=Multilink("keyword"), priority=Link("priority"), status=Link("status")) 2. Add the new "blockers" property to the issue.item edit page, using something like:: Waiting On
View: You'll need to fiddle with your item page layout to find an appropriate place to put it - I'll leave that fun part up to you. Just make sure it appears in the first table, possibly somewhere near the "superseders" field. 3. Create a new detector module (attached) which enforces the rules: - issues may not be resolved if they have blockers - when a blocker is resolved, it's removed from issues it blocks The contents of the detector should be something like this:: def blockresolution(db, cl, nodeid, newvalues): ''' If the issue has blockers, don't allow it to be resolved. ''' if nodeid is None: blockers = [] else: blockers = cl.get(nodeid, 'blockers') blockers = newvalues.get('blockers', blockers) # don't do anything if there's no blockers or the status hasn't # changed if not blockers or not newvalues.has_key('status'): return # get the resolved state ID resolved_id = db.status.lookup('resolved') # format the info u = db.config.TRACKER_WEB s = ', '.join(['%s'%( u,id,id) for id in blockers]) if len(blockers) == 1: s = 'issue %s is'%s else: s = 'issues %s are'%s # ok, see if we're trying to resolve if newvalues['status'] == resolved_id: raise ValueError, "This issue can't be resolved until %s resolved."%s def resolveblockers(db, cl, nodeid, newvalues): ''' When we resolve an issue that's a blocker, remove it from the blockers list of the issue(s) it blocks. ''' if not newvalues.has_key('status'): return # get the resolved state ID resolved_id = db.status.lookup('resolved') # interesting? if newvalues['status'] != resolved_id: return # yes - find all the blocked issues, if any, and remove me from # their blockers list issues = cl.find(blockers=nodeid) for issueid in issues: blockers = cl.get(issueid, 'blockers') if nodeid in blockers: blockers.remove(nodeid) cl.set(issueid, blockers=blockers) def init(db): # might, in an obscure situation, happen in a create db.issue.audit('create', blockresolution) db.issue.audit('set', blockresolution) # can only happen on a set db.issue.react('set', resolveblockers) Put the above code in a file called "blockers.py" in your tracker's "detectors" directory. 4. Finally, and this is an optional step, modify the tracker web page URLs so they filter out issues with any blockers. You do this by adding an additional filter on "blockers" for the value "-1". For example, the existing "Show All" link in the "page" template (in the tracker's "html" directory) looks like this:: Show All
modify it to add the "blockers" info to the URL (note, both the ":filter" *and* "blockers" values must be specified):: Show All
:Note: the above examples are line-wrapped on the trailing & and should be unwrapped. That's it. You should now be able to set blockers on your issues. Note that if you want to know whether an issue has any other issues dependent on it (i.e. it's in their blockers list) you can look at the journal history at the bottom of the issue page - look for a "link" event to another issue's "blockers" property. Add users to the nosy list based on the topic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We need the ability to automatically add users to the nosy list based on the occurence of a topic. Every user should be allowed to edit his own list of topics for which he wants to be added to the nosy list. Below will be showed that such a change can be performed with only minimal understanding of the roundup system, but with clever use of Copy and Paste. This requires three changes to the tracker: a change in the database to allow per-user recording of the lists of topics for which he wants to be put on the nosy list, a change in the user view allowing to edit this list of topics, and addition of an auditor which updates the nosy list when a topic is set. Adding the nosy topic list :::::::::::::::::::::::::: The change in the database to make is that for any user there should be a list of topics for which he wants to be put on the nosy list. Adding a ``Multilink`` of ``keyword`` seem to fullfill this (note that within the code topics are called ``keywords``.) As such, all what has to be done is to add a new field to the definition of ``user`` within the file ``dbinit.py``. We will call this new field ``nosy_keywords``, and the updated definition of user will be:: user = Class(db, "user", username=String(), password=Password(), address=String(), realname=String(), phone=String(), organisation=String(), alternate_addresses=String(), queries=Multilink('query'), roles=String(), timezone=String(), nosy_keywords=Multilink('keyword')) Changing the user view to allow changing the nosy topic list :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: We want any user to be able to change the list of topics for which he will by default be added to the nosy list. We choose to add this to the user view, as is generated by the file ``html/user.item.html``. We easily can see that the topic field in the issue view has very similar editting requirements as our nosy topics, both being a list of topics. As such, we search for Topics in ``issue.item.html``, and extract the associated parts from there. We add this to ``user.item.html`` at the bottom of the list of viewed items (i.e. just below the 'Alternate E-mail addresses' in the classic template):: Nosy Topics Addition of an auditor to update the nosy list :::::::::::::::::::::::::::::::::::::::::::::: The more difficult part is the addition of the logic to actually at the users to the nosy list when it is required. The choice is made to perform this action when the topics on an item are set, including when an item is created. Here we choose to start out with a copy of the ``detectors/nosyreaction.py`` detector, which we copy to the file ``detectors/nosy_keyword_reaction.py``. This looks like a good start as it also adds users to the nosy list. A look through the code reveals that the ``nosyreaction`` function actually is sending the e-mail, which we do not need. As such, we can change the init function to:: def init(db): db.issue.audit('create', update_kw_nosy) db.issue.audit('set', update_kw_nosy) After that we rename the ``updatenosy`` function to ``update_kw_nosy``. The first two blocks of code in that function relate to settings ``current`` to a combination of the old and new nosy lists. This functionality is left in the new auditor. The following block of code, which in ``updatenosy`` handled adding the assignedto user(s) to the nosy list, should be replaced by a block of code to add the interested users to the nosy list. We choose here to loop over all new topics, than loop over all users, and assign the user to the nosy list when the topic in the user's nosy_keywords. The next part in ``updatenosy``, adding the author and/or recipients of a message to the nosy list, obviously is not relevant here and thus is deleted from the new auditor. The last part, copying the new nosy list to newvalues, does not have to be changed. This brings the following function:: def update_kw_nosy(db, cl, nodeid, newvalues): '''Update the nosy list for changes to the topics ''' # nodeid will be None if this is a new node current = {} if nodeid is None: ok = ('new', 'yes') else: ok = ('yes',) # old node, get the current values from the node if they haven't # changed if not newvalues.has_key('nosy'): nosy = cl.get(nodeid, 'nosy') for value in nosy: if not current.has_key(value): current[value] = 1 # if the nosy list changed in this transaction, init from the new value if newvalues.has_key('nosy'): nosy = newvalues.get('nosy', []) for value in nosy: if not db.hasnode('user', value): continue if not current.has_key(value): current[value] = 1 # add users with topic in nosy_keywords to the nosy list if newvalues.has_key('topic') and newvalues['topic'] is not None: topic_ids = newvalues['topic'] for topic in topic_ids: # loop over all users, # and assign user to nosy when topic in nosy_keywords for user_id in db.user.list(): nosy_kw = db.user.get(user_id, "nosy_keywords") found = 0 for kw in nosy_kw: if kw == topic: found = 1 if found: current[user_id] = 1 # that's it, save off the new nosy list newvalues['nosy'] = current.keys() and these two function are the only ones needed in the file. TODO: update this example to use the find() Class method. Caveats ::::::: A few problems with the design here can be noted: Multiple additions When a user, after automatic selection, is manually removed from the nosy list, he again is added to the nosy list when the topic list of the issue is updated. A better design might be to only check which topics are new compared to the old list of topics, and only add users when they have indicated interest on a new topic. The code could also be changed to only trigger on the create() event, rather than also on the set() event, thus only setting the nosy list when the issue is created. Scalability In the auditor there is a loop over all users. For a site with only few users this will pose no serious problem, however, with many users this will be a serious performance bottleneck. A way out will be to link from the topics to the users which selected these topics a nosy topics. This will eliminate the loop over all users. Changes to Security and Permissions ----------------------------------- Restricting the list of users that are assignable to a task ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. In your tracker's "dbinit.py", create a new Role, say "Developer":: db.security.addRole(name='Developer', description='A developer') 2. Just after that, create a new Permission, say "Fixer", specific to "issue":: p = db.security.addPermission(name='Fixer', klass='issue', description='User is allowed to be assigned to fix issues') 3. Then assign the new Permission to your "Developer" Role:: db.security.addPermissionToRole('Developer', p) 4. In the issue item edit page ("html/issue.item.html" in your tracker directory), use the new Permission in restricting the "assignedto" list:: For extra security, you may wish to setup an auditor to enforce the Permission requirement (install this as "assignedtoFixer.py" in your tracker "detectors" directory):: def assignedtoMustBeFixer(db, cl, nodeid, newvalues): ''' Ensure the assignedto value in newvalues is a used with the Fixer Permission ''' if not newvalues.has_key('assignedto'): # don't care return # get the userid userid = newvalues['assignedto'] if not db.security.hasPermission('Fixer', userid, cl.classname): raise ValueError, 'You do not have permission to edit %s'%cl.classname def init(db): db.issue.audit('set', assignedtoMustBeFixer) db.issue.audit('create', assignedtoMustBeFixer) So now, if an edit action attempts to set "assignedto" to a user that doesn't have the "Fixer" Permission, the error will be raised. Users may only edit their issues ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Users registering themselves are granted Provisional access - meaning they have access to edit the issues they submit, but not others. We create a new Role called "Provisional User" which is granted to newly-registered users, and has limited access. One of the Permissions they have is the new "Edit Own" on issues (regular users have "Edit".) We back up the permissions with an auditor. First up, we create the new Role and Permission structure in ``dbinit.py``:: # New users not approved by the admin db.security.addRole(name='Provisional User', description='New user registered via web or email') p = db.security.addPermission(name='Edit Own', klass='issue', description='Can only edit own issues') db.security.addPermissionToRole('Provisional User', p) # Assign the access and edit Permissions for issue to new users now p = db.security.getPermission('View', 'issue') db.security.addPermissionToRole('Provisional User', p) p = db.security.getPermission('Edit', 'issue') db.security.addPermissionToRole('Provisional User', p) # and give the new users access to the web and email interface p = db.security.getPermission('Web Access') db.security.addPermissionToRole('Provisional User', p) p = db.security.getPermission('Email Access') db.security.addPermissionToRole('Provisional User', p) Then in the ``config.py`` we change the Role assigned to newly-registered users, replacing the existing ``'User'`` values:: NEW_WEB_USER_ROLES = 'Provisional User' NEW_EMAIL_USER_ROLES = 'Provisional User' Finally we add a new *auditor* to the ``detectors`` directory called ``provisional_user_auditor.py``:: def audit_provisionaluser(db, cl, nodeid, newvalues): ''' New users are only allowed to modify their own issues. ''' if (db.getuid() != cl.get(nodeid, 'creator') and db.security.hasPermission('Edit Own', db.getuid(), cl.classname)): raise ValueError, ('You are only allowed to edit your own %s' % cl.classname) def init(db): # fire before changes are made db.issue.audit('set', audit_provisionaluser) db.issue.audit('retire', audit_provisionaluser) db.issue.audit('restore', audit_provisionaluser) Note that some older trackers might also want to change the ``page.html`` template as follows::

+ tal:condition="python:request.user.hasPermission('View', 'user')"> Administration
Class List
(note that the "-" indicates a removed line, and the "+" indicates an added line). Changes to the Web User Interface --------------------------------- Adding action links to the index page ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Add a column to the item.index.html template. Resolving the issue:: resolve "Take" the issue:: take ... and so on Colouring the rows in the issue index according to priority ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A simple ``tal:attributes`` statement will do the bulk of the work here. In the ``issue.index.html`` template, add to the ```` that displays the actual rows of data:: and then in your stylesheet (``style.css``) specify the colouring for the different priorities, like:: tr.priority-critical td { background-color: red; } tr.priority-urgent td { background-color: orange; } and so on, with far less offensive colours :) Editing multiple items in an index view ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To edit the status of all items in the item index view, edit the ``issue.item.html``: 1. add a form around the listing table, so at the top it reads::

and at the bottom of that table::
`` from the list table, not the navigation table or the subsequent form table. 2. in the display for the issue property, change::   to::   this will result in an edit field for the status property. 3. after the ``tal:block`` which lists the actual index items (marked by ``tal:repeat="i batch"``) add a new table row:: which gives us a submit button, indicates that we are performing an edit on any changed statuses and the final block will make sure that the current index view parameters (filtering, columns, etc) will be used in rendering the next page (the results of the editing). Displaying only message summaries in the issue display ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Alter the issue.item template section for messages to::
Messages
author date summary remove
Enabling display of either message summaries or the entire messages ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is pretty simple - all we need to do is copy the code from the example `displaying only message summaries in the issue display`_ into our template alongside the summary display, and then introduce a switch that shows either one or the other. We'll use a new form variable, ``@whole_messages`` to achieve this::
Messages show entire messages
author date summary remove
Messages show only summaries
author date (remove)
Setting up a "wizard" (or "druid") for controlled adding of issues ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Set up the page templates you wish to use for data input. My wizard is going to be a two-step process: first figuring out what category of issue the user is submitting, and then getting details specific to that category. The first page includes a table of help, explaining what the category names mean, and then the core of the form::
Category: The next page has the usual issue entry information, with the addition of the following form fragments::
. . .
Note that later in the form, I test the value of "cat" include form elements that are appropriate. For example:: Operating System Web Browser ... the above section will only be displayed if the category is one of 6, 10, 13, 14, 15, 16 or 17. 3. Determine what actions need to be taken between the pages - these are usually to validate user choices and determine what page is next. Now encode those actions in a new ``Action`` class and insert hooks to those actions in the "actions" attribute on on the ``interfaces.Client`` class, like so (see `defining new web actions`_):: class Page1SubmitAction(Action): def handle(self): ''' Verify that the user has selected a category, and then move on to page 2. ''' category = self.form['category'].value if category == '-1': self.error_message.append('You must select a category of report') return # everything's ok, move on to the next page self.template = 'add_page2' actions = client.Client.actions + ( ('page1_submit', Page1SubmitAction), ) 4. Use the usual "new" action as the ``@action`` on the final page, and you're done (the standard context/submit method can do this for you). ------------------- Back to `Table of Contents`_ .. _`Table of Contents`: index.html .. _`design documentation`: design.html code-0e2a0c2c8142/doc/debugging.txt0000644000000000000000000000154410062724152015076 0ustar 00000000000000Debugging Flags --------------- Roundup uses a number of debugging environment variables to help you figure out what the heck it's doing. HYPERDBDEBUG ============ This environment variable should be set to a filename - the hyperdb will write debugging information for various events (including, for instance, the SQL used). This is only obeyed when python is _not_ running in -O mode. HYPERDBTRACE ============ This environment variable should be set to a filename - the hyperdb will write a timestamp entry for various events. This appears to be suffering rather extreme bit-rot and may go away soon. This is only obeyed when python is _not_ running in -O mode. SENDMAILDEBUG ============= Set to a filename and roundup will write a copy of each email message that it sends to that file. This environment variable is independent of the python -O flag. code-0e2a0c2c8142/doc/default.css0000644000000000000000000000757610062724152014553 0ustar 00000000000000/* :Author: David Goodger :Contact: goodger@users.sourceforge.net :date: $Date: 2004-06-09 00:25:32 $ :version: $Revision: 1.13 $ :copyright: This stylesheet has been placed in the public domain. Default cascading style sheet for the HTML output of Docutils. */ a.target { color: blue } a.toc-backref { text-decoration: none ; color: black } dd { margin-bottom: 0.5em } div.abstract { margin: 2em 5em } div.abstract p.topic-title { font-weight: bold ; text-align: center } div.attention, div.caution, div.danger, div.error, div.important, div.tip, div.warning { margin: 2em ; border: medium outset ; padding: 1em } div.hint, div.note { font-size: 80%; float: right; width: 15em; margin: 0.5em; margin-left: 1em ; border: solid #aaa; background: #eee; padding: 1em; } div.attention p.admonition-title, div.caution p.admonition-title, div.danger p.admonition-title, div.error p.admonition-title, div.warning p.admonition-title { color: red ; font-weight: bold ; font-family: sans-serif } div.hint p.admonition-title, div.important p.admonition-title, div.note p.admonition-title, div.tip p.admonition-title { font-weight: bold ; font-family: sans-serif } div.dedication { margin: 2em 5em ; text-align: center ; font-style: italic } div.dedication p.topic-title { font-weight: bold ; font-style: normal } div.figure { margin-left: 2em } div.footer, div.header { font-size: smaller } div.system-messages { margin: 5em } div.system-messages h1 { color: red } div.system-message { border: medium outset ; padding: 1em } div.system-message p.system-message-title { color: red ; font-weight: bold } div.topic { margin: 2em } h1 { margin-top: 2em; text-decoration: underline; } h1.title { text-align: center; margin-top: .5em; } h2.subtitle { text-align: center } hr { width: 75% } ol.simple, ul.simple { margin-top: 0; margin-bottom: 1em } ol.arabic { list-style: decimal } ol.loweralpha { list-style: lower-alpha } ol.upperalpha { list-style: upper-alpha } ol.lowerroman { list-style: lower-roman } ol.upperroman { list-style: upper-roman } p.caption { font-style: italic } p.credits { font-style: italic ; font-size: smaller } p.first { margin-top: 0 } p.label { white-space: nowrap } p.topic-title { font-weight: bold } pre.address { margin-bottom: 0 ; margin-top: 0 ; font-family: serif ; font-size: 100% } pre.line-block { font-family: serif ; font-size: 100% } pre.literal-block, pre.doctest-block { margin-left: 2em ; margin-right: 2em ; background-color: #eeeeee } span.classifier { font-family: sans-serif ; font-style: oblique } span.classifier-delimiter { font-family: sans-serif ; font-weight: bold } span.field-argument { font-style: italic } span.interpreted { font-family: sans-serif } span.option-argument { font-style: italic } span.pre { white-space: pre } span.problematic { color: red } table { margin-top: 0.5em ; margin-bottom: 0.5em ; } table.citation { border-top: 0; border-bottom: 0; border-right: 0; border-left: solid thin gray ; padding-left: 0.5ex } table.docinfo { margin: 2em 4em } table.footnote { border-left: solid thin black ; padding-left: 0.5ex } td, th { padding-left: 0.5em ; padding-right: 0.5em ; vertical-align: baseline; } table.table { border-spacing: 0px; border-collapse: separate; } table.table td { text-align: left; border: solid thin gray; } table.table th { text-align: left; border: solid thin gray; } td > p:first-child, th > p:first-child { margin-top: 0em } th.docinfo-name { font-weight: bold ; text-align: right } th.field-name { font-weight: bold ; text-align: right } h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt { font-size: 100% } tt { background-color: #eeeeee } tt.literal span.pre { background-color: #eeeeee } ul.auto-toc { list-style-type: none } code-0e2a0c2c8142/doc/design.txt0000644000000000000000000016634210062724152014424 0ustar 00000000000000======================================================== Roundup - An Issue-Tracking System for Knowledge Workers ======================================================== :Authors: Ka-Ping Yee (original__), Richard Jones (implementation) __ spec.html .. contents:: Introduction --------------- This document presents a description of the components of the Roundup system and specifies their interfaces and behaviour in sufficient detail to guide an implementation. For the philosophy and rationale behind the Roundup design, see the first-round Software Carpentry submission for Roundup. This document fleshes out that design as well as specifying interfaces so that the components can be developed separately. The Layer Cake ----------------- Lots of software design documents come with a picture of a cake. Everybody seems to like them. I also like cakes (i think they are tasty). So I, too, shall include a picture of a cake here:: ________________________________________________________________ | E-mail Client | Web Browser | Detector Scripts | Shell | |---------------+---------------+--------------------+-----------| | E-mail User | Web User | Detector | Command | |----------------------------------------------------------------| | Roundup Database Layer | |----------------------------------------------------------------| | Hyperdatabase Layer | |----------------------------------------------------------------| | Storage Layer | ---------------------------------------------------------------- The colourful parts of the cake are part of our system; the faint grey parts of the cake are external components. I will now proceed to forgo all table manners and eat from the bottom of the cake to the top. You may want to stand back a bit so you don't get covered in crumbs. Hyperdatabase ------------- The lowest-level component to be implemented is the hyperdatabase. The hyperdatabase is intended to be a flexible data store that can hold configurable data in records which we call items. The hyperdatabase is implemented on top of the storage layer, an external module for storing its data. The storage layer could be a third-party RDBMS; for a "batteries-included" distribution, implementing the hyperdatabase on the standard bsddb module is suggested. Dates and Date Arithmetic ~~~~~~~~~~~~~~~~~~~~~~~~~ Before we get into the hyperdatabase itself, we need a way of handling dates. The hyperdatabase module provides Timestamp objects for representing date-and-time stamps and Interval objects for representing date-and-time intervals. As strings, date-and-time stamps are specified with the date in international standard format (``yyyy-mm-dd``) joined to the time (``hh:mm:ss``) by a period "``.``". Dates in this form can be easily compared and are fairly readable when printed. An example of a valid stamp is "``2000-06-24.13:03:59``". We'll call this the "full date format". When Timestamp objects are printed as strings, they appear in the full date format with the time always given in GMT. The full date format is always exactly 19 characters long. For user input, some partial forms are also permitted: the whole time or just the seconds may be omitted; and the whole date may be omitted or just the year may be omitted. If the time is given, the time is interpreted in the user's local time zone. The Date constructor takes care of these conversions. In the following examples, suppose that ``yyyy`` is the current year, ``mm`` is the current month, and ``dd`` is the current day of the month; and suppose that the user is on Eastern Standard Time. - "2000-04-17" means - "01-25" means - "2000-04-17.03:45" means - "08-13.22:13" means - "11-07.09:32:43" means - "14:25" means - - "8:47:11" means - - the special date "." means "right now" Date intervals are specified using the suffixes "y", "m", and "d". The suffix "w" (for "week") means 7 days. Time intervals are specified in hh:mm:ss format (the seconds may be omitted, but the hours and minutes may not). - "3y" means three years - "2y 1m" means two years and one month - "1m 25d" means one month and 25 days - "2w 3d" means two weeks and three days - "1d 2:50" means one day, two hours, and 50 minutes - "14:00" means 14 hours - "0:04:33" means four minutes and 33 seconds The Date class should understand simple date expressions of the form *stamp* ``+`` *interval* and *stamp* ``-`` *interval*. When adding or subtracting intervals involving months or years, the components are handled separately. For example, when evaluating "``2000-06-25 + 1m 10d``", we first add one month to get 2000-07-25, then add 10 days to get 2000-08-04 (rather than trying to decide whether 1m 10d means 38 or 40 or 41 days). Here is an outline of the Date and Interval classes:: class Date: def __init__(self, spec, offset): """Construct a date given a specification and a time zone offset. 'spec' is a full date or a partial form, with an optional added or subtracted interval. 'offset' is the local time zone offset from GMT in hours. """ def __add__(self, interval): """Add an interval to this date to produce another date.""" def __sub__(self, interval): """Subtract an interval from this date to produce another date. """ def __cmp__(self, other): """Compare this date to another date.""" def __str__(self): """Return this date as a string in the yyyy-mm-dd.hh:mm:ss format. """ def local(self, offset): """Return this date as yyyy-mm-dd.hh:mm:ss in a local time zone. """ class Interval: def __init__(self, spec): """Construct an interval given a specification.""" def __cmp__(self, other): """Compare this interval to another interval.""" def __str__(self): """Return this interval as a string.""" Here are some examples of how these classes would behave in practice. For the following examples, assume that we are on Eastern Standard Time and the current local time is 19:34:02 on 25 June 2000:: >>> Date(".") >>> _.local(-5) "2000-06-25.19:34:02" >>> Date(". + 2d") >>> Date("1997-04-17", -5) >>> Date("01-25", -5) >>> Date("08-13.22:13", -5) >>> Date("14:25", -5) >>> Interval(" 3w 1 d 2:00") >>> Date(". + 2d") - Interval("3w") Items and Classes ~~~~~~~~~~~~~~~~~ Items contain data in properties. To Python, these properties are presented as the key-value pairs of a dictionary. Each item belongs to a class which defines the names and types of its properties. The database permits the creation and modification of classes as well as items. Identifiers and Designators ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Each item has a numeric identifier which is unique among items in its class. The items are numbered sequentially within each class in order of creation, starting from 1. The designator for an item is a way to identify an item in the database, and consists of the name of the item's class concatenated with the item's numeric identifier. For example, if "spam" and "eggs" are classes, the first item created in class "spam" has id 1 and designator "spam1". The first item created in class "eggs" also has id 1 but has the distinct designator "eggs1". Item designators are conventionally enclosed in square brackets when mentioned in plain text. This permits a casual mention of, say, "[patch37]" in an e-mail message to be turned into an active hyperlink. Property Names and Types ~~~~~~~~~~~~~~~~~~~~~~~~ Property names must begin with a letter. A property may be one of five basic types: - String properties are for storing arbitrary-length strings. - Boolean properties are for storing true/false, or yes/no values. - Number properties are for storing numeric values. - Date properties store date-and-time stamps. Their values are Timestamp objects. - A Link property refers to a single other item selected from a specified class. The class is part of the property; the value is an integer, the id of the chosen item. - A Multilink property refers to possibly many items in a specified class. The value is a list of integers. *None* is also a permitted value for any of these property types. An attempt to store None into a Multilink property stores an empty list. A property that is not specified will return as None from a *get* operation. Hyperdb Interface Specification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ TODO: replace the Interface Specifications with links to the pydoc The hyperdb module provides property objects to designate the different kinds of properties. These objects are used when specifying what properties belong in classes:: class String: def __init__(self, indexme='no'): """An object designating a String property.""" class Boolean: def __init__(self): """An object designating a Boolean property.""" class Number: def __init__(self): """An object designating a Number property.""" class Date: def __init__(self): """An object designating a Date property.""" class Link: def __init__(self, classname, do_journal='yes'): """An object designating a Link property that links to items in a specified class. If the do_journal argument is not 'yes' then changes to the property are not journalled in the linked item. """ class Multilink: def __init__(self, classname, do_journal='yes'): """An object designating a Multilink property that links to items in a specified class. If the do_journal argument is not 'yes' then changes to the property are not journalled in the linked item(s). """ Here is the interface provided by the hyperdatabase:: class Database: """A database for storing records containing flexible data types. """ def __init__(self, config, journaltag=None): """Open a hyperdatabase given a specifier to some storage. The 'storagelocator' is obtained from config.DATABASE. The meaning of 'storagelocator' depends on the particular implementation of the hyperdatabase. It could be a file name, a directory path, a socket descriptor for a connection to a database over the network, etc. The 'journaltag' is a token that will be attached to the journal entries for any edits done on the database. If 'journaltag' is None, the database is opened in read-only mode: the Class.create(), Class.set(), Class.retire(), and Class.restore() methods are disabled. """ def __getattr__(self, classname): """A convenient way of calling self.getclass(classname).""" def getclasses(self): """Return a list of the names of all existing classes.""" def getclass(self, classname): """Get the Class object representing a particular class. If 'classname' is not a valid class name, a KeyError is raised. """ class Class: """The handle to a particular class of items in a hyperdatabase. """ def __init__(self, db, classname, **properties): """Create a new class with a given name and property specification. 'classname' must not collide with the name of an existing class, or a ValueError is raised. The keyword arguments in 'properties' must map names to property objects, or a TypeError is raised. A proxied reference to the database is available as the 'db' attribute on instances. For example, in 'IssueClass.send_message', the following is used to lookup users, messages and files:: users = self.db.user messages = self.db.msg files = self.db.file """ # Editing items: def create(self, **propvalues): """Create a new item of this class and return its id. The keyword arguments in 'propvalues' map property names to values. The values of arguments must be acceptable for the types of their corresponding properties or a TypeError is raised. If this class has a key property, it must be present and its value must not collide with other key strings or a ValueError is raised. Any other properties on this class that are missing from the 'propvalues' dictionary are set to None. If an id in a link or multilink property does not refer to a valid item, an IndexError is raised. """ def get(self, itemid, propname): """Get the value of a property on an existing item of this class. 'itemid' must be the id of an existing item of this class or an IndexError is raised. 'propname' must be the name of a property of this class or a KeyError is raised. """ def set(self, itemid, **propvalues): """Modify a property on an existing item of this class. 'itemid' must be the id of an existing item of this class or an IndexError is raised. Each key in 'propvalues' must be the name of a property of this class or a KeyError is raised. All values in 'propvalues' must be acceptable types for their corresponding properties or a TypeError is raised. If the value of the key property is set, it must not collide with other key strings or a ValueError is raised. If the value of a Link or Multilink property contains an invalid item id, a ValueError is raised. """ def retire(self, itemid): """Retire an item. The properties on the item remain available from the get() method, and the item's id is never reused. Retired items are not returned by the find(), list(), or lookup() methods, and other items may reuse the values of their key properties. """ def restore(self, nodeid): '''Restore a retired node. Make node available for all operations like it was before retirement. ''' def history(self, itemid): """Retrieve the journal of edits on a particular item. 'itemid' must be the id of an existing item of this class or an IndexError is raised. The returned list contains tuples of the form (date, tag, action, params) 'date' is a Timestamp object specifying the time of the change and 'tag' is the journaltag specified when the database was opened. 'action' may be: 'create' or 'set' -- 'params' is a dictionary of property values 'link' or 'unlink' -- 'params' is (classname, itemid, propname) 'retire' -- 'params' is None """ # Locating items: def setkey(self, propname): """Select a String property of this class to be the key property. 'propname' must be the name of a String property of this class or None, or a TypeError is raised. The values of the key property on all existing items must be unique or a ValueError is raised. """ def getkey(self): """Return the name of the key property for this class or None. """ def lookup(self, keyvalue): """Locate a particular item by its key property and return its id. If this class has no key property, a TypeError is raised. If the 'keyvalue' matches one of the values for the key property among the items in this class, the matching item's id is returned; otherwise a KeyError is raised. """ def find(self, propname, itemid): """Get the ids of items in this class which link to the given items. 'propspec' consists of keyword args propname={itemid:1,} 'propname' must be the name of a property in this class, or a KeyError is raised. That property must be a Link or Multilink property, or a TypeError is raised. Any item in this class whose 'propname' property links to any of the itemids will be returned. Used by the full text indexing, which knows that "foo" occurs in msg1, msg3 and file7, so we have hits on these issues: db.issue.find(messages={'1':1,'3':1}, files={'7':1}) """ def filter(self, search_matches, filterspec, sort, group): """ Return a list of the ids of the active items in this class that match the 'filter' spec, sorted by the group spec and then the sort spec. """ def list(self): """Return a list of the ids of the active items in this class. """ def count(self): """Get the number of items in this class. If the returned integer is 'numitems', the ids of all the items in this class run from 1 to numitems, and numitems+1 will be the id of the next item to be created in this class. """ # Manipulating properties: def getprops(self): """Return a dictionary mapping property names to property objects. """ def addprop(self, **properties): """Add properties to this class. The keyword arguments in 'properties' must map names to property objects, or a TypeError is raised. None of the keys in 'properties' may collide with the names of existing properties, or a ValueError is raised before any properties have been added. """ def getitem(self, itemid, cache=1): """ Return a Item convenience wrapper for the item. 'itemid' must be the id of an existing item of this class or an IndexError is raised. 'cache' indicates whether the transaction cache should be queried for the item. If the item has been modified and you need to determine what its values prior to modification are, you need to set cache=0. """ class Item: """ A convenience wrapper for the given item. It provides a mapping interface to a single item's properties """ Hyperdatabase Implementations ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hyperdatabase implementations exist to create the interface described in the `hyperdb interface specification`_ over an existing storage mechanism. Examples are relational databases, \*dbm key-value databases, and so on. Several implementations are provided - they belong in the ``roundup.backends`` package. Application Example ~~~~~~~~~~~~~~~~~~~ Here is an example of how the hyperdatabase module would work in practice:: >>> import hyperdb >>> db = hyperdb.Database("foo.db", "ping") >>> db >>> hyperdb.Class(db, "status", name=hyperdb.String()) >>> _.setkey("name") >>> db.status.create(name="unread") 1 >>> db.status.create(name="in-progress") 2 >>> db.status.create(name="testing") 3 >>> db.status.create(name="resolved") 4 >>> db.status.count() 4 >>> db.status.list() [1, 2, 3, 4] >>> db.status.lookup("in-progress") 2 >>> db.status.retire(3) >>> db.status.list() [1, 2, 4] >>> hyperdb.Class(db, "issue", title=hyperdb.String(), status=hyperdb.Link("status")) >>> db.issue.create(title="spam", status=1) 1 >>> db.issue.create(title="eggs", status=2) 2 >>> db.issue.create(title="ham", status=4) 3 >>> db.issue.create(title="arguments", status=2) 4 >>> db.issue.create(title="abuse", status=1) 5 >>> hyperdb.Class(db, "user", username=hyperdb.Key(), ... password=hyperdb.String()) >>> db.issue.addprop(fixer=hyperdb.Link("user")) >>> db.issue.getprops() {"title": , "status": , "user": } >>> db.issue.set(5, status=2) >>> db.issue.get(5, "status") 2 >>> db.status.get(2, "name") "in-progress" >>> db.issue.get(5, "title") "abuse" >>> db.issue.find("status", db.status.lookup("in-progress")) [2, 4, 5] >>> db.issue.history(5) [(, "ping", "create", {"title": "abuse", "status": 1}), (, "ping", "set", {"status": 2})] >>> db.status.history(1) [(, "ping", "link", ("issue", 5, "status")), (, "ping", "unlink", ("issue", 5, "status"))] >>> db.status.history(2) [(, "ping", "link", ("issue", 5, "status"))] For the purposes of journalling, when a Multilink property is set to a new list of items, the hyperdatabase compares the old list to the new list. The journal records "unlink" events for all the items that appear in the old list but not the new list, and "link" events for all the items that appear in the new list but not in the old list. Roundup Database ---------------- The Roundup database layer is implemented on top of the hyperdatabase and mediates calls to the database. Some of the classes in the Roundup database are considered issue classes. The Roundup database layer adds detectors and user items, and on issues it provides mail spools, nosy lists, and superseders. Reserved Classes ~~~~~~~~~~~~~~~~ Internal to this layer we reserve three special classes of items that are not issues. Users """"" Users are stored in the hyperdatabase as items of class "user". The "user" class has the definition:: hyperdb.Class(db, "user", username=hyperdb.String(), password=hyperdb.String(), address=hyperdb.String()) db.user.setkey("username") Messages """""""" E-mail messages are represented by hyperdatabase items of class "msg". The actual text content of the messages is stored in separate files. (There's no advantage to be gained by stuffing them into the hyperdatabase, and if messages are stored in ordinary text files, they can be grepped from the command line.) The text of a message is saved in a file named after the message item designator (e.g. "msg23") for the sake of the command interface (see below). Attachments are stored separately and associated with "file" items. The "msg" class has the definition:: hyperdb.Class(db, "msg", author=hyperdb.Link("user"), recipients=hyperdb.Multilink("user"), date=hyperdb.Date(), summary=hyperdb.String(), files=hyperdb.Multilink("file")) The "author" property indicates the author of the message (a "user" item must exist in the hyperdatabase for any messages that are stored in the system). The "summary" property contains a summary of the message for display in a message index. Files """"" Submitted files are represented by hyperdatabase items of class "file". Like e-mail messages, the file content is stored in files outside the database, named after the file item designator (e.g. "file17"). The "file" class has the definition:: hyperdb.Class(db, "file", user=hyperdb.Link("user"), name=hyperdb.String(), type=hyperdb.String()) The "user" property indicates the user who submitted the file, the "name" property holds the original name of the file, and the "type" property holds the MIME type of the file as received. Issue Classes ~~~~~~~~~~~~~ All issues have the following standard properties: =========== ========================== Property Definition =========== ========================== title hyperdb.String() messages hyperdb.Multilink("msg") files hyperdb.Multilink("file") nosy hyperdb.Multilink("user") superseder hyperdb.Multilink("issue") =========== ========================== Also, two Date properties named "creation" and "activity" are fabricated by the Roundup database layer. Two user Link properties, "creator" and "actor" are also fabricated. By "fabricated" we mean that no such properties are actually stored in the hyperdatabase, but when properties on issues are requested, the "creation"/"creator" and "activity"/"actor" properties are made available. The value of the "creation"/"creator" properties relate to issue creation, and the value of the "activity"/ "actor" properties relate to the last editing of any property on the issue (equivalently, these are the dates on the first and last records in the issue's journal). Roundupdb Interface Specification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The interface to a Roundup database delegates most method calls to the hyperdatabase, except for the following changes and additional methods:: class Database: def getuid(self): """Return the id of the "user" item associated with the user that owns this connection to the hyperdatabase.""" class Class: # Overridden methods: def create(self, **propvalues): def set(self, **propvalues): def retire(self, itemid): """These operations trigger detectors and can be vetoed. Attempts to modify the "creation", "creator", "activity" properties or "actor" cause a KeyError. """ # New methods: def audit(self, event, detector): def react(self, event, detector): """Register a detector (see below for more details).""" class IssueClass(Class): # Overridden methods: def __init__(self, db, classname, **properties): """The newly-created class automatically includes the "messages", "files", "nosy", and "superseder" properties. If the 'properties' dictionary attempts to specify any of these properties or a "creation", "creator", "activity" or "actor" property, a ValueError is raised.""" def get(self, itemid, propname): def getprops(self): """In addition to the actual properties on the item, these methods provide the "creation", "creator", "activity" and "actor" properties.""" # New methods: def addmessage(self, itemid, summary, text): """Add a message to an issue's mail spool. A new "msg" item is constructed using the current date, the user that owns the database connection as the author, and the specified summary text. The "files" and "recipients" fields are left empty. The given text is saved as the body of the message and the item is appended to the "messages" field of the specified issue. """ def nosymessage(self, itemid, msgid): """Send a message to the members of an issue's nosy list. The message is sent only to users on the nosy list who are not already on the "recipients" list for the message. These users are then added to the message's "recipients" list. """ Default Schema ~~~~~~~~~~~~~~ The default schema included with Roundup turns it into a typical software bug tracker. The database is set up like this:: pri = Class(db, "priority", name=hyperdb.String(), order=hyperdb.String()) pri.setkey("name") pri.create(name="critical", order="1") pri.create(name="urgent", order="2") pri.create(name="bug", order="3") pri.create(name="feature", order="4") pri.create(name="wish", order="5") stat = Class(db, "status", name=hyperdb.String(), order=hyperdb.String()) stat.setkey("name") stat.create(name="unread", order="1") stat.create(name="deferred", order="2") stat.create(name="chatting", order="3") stat.create(name="need-eg", order="4") stat.create(name="in-progress", order="5") stat.create(name="testing", order="6") stat.create(name="done-cbb", order="7") stat.create(name="resolved", order="8") Class(db, "keyword", name=hyperdb.String()) Class(db, "issue", fixer=hyperdb.Multilink("user"), topic=hyperdb.Multilink("keyword"), priority=hyperdb.Link("priority"), status=hyperdb.Link("status")) (The "order" property hasn't been explained yet. It gets used by the Web user interface for sorting.) The above isn't as pretty-looking as the schema specification in the first-stage submission, but it could be made just as easy with the addition of a convenience function like Choice for setting up the "priority" and "status" classes:: def Choice(name, *options): cl = Class(db, name, name=hyperdb.String(), order=hyperdb.String()) for i in range(len(options)): cl.create(name=option[i], order=i) return hyperdb.Link(name) Detector Interface ------------------ Detectors are Python functions that are triggered on certain kinds of events. The definitions of the functions live in Python modules placed in a directory set aside for this purpose. Importing the Roundup database module also imports all the modules in this directory, and the ``init()`` function of each module is called when a database is opened to provide it a chance to register its detectors. There are two kinds of detectors: 1. an auditor is triggered just before modifying an item 2. a reactor is triggered just after an item has been modified When the Roundup database is about to perform a ``create()``, ``set()``, ``retire()``, or ``restore`` operation, it first calls any *auditors* that have been registered for that operation on that class. Any auditor may raise a *Reject* exception to abort the operation. If none of the auditors raises an exception, the database proceeds to carry out the operation. After it's done, it then calls all of the *reactors* that have been registered for the operation. Detector Interface Specification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The ``audit()`` and ``react()`` methods register detectors on a given class of items:: class Class: def audit(self, event, detector): """Register an auditor on this class. 'event' should be one of "create", "set", "retire", or "restore". 'detector' should be a function accepting four arguments. """ def react(self, event, detector): """Register a reactor on this class. 'event' should be one of "create", "set", "retire", or "restore". 'detector' should be a function accepting four arguments. """ Auditors are called with the arguments:: audit(db, cl, itemid, newdata) where ``db`` is the database, ``cl`` is an instance of Class or IssueClass within the database, and ``newdata`` is a dictionary mapping property names to values. For a ``create()`` operation, the ``itemid`` argument is None and newdata contains all of the initial property values with which the item is about to be created. For a ``set()`` operation, newdata contains only the names and values of properties that are about to be changed. For a ``retire()`` or ``restore()`` operation, newdata is None. Reactors are called with the arguments:: react(db, cl, itemid, olddata) where ``db`` is the database, ``cl`` is an instance of Class or IssueClass within the database, and ``olddata`` is a dictionary mapping property names to values. For a ``create()`` operation, the ``itemid`` argument is the id of the newly-created item and ``olddata`` is None. For a ``set()`` operation, ``olddata`` contains the names and previous values of properties that were changed. For a ``retire()`` or ``restore()`` operation, ``itemid`` is the id of the retired or restored item and ``olddata`` is None. Detector Example ~~~~~~~~~~~~~~~~ Here is an example of detectors written for a hypothetical project-management application, where users can signal approval of a project by adding themselves to an "approvals" list, and a project proceeds when it has three approvals:: # Permit users only to add themselves to the "approvals" list. def check_approvals(db, cl, id, newdata): if newdata.has_key("approvals"): if cl.get(id, "status") == db.status.lookup("approved"): raise Reject, "You can't modify the approvals list " \ "for a project that has already been approved." old = cl.get(id, "approvals") new = newdata["approvals"] for uid in old: if uid not in new and uid != db.getuid(): raise Reject, "You can't remove other users from " \ "the approvals list; you can only remove " \ "yourself." for uid in new: if uid not in old and uid != db.getuid(): raise Reject, "You can't add other users to the " \ "approvals list; you can only add yourself." # When three people have approved a project, change its status from # "pending" to "approved". def approve_project(db, cl, id, olddata): if (olddata.has_key("approvals") and len(cl.get(id, "approvals")) == 3): if cl.get(id, "status") == db.status.lookup("pending"): cl.set(id, status=db.status.lookup("approved")) def init(db): db.project.audit("set", check_approval) db.project.react("set", approve_project) Here is another example of a detector that can allow or prevent the creation of new items. In this scenario, patches for a software project are submitted by sending in e-mail with an attached file, and we want to ensure that there are text/plain attachments on the message. The maintainer of the package can then apply the patch by setting its status to "applied":: # Only accept attempts to create new patches that come with patch # files. def check_new_patch(db, cl, id, newdata): if not newdata["files"]: raise Reject, "You can't submit a new patch without " \ "attaching a patch file." for fileid in newdata["files"]: if db.file.get(fileid, "type") != "text/plain": raise Reject, "Submitted patch files must be " \ "text/plain." # When the status is changed from "approved" to "applied", apply the # patch. def apply_patch(db, cl, id, olddata): if (cl.get(id, "status") == db.status.lookup("applied") and olddata["status"] == db.status.lookup("approved")): # ...apply the patch... def init(db): db.patch.audit("create", check_new_patch) db.patch.react("set", apply_patch) Command Interface ----------------- The command interface is a very simple and minimal interface, intended only for quick searches and checks from the shell prompt. (Anything more interesting can simply be written in Python using the Roundup database module.) Command Interface Specification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A single command, roundup, provides basic access to the hyperdatabase from the command line:: roundup-admin help roundup-admin get [-list] designator[, designator,...] propname roundup-admin set designator[, designator,...] propname=value ... roundup-admin find [-list] classname propname=value ... See ``roundup-admin help commands`` for a complete list of commands. Property values are represented as strings in command arguments and in the printed results: - Strings are, well, strings. - Numbers are displayed the same as strings. - Booleans are displayed as 'Yes' or 'No'. - Date values are printed in the full date format in the local time zone, and accepted in the full format or any of the partial formats explained above. - Link values are printed as item designators. When given as an argument, item designators and key strings are both accepted. - Multilink values are printed as lists of item designators joined by commas. When given as an argument, item designators and key strings are both accepted; an empty string, a single item, or a list of items joined by commas is accepted. When multiple items are specified to the roundup get or roundup set commands, the specified properties are retrieved or set on all the listed items. When multiple results are returned by the roundup get or roundup find commands, they are printed one per line (default) or joined by commas (with the -list) option. Usage Example ~~~~~~~~~~~~~ To find all messages regarding in-progress issues that contain the word "spam", for example, you could execute the following command from the directory where the database dumps its files:: shell% for issue in `roundup find issue status=in-progress`; do > grep -l spam `roundup get $issue messages` > done msg23 msg49 msg50 msg61 shell% Or, using the -list option, this can be written as a single command:: shell% grep -l spam `roundup get \ \`roundup find -list issue status=in-progress\` messages` msg23 msg49 msg50 msg61 shell% E-mail User Interface --------------------- The Roundup system must be assigned an e-mail address at which to receive mail. Messages should be piped to the Roundup mail-handling script by the mail delivery system (e.g. using an alias beginning with "|" for sendmail). Message Processing ~~~~~~~~~~~~~~~~~~ Incoming messages are examined for multiple parts. In a multipart/mixed message or part, each subpart is extracted and examined. In a multipart/alternative message or part, we look for a text/plain subpart and ignore the other parts. The text/plain subparts are assembled to form the textual body of the message, to be stored in the file associated with a "msg" class item. Any parts of other types are each stored in separate files and given "file" class items that are linked to the "msg" item. The "summary" property on message items is taken from the first non-quoting section in the message body. The message body is divided into sections by blank lines. Sections where the second and all subsequent lines begin with a ">" or "|" character are considered "quoting sections". The first line of the first non-quoting section becomes the summary of the message. All of the addresses in the To: and Cc: headers of the incoming message are looked up among the user items, and the corresponding users are placed in the "recipients" property on the new "msg" item. The address in the From: header similarly determines the "author" property of the new "msg" item. The default handling for addresses that don't have corresponding users is to create new users with no passwords and a username equal to the address. (The web interface does not permit logins for users with no passwords.) If we prefer to reject mail from outside sources, we can simply register an auditor on the "user" class that prevents the creation of user items with no passwords. The subject line of the incoming message is examined to determine whether the message is an attempt to create a new issue or to discuss an existing issue. A designator enclosed in square brackets is sought as the first thing on the subject line (after skipping any "Fwd:" or "Re:" prefixes). If an issue designator (class name and id number) is found there, the newly created "msg" item is added to the "messages" property for that issue, and any new "file" items are added to the "files" property for the issue. If just an issue class name is found there, we attempt to create a new issue of that class with its "messages" property initialized to contain the new "msg" item and its "files" property initialized to contain any new "file" items. Both cases may trigger detectors (in the first case we are calling the set() method to add the message to the issue's spool; in the second case we are calling the create() method to create a new item). If an auditor raises an exception, the original message is bounced back to the sender with the explanatory message given in the exception. Nosy Lists ~~~~~~~~~~ A standard detector is provided that watches for additions to the "messages" property. When a new message is added, the detector sends it to all the users on the "nosy" list for the issue that are not already on the "recipients" list of the message. Those users are then appended to the "recipients" property on the message, so multiple copies of a message are never sent to the same user. The journal recorded by the hyperdatabase on the "recipients" property then provides a log of when the message was sent to whom. Setting Properties ~~~~~~~~~~~~~~~~~~ The e-mail interface also provides a simple way to set properties on issues. At the end of the subject line, ``propname=value`` pairs can be specified in square brackets, using the same conventions as for the roundup ``set`` shell command. Web User Interface ------------------ The web interface is provided by a CGI script that can be run under any web server. A simple web server can easily be built on the standard CGIHTTPServer module, and should also be included in the distribution for quick out-of-the-box deployment. The user interface is constructed from a number of template files containing mostly HTML. Among the HTML tags in templates are interspersed some nonstandard tags, which we use as placeholders to be replaced by properties and their values. Views and View Specifiers ~~~~~~~~~~~~~~~~~~~~~~~~~ There are two main kinds of views: *index* views and *issue* views. An index view displays a list of issues of a particular class, optionally sorted and filtered as requested. An issue view presents the properties of a particular issue for editing and displays the message spool for the issue. A view specifier is a string that specifies all the options needed to construct a particular view. It goes after the URL to the Roundup CGI script or the web server to form the complete URL to a view. When the result of selecting a link or submitting a form takes the user to a new view, the Web browser should be redirected to a canonical location containing a complete view specifier so that the view can be bookmarked. Displaying Properties ~~~~~~~~~~~~~~~~~~~~~ Properties appear in the user interface in three contexts: in indices, in editors, and as search filters. For each type of property, there are several display possibilities. For example, in an index view, a string property may just be printed as a plain string, but in an editor view, that property should be displayed in an editable field. The display of a property is handled by functions in the ``cgi.templating`` module. Displayer functions are triggered by ``tal:content`` or ``tal:replace`` tag attributes in templates. The value of the attribute provides an expression for calling the displayer function. For example, the occurrence of:: tal:content="context/status/plain" in a template triggers a call to:: context['status'].plain() where the context would be an item of the "issue" class. The displayer functions can accept extra arguments to further specify details about the widgets that should be generated. Some of the standard displayer functions include: ========= ============================================================== Function Description ========= ============================================================== plain display a String property directly; display a Date property in a specified time zone with an option to omit the time from the date stamp; for a Link or Multilink property, display the key strings of the linked items (or the ids if the linked class has no key property) field display a property like the plain displayer above, but in a text field to be edited menu for a Link property, display a menu of the available choices ========= ============================================================== See the `customisation`_ documentation for the complete list. Index Views ~~~~~~~~~~~ An index view contains two sections: a filter section and an index section. The filter section provides some widgets for selecting which issues appear in the index. The index section is a table of issues. Index View Specifiers """"""""""""""""""""" An index view specifier looks like this (whitespace has been added for clarity):: /issue?status=unread,in-progress,resolved& topic=security,ui& :group=priority& :sort=-activity& :filters=status,topic& :columns=title,status,fixer The index view is determined by two parts of the specifier: the layout part and the filter part. The layout part consists of the query parameters that begin with colons, and it determines the way that the properties of selected items are displayed. The filter part consists of all the other query parameters, and it determines the criteria by which items are selected for display. The filter part is interactively manipulated with the form widgets displayed in the filter section. The layout part is interactively manipulated by clicking on the column headings in the table. The filter part selects the union of the sets of issues with values matching any specified Link properties and the intersection of the sets of issues with values matching any specified Multilink properties. The example specifies an index of "issue" items. Only issues with a "status" of either "unread" or "in-progres" or "resolved" are displayed, and only issues with "topic" values including both "security" and "ui" are displayed. The issues are grouped by priority, arranged in ascending order; and within groups, sorted by activity, arranged in descending order. The filter section shows filters for the "status" and "topic" properties, and the table includes columns for the "title", "status", and "fixer" properties. Associated with each issue class is a default layout specifier. The layout specifier in the above example is the default layout to be provided with the default bug-tracker schema described above in section 4.4. Index Section """"""""""""" The template for an index section describes one row of the index table. Fragments protected by a ``tal:condition="request/show/"`` are included or omitted depending on whether the view specifier requests a column for a particular property. The table cells are filled by the ``tal:content="context/"`` directive, which displays the value of the property. Here's a simple example of an index template:: Sorting """"""" String and Date values are sorted in the natural way. Link properties are sorted according to the value of the "order" property on the linked items if it is present; or otherwise on the key string of the linked items; or finally on the item ids. Multilink properties are sorted according to how many links are present. Issue Views ~~~~~~~~~~~ An issue view contains an editor section and a spool section. At the top of an issue view, links to superseding and superseded issues are always displayed. Issue View Specifiers """"""""""""""""""""" An issue view specifier is simply the issue's designator:: /patch23 Editor Section """""""""""""" The editor section is generated from a template containing ``tal:content="context//"`` directives to insert the appropriate widgets for editing properties. Here's an example of a basic editor template::
As shown in the example, the editor template can also include a ":note" field, which is a text area for entering a note to go along with a change. When a change is submitted, the system automatically generates a message describing the changed properties. The message displays all of the property values on the issue and indicates which ones have changed. An example of such a message might be this:: title: Polly Parrot is dead priority: critical status: unread -> in-progress fixer: (none) keywords: parrot,plumage,perch,nailed,dead If a note is given in the ":note" field, the note is appended to the description. The message is then added to the issue's message spool (thus triggering the standard detector to react by sending out this message to the nosy list). Spool Section """"""""""""" The spool section lists messages in the issue's "messages" property. The index of messages displays the "date", "author", and "summary" properties on the message items, and selecting a message takes you to its content. Access Control -------------- At each point that requires an action to be performed, the security mechanisms are asked if the current user has permission. This permission is defined as a Permission. Individual assignment of Permission to user is unwieldy. The concept of a Role, which encompasses several Permissions and may be assigned to many Users, is quite well developed in many projects. Roundup will take this path, and allow the multiple assignment of Roles to Users, and multiple Permissions to Roles. These definitions are not persistent - they're defined when the application initialises. There will be two levels of Permission. The Class level permissions define logical permissions associated with all items of a particular class (or all classes). The Item level permissions define logical permissions associated with specific items by way of their user-linked properties. Access Control Interface Specification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The security module defines:: class Permission: ''' Defines a Permission with the attributes - name - description - klass (optional) The klass may be unset, indicating that this permission is not locked to a particular hyperdb class. There may be multiple Permissions for the same name for different classes. ''' class Role: ''' Defines a Role with the attributes - name - description - permissions ''' class Security: def __init__(self, db): ''' Initialise the permission and role stores, and add in the base roles (for admin user). ''' def getPermission(self, permission, classname=None): ''' Find the Permission matching the name and for the class, if the classname is specified. Raise ValueError if there is no exact match. ''' def hasPermission(self, permission, userid, classname=None): ''' Look through all the Roles, and hence Permissions, and see if "permission" is there for the specified classname. ''' def hasItemPermission(self, classname, itemid, **propspec): ''' Check the named properties of the given item to see if the userid appears in them. If it does, then the user is granted this permission check. 'propspec' consists of a set of properties and values that must be present on the given item for access to be granted. If a property is a Link, the value must match the property value. If a property is a Multilink, the value must appear in the Multilink list. ''' def addPermission(self, **propspec): ''' Create a new Permission with the properties defined in 'propspec' ''' def addRole(self, **propspec): ''' Create a new Role with the properties defined in 'propspec' ''' def addPermissionToRole(self, rolename, permission): ''' Add the permission to the role's permission list. 'rolename' is the name of the role to add permission to. ''' Modules such as ``cgi/client.py`` and ``mailgw.py`` define their own permissions like so (this example is ``cgi/client.py``):: def initialiseSecurity(security): ''' Create some Permissions and Roles on the security object This function is directly invoked by security.Security.__init__() as a part of the Security object instantiation. ''' p = security.addPermission(name="Web Registration", description="Anonymous users may register through the web") security.addToRole('Anonymous', p) Detectors may also define roles in their init() function:: def init(db): # register an auditor that checks that a user has the "May # Resolve" Permission before allowing them to set an issue # status to "resolved" db.issue.audit('set', checkresolvedok) p = db.security.addPermission(name="May Resolve", klass="issue") security.addToRole('Manager', p) The tracker dbinit module then has in ``open()``:: # open the database - it must be modified to init the Security class # from security.py as db.security db = Database(config, name) # add some extra permissions and associate them with roles ei = db.security.addPermission(name="Edit", klass="issue", description="User is allowed to edit issues") db.security.addPermissionToRole('User', ei) ai = db.security.addPermission(name="View", klass="issue", description="User is allowed to access issues") db.security.addPermissionToRole('User', ai) In the dbinit ``init()``:: # create the two default users user.create(username="admin", password=Password(adminpw), address=config.ADMIN_EMAIL, roles='Admin') user.create(username="anonymous", roles='Anonymous') Then in the code that matters, calls to ``hasPermission`` and ``hasItemPermission`` are made to determine if the user has permission to perform some action:: if db.security.hasPermission('issue', 'Edit', userid): # all ok if db.security.hasItemPermission('issue', itemid, assignedto=userid): # all ok Code in the core will make use of these methods, as should code in auditors in custom templates. The HTML templating may access the access controls through the *user* attribute of the *request* variable. It exposes a ``hasPermission()`` method:: tal:condition="python:request.user.hasPermission('Edit', 'issue')" or, if the *context* is *issue*, then the following is the same:: tal:condition="python:request.user.hasPermission('Edit')" Authentication of Users ~~~~~~~~~~~~~~~~~~~~~~~ Users must be authenticated correctly for the above controls to work. This is not done in the current mail gateway at all. Use of digital signing of messages could alleviate this problem. The exact mechanism of registering the digital signature should be flexible, with perhaps a level of trust. Users who supply their signature through their first message into the tracker should be at a lower level of trust to those who supply their signature to an admin for submission to their user details. Anonymous Users ~~~~~~~~~~~~~~~ The "anonymous" user must always exist, and defines the access permissions for anonymous users. Unknown users accessing Roundup through the web or email interfaces will be logged in as the "anonymous" user. Use Cases ~~~~~~~~~ public - end users can submit bugs, request new features, request support The Users would be given the default "User" Role which gives "View" and "Edit" Permission to the "issue" class. developer - developers can fix bugs, implement new features, provide support A new Role "Developer" is created with the Permission "Fixer" which is checked for in custom auditors that see whether the issue is being resolved with a particular resolution ("fixed", "implemented", "supported") and allows that resolution only if the permission is available. manager - approvers/managers can approve new features and signoff bug fixes A new Role "Manager" is created with the Permission "Signoff" which is checked for in custom auditors that see whether the issue status is being changed similar to the developer example. admin - administrators can add users and set user's roles The existing Role "Admin" has the Permissions "Edit" for all classes (including "user") and "Web Roles" which allow the desired actions. system - automated request handlers running various report/escalation scripts A combination of existing and new Roles, Permissions and auditors could be used here. privacy - issues that are only visible to some users A new property is added to the issue which marks the user or group of users who are allowed to view and edit the issue. An auditor will check for edit access, and the template user object can check for view access. Deployment Scenarios -------------------- The design described above should be general enough to permit the use of Roundup for bug tracking, managing projects, managing patches, or holding discussions. By using items of multiple types, one could deploy a system that maintains requirement specifications, catalogs bugs, and manages submitted patches, where patches could be linked to the bugs and requirements they address. Acknowledgements ---------------- My thanks are due to Christy Heyl for reviewing and contributing suggestions to this paper and motivating me to get it done, and to Jesse Vincent, Mark Miller, Christopher Simons, Jeff Dunmall, Wayne Gramlich, and Dean Tribble for their assistance with the first-round submission. Changes to this document ------------------------ - Added Boolean and Number types - Added section Hyperdatabase Implementations - "Item" has been renamed to "Issue" to account for the more specific nature of the Class. - New Templating - Access Controls - Added "actor" property ------------------ Back to `Table of Contents`_ .. _`Table of Contents`: index.html .. _customisation: customizing.html code-0e2a0c2c8142/doc/developers.txt0000644000000000000000000003435010062724152015314 0ustar 00000000000000================== Developing Roundup ================== :Version: $Revision: 1.11 $ .. note:: The intended audience of this document is the developers of the core Roundup code. If you just wish to alter some behaviour of your Roundup installation, see `customising roundup`_. .. contents:: Getting Started --------------- Anyone wishing to help in the development of Roundup must read `Roundup's Design Document`_ and the `implementation notes`_. All development is coordinated through two resources: - roundup-dev mailing list at http://lists.sourceforge.net/mailman/listinfo/roundup-devel - Sourceforge's issue trackers at https://sourceforge.net/tracker/?group_id=31577 Small Changes ------------- Most small changes can be submitted through the Feature tracker, with patches attached that give context diffs of the affected source. CVS Access ---------- To get CVS access, contact richard@users.sourceforge.net. CVS stuff: 1. to tag a release (eg. the pre-release of 0.5.0):: cvs tag release-0-5-0-pr1 1. to make a branch (eg. branching for code freeze/release):: cvs co -d maint-0-5 -r release-0-5-0-pr1 roundup cd maint-0-5 cvs tag -b maint-0-5 2. to check out a branch (eg. the maintenance branch for 0.5.x):: cvs co -d maint-0-5 -r maint-0-5 3. to merge changes from the maintenance branch to the trunk, in the directory containing the HEAD checkout:: cvs up -j maint-0-5 though this is highly discouraged, as it generally creates a whole swag of conflicts :( Standard tag names: *release-maj-min-patch[-sub]* Release of the major.minor.patch release, possibly a beta or pre-release, in which case *sub* will be one of "b*N*" or "pr*N*". *maint-maj-min* Maintenance branch for the major.minor release. Patch releases are tagged in this branch. Typically, release happen like this: 1. work progresses in the HEAD branch until milestones are met, 2. a series of beta releases are tagged in the HEAD until the code is stable enough to freeze, 3. the pre-release is tagged in the HEAD, with the resultant code branched to the maintenance branch for that release, 4. bugs in the release are patched in the maintenance branch, and the final and patch releases are tagged there, and 5. further major work happens in the HEAD. Project Rules ------------- Mostly the project follows Guido's Style (though naming tends to be a little relaxed sometimes). In short: - 80 column width code - 4-space indentations - All modules must have a CVS Id line near the top Other project rules: - New functionality must be documented, even briefly (so at least we know where there's missing documentation) and changes to tracker configuration must be logged in the upgrading document. - subscribe to roundup-checkins to receive checkin notifications from the other developers with CVS access - discuss any changes with the other developers on roundup-dev. If nothing else, this makes sure there's no rude shocks - write unit tests for changes you make (where possible), and ensure that all unit tests run before committing changes - run pychecker over changed code The administrators of the project reserve the right to boot developers who consistently check in code which is either broken or takes the codebase in directions that have not been agreed to. Internationalization Notes -------------------------- How stuff works: 1. Strings that may require translation (messages in human language) are marked in the source code. This step is discussed in `Marking Strings for Translation`_ section. 2. These strings are all extracted into Message Template File ``locale/roundup.pot`` (_`POT` file). See `Extracting Translatable Messages`_ below. 3. Language teams use POT file to make Message Files for national languages (_`PO` files). All PO files for Roundup are kept in the ``locale`` directory. Names of these files are target locale names, usually just 2-letter language codes. `Translating Messages`_ section of this chapter gives useful hints for message translators. 4. Translated Message Files are compiled into binary form (_`MO` files) and stored in ``locale`` directory (but not kept in the `Roundup CVS`_ repository, as they may be easily made from PO files). See `Compiling Message Catalogs`_ section. 5. Roundup installer creates runtime locale structure on the file system, putting MO files in their appropriate places. 6. Runtime internationalization (_`I18N`) services use these MO files to translate program messages into language selected by current Roundup user. Roundup command line interface uses locale name set in OS environment variable ``LANGUAGE``, ``LC_ALL``, ``LC_MESSAGES``, or ``LANG`` (in that order). Roundup Web User Interface uses language selected by currently authenticated user. Additional details may be found in `GNU gettext`_ and Python `gettext module`_ documentation. `Roundup source distribution`_ includes POT and PO files for message translators, and also pre-built MO files to facilitate installations from source. Roundup binary distribution includes MO files only. .. _GNU gettext: GNU gettext package ^^^^^^^^^^^^^^^^^^^ This chapter is full of references to GNU `gettext package`_. GNU gettext is a "must have" for nearly all steps of internationalizing any program, and it's manual is definetely a recommended reading for people involved in `I18N`_. There are GNU gettext ports to all major OS platforms. Windows binaries are available from `GNU mirror sites`_. Roundup does not use GNU gettext at runtime, but it's tools are used for `extracting translatable messages`_, `compiling message catalogs`_ and, optionally, for `translating messages`_. Note that ``gettext`` package in some OS distributions means just runtime tools and libraries. In such cases gettext development tools are usually distributed in separate package named ``gettext-devel``. Marking Strings for Translation ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Strings that need translation must be marked in the source code. Following subsections explain how this is done in different cases. If translatable string is used as a format string, it is recommended to always use *named* format specifiers:: _('Index of %(classname)s') % locals() This helps translators to better understand the context of the message and, in Python, remove format specifier altogether (which is sometimes useful, especially in singular cases of `Plural Forms`_). When there is more than one format specifier in the translatable format string, named format specifiers *must* be used almost always, because translation may require different order of items. It is better to *not* mark for translation strings that are not locale-dependent, as this makes it more difficult to keep track of translation completeness. For example, string ```` (in ``index()`` method of the request handler in ``roundup_server`` script) has no human readable parts at all, and needs no translations. Such strings are left untranslated in PO files, and are reported as such by PO status checkers (e.g. ``msgfmt --statistics``). Need some note about i18n in TAL here... this link has good info: http://plone.org/documentation/howto/I18nForDevelopers Command Line Interfaces ~~~~~~~~~~~~~~~~~~~~~~~ Scripts and routines run from the command line use "static" language defined by environment variables recognized by ``gettext`` module from Python library (``LANGUAGE``, ``LC_ALL``, ``LC_MESSAGES``, and ``LANG``). Primarilly, these are ``roundup-admin`` script and ``admin.py`` module, but also help texts and startup error messages in other scripts and their supporting modules. For these interfaces, Python ``gettext`` engine must be initialized to use Roundup message catalogs. This is normally done by including the following line in the module imports:: from i18n import _, ngettext Simple translations are automatically marked by calls to builtin message translation function ``_()``:: print _("This message is translated") Translations for messages whose grammatical depends on a number must be done by ``ngettext()`` function:: print ngettext("Nuked %i file", "Nuked %i files", number_of_files_nuked) User Interfaces ~~~~~~~~~~~~~~~ *(not yet)* This includes Mail Gateway and Web User Interfaces, where translation depends on the language of current Roundup User. These translations will be done by the tracker configuration object. Translatable strings will be automatically marked by calls to the ``_()`` and ``ngettext()`` methods of that object:: self.config._("This message is translated") self.config.ngettext("Nuked %i file", "Nuked %i files", number_of_files_nuked) Deferred Translations ~~~~~~~~~~~~~~~~~~~~~ Sometimes translatable strings appear in the source code in untranslated form [#note_admin.py]_ and must be translated elsewhere. Example:: for meal in ("spam", "egg", "beacon"): print _(meal) In such cases, strings must be marked for translation without actual call to the translating function. To mark these strings, we use Python feature of automatic concatenation of adjacent strings and different types of string quotes:: strings_to_translate = ( ''"This string will be translated", ""'me too', ''r"\raw string", ''""" multiline string""" ) .. [#note_admin.py] In current Roundup sources, this feature is extensively used in the ``admin`` module using method docstrings as help messages. Extracting Translatable Messages ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The most common tool for message extraction is ``xgettext`` utility from `GNU gettext package`_. Unfortunately, this utility has no means of `Deferred Translations`_ in Python sources. There is ``xpot`` tool from Francois Pinard free `PO utilities`_ that allows to mark strings for deferred translations, but it does not handle `plural forms`_. Roundup overcomes these limitations by using both of these utilities. This means that you need both `GNU gettext`_ tools and `PO utilities`_ to build the Message Template File yourself. Latest Message Template File is kept in `Roundup CVS`_ and distributed with `Roundup Source`_. If you wish to rebuild the template yourself, make sure that you have both ``xpot`` and ``xgettext`` installed and just run ``gmake`` (or ``make``, if you are on a `GNU`_ system like `linux`_ or `cygwin`_) in the ``locale`` directory. Translating Messages ^^^^^^^^^^^^^^^^^^^^ Gettext Message File (`PO`_ file) is a plain text file, that can be created by simple copying ``roundup.pot`` to new .po file, like this:: $ cp roundup.pot ru.po The name of PO file is target locale name, usually just 2-letter language code (``ru`` for Russian in the above example). Alternatively, PO file may be initialized by ``msginit`` utility from `GNU gettext`_ tools:: $ msginit -i roundup.pot ``msginit`` will check your current locale, and initialize the header entry, setting language name, rules for `plural forms`_ and, if available, translator's name and email address. The name for PO file is also chosen based on current locale. Next, you will need to edit this file, filling all ``msgstr`` lines with translations of the above ``msgid`` entries. PO file is a plain text file that can be edited with any text editor. However, there are several tools that may help you with this process: - ``po-mode`` for `emacs`_. One of `GNU gettext`_ tools. Very handy, definitely recommended if you are comfortable with emacs. Cannot handle `plural forms`_ per se, but allows to edit them in simple text mode. - `po filetype plugin`_ for `vim`_. Does not do as much as ``po-mode``, but helps in finding untranslated and fuzzy strings, and checking code references. Please contact `alexander smishlajev`_ if you prefer this, as i have patched this plugin a bit. I have also informed the original plugin author about these changes, but got no reply so far. - `poEdit`_ by Vaclav Slavik. Nice cross-platform GUI editor. Unfortunately, it does not handle `plural forms`_. Even worse, it deletes all messages with plural forms when the file is saved. Still, it may be useful to initially translate most of the messages and add plural form messages later. - `KBabel`_. Being part of `KDE`_, it works in X windows only. At the first glance looks pretty hairy, with all bells and whistles. Haven't had much experience with it, though. Compiling Message Catalogs ^^^^^^^^^^^^^^^^^^^^^^^^^^ Message catalogs (`PO`_ files) must be compiled into binary form (`MO`_ files) before they can be used in the application. This compilation is handled by ``msgfmt`` utility from `GNU gettext`_ tools. ``GNUmakefile`` in the ``locale`` directory automatically compiles all existing message catalogs after updating them from Roundup source files. If you wish to rebuild an individual `MO`_ file without making everything else, you may, for example:: $ msgfmt --statistics -o ru.mo ru.po This way, message translators can check their `PO`_ files without extracting strings from source. (Note: String extraction requires additional utility that is not part of `GNU gettext`_. See `Extracting Translatable Messages`_.) ----------------- Back to `Table of Contents`_ .. _`Table of Contents`: index.html .. _`Customising Roundup`: customizing.html .. _`Roundup's Design Document`: spec.html .. _`implementation notes`: implementation.html .. _External hyperlink targets: .. _alexander smishlajev: .. _als: http://sourceforge.net/users/a1s/ .. _cygwin: http://www.cygwin.com/ .. _emacs: http://www.gnu.org/software/emacs/ .. _gettext package: http://www.gnu.org/software/gettext/ .. _gettext module: http://docs.python.org/lib/module-gettext.html .. _GNU: http://www.gnu.org/ .. _GNU mirror sites: http://www.gnu.org/prep/ftp.html .. _KBabel: http://i18n.kde.org/tools/kbabel/ .. _KDE: http://www.kde.org/ .. _linux: http://www.linux.org/ .. _Plural Forms: http://www.gnu.org/software/gettext/manual/html_node/gettext_150.html .. _po filetype plugin: http://vim.sourceforge.net/scripts/script.php?script_id=695 .. _PO utilities: http://po-utils.progiciels-bpi.ca/ .. _poEdit: http://poedit.sourceforge.net/ .. _Roundup CVS: http://sourceforge.net/cvs/?group_id=31577 .. _Roundup Source: .. _Roundup source distribution: .. _Roundup binary distribution: http://sourceforge.net/project/showfiles.php?group_id=31577 .. _vim: http://www.vim.org/ code-0e2a0c2c8142/doc/features.txt0000644000000000000000000001147710062724152014767 0ustar 00000000000000================ Roundup Features ================ Roundup is a simple-to-use and -install issue-tracking system with web, e-mail and command-line interfaces. It is based on the winning design from Ka-Ping Yee in the Software Carpentry "Track" design competition. *simple to install* - installation (including web interface) takes about 30 minutes - the instant-gratification Demo Mode takes as long to set up as it takes to type ``python demo.py`` :) - two templates included in the distribution for you to base your tracker on - requires *no* additional support software - python (2.1+) is enough to get you going - easy to set up higher-performance storage backends like sqlite_, metakit_, mysql_ and postgresql_ *simple to use* - accessible through the web, email, command-line or Python programs - may be used to track bugs, features, user feedback, sales opportunities, milestones, ... - automatically keeps a full history of changes to issues with configurable verbosity and easy access to information about who created or last modified *any* item in the database - issues have their own mini mailing list (nosy list) - users may sign themselves up, there may be automatic signup for incoming email and users may handle their own password reset requests *highly configurable* - web interface HTML is fully editable - database schema is also fully editable (only the "user" class is required) with a full set of data types (including dates and many-to-many relations) across all storages available - customised automatic auditors and reactors may be written that perform actions before and after changes are made to entries in the database, or may veto the creation or modification of items int he database - samples are provided for all manner of configuration changes and customisations *fast, scalable* - with the sqlite, metakit, mysql and postgresql backends, roundup is also fast and scalable, easily handling thousands of issues and users with decent response times - database indexes are automatically added for those backends that support them (sqlite, metakit, mysql and postgresql) - indexed text searching giving fast responses to searches across all messages and indexed string properties *documented* - documentation exists for installation, upgrading, maintenance, users and customisation *web interface* - fully editable interfaces for listing and display of items - extendable to include wizards, parent/meta bug displays, ... - differentiates between anonymous, known and admin users - may be set up to require login, and may also only allow admin users to register new users - authentication of user registration and user-driven password resetting using email and one time keys - may be run through CGI as a normal cgi script, as a stand-alone web server, or through Zope - searching may be performed using many constraints, including a full-text search of messages attached to issues - file attachments (added through the web or email) are served up with the correct content-type and filename - email change messages generated by roundup appear to be sent by the person who made the change, but responses will go back through the nosy list by default - flexible access control built around Permissions and Roles with assigned Permissions - generates valid HTML4 or XHTML - detects concurrent user changes - saving and editing of user-defined queries which may optionally be shared with other users *e-mail interface* - may be set up using sendmail-like delivery alias, POP polling or mailbox polling - may auto-register users who send in mail and aren't known to roundup - nosy list configuration controls how people are added and when messages are sent to the list - auto-filing of "unformatted" messages into a particular class - e-mail attachments are handled sanely, being attached to the issue they're intended for, and forwarded on to the nosy list - sane handling of content-type and content-encoding of messages (text/plain preferred in all situations) - email packages that display threading will show issue messages correctly threaded - users may send in messages from multiple addresses and be associated with the same roundup username - built-in security features like TLS and APOP *command-line* - may be used to interactively manage roundup databases - may be scripted using standard shell scripting - roundup's API may also be used by other Python programs - a sample is provided that runs once a day and emails people their assigned issues - a variety of sample shell scripts are provided (weekly reports, issue generation, ...) .. _sqlite: http://www.hwaci.com/sw/sqlite/ .. _metakit: http://www.equi4.com/metakit/ .. _mysql: http://sourceforge.net/projects/mysql-python .. _postgresql: http://initd.org/software/initd/psycopg code-0e2a0c2c8142/doc/glossary.txt0000644000000000000000000000155610062724152015011 0ustar 00000000000000================ Roundup Glossary ================ :Version: $Revision: 1.5 $ .. contents:: class a definition of the properties and behaviour of a set of items db (or hyperdb) a collection of items designator a combined class + itemid reference to any item in the hyperdb itemid a numeric reference to a particular item of one class item a collection of data that forms one entry in the hyperdb. property one element of data that makes up an item. In Roundup, item properties may be changed as needed - even after the tracker has been initialised and used in production. schema the definition of all the classes that make up an tracker tracker the schema and hyperdb that forms one issue tracker tracker home the physical location on disk of a tracker ----------------- Back to `Table of Contents`_ .. _`Table of Contents`: index.html code-0e2a0c2c8142/doc/images/edit.png0000644000000000000000000002335010062724152015301 0ustar 00000000000000‰PNG  IHDR«×ô¡Z%UPLTEÿï÷µ””JBBïcœ­­­”„„÷ïïÞÆÆƵµ¥¥¥÷ÎÎïçç­Þ½¥ÞµïÆƽçÆ{œïkÎŒ„Ö”cÆ„ïs¥ïk¥ZÆ{{{{RÆs÷”½sssZJJB99ÖçÿŒ{{Ö½½kkkRBBµ­­œ„„„ssœÞµçïÿçÞÞεµcccÿçï„¥÷”Þ­­¥¥÷ççÆ­­{Ö”{Δ÷œÆsÎŒ­Æ÷k΄ÆÖÿ999÷½ÖZÆs÷µÖ111ÞÞÞJ99Þçÿ÷Œµ”{{)))Þ½½÷„µÖÖÖ½­­ï÷ÿ¥œœï„­Œss!!!ïïÿïÞÞŒ­÷ÖµµkccÎÎÎŒ¥÷œÞ­µ¥¥„kkçÖÖ„¥ï”ޥέ­ÆÆÆÆ¥¥ÆïÖB½kµÎ÷ÎÞÿµÆ÷ÎÖÿÆÖ÷1µZ­ç½ÆÎ÷cŒï911!µJœœœ÷µÎ÷­Î÷¥Î”””{kk÷ÿÿcZZ÷÷ÿ”µ÷ŒŒŒ”­÷scc½¥¥¥””ç÷諒÷ïÖÖ„„„÷ÆÞÎÆÆçÎÎÖ÷ÞÖïÞR½sÎïÖJ½kÆïνÎ÷ÖÞÿB½cZ„ï9½Zk”ï9µZµç½kŒïÿÞïZZZRRRœ””ÿÿÿkZZÿ÷ÿ÷¥ÆµœœJJJœµ÷÷ÿ÷{cc÷÷÷cRRÞÎÎƽ½­””BBBÿÎÞï÷ï­½÷Œ„„ÿÆÞïïïÖÆÆç÷祌Œ÷ÆÖïÎÎççç½çÎ9½cçÆƵçÆR½ksœï„Öœs”ïï{­ïs­„œïÿÖçÿÎçZRR½½½½œœRJJÞ÷çµµµcÆ{œŒŒÿ÷÷Ê>- IDATxœí}ƒ·uß%-œMÔž[ËC\rÒŠu4fZÆ6-²2êÊì$\‘96K°•Î´ãrAWɈÝÆ‘ÖtíÙB±–Zë×H”À”Ëœ$W)¤ÿ®¾‡™Ýû$u{·s{'ïË›ÏÝý-æÍÃÛ‡÷ÌÁÁ¬ L€9×~ÐqýÊA@ËõâÅ€–ëõ›+#®wæ\ûÁœk?˜sís®ý`εL®+7o®Ü¹sqÖWpß ž³2k’Æ\WÎ]ÿüµ•Å'~øá‹ç®_[Yyöúâʹ¯Ós‹³fÙbl>k>ô°¹~þ>ü›Çž1ç¾ý¤9ö{_yèÿž9¶?ZvÜ®ŸüÐ/]昹þŸ¿ô¥ÅgÌ'o.™ëæÜ’yâC&q]Y\ì„a¼‹v½ÛŸV{¼#®‹ðÿܱc‹Ð®Ÿ¿uÇ<õk·N˜'î,~òC‹w®#וgOœ¸ylqeñÜÊåcwÎ!­Åñ:ÉâÏ]\ãwn]ëí"¬áºò¡g~íØWZ®×—>¹d/së&40p]\zbéÌõ¥s'®/ݺüù'o=qneñ©'o]Ãõ3O>uæÄ÷oýÝg—–Ž=uk©7‰Y+7/š'Z0o>õ/Ì™g>yçÛwZ®Ç–—®-^»u·®/> WüÜõ•¸~âÚ±ï_þþ5X^¿øìõ›×ží›+Þ[ÍWžøJº·ÌÅ/]6Ï\4Ÿ¿øðâ®·–ž]ºu‰ëâS—Oà:ìøòåë——®¸væÉo÷ÏõÎÍ[þÚ‰sK­ÎºµróÖõ[×/>üð"*/Î¥c——n­ÜúþÒ™'./^>snåÜo~ÿÜ™'ž]|vñÚõ3—¯Ý9qìĵÅ[+ýËÀÊJêÆS×Öa Æ7Ÿ½•v_[º5ó..};-ož9±ôc<;½å̵ÞÆÄÛ÷KÏ]ïøñ¹ÑÚ™'6žÖ &ö»<³Í}=àú³æ\ûÁœk?8€\U¦2»ùh‡½¥sOt\ó…êäÉÍGÝB±Íϱ{ð£:®z^Ö*eë< mUŒ™3A¾•û´-c¤pš"Š©œÑ± y¤p-`«VY=üT])xËžp-ÞŠf9ÏNú ij…|AWo ¹YÈå‚Õ ù[O“¤äŸ|B/ÔobÁ—Ãì7³‚¿14ŸÎÊzo¸Ê·‚YPrÁ¿¥å‚Q ì­LÀŸÜàÒÊöfi 6ožðKìÀ?Ÿþ„ÐÍ‚0oL‹½á /†4ý[™ê¸Ò… ¹b»JlÆŽkiì›e"?æÓ ˆj±ÀÞ‹½à:Xàö͆ V—ßåùôÐ †ÃeÓÀ6 ù„±\ˆ&¼‘—áSË ¾€¤z#o>• mù©p2n¡J¦ÏÕ9g¬7Þ㺵°é,póø¶¡«ÑiÆ1Û¶0žh,³ÖÃ|¿T·Û`ƒ®C±@¦Oæ°M®©Aï¹cpûØ9×~0çÚæ\ûÁœk?ØןØ}‚mpý_G÷ ¶Áõ±«ßØ×ÃçœÝXÏÕ{¶Ù^>||Ö$;¬çªj°‰ì>åê•!ÑnjmCj·¿¹zA›† ¨oj¾ß¹’ ‚±¤aÊØ}-(¯& d̵-3*Ø>æÚêÏŒÇÁ´Û×íº%æ\w€mp=z|_ö[[á'ÿüñŸßx—Ù¯ûs®ý`ε̹öƒípµ~rÌŠ«¯'¦JûðÐo‹ëä­ÄœëNÓ­Ÿ§Ž¸nEöÕ[<=ê›k&£’ÜxË2X3~´Öqµye¼qÎâS»v32?Ž<¨Üî×8ˆ¦Ñ¡Qq¨%WuA [ÕJ–/“¼h¬*Û¦,JIÊÆ•M÷иÓì]^½®s¢äÒ)+ëÁHñ´\£AZI+Á ™V†ºFÔ4h«Ç\­Ý®šPEk‰¢à‘³\Un W©ËPJ-+K_3ƼT• %W¤‹Þ¨@îךhg…בq(Êòµ\­Œç^FxÖ>…eQ#²Ñ@/iZ™ë¬mœsÀ¸Nê.ŸWGŤ³â:q«Ú~4Þmöë~Áœk?˜sís®ýàÝÆÕÕÕöÁû *œºÕ‹ÕÒâ@rµ­_§»‚ë.dâºÝ€Ñ½à Aó¯Ý"ÕWrËÍÖdëôÝ؉µ\½dY­ò`²Èh®ÈP¸;¸WîUŠÖå±"µŽuÁ 啾(ð7TläÄÚ ®®i‚Ö`&«’71‹Y•WY=æj|c-Œ]™vJfq@) x)2‘†‰={6põÚÉœ^i$ü'YwO!W –~…>í%­M¡k SF¶~¥:Ô^qcšMº\ÀjCesCÙˆ«<©T:¯(š†:¨ù@膸Â&eȵ?ïЮè£òãËÛ?&U§Zè"a¬sppæ˜óN]ÿ3ѯaìþÛB¿}7;ï ¶Å5L5[®–OÀuƶË~Áœk?˜sís®ý`7\'wuîÎ º ®_»4ÅXìïõËõ{žZ(ö‘Ÿë›ëé©…´ýµÉ¹Z϶¯nµsÆ\Ãfj‹˜ ·f–n=2¤fÌÕkDT\;ÁÕ1Ñ”Ô#nD,rG9#™ýÚl¹º&S’ë<Š¦¡WËUË2H%˯´¬§Í n謹zÿI–1, RÝNÉhÔÓªÐÜ4‘2Áê™Ë@€ÁlY”´Œ8H톱²,Ñ)SD2¨ào¥ðàÀΚ+fapšfKõ½ûU@g _aðZáh×àvæíº%Ô(eÆÁë~äz7L“ëéĵïvýÚ¯þÜôb±{æºç˜sís®ýà]Æu¯çòî†ëÏå}Ï]Uíþ›Ëû¹Ý´ëÏåýímr…¡ßä—îæšyuÓÇNÏXƒí¶ë07ͦˆfäzäÈé—_8 Xm?/I‹õ;w{¶ËU”Q0›S« F8‘ëÕ«§Ï¾ðòé«WÏž¿p›óüÕó§ßÆ­ã§zûüÙ Ç_½ôèñÓWÏà {ÃU†R9©Êj@ëlôˆóðñ#g/ý•÷üÍϾ|úÒß{ôÒ_:d/]¹rü¥N¿ôÁ+>{åÊ+¼pö?åÅ?àÂÑÜhl›«^0Ò˜8zÄ \:zé…¿qôÅÓG/]zÏÛ‡öìÙWžôåÓWþä±}ðÒ«/?ü/¾ú'—^¸rü=/¾º7íÚDSº°\ºB2zĉ\_ºtéåò¼ôÙ—>øàÑÇŽ¾øêg¸rüÒ¿}åÇ/=ö¸zéÊñŸ}áÒ_^:úÐ`—jc»\[%€ÚÀÖãGœ ¯Gzû¡ Wß>~öíóoèê+gO_9zöÈÕ«.èüñÇ^xõêñ#§¯^8 ‹ o?´7íº«8“ÎÂ{=Ýïøò Hå‘´uúg¯\8²ªŽì•Ø[Îå=½z™®šÝ×=žË»Ý~k+ìù\ÞÝ´ë¾Áœk?˜sís®ýà@r•jßc5Fí{H8˜sís®ýà]Æõ{Ÿ`\?ûèƒûÛòižÞx—åÏšsÝæ\ûÁœk?˜sís®ý`ε̹öƒ9×~0çÚ6pÕq5Üu¿sÍ£ë”ò cŒí¾æ*2M}X.â2We û9¿¶‘¬È]šÒmK÷· èªZ©ÊZùÆUq?çƒÇ+X Î œgïk®[aÎu˜sís®ý`ε̹öƒ9×~°®» ž¶Áõ=ÿã·÷¶Oø_#áÎÛ‰Ó|ìðcýÖ+¿5kªÛázøåÿúçþð•ôøþ—sôêçÿ¯~|æm¶Ó®¿ú/ž~ùðã½ÌÒ˜6×W<úèáG~zYvˆíÈÀËW¯¾rô/ÿððÞÎÚŒíÄ@ÿF&?þø/Íï²’}ƒ9×~0çÚæ\ûÁœk?8€\ÿÛA@Ëõ‹7ž?h¹Þ÷…s®ý`εH®ßºqãöíY³¹7F\ŸÿÌ¡o~ä#‰ìó³æt7Œ¹šûþÝô…‡¾õŸûøíC‡nß~þЬ¹mĈë×ÿè‹ï½ï¿ÜþÑïþÊÇÍ/ÿÊø·?öÜßúÈ>“‰×CÏ}üG_¼ï3?ºñÜûŸ»ñ~÷¿ðÞß¹ïý³&·c®ðüÇþà3ÈõÿýÑ×ïûÆ¡C7ÞÿŸ~´Ï´ÃXþâз~ç>?½ýÃÏ|ä¹o|ìïüÅ¿þÓoΚÝzŒuÞýÏß¾qèöóü7ÿ7ÜW_?´N\oaæØn_pû½¿p߬±]®ßúå)ø;Äœk?øéá:N"–ª´¾CâéÕ"ÈvSñ EïR$ßÇ,,vǵκ6¨`+ß|FÕ9VAÁußÔFè ɤ˜Ö>W¤]M?„µ?‡”ÆÃ1¢),vŵÎ2#IUigD [9¥µ¡ÂóîkU0E™Â>YfH Ü8c$7Ú¤"®•fµL…~Q·‰»28• £›!èsʨø„\…æLKK52pš)ÂeTL#׌)Z,4Õ¢NLJL$V›ÚÇÀnF\á $£¡å¢J´µQVŽˆV ´ñ²€c,&ä꙳py`Ñq¥\䪈×LÓ,*d²&Ø*‘jc*xÄ àH9F©BKflÄ•†”K("˜ËºÈþ£¸~_Æ,•°Ø ¨àcÃ@@àB…ùÁb¬$‡õ$‚€l¦Ö¢Y„-c8È£‚³}+žÖ§†v‚ ô<#NU†ãUµkEz,\²“qµ˜Åx=0Õƪ×ÂoÜ[Ôņ¶#¥ïDÒ‹påƒ8è’lí6³56$I“d”…׺ºØ µ¨ºc.÷#ýŠW½²x¯ÛöÀ˵…ˆ¼·Î:“·[°È¼5nBýêòLTeŽ_ªÒ©22ØYR¬EÉA‡â1Z('ËÔ\¢Œ±„ÚTE‘î²eåh«_ó2¸†ã½Ž;E)\«‚A¤Cî ·œ¶Ü²ö…¦®('”¦PT¥Œò‚ªU¥ZzJT CkEBÑÞTd±Ž¨RIÖVÓ ?Ú7€öJÿ5¾l÷z[;;¢KŠ­Í›nlŠ,—Þ[´`•¢xiÊH•5n •ôx…ÈÛ\° ’'q˜AÄÑ¡ä²-u$tìÚ5+­+KK†ØÒ‘Èà—»® z*…½UÚ¤Jë¼}R=`ÇIáˆ*KK˺ÚØn$“ig{>s¸å=e”„Ý1Ì6î}:fÚ— yúÌ®ŒVW;kBy}§²÷R_ö.¦Éö1×mõm)>\õVÇ[ Ñ²¼o®n~á„­Çlûè¬LY$û¤(k¢¢©$R¯t­ô´\Di’;¸˜t¾=Å/OÞ‡L¨³2&%K+r›ö ½ŒI4$1BŠº)ñn†Ž<#ƒ:Q#£Œצ̌ÖôY1¹HLÆÕ×dYUÊa$@3PP)ñ& UV ’…–Ù'X„>;¬¦µk%uyA¨Èƒ2™ç“–ÆžŒ+‹på’Å †k¢dÑ>‘m*ˆ„ ÎÚ‚–¤žU€:k¥Í¿ÞPÁŒW?aÓîÌv©TÜþWtVÕî±3®›L÷Àî•Õ®¸Îs®ý`εìšëöõùŒý. ¶µ[›,’-ý.Tobõïw^ÌVÚ2¢SgVKW-K‹öIL†É]ý.Îí¹ß¬øÊ‚ÍN‚à´$.wvPjËáÉwõ»tƒÿ=õ»$®ÑƒíD¹¬y„“`ŸØd‚ÝÝïüÈŲg~ÛH­ŒÕº|lªä±ÖL0–µæÂÝü.ÕÞû]øpu}/Ü/“ú]Ö"k×Û_¥×3^uÀTkîüÔ”›4”Ý\`W\;¿Ë¨*F’ÂV«_Pª: bÓÈ:¸Ö©dyÞéW—{—Á0·²Ô¬k”E=Á̪Ã>Ûa-›*îM($c•–Q·m©¹/²ºÉ“xŠ’¸}˜Ôeá@+0UŠA½œ<:÷SZ¥&èpå:+8r,CËØ9\`HÆ _8­ê"9q&äê:\‚²iL ¥¦o·ànÈ‘+¾´bDhR.~‹Em“ªÕÐÜè† †Ãݽ CP³Ur¿¬:\’&K™ ¹ÂíTÃ,Tª íZ+©®L[BÖMÁ³† 0ØÐJ:TŸHWÞÀ[ß®ø°. A}­vtB{è›îìü2° J×Câ–}Á&æš*Ž=-­ßûòv˺T«m|Š‡[±uQµ[£UïÒ»ðí«÷Súh‚<ºLç¶I^”ÝÚëô‚ݼNӹˈ5í¶nÃ[7yoÞsðEríR¬ùœA5^¯¡ó]Óºïι© ³X1ú­ÜY+°Ð«;Xd†Ho*ãÊ8¹Ÿ0Y,ÒYAtÓÐsÁ¸Ÿ åmQD°2Э°4.t®¾YÄëÖBo¯Áªªtú p¦‡Ž,k­Ý„âÊd¢Î n—¥Ã4Éý„>CûD‚²‚¡‹¥Æ­öRÒXù²–wúŠ4•…^>FÊy™|Z¡ÌÑhÑ,i¾†Ã§DP#éÍзƌð¢Ì»ïCmëòp5­Ë<°SÚ€œôDÖ}u˵ÊlF$ìô•P‘µ\ ­2Á#Qù€¡“!€K²ue:€Õ³Z—Ì4aĤ¾b”Ä,0S¬D°èMé\,uWO&É@•¯3£«Í  0aZÇœâ:2è+šüš«Z´Ö ˜1 “©W£ûÀg$™0»|ƹǘsís®ý`ε̹öƒw#×/ü«5#®ï<æÆgfLÔL0Ïh¶4àü­9×~0çÚZ®ßyäÔ@ËõÔ_½ÿ ãzÿës®ý`εD®¯½éüm—ûc®?óÏ^¿ÿ«_E5öôÓü`_¶ó˜«ùÁý¿hN½öÈ#¯}÷£§þçþæú“ï¼þåß?õOŸþ³Süñ#û›ë/~øÔwOýÙàÿçpý™|øéS§žþðw¾zêÔ>çúÚ#¯}ô×?úÑ×N}ùß÷£øîûfÍk+Œõëý¯¿ïõ÷½ïõûß—°Yi½öë¯ÍÛí îÿ²ùýYcÛ\Ÿž¦…¿3̹öƒ9×~0çÚÞÅ\¥ZÔ®ôš™®©Ž„…¹`ªÌ3|18Q¤°7|D`Ãx¦œL+&¥‘¨Ã¸RÂë´S‹ÝqUfÆ›P›T9$(B¬kÃ@Dĉ¦’g†cpr)ÓË,Ï# –3]ãN2t•HÑ1Ïe¥U–åÎTÑ.· É|®xÆ×Ägì„«¨ AŠXd¼$Ÿ#ª:Ë*Y8 1ʆ\hMq—×fPë&½ ­ƒä¬ò%w%÷•Ò)&Î2GyàLD^uˆ&FSªE9éÝrUT+ÂDÑÎ*­­$¼Ä€Ê‹ vAàÅ1$«:)=¾‹E§ÀWŒ} ÍÐc¯¤ä1C(xL\3†þj¹{®EÖÐJÉ cC±G)0Î-Ë"7µ’Π­½jÙFåÛ—©†MPÒWdFϼŽežÂIØpWþ†ÁÐW·ìÊ!ÕÝqMAÕ)`Ê; OI“9-†¿µáIxq&Æ(á©éïKáY¶—œFÑÛÎuÓŠv§€²ôþwÅõn˜pÆÐ]Q­ ‡Üü=¹ÎÚrVîž`RÅ«ƒQ¥njsrzâ*³’4 –aP ‡$V÷úìs!TÚHFƒõ£ïõÉ3窹a9¨©"dþÕ{*÷±@f4©TŠÞÏ\gŠÉ¸Z¿f>ãV:Õƒ¦wÓR¶»ãJ‹¦kk¶)ÆÞ*!ƒ[¤N™W°6Œ®rÐ)8ZC'Xe©¸Ì«ºd¤Ò…×5Øc¯n}\AM Šñ¸Š •à: ¹¬s×4õ V„+RrI©[–FhZßÁÜí)pE…•¸ àJØ™E­ÝÌä’àn-‰¤±ã*ˆ¢L¦"WTXIDÆŸ Q/Ðc¡VQ;*”ò`ÞêH"©’ xAÈ´„`§:«ìæ·H¹†ˆí’9ô„Iï­ÖÚ\z3š Ã:ûg´ünÝtíwžgîíšó¶œÆ3W.5ÆdÃ`eÂJºŠuƆ"§Ë¶bHx^¬™BR½“" e›Ú¢ý«6QÕ씫®9œŽÚ:ššÔËY¨«ç…Í`¨=$VaŠ™WhM=Ü€$ ãmœ^F Ó°åÛ•aôš™"N?ÔŽQuT%H~ÌåîZxM(¼ "¦»—M­ª*ÇK® —ð™ÕÀ•:uQSÐrÙEÔ ¶$¬P\õ<¨ŠAÔCÈu¦êÜæº2‘¸OsA…”AQJTÉŠ"f¹5p!ëɸ·eøµFª`½ªŠiäštÕ£ïc‰\Bï@¥’0¤ÝË¸Ü iP"HãKŠ þW C~zÌ,|‹D M¢–™÷ÁÇT“q­qz)Å´ ¢âÚÁˆ”ÔUFiÏ´TèsPÒS”)ˆ‚‡Æ/¼a™Å4 g´‚ALEÐ9/ü8 2 ¹†1ygs 㧌0¿S%ÖÝ[pÞáÖIÈWo¶Lm¼·Šbý.½©Ù)×Í„tn«Õ~Ã|ÃÍßðîµ_g‹9×~0çÚ¦Æu“ŠiçvvæQ“¦ôÙ%×ú¢»|c¾1U2•FS$E>6#wnáNÆÕ}¢ˆbàÉZ9á(Oo)BEëö‰¦%‚‹¥1M‘4iâ1ƒ³*éqŽôÎz’I¹¹\aÓøÌ9ͤ`"4˜×Aw°HR"M!4¦C`yîËZw\1ù-©ÅdT÷H 65®¬ ™¤oÇ)’À•0°Œ¦ÐØ Ó4$®U‘;_X†¹5mѾѧ„m2ªº–'”WŵiÇTN‘Ĥ‘b^AªJÕªh Ž …ã"¦¹³§fKŽ ðÙ«;“ÙÉõÀÆ|kQl||6ULÎu³…´Š{›×Ùaε̹öƒiruÓÐÝ3[ÃöUÆècvÅUÓk ½|eXS²P!Ö9’ò @¶E‡À×-ÆΦÀµs•YV¡›•ò”…Šb"ÍàµõDc`ìxIS: LR Ò$F‚¤SðÃ$Ã$›Qz·¬8ñÂÖÉ”‰’Õ£ü¯;äºú0Žž¬RNbà*‰iiZF΀Ë“aF#­y™;4hJL‡€.…IhB›e·˜—%,\f2—µÏ&E,ÈîÚ5·Ø¡–Á–¢‘)Ñ&Ò”ÓÎ`n-lÁH¹ 9æƒÈBˆ1y»kÌLò!  v…ÑŒk–±ÐZÀU‡œF¾+®í—vMYØâ˜å!eÑÄDšvœ¯ªÄïäèR½B)­f ”ÌÑ6ÙÄTLç5ópæ(™5|ØLdÇ>¢I@Ôî/VÓ¸·¶‰Ió‘Þ ?­}Aߘsí?5\ß9½îØzY“L³ÍÆ¿Ñ cßÙ–ÙW9ö“ß-'ñÈï‚i¸G§â¤D~M07¬ìßý÷ÓvläÉΰ˜…J:L¤ÉÁtäwÉ‹:%‡ ‡Á:ý¸¼ ø0ä„u>ÌË8J¤‰¹Š"ñQ34ajJœÜ=`ÇO8êe|T˜<-˜ \EË ù]À@°zȵ¯“{½0SBŠô Æ 3¦äÚªaÛÔT™×qÐð2(>lê;ÕpW\u í¢bºÈ­aÂ#Õu˵êü.À( mî)¦¨‰¤òE+$™¹Í"æ oifLÁèÔQE¥áRîN^Á¬jmÙÚ}˜¨ªJé§jŠ9ËÚÔTȵÝb(Ê-k¬y×l£F0O|[ 'í%ö™§Œ€%›aYŽë,·<á^n®2=®k‹™T0¢©“s V3h®ŽQÚD£¯~+ýfÿÜ”¸úÜ1 îâ nSvMŽ7U*!á­¬m©ºî)#]Nw>¦UÅ“1jÊÛ¼fv…MÚÅ”¸ÖËÒ7*%ÒÄf]–=ÙiôÅYQ8ªƒk*בaèüú@Äv+kB(•'…¡CíukhãÀK9=® h}f%Ñ©Pª]ü?ή鱼 &ëÒjnÅý 0¶­BèÎZ¬.¦%¯Bé†c±›Ú”çrðMÙqgVXßäõÐA65ke¶“8³”JÇå¨UÝämO(DʶK¥fÓãŠYl±Øȸ& õ]*Xו,q˜°²Êjº.‘¦W/q‹ô®”À’µiÑß3#»ÅZjF2:7ý°Q°Ï6>xj\·~f”¼0›[  Ó&ÏÌî~°G0-®´©˜tÉvÑs'× A/ Z+°³V]M.ŠÙ )tHxS‘”+<6ã šL¦á #3 ½9G³O‰+ ’7 qÀvV.ÃXœÃQ¡~kSig4Õ:’šà›:Õb‹­û…qͲÌbNBz¨£òšd$N™«ˆY“l×ÜbªTEcíRÕ5…4±Ý ø9)»ft…#míJHè2hæ!¨Â”à~•¦$ŠVä§%XÜŒ™d€eø̈ÌŒIA1m¼±Mû z´jr “µ 4?k3h2ÅÚø=YíeA)FrM“ëV˜Â$·Ö„éÅvIÀêOª6µùÈ®Ù``±­[£ðz±]0%xÊîÌ(Ï>X$EHÚxIa\@©m'ÿ¤™3øP짊lÖºÑÌŸér]o»$7l·Q†uÖp‡Ð‘-ËTÔØ»ƒ€ñŒ F%ÁJ5Î,Å!ÑBIDATh08˜ã„€ CÊ5–f/¶ r…=ð…Ž¤ÅVjE¶–ŠN\ñ•I֦Ǒ´^l*Ó†ÕbEטõb»°¦l‰eÛªlØ®­‰ 8æì$’]£S4)ŒmæoÇ8ÚUÁ¨&H±jåLÍvé ¥u¶ æún+²µ† ÊëF»˪¥¢ ­•âRýkº$á gXº6·ö”¹îæ\ûÁœk?˜sí»âÊW ­¬'ÇŸØìúÙbW»gùص#£]q £øo°¬4VçtiœŠLRmf€ƒ0"¶zÞµÅ6[#̦ª&£º³©sÀÁn2hÒ¨–µs–S±;£6ó8±ÔX*V¥z–…Ì¥h'Bs,# ¦€ Ýçj5Ù:Ö"=&†™«!ÏÑ ‰ZÉ,–ŽñAîÖ?`™ZåZ),KÛ2²Qgu‘j•$C†Ç@R5ÙTö)“£j²Ùx m:0hÀ„avjƒóÔZ­c²ÓgÇ0®G2€íÊ´Žt(¸Je›)ÓEóc› ­¨ ŠèÜ«Ö'MÅ1wŠÚ¤5#Œ\¤Áߨœ I.5! “Û‡îAF¿€bÕ¡&š¶Ðlh¢×uz¿n‡!N ‚ÑÓòeÄ ëÉW—YE@Í4<éˆ&•3a¡ÉbîyL|Æò¤³<,ð}y*·áò¤º"!1÷Ê ì  UÙ˜‚M™«"4ˉNQ,.ïÊ™À7&O‹ILXæƒD  Žïƒ!e$ç)Â=FõÉ$XÕ$F*SÌteã]à+ C5ÄFåLd@ ÎþŠ ÔP1ÊE#ZÈ>0°­ã½ÆENE©@¿‹ ÞOK&ƒ—ï8 u«"óÓçz7ÛŬb[û|œ2ìNP‹­sàºõî\/¦Èµí ÖÛ.ÝN¡vî,Ÿƒ]®º¶Ÿ°:86vÆ æO5ØŒk·l÷˜«* sSâZié6Ù.¬È,tÃ0â·û¥Ñ1ûö¬ÄÂì ¹%'E2ap¡•‹%M~,n©ê¢hK êÒeÅ”¸Š«‚m°]ÑU[ÃÞ´eÑ·R‰ä¿yÎUëieóÁ‡EÖáã!¬Á†[XÜ2YðLdÓm×õ¶ “8»;9\ªä~v#¦Lw¸Î2Itò´åˆEïqgQ¡Ñï—ÑÇ.i\°pÂ.Ÿs¯ÁÈvñkm—N^Çî”\ÓÎðÇj€ã7¸ÖãW‹Þ§Öøê,ŠTÂmÏuVuÏ!Ë=ñS36Üc̹öƒ9×~0i ïåxTïqÚ¯ÿ.H€7S¿/IEND®B`‚code-0e2a0c2c8142/doc/images/hyperdb.png0000644000000000000000000002333610062724152016015 0ustar 00000000000000‰PNG  IHDR±`l· JPLTEckk­­­cckÆÎÖÆÆÖ¥¥¥!s{„½½ÆÖÞïÎÖç199{{{119)11Zcksss))1Œ”œ½ÆÖŒŒœ!))œ¥¥kkk!!)„Œ”ccc{{„ÖÞç999111”œœÞÞÞ””œZcc)))Œ””½ÆÎÖÖÖŒŒ”¥­½!!!„ŒŒÎÎ΄„ŒÆÆÆ99Bœœ­”œ¥””¥RZZœœœRRZ!!JRR{„Œ”””JJR­µ½­­½BJJŒŒŒBBJ¥­µ¥¥µ„„„RZcœœ¥µ½Î­µÆZZZRRRks{ÿÿÿµµ½{„„JJJ­µµcks÷÷÷­­µÆÎÞBBB¥­­ïï便­çççZZc½½Îµ½ÆµµÆs{{½½½ss{9BBkssœ¥­µµµkksÎÖÞX¥O½ IDATxœíý_ÚVÿÿO‘2v(®T×) eà(âX±ŠLt¹t—½hÓ,EYrasqóÿÿú}Ÿ! ÉI I—×£VÈÝyç<ÏÍ뜱¾¼%ät¾LÊ'æ5ùļ&Ÿ˜×äóš|b^Ó˜öåzùļ&Ÿ˜×äóš|b^“OÌkò‰yM>1¯É'æ5ùļ&Ÿ˜×äóš|b^“OÌkò‰yM>1¯É'æ5ùļ&Ÿ˜×äóš|b^“OÌkò‰yM>1¯É'æ5ùļ&Ÿ˜×äóš|b^“OÌkò‰yM>1¯É'æ5y‚²¬/(ZŸ˜×¢õ‰y-ZŸ˜×¢õ‰y-ZŸ˜×¢ý¢ˆIýî!¶þ˺v¤o6~Ü|bHªÝ‘¬r±Ã«Ã‡ôgcúmxÜ}ëStÓw±i}¾zü^À{z· {yo;À­N6†Ð¤¬l|”>‡‡Ò]ømßÝì¯I7CtœÌ…Ãá5ô:¼n0–máýg”}Þ8C©Q+¼Î÷¿m¢ßÏn6Îâ¸~' ãñ4)bûñÏ÷7õ…Ëb!UCo‚©S|‚Nƒ/ÏðÕnÑK<Æ›åa¤ÄÜ…€vð!:ÿÍÑ:&l@=z‚Gkµˆ$]äéuíMžåp?x~ˆ‡Š·P<ˆP¹,•“Âø¦¾4b)|"¡Íp8DÝ0Bï×QÿÚ˜!ZÇ7pÀm_ù"eôíš³­âK &á0zŽ_’ Qî×ð.0Ù÷¡µÇRo£wÒø¦¾4bè'¼yŽú}$a…È=±ã)bh?™‰î ¶§ƒx!jí¶&ÄÐð¢¥,Ç©ÜÔGLÜ> &·ËÁß:{“,Ös bYœ+Os1”܇{SÄÊWÒKGø ¡í‚rS—Fl½Œ¾Á‡q\8êþÞÇÃìÆúi$á; vä€ÖUíí6dÉG‰e§‰ÿóÍ/É#áàD!Fö¡HMÚÀÛ…äæáaWßÔG,rP¾„q2Æ¿m£B'¡«>$/’ýÏ—ø—gh˜l£œ{ •¯…œ%öÕ®eø{\Ãûà@‚‡/r8ù­tÄaé«ŸqííâQßJÿáàçÉM}iÄ ]”}Q| ²–Dôxö@nZÞï8Lì±ÞJ÷ñN*ɱJJ[(>Œ¨u/ï1bÆ$ܵ ®"fNº—ÿ"‰½kEž›È‡£õ‰ýn&Ö'f2¼­OÌkÑz‚˜¾"Û“+Âœ,Äæyb‘O]=·Á•bL‘2¬?é¯àqb‘ ¦®U^k»+ ň‚Ÿ™U’¡/Mž&–¬0LMkï_ŒVísFÉUf\¾ZÌ÷Ô—ñ0±d·Î€´º1|ÉÔ5÷­^P½ˆnå7· “£½w‰}-óbþÒ<J´…îÂV%»»r°Ì¥ò¾Æ0?Ð^Ë«ÄZ?(YÀŒ4©ëî]©F£%õ¶Éö*1¬42:U,9U¦×S%ÚI'5NÓ1-g‰±Ð¯b#y?uwa¯’UfÒ+òNÓ2é˳ÄFû䮿Ó>`S&¶ïŠqô¨:e;`L"¿{E狼J,²ÏT¡ÿÖÖt•†èÃêbÒT°ÎÔ[Ÿšè™6Òœád•ý0rùBxñ+!v·ÉOîL|ù“|öz\âÿüR< âѱølïOÅÂ.Ná£ÅñÑssÞ#ç¬Gò;ýù–¯ijªíµ.…«Ñé Î>kå Ð*ÂûÖú ì¼x—Äw§Iñ¼ÿ’;còóÍ0r!Êm'zù~k‘µÏøætÔñá^¤&æ~J·‚Ù>]˜cuÍ>¤8pêyKDË$NDm5ZÅS‘“’Ù]¹UC­ã÷]òpôM¿ì's­_Þ Ä®¤«\îpƒìG§”û käÿ8åæ8ˆº¹ÜÙAYˆçF–¼Û­é ï 󵕩¥m'JÒúX bÏ ÷“h”… :8bëñÉ Ã›¿…dä°pz3E¬/ƒdÃB\Š”;‚ÍX¨‰W„x ‘½8~þ.keéEŽ1m$þœ›oX‰6uLâD?0Fœö¼4ˆÝ|Äø—·8 àžÂÑta¤UÄ·oŸ ñÆz_(Äþ ]W8'Ay‰Ë4bw`7‚Ò(]&u¬E¶mÔÊ?âäéU”²žêöäêÊ1N,¨Ò5‰}GùXAØûgµ®xPÎîàìWqñ(\ˆñoÅå½ëRÿú¶_^sÄyd/‡bŸŸõ肋‰߆/SÏñF¡|ýØÑçËðÛ§/Ëå}°O¦OŠ0 u‚ÔúÓPѪQÜ‘±Í›]\{}ú-ÆÙ“£#h‡|qtÜWöþJªZül-÷d£Ç‘ÿí”/päýùžÒѱø®…ooÎN ˜mœ>ïïâHø즋“ñÓcz`Á½Ç—š¢¨Rk‘Iœˆ¶úëÏyX´v6*øÊ@C£"ê*­šÄ‰F”Õß#ÄFu¦B5”«ÑT)5ZhïõE?Ñ„| |–œcª6Ç¢+#&q"ÊIOO#‹:('KèçÈi&ÑxS@ù¼Õ Ä”E”Ú_¡õøÃÔøã••š!æNU˜*G}ò€)ÚŠ®Œ©´:LÕBbn&bêôÀØ"3°/=q!†É˜:a,$çbbŒ·pºµ’l\|Õtœuƹ—XÀ0–µT’ «S7ßt‡˜<}‚®%À:Ö®P1×VÑ)Ï0!Ó'õ˜}Šn%Öc‹ÀÀz”ìˆDW%†¦·Ì3ú$]J¬g²3W“¥|1¦9“8‘¥.ÖÄJ6cù¥[³&ñ^VºXW+2Vºæ{1Œ…ÁÁb“HÙrW-4ùn$–·TeZ“8QÀÂèÞ…ÄXÉ– õ–i=¨LâDVÌ¢ûˆeì™JŸ§‹Dg'²™ëˆu+ƒ•G☺MWš¥Iœˆ·™Ûˆu,•ÝÕ—e=¨MâDL‘ˈñu;Q–fƒ´eÁ$NT¡7‹î"f/0èlìj`§EL¢µOKfÑUĸº½^!³ ëaÉ$NT¢oûÝDŒ«ÚœÃÖD©«hKG›a*´§ºˆ£¾ U­<ˆRÕÀž±‡…²äbœ¥5ê²2· ªMÓ1`iË’{ˆ-˜Ý+8ë&q"ú‡w®!fmQ‡†,t*²Ã$NDÿðÎ-Ä–ÌÞ•;LâDEêaŒKˆY^Ô¡!+5fdIœˆþ¡¦;ˆ- ˜‹m2‰÷¢®ý® fâ Ùf=l3‰Q¯€s1;uhȦE‹6šÄ‰¨ç<]@Ì–EZ²Åzð6šÄ‰¨j:O̦E²cÑ¢­&q"ꇚŽ³kQ‡†lX´Ej Ëè¨Ûk§‰å­=Ì5p}«¹m·Iœˆ¶½v˜˜}‹:4dåù¼,ÛMâD´CEg‰eì[Ô¡%k+¸Ší&q"ÚYjG‰Ù¸ GS–-.Ã$NDû€ÜIb6¯P—•¥ÐT–¶¬˜Ö,:Hl%À¬¬XŽIœˆ¶‡U'Fñ¥¦S6¹¨ƒ6$úE‹‹L¢ÕL¢\ç1³«p¨C¢À[h­fåàÞ)b¦uP‡D7gÀ$ZÍ$J³è1Ì\›@ÕB3¾ºØ$ZÍ$Êp3¿¨ƒ:$ëaÈ$ZÍ$Ê% úÄÒiº`‰buH ÍŒ™D«™D¹NŸX§³ „F($¨³@4‹: †$2Jöqþ˜^´Ø36°7QT>¶­–ItžHŸXR’šÑ¥N{òÚDšTk †T¬D¹IÞ'g®‡œI4Q&ÖhT8ÕL¢3‹ ú±B!N$/²ÊÛlÉŠÊN)Ïî4ž$Ý¢c!¥„ê¬ô($s+ˆI4–‘†"’šðß ¤šItO‚t‰%2±$V¢e3¾‰ªlåyIw^1è\lÖ81+‹:Œ…$6EÔæf†ˆÆ>îL¢¹ÛXDÐ(>8ÿ™+P=»Ó÷Š C… #¡D¥šF)†‰^3ÌVŒa”ž"Ôa:[êÁ¨ÉÒ¢c!5Y>TJ͆d乆 “h*"èê›ZĨjZ›WÒZ^EÖuŽH˜Ï+(7ͤ)Í\ê³ÎV7lqQ‡•Uó›mÈ$³¸2bV×X iaëcÎ$ÚÑX4+àVEÌò¢+!-ZRaÒ$ÚÑ}ÂæÓ]1ëŸÔa)$ÝE‹¦M¢)¢y¨i1]I1Fki8P+ºf²šûÄåšDK)Ê>dËcé%kb«žt»éEÔÄLŸ1’ÎÀ'SgtkmÈ$­æÚibu8BL{å1‰”!Ù‘I#E§‰=ZÔá1ÍE‹=òçèÓx¨é0±Ð£U8ŽÓšsUL¢ƒÄ4&©%6³¨Ãbµ9׉It˜†Yt”Øìgˆ©åÌýWä8HLcœÄ´éZÄæuØOÌHH*9Ó©OüíÄŒg’Æ 8;‰¥KFƒpxn0·¨Ã~b†Bš3eSli;1™¤ÞÁÒ žDQ)>ù@¨2¿ Ç*1ʪL)3fÆçónúÓÏ-³’I`{™yƒOMl Õ!šA¥¯‹|€4"ÒU*sžT¥‰1ŒÊ#g‹Ä(C‚>‹ )±ð½j¥‡|¶FÌR&ñ•û¸T.­—¬úÖð\3Ï^o±U´UI¥ÙžTaùk>ƒfS™&_`óó?‰Q†$ s¾JJÒô8È1뙘«dô­"*²Õk( ¨È£ ËK6]a· 9™ûK•`ª¦ƒÑ“µäœ ñ÷/ \-¶Š–2é!.µKë%«Lc ~ª$6U%ÁdÕÚm• OZs^OÖB"Mt½ÇÝ¿Ø0D´#“¦âR»´^²šÁ$šð;R‚‘‹O–x¬ÙDT:Uèá;æ:U=Y ‰Ø ^gö¥µìȤù`F´XOâYNàH0\“+|¡Ãöf‹áG¸6£ †*/­„dO&ͳ0"}bmH»ÞèÅJÐJo%¶$&x¾ sãÑ•sOHE´`-÷‰¤ÖBñy¨¼*Ýʈ¹'$‡"2:ç!7Ñ:Z±{9’C%BúÖ ætHEd¸Žñúk!œ¨c‡äPD«xmñÒ´ç­žØ"ùÄôõÏ"¶D™½M׆äPD~ûBê˜ÙX|bFäÓ—OLW>1ò‰éË'¦+Ÿ˜ùÄôåÓ•OÌ€VEŒ»_ÉEÍ#¯23Œžl Iõñ¡-Äh#²û‰f&Ðëðív€e¡"Ë5ÓL ÏËÖp¬l‡…4Ñ[%f%“ì^5йf{.ÑÈ°›.r±6¼Š±Y‹Âs[úÁ,g-••4–ÁX$f)“:{Wæô²<›ac –ÝÊ°Í*m°l"Æ’• €}ôôΖ…]z²!$ˆ,³”I%ÆæÕom©ÎÊÁ°Pª>L5Uf5Á!Û×+ZI®õóYm-D”‘»Ú¸Â”c+bB¦9`‚áŠmqºh¨6ÑjÄo‘˜• gUý¶>kÄ,D”g˜ªéÎ^¿U̳Å,»fó¨Ã¶ë,Ó„`®ÙYË>^D©nƒóálµU´Ÿ/©}€ªÅV‘:"ò×æuêk”ê!v Å2ÙBô:[*Á«’Ô¬ u6è%¦ÏÐj„æþnË*1‹!õT*™Eb´ ´?÷ÅÂxL,ðÊòjŽ¼‡{Ü]j㪳•cyÛcõÄþÛü¥W0zÔ9NŒü!«ÕKSž6Iwá§9:Lì±ûpžXgö¯ØWM¬È,úÈ7 b¶JŒ2ßø@MÌ>5˜æã «¨ÉLg‡ºô’¥‹Öœ2´_K°]ÖWÑ/òÑÒJˆÍº§5°úñœô²þ•à«!6ã>—cuÞüg´ÏiEÄع¹G¥2Œ^‰¹z#Z1ÞÊ·دùaô*”W}t`R«"æ2÷1?Œ^»z#Z1¶ä*÷QY}•_ôîµ:bîrsÃè¥Ëª«Ÿh…Ä ópÌTÏ+`G e\´ª?¯Uãë.r«FÛàê'Z%1w¹U£ípõ­”˜«Ü·ºâ“±ÃÕO´ZbÐ{¸Ç}”Ì|ë°Ùãê'Z11W¹º=æm‘zöN¬š˜›ÜÇj†Ñv¹ú‰VMÌUîcÃèÝ÷»rbd]¥[ÜGféÃèûoA°O«'FÜÇŠ§4Zò0\½í÷ê1¹%£muõ9A ܇á¿/]²Ë|lW¤øÜÅr‚˜‹Ü§ö—6‰ê pËb¤ô¹Ä},oM÷¸‹å 1¹e £mwõ9DÌ=îc9K>8û]ýDNã\ã>–±äƒ_‚«ŸÈ)bÄ}¬dVo¡2ê_Úfñ’ËkA#æ÷²»¶/üCKrŽŒ…Üá>ìF—–ãê'r[q‰û°w­óçͶÈIbnq¶£—æê'r’Y‚æ ÷ѳmM\ýÒ&Q9JÌ5îCå¨D\ý²ohL ;¤OL=âTÚSúÀÔ“6\&Ç0»Ë»wKV™ïíÈ+«aì3¬_¥Ë0—K¼wãWÌ_Ž%þ s`¹rüÁ,÷V\B o2L×¹ÔïµË\X»@òÃÔì‰ECn!}t0ù±‚ 3²r~²Â09»‚Q—kˆ¹Ä}|Ç|gáìQ•yµìrçbà>vw#+U½Ugê–ª¨¹‡ÕÝà>.˜]ÚS7–éê'r1üÔ î#òŠ¶#úz¹®~"7s‡ûøÀìSå{mÉ®~"Ws…ûHÖi†ÑÉ¿–íê'r±ä® ÜÇ-óÊt±!®þëe3/w#îã“Ó1À0úO“g€«?Ø\J,ór1W¸ÓÃhâê[K fNn#FæQŸ:Ã¥¹Š®¾ºôaؽ\GŒ¸ÕݾºÌ £ÁÕWVØùº˜ÜÇ_Ì÷†Wÿi•ñºŽ8ï>"†‡Ñ+sõ¹éùmx°hI5æ¨7‹«Nòre®~"7sû€at·u¹p#²»:W?‘+‰ASîビmã×äû¥ôæ„sIyô¸:W?‘;‰û¨~bç HòBì@û€ó¾Z¥«ŸÈĈû`VÞC<è©œ¼Þ@ÊÓåj]ýD.%öôÉ°ŠSÉCAt«u@PÞ½RW?‘;‰}`•ñeë“œ¾æübUÞ½äêr'± ’#+é<ÒŸ$ýKÝq‰rÂѺ“˜<“úÁÁH=¯«ïŠ¼R€½r¢D¹•}OòÄÉGÒ¤"©?(ûKæUí:âe]K rì`EÏáµ”cÕáqKvN&ãK{þrZ›ªÍ^…©ÿáÜâ7Ãø¶îˆ»WPÍ,Þ~¯iúW!wÃg‰©Î;¼vÈab´_·6#Ç°!£ò‰Ù+û²FK>1{e_ÖhÉ'f¯ìË-ùÄì•}Y£%Ÿ˜½²/k´ä~b…a_œßºý¾oK>/°·–µHŒÊÄ6° ²µÖ²%ŸÆ(—m e-£r?14T#†vm%f›ìË-¹†˜x3 ÇÑ»ÿíøÉ)B/6î™ØWáðst>D…“¡„гx¼k+±Ó$îŸoœügÍÚpgc¡óøÑn5ãO U!¼>üf¼íh#žBè0ÂÙñƒ½±Édù©X{’mýŽ6JGNß]´¹Ž ñ1:ì¢7ÁÔ)>Aç‘´´“ØQ®…²ø§!¾S6„qëã¯ø¦ÝÅýÍÓµVa»õ#BWq!8*Ûî~ú‘m1²^¢,Rµ1Ô+q†wÂ9\XKîI§¨œC(YHˆI£>:¸A;›áp2ˆº»ÐóØZÇHÆí*ï%¼ƒ¤ÈŠÃ6Ô[ònã'è$‰ämR¤îãoð†xAžHGÿDbYG‰]\{®º$çv•~ì$™ J¨ß'û%¶»›ƒ Nnoo r·@C¨Õè3¾#}ôWHÞ¶O!wè·^#ôÞ<ÿ‡[Ã/zù¬ðÕ0Ò’~‰ü9p¢+à[(éå l:{“,/‘Øöúúº$«õe:RòWè°ð):Šôû/büÎú—ôÍùþ,n“Ûÿ@b€!kÛÏ®¶÷†è5×ð:L¦Ç^±ÓPq\8êþ~I¡ÚH´‘ØÏÄÆ­â"G2TNÐÔðÚ]áßH!†‚£ó7å5¡†Düz½Œ¾Á‡ÿ8bïqë¡ÿ&qð íµî~2~Ò:¹zžuqàœþM2²ñoÛ({› sCûˆñ0ÛÅ;køijL,²qµƒÎ7ñ‰ˆÄ~î¤ å…<«‹+Û>·pd îÆy·9(_þ[ÅqáVÆ^oßM½QôVþ_T~ Ҧϲ1€IÛ¤‡·"©[‡¹7…ìëû©eÿ»Ëûïë»}Y£%·£“íÈýØŒ.o³H8x²¬HŒÊ'¦ªÿÃWdzÛ»Ð$¿^Z$FåS•RÙúû#1*Ÿ˜½²/k´ä³Wöe–&æË´|b^“OÌkò‰yM>1¯É'æ5ùļ&Ÿ˜×äóš|b^“OÌkò‰yM>1¯É'æ5ùļ&Ÿ˜×äóš|b^“ÄrkªÝÑ]Ü׌tˆ¡Öü+UÕ í®SÅçkVªÄ‚›ø•“ÉþÎFD~u1Â~ä= [ò[¿Ž”ý@,×ÅòÏÕɾò¹£­ƒ ùøÖòu½¹“2!–;ˆÃÞVüäÊ™›ý"¤F,'<¿6×ÐéèæYøü&¯@$Ô”=pHùmÿ-E”ý@l¸‡ÉÏ®¸ÖÌÊŸÛ$¤÷N…>[ÿXxkâÍëíuÜŸF£ÂÍÚ[?œÔëR#¶ßÆ8^#má^‘Ü**ÄÆ{ îˆøãÍxÿ1¡ñç r á~.úo"ø©<…>ìõ:ÎþŒñéÉÅË$.÷»aÏKµŽ½ŽÊ2§ÚÚyvšØxèùsüUm¼ÿžØSt||üò ÙOŽÏößÿ ^~SÎöôz¿¸½O龩Ò‘j?–¬…¡Ž VP<èNÕ1±6Þƒ‰Û¸Èâñþ1±'{Aôc­V“?`O!>†—/ûÏ€ò>ë+{»'…'Nݯ÷¥Fì9ä翆Àéâ«$ÞPˆʸjã=DÙôïbwçxTØÃ…}IKv+ĺ"81r×L&Ï×1œ‘ü|²sŠñݱc7ìy©»z“Íf7ñ˯‚/¾Y¿y;„W£)ý¬Pï!ú/ ∲ˆÝ¾ÍÎöðÿ~!É-žB ïˆé·e1¯É'æ5ùļ¦ÇÄ|yF>1¯É'æ5ùļ&Ÿ˜×äóš|b^“OÌkò‰yM>1¯É'æ5ùļ&Ÿ˜×äóš–N¬š×ÙYªd¦ßrK¤“®L¿í œS ,7& Y&VäÔ^>¨Ð9™CüÔ» êXæAóÁd Õé·LlñEªXȾì‘Ub1£òÒ¨zéGo”z…ŠóÛ(‚™Ÿ^|Œ)($ EOŒ‹]o•:”°¡ëë*K^†¢±Ò ãØâu"¦ò´ŠÅ@O©K™@è¾èçaS4Êvä ¹vÉeäÿy%ùR§Z"¿2Ò†¤L©JvöH{ËóT/ö%–dØÁ¸–*qe¶[pP QmluØNêm$ŠãKÃañ | 4©ß<Ësã0ê[r@y«PvqœòZ~3Þ äó$ N¾A*pq¶È*äf8$“éõª(òìtÓbRôĶÚìu‹¡@½*É/K¨Î& ©CQŽª(DÙRŒ­ôä7i6ÐTÎ0ùt‡Mõ*ÜúV2'Ÿeà^£ùTžåc¥&¹çN;ËÔ¥J'•f <4PÕ4W›Õ„”acù¼ØËgÛÑl ø  ×Ô ÙECIDAT,+2Êåå`2Ã5Qq  ëJs[(Ár…WYùÒm–k²yùNà;‚œÿ\E,f!–X±ÀU…D•ÍÀ+¾s¨H=¶R5¸¨Ô© ÐÔW«ù,§ì†óò…vÒ, hšmÙ­k6„•vã¶:©S’[ÊpÄÉ‘R‹žØµÈ”Ø(Ê°¥f'€*òË"‹!žC©Ì¸65¢l¥=.•%†-ÊÙÅ€S”ç¤_O@Ó>Œc %¶×†¦Ã¥‹\V.ºQ\/°QØœà}¶Îÿ¢@ºÁ&ä€Vc‹ÍÔ§¼ f ‘¾±Á6$ˆåY V•Ha‘¨·ÙŒQã! %Å"õÚ¡,òYØ»³|¦Å3‘ϳÕËÀÝ4C$ÒjŒ4rãÝÊ}²×lAІ¸81TÝ   ¥¡‚In*l GëVˆEÔîÈ9ÃRÇÄXIãÒwÂ¥…qÿÝ©Ôb‚Ü2 Çàþ›p³=‰Í@nä{‰6J 妢@¶„ä_UÈB6щEõX&íQ‚ô „XQâ™ißB‚iÃY1Í6 Í*êb áþ Æ&¤¨Â˜ $¥±Œ¦à¿T=”è°y8¯É®áIõïHEÆB£Ð‘X^’SïVîšùW‚T¡4#ÇÕd®+)/‡-«¬ugôÄJJË9SÖ`†X¯—FÕÉpl]áWjëXQ’÷mA?!A…„;‹AùoÊ5 $D'^‚ *ä_!rÎVB!«Ãè\©ÇÞÓ ¥Ih‰u±-²IéT 16P ÿƒÅè°¢’&¹|†Jƒå‘<þè[OHt†5àDù·'rœÜ ´J÷u`K 1’l‡Í–ØR:ßÂ,Ï6ªy™X†•JÐÊg“V±•‰ñÐΰí’|ëíb •XŽ™"6È0"0ý‘`(ÊæQHnÛ‹èš  t©’•‹ipUòÊ=§Ô1^â”ÅA«ZgÇUHø$(“PK¯«EBŒãÇ»Ç÷I²„ü*¾Ð»‘¸ |\+ø&v^ÎmF"gè zte˜…&¹Í_¡&B=ò’M!)-ÆXÔÞ*(æªÐ섶ŠQ¹‘« FÉþ+µªÆ…­d``Š188•€6ò:PáØ­t½ª¸©h¡ZIpvn¾— ·—n†¢ð+†² >“N¢¶<4–¸XG'•YÒŽ¡t;›ç!  ’¡‚LµÓò™v©R—£”Rõl“´s!¹h¥uhÇÓh»Y‡‹7Hy1 ¾•Ù"‘v¸B4šì&j¤*õ(1 p'Õæ€Ü0xç­Ø”Þ‚’z݃Ó#ɧäøôfôdÁÝ+ÆœçåŸñ/È ŽüÏqÃΙûÚ<ÿ°ilS-¿ÌLNˆ6¸)#,oMWxÅÕ=ìSTªô}ƒ#ÃeÈ¡ ‘ˆ†?¶*àعé!·ìâ … “LævÜïnDù© ȉ bçQ"¬’F¾r\>¯HZ¢=žk«Ø‹ÊÙ9P77$Š”{Å@uñQS‰Dç6!•‘=\7amâËÝÄ:ÍÂì]Å„JñÜBuÍ‹D5?bDÕJ†¦2Ùæla ºJ²)‰rfg"wãx~¶@ªl’7ë^ăA©„µ¤dÝMÌ×¼|b^“OÌkò‰yM>1¯É'æ5ùļ¦ÿÈeZË°Î]qIEND®B`‚code-0e2a0c2c8142/doc/images/logo-acl-medium.png0000644000000000000000000001176510062724152017336 0ustar 00000000000000‰PNG  IHDR¼J6\ÎÜPLTE1Îï9B„9”ZB祌ïÎJJ„Rkïcœ{cï!”„Æ÷ïœZï­sRÞ”Þ÷ïµJ99Bs÷µZ1„ï)ÎÖ{{ŒRŒ„c÷çÞ99”BcŒ€ckœB!÷{„﵄œ­¥Þœ¥!ŒJ)çÎRÎ9÷9µœœ„c)Zµç{c9µ¥)k{)ï!Zµï”„÷J­ÎÆç1k½c{!ZçÞJ­J1kÿ÷­!œ½Rsÿ)ŒB{k½ÆïZ­÷”¥Î){Jœç)Bïs­÷Ö!Jk{Z÷µ¥JZ)1œµ{sc÷µs„ÿk))÷÷Öµk!¥ÎZ¦ÊðJ­½­œZs{{1çç1BZR„RR÷œZµçk!Öµï÷½)÷!Îç)1)k¥{¥÷„„J”÷„Ö)œ¥Rµï9”ZZZÎ÷”ŒÞBJ”ÆÎ1Z½­ZµJ„{­BRÖ„÷!÷ÆZRcJZ÷Zœ÷ZZs„c1çZZ÷JZ„÷ZsÖ”µ1cB)Z!Rœ„!1sÎ÷¥Œ÷”kÿûðs÷”1RJ÷c„÷RÿkµœÖ!Ö”έ!{skïcB{{Rsÿ”¥÷{ks„11ÎBœï1Î÷”€€€½­R)9ÎÞçJœcR„!!Æï9Z!÷ÎcR¥s)Ö)!)J÷­B¥ZÖ¥÷­÷µs„÷Œ¥!RR¥9¥ï{ŒB)J÷çç!)ÆkcsÆ9ƽŒœBcZs1!Bï!kçïc„kÖ­ç÷ÿÿÿŒ÷”ÿÿ÷Z!÷÷÷Jï!cRçBµ”B„1Þ÷œ1)c{Þ÷µ)Œœ1„÷9ç÷ç9÷­­÷Ö­Rµ)Œ„11Rs¥”9œ÷k½{çs!{s”99Œk„”ï1Z÷)„œÆ÷s½¥9Îÿ½½J)ÿœcïŒ{ïsZ9{„Jk€€cc)çkc÷Rs­Þ”÷ÖŒ÷”Îz5tÔIDATxœí›ý[T×µÇÐ.‚Úæ¢8¡Â¥€„ˆ ‰R•ëD$XH#hà†¥âXS¤ÃÄ”¹)Šå¥áÅÀ½£0Ä«6R|ÉT­ã €Q±Uˆ’Þx)ñ¸kíóþOž§ýá~eÎÌ™}ÎÞŸµöÚëì}æH¦ªAS?Ër:ŒœNþ£Ã1j:'qŒÜµ–‹˜ãœ†S';Dn#:Ef€Ä¼Wŧ8WŠÔק°d ¸/iÛ9´Îà©g‰¬€?Åùß|5‡1 :"Ö(/çè$öˆ¨ç¡üüüæÍIè ”{½0)hLë˜ ´ØK®½m°Xi³•—ÅõÙΤºááÖë×}ÊËË}Bì”X4MS™IÃœZ#"ZáèÊûý¹àzÍ« &<¸=Ï™søðá„„†°šnôõÕàÏÏÏ7Fv¹, ‘0sïÎ:à!tuz)<)OŠ`”bÞÁ½½ý¾¹¹AS„çØÑãHžàö¥˜n ††úËðyþ|£>ʪcñº¾Îˆux–™qB>~€¾ìíEø  )Á3!3‡uz“„Áúõl%8rÐ,Q𣌑×4б/\‘„zG ` %ÐÇŽñ®À×8ðí·iiAZ¾W…¯Föÿö·Ã‡ç²ªZÄ4ãªJ†0ã !ò -·3²G‘Ê™©„oå‘q{ û*?<‡£WÅW…öUþö›;skjj²kp3ÔnaüG—egƒ1Oäòo¨j™˜¢,z’­" jðrùKè݇gØ?:¾¸øüùìâââì²¹v¬k²kÎ×à#ì°§>D3ÜYo5ø' ê]èÑ×4Oh£Ò_LŸä`ð“Á;0fþ益y•µG }Pßð5ÙÙøº79;x8r0a0Ì¥ü~Ð_U<}jܫïúð›Î/_ΰn‹²ˆüô¡+{îP•EA¤"Úþ`Ð_ ¾!çåÜÎáx_¤W^¬”ðˆx½xÛI”ZÛËŠÇCÜÔ»rªëÇ ¡aªRzÅÁ¿sŽ/&LEà«Á“Ñ*À—µ/’^rìeç‹Å!?÷ÎêZ¤.kW]­Jž¯ö)÷Ë+\[‡‡á{¹Âì‰Ù¾×ò=\leëf<8~ÕªßÂpåâ½f[£EÚÝ^FŠø¨’12kkí´tÀâ—åÛA匸wV>>×÷ÜÞÔߟ«˜*(àÙ4É×5*ºÙÊÒ³&”µ+}©­k!vE7ê†q2–³‡ÄòòDnž==1Ñ ³€Ï• [5xL5„}y!lÚ;dnÂÔ&‚Ǹ²LÞÓ9½ÁØÉÎŽò¹€‰àfíd–Ó¯œ)HáqNÃ8¾˜|áòâvÕë&fœB(%Gµ/š„W2M£?SXƒqÃ~l7Ie÷‘é |_ |Œœj xÂŽ9~ùr`ƒ×¶Fv¾Bó”W;°ÃpÈòÂvwS #»J¶‰ÍMÉ–Ÿ 1“4ÀïEï3£VÓä* À&ðÛD^¥­VÁ‚€mP^H^ÛvXÔ)­êÊT…ÏÏOEäËÅÓ¹´÷¾Œž’±±ŽGrøkç/œÖ‡vtðœö¯yøF5ò€ª°ðð¡ðö5CkÖ¬Y½zhõꪪըª5xcÝ[‹23/wÕ‘˜P¬Òî·!½&ü*f´.'*²¤¥Ã‚Kk&7É¡_(d#«=J…Ý5øì'k×n];³‡ìlv“]ÿ¤¾>\™› I]—-”ÙLQw&)±ÙÜÓÚ ô£¹B¾¤$ìii«0K²ð…eíÜ•ÜrÙkëÝ»[½`ÅÆù-økÈEä •w=°ï 6ØëëlnjÊ\Ó²ï ©ÀwhóéW_=m¦ ;eÌbµâÂ0á«eð$àaRC¦“L läF¨Ë²õóÏ_¿»ö \ ½\¦™(­ìòÿœ_´Þô¢©3—P¹ÂFYÍ?øýüÕÓÉÔå:Mv '®¯>[-ƒw°óô<Ð×Ö#èJÆEÿéóßýîu€§-œ£éöœ3«ÁÛ#ÂŽ…æƒëè—¥ðs宅 Ô™ ð?BxKÒDð·!êŽj¼£šY=AísÙ‹~?³XèçÁó¯oõÂ^ྠ†€>_3´^ ÒòAÑ`è`QQc½6[ŒÕW)á7n¤NÿàçÄófj§:¼Ob9G×;ä1+îçNÀžàÊou _yÀß} ž²Áõë•W±ª–ÂÊַПܩ™+V½:|2„<}r2Âwj¹^ï[O`ÝÖ(@ç·>ÿüÝç½^˜Ó_ÂÊHþ“–ª¢¢ðGö¯µwž<¯Õ²u#eFúÓ|§Fä`ØŒò醅Ç;’¾x{‰ÜÙ€þªD·ì”×VFE´–°F††ªÀÛ#ƒ3=zÔb‡»ƒø‚¬s‰«”‹p ô§1j,äJ¥îûÖÛ*ðÕÕÎ\_r/’[4ÜûÇð†•ö¡ã£Ä™Ñn4C”ðÖ[vk€Ýn¦ƒøK×Fƒa-Šã1…}2°S{ÂÄL /Iôïw_r•a¥÷1 úE4E-º&Ië_]˜[´58ØJÓ·ÖájH¼6ŠlT®\è_csø}fR§{"À/#©R”›Ûß»´“œFnÛC$D†$ýä ëÛI]x«>I¯¼•gTµƒ±z£«3†}©2Oµ6’·¨IÆ$£1‰Q]]>ñº<°ß_Š£„5YFH""ŠBB¢¢BŠê’ôÒ¢L½^%†!î¨ ×ß*uué‹ô¨}Q‘þšEí‹ËåŠÚ{-„ÕzÔ½¢\é“ž'!/‚Ç÷·-íleº {K/[“’†#êê?Ô¾,)2wÔ6z©¯`ùy$MsA‡¡‘©VõpÑÔ[À +Af=˜ËÁ#ÌxupðÎÜѶû0íám¬“ Y ³Æ——Ëàië[!î.¿ OG—JÐk©C´˜½àS™ºiÙè¨Þám»}ûz¢wPmˆü†),ÙóóÊ_|YVh ¹7xŠºQû–ûÖ>$+sFy *SS—ë¹8ï=²)uÏ…žóÔø¥77º ?>ε<žåÇÃ;8ø¾•3âârr ô©ñœwÔ|²ûå\zSå€ù7Jñ3šDLÑÍŒ¢“'ßt¯¯¾Âv ùSpšŸŸþ´ß'À÷õõø ;™ñ5Ojx*'C žz÷¿ºƇ2Nrð'þÕìNÜ•#–Ÿ_>˜ÐÇþ¬Oãûž¹z5.îd`ξ“'©U±û¤P:<ý÷wþ:}(#p_à>P (ã'î˜û`åäà+Ή‹CxòTˆ~s\`à>îGU«ØȱªÃS‡f¾r…’ßý•êJ!gÕýþ+ɓÿHŒ%özÄÅ]}æ|ïá±oŸG…F}7…fþA½™ÚÎÌžÞ³ÛcŸXÝ'®L4JXxÑHõ*ïà7/ôðøôÓî÷¯¨WvSh×£Bž:Qaû‰ö(Lþ{÷§rUØžžlؾÔ-¶×ÃcóUâz1ü3›vwwWØŽj8â¦Ð°6ü!¨àÌu³§IÉþi©Îô¾Æ <¼ä„îîÍ›%ð±}ééMk!À—––2èÔáir”ÎöÊl% =û}“a™:JQÌŽÎC†Š6|©Hß½póU1|lzssAAE…­D¥]FžºÒ±±1¦†¦ìµ`5cd@=G¯˜™ù;ÎäÍæ+/™t:]©†â›L¶-ÉZiÓü4Œm‘öuºŠ‚‚æôt çà¼É³ÅsölOOÏçàŸáÏ_Ås§—ê¼cž~úæÓ¬nÎäùÜKß­3Ùl1'Žþp‹§ç–£Gž)±™´Ð±Æ±øø&o›íÄÏÙR•ÙÏýjL$8”…e²ƒÀ7Û@))Þ&S+v½QMññc#=#ñ(·UŠÛ±²­B×=[*(`ËM¿“JâÇ$‰÷njò–jÃØŒô|;ÕÓG5Ù š>Ö)À ÄÄØR.nØ€å#(¨Ÿ¼Œlèéa÷` F¡c‰Ÿ·6lÔ麻yxìÎ GF.^¦1™zd:Õs ô§Sß3âmøØXnzÀÑŸ™uñ"ÒŒô-«Þ›í SçsÁµM¼z!ãtôŒ%ŒGb 7ƒ<ÂÃóµƒÀ±c_L¬SÄóM6[³þ,ÀÇÌ/)™y†àóðx±Ø&BÝL4>@Dv„°a¹›±Aú[œâÍVÅöªŒþ”ÄÉêð¬ãÅìôóç—Ìœ9ó•3³fméâÅ)¼« ö¸4=–S:1 Â.&¦™;ë'"öa!Ôsñ"gÁìÆ&ooÆ‚ÿÚkô¯áßk ô¢­™wpð°”âéÏ€fÍJí²c³™åŠËÉ#43ÝÀ™F¥%¥óA%%˜‘®"ŒøI„ì)¶†@t—ØÁÒÏŸ?“-ˆáUR.•8Tô¤2yÚ™ç!.ƒªJø !‘ŠdÃ.!Ý1HAÀ±ÇŠî0CèÑGÈ_RR‚;R‰±ø§¬y Ý!< +X‰ml÷Žbw™ ñÑ*ææ¾ãÐ »þ¬à"A">Xœ2p‘;Ÿ;FR&  ;øR1kV3é…22á€C£Ç™øa1D‰RŠ&x9ƒ$ßÊ°ÎJÕÍb¼¤R¹LÄ_1[gHÐâˆaÃ…’â(¾ )¨“ gP ?Ë>ÁÓúäéû Écý2 &”-aÐÄ.®Ã¤m?¨‘&xP…S'wG“Ô sÛ’o”þ“þþ]‘NO\Š"Bƒ4ÆÑ´ÿ·Î?ƒþþ¥ÿkäÉuPM-JIEND®B`‚code-0e2a0c2c8142/doc/images/logo-codesourcery-medium.png0000644000000000000000000000531110062724152021273 0ustar 00000000000000‰PNG  IHDR¼J6\ÎŒPLTEckkÞçç­­­÷ï便¥ccZ½Öç½ÎçÖÞïÎÞçÎÖç199{{{119sss))1ÖÖÞkkk!!)Îç÷ÎÖÖç÷ÿÎÎÖ­­¥ccc{{„ÖÞç999111Þ÷ÿ”œœÞïÿÞÞÞ””œZccssk)))Œ””BJRÖç÷ÖÖÖŒŒ”ï÷ÿµÆÆ!!!Îçï„ŒŒç÷÷ÎÎ΄„Œçï÷ÀÀÀ”œ¥RZZ911œœœ!!JRRÞï÷”””JJR÷ÿÿ­µ½Þç÷÷÷ÿ½ÆÆÖçŒBBJï÷÷¥­µÖÎÎïï÷„„„çïïÎÆÆççïBB9RZcµÖïççÞÆÞïÆÖïZZZRRRµ½½ks{!ÿÿÿµµ½JRJ{„„ÞïïJJJ­µµÞçŒÆÖÞ÷÷÷Öç猌„BBB¥­­ïïïçççZZc½ÖïÎÞïÆÞçÆÖçZZR½ÖÞs{{)19½½½RRJkssµÆÖÿÿ÷µµµkksÎÖÞ§mÓøIDATxœíšŸWÀ§¥¸çV‰žšJTlÑÒ›Ëb¥½-ö¶Êù£6•Ú†Y‹K®kŵ¥þã¾™y¿Û˜Ëñ©¦Ÿ °ovÞwçÍÌû±…áçX`×"{ø]É~W²‡ß•ìáw%{ø]É~W’ __¹BüÙÃ<¬l‡ùiâQ/¿\¥áOWáUQ}FY‡¯@iùñÇô«}îݹsvÒn ôŠhh]=à“4ü¬R ðûùq!Š"Çq&‡Çí. Vau°2ºõ~å³wsÚ}£–‚Ï5®=sq.\î ¶3âDïþ¢J¾R Šb ò«ƒ$^­_t—M>LÃû‚§{ãÉóa{17‰ó`r­²–»!¸2J°Cí’ÁQ,xáËäÖÅáIûâp¢Ù…÷;?|g´vWPCöZV( h3}©µM÷QÅÀ ¿Ç¿On´`ÀÌ ßÁyJëw•}dìmÀ±°\½lp ¿Þó&ßh"éqb¼WÁ_¿i‰ìÅlƒ›žÇhÜ0q)¢àC‘«®7q¾}ÈìÃ&µ÷–7•·³gÀO— ­DÁ‹@¨yoÏTN'‰ÆË$>ݸ§)ø¦Û n‹¨Ùˆ»Ë _].œùÛ“¹©2Ñõg¡–¬%›/pc(K¥fb1‚À¥iU¦©]–‚₵¿[*5˜¢¥nÍ.¿É”<&ZÉ@·Ñ[#¨%# ~$ ¼Ëë"d¼×àgY¼Ðó×åî)H!xL"À>€£ m ÒA´uҸ–«T9Cøi•Ÿ[ó¢U8 ‡<W üLüúËcBF¤jçß_‡/d±ã(iW”—r B¯W‘ðaL "a*æYv‹úÏ…T—†R\êÃDݦ p«­"Ùba¦š‚íïxgjÉî½›ÀYìä 53¬‚ N°] /fA…ÐJää5í<õ¿dÏã¼O3™¸½1 »¶ÝZ¡0äÛ ¼ˆš—ÇŽBÑ~xò!ÀÆ,ÏRäa$éaçâÑ“!!Œ† ^÷ǨÂNn)í’Ôfø&{dŠÏ`H²®1`µæÙo-†Çz±`ù½ð‹× i®SKÑÑPߧØ:¢J WÃçh5C„2ö©Ä*íÁ×¾ÉÑ”ç œîÆ€i¥xñ©©†ÇL»5¡êÎŽ÷^±Âz¸êjµžg*V¡LÐUÛ9 ߧ™€‡wªâÆÒnRÓŒ' Îô‡¤tLI0­Tv‹ªM‹§„×eº¢ó#o àôôïß|öé»ðO Ü0u»J¤3ö )—ìÅWUÁ—qÃÚ!ix—?x5w¤ ãG0­ä‡ ¯áE %ßµàÂ׼Ѡ¼xîÇÞ¸sppÐù)y—n1Ók“Ii0g<.Qa¯µFÂ~Tq³´´>4ð}28RŽÑV+å[<ÓÔð˜âg‘cà£×¿yÿîÝ÷®Ý<ó²þ‹Ññ«*ÀL:œv|¥ÉñÂðºä—%R¯kk[3PÌ55'XL+Ç=X áEhxW^MF¯íœu¢HMZ…•¿-ø®Fè‘Ý@Áã?ßr{§rdqœmí¼ÌXÙVÜÓÔPcB‡M• ˜Ü˜X𴞌äâLÂÿ>Ãó®…#ýZ¤_å( FÇÔÖvɳ)x7mÛ6`uˆßO}µ/#x¬[ ï8ÖÊZ;/Á·øþ$ Þ¥…ü§¤¡ú¡„ãÆ~ÔÙ§ÀÛlx,iE­ÿ ¥[‡:cÍan.]ÀWùDÁÄ¥ ï§áÝ4¼OµÎÖþ4xw ¼(ÁîTÍŸ¬!ªß‹ǸY†Žç…›:ã§f7mpòêûQ|•ÂÖhçþgxq½«ž5„»þxý6òÞÞŒ˜·Þš;~ ¦jµP4 ­ž®‹Måy†ï¦á1§Vmª)`^jw ¼HäŠÞͳ†Èß/¿™ìœÛaƒ~ÿzSâƒ^ÛäAMR3å+n0ÒÇakÙÈ:|YªmÀ†¯Sý,Ùð7ßë8ëìj™vöh˜MÉ ÔdM­ŠAsw!­|d··`ôd¶6úxFþOÁ÷Õ¨Úlø€àý¼èù•“‰“F—?#oûäB»‡ºh⸠¸dÍx!ÃÅÑÞt¼­¨ª–¯«F5° Øðèf€z KÐ÷;‘“ö;þ'ا0Mr´´W˜Ñ§¥K•¯2<> ½ÍícœÚÚ˜9KºGÂó$‚Q±RRÀ^%¢ýX5ÈOá·øøð¶ Up¢ãÀú™ÓB"‰D,HBþ^+b)鮾a–PœŠ¶JPfí<¦f“¹ä⥦˜«uÈ9¥êžNiQ%ž;‹6¢þ¯Ï4àok켋biQWûº¢ô®”!Ÿ4‰gqÉež•,‡)m†âˆY«¬}×mj.išã׎'uñ\zó…uøÅzF²¤È]¹QX„rðÄ׆¬q9VÁ®ã¶GÏ֦̖•áU/ºèZìV® ªx˜jŠ.î'v¡q ·+Ü,éâ>CÑùÓ]ÄGa_1åiݲtù¡•v7 ¯1Ä6Ö2›¢ufkM%Oýâ{w(O甫‚=ûûÈ»-Êâe¯•Êæ Õ•¿ƒUÏfè|m*«•­]KÎ¥K*ËžkÊYÎÍ+²ÕµZ­ÅIú|þy€ï\×qＩ7 "aiqyoTf` ¤ßŒ¬ðƒ'Ïyi?~iû&|g‚gzìÖÞIÄàþêÎXÌŸý ¾òË«fÛ_L‹‚&GSK ¬Â½ñ6ð©?ý$~ùÝ7<ï ˆ~eŒ[Sÿf:¼ ö[½¬÷°¿Í??ê߇dó|øêä_Ÿ‘û`ïж¾ÿö:sµ¢àc t\=LÓY²|,¯ï^Àúã÷x~º1KÜÇô&æa%A‚åe$ëÞÊ*ù[áýÌ÷”W/£b¯>:rëÕ¾[ßhÜóG‹òc¥º ù?ü_V>'²‡ß•ìáw%{ø]É~W²‡ß•ìáw%ÿ2ŸÂ<–#IEND®B`‚code-0e2a0c2c8142/doc/images/logo-software-carpentry-standard.png0000644000000000000000000003147410062724152022755 0ustar 00000000000000‰PNG  IHDR,¡JúrõÀPLTEÿÿúî÷ýÿÿýÌæù×áæßðûÜÝÚûýÿª¿Í²¶·©¬®úúúÁÃÂÄæýöööèôüòòòœ ¤O<ÖÖÓ†ˆ‹¹×ëÕëùããß¿á÷“•—ýÿÿýýÿþþöççæÀ©wgge»¾¾·ÏÞ÷ûÿõûýDCB./,Ìíÿ##!ÏÐÍýýýÈä÷—€Prsqíííáíõ{}}VWUÂâ÷‹IV½ÜòÇÉÇÊÙáXG/÷÷ìññæ‘UƒÅ IDATxœí]‹{ªº²¯b}€ RiUJZÝø-.ô,éëÿÿ¯îÌäA@´íÞçÜûÝó­Ü{ÖN#$ÙÉ<’pü)ß.7ÿ×ü*ÀúAùÖÊ°~Pþ€õƒò¬”?`ý üëåX?(«vÇc•ºµã±Ö¥j]UõÚg­tmu Zy•QgØ×€Z»¼–©ê€:˜Ã»ã·»:ã$À|Ü*ÞUÇZ³œ°n0>nÇ¥k5D'ÛÔÈÖ’@­œ—·Ö5¢J`5GXhœùqt<òzu¤ª]º`ð*´ŒÁQµRõH£F£ÝhTƒáÙ'šx•Àb5¼àˆhÍ©:Â*£8ð+´"}‹¬µZJX}¤ÆE ;|ìzŽAV|° –#L0)缕H8*jgU«5ôX‡ak¼ÚíŠ~ªUx‚¥&Z‘è*>µò*½xŽù€÷^­ÂÈ7ŒU"¤ŠHòá ©ŽÔB¬[Xð濯‰ãªV1.¢Ý½Í³qáÂ*uˆ­]Ñ ãB•Hhâ+c@« »lò1€I£l]ðqñí(°8-U9$@ œÃðåUå²*FbL‚Å«MñÚ&G†ßUEHÀ‰¦k@« ¼Î!`âg9.PƒÕ¦$!ã.ĸ5jœK°HVj–]P/FÔÔç(ºë¢µÊ©ÁÞt°g!£‚µ œ«A‹!MMa=ãTh4u3°Š„tA»ÊÀ†¦ìX‚5ÏÀÂ*S$ˆqyƒnq”/«–š"Œ °X] î?Jëü·–à,…Ð9Ž:ÓéÔk ¬ z‚û®E4u5°vç`Õ5Îb|ä ý ÁªæÀ’„ „ˆ –÷$†ËƒEmK]òäL ‹$÷ThÔÅ[¼ËÀröýhj™¦Å4íck®Ê«’Òf,)¹Xä,E4Á¤ÀêÞ‹WI¢”³ÉYbÜõã01ïrÜÝU1̳|¬3Ó¡Î.φBg1gõš("| D}j¡?£é´e·Ú9#ç¬ë¦C7ÓY‚³^°ØÛב#_+™zØ[û€X­‡åªåh`±j+9Ü-ßß—wáýN·ïvßKê¬z9X™uI ·³4ꧮ—$žç¦‘(©åº–9µ©¡oÎM%bHD×ÎÂ×(…/ýõ¨I3"Rœ_èòà})aœuØøŽ0†QUt¬åÝjy·\Ý­V>Ê#Ë¥ì¬2XNÁu–²¾8g¥¬†¦V{®ëzal§6–È;ðZàeÖÕìQøǪ>u’¹ØIwg°pîc ËË‹ß êëV˜®é>Ãâ`%–·®×¥»ã¸«»%`µ|?ÞcG:y]5n‰ÎB«µ¢…Ô(—Jé,¤uq”îú%b™©í{­{PÁ"=øétjOm÷pH|Ï-º®ïYànŠº¿ ¦ªMÁ9è6ËÀ¢§ð ÐõCßÖ¹çX¥ˆ”ÄJîîÂŒð%XჷFï˜f¡Ú ™êýð;|‰_BËiŠÇGš\ %5Tå$ÔÕ¸XÍÞ*il’§M¸ÎyµË4°êƒÁ<Z¶é¹#g„²¦·L˜­0të‹õzÝŠ‘½–­uGBðÁ<ëbÄZ­&[ƒAeU1VmÇ#0Á¼¾ÞÍ\ÅXˆÖûûoÀ_µŸq–¿®Éq«3€Š€ üµwˆW7WÔ`µžVofԈȶJÿu ÆeƒÚn …hÄã­©åMw²Ûƒ `µ¼C‹þd¬îÁôÞ,¸^²ßYi5»€m#€ !‚X½ X‰Á6<Âj :kåe·±Õo@ .?„ý-+á9†êB]Ì õœHVF®V qÚ ÕÐÞ]ÕCõvp{Û,'éï•>ú6ζ¶û.øê)*øUœ=R`ø‡—ðpxùË«FyÇÿ‰’µ“Óíé¿mãÄ÷]/®ªÆ.½½¿[z€Uòl•§§§—ÀʪÈQ„jCœoµÛ +IÜ)ðäÇ¿™ž«%  Jó#3ÔêIbÿ'é) %F`VÖSÆ,‰ÒY«X¿ øÉx2ü¿^úÿAÚΊË0­Ioå~šË/±Nþöð€Õ‹—ýÙüëýîýC¬$ÓYañ^VZî´¤ÓÉÔ‡ým¢.+‘ýxcѦóEFdŠZßþÑØÆЧ‰ðêa£ßè[ ²Lý’$3JÏÀ ‚ŠÇû|Ó>5½8NðÿýÞùÿ¬\M…%+hmz_°VãCÊ‚þHbÛÂtÿË6ÉÄ"õþþ‘§€tŠá¡¤‡aœXÙKÞî(DÊOm/L’οYù_‹ùnÚ··×.’)'ŠÅáíOÈó^òÙX¾Þƒ+1Ü”e¸q<äÕ‰éJ`ÚXÓ>ÍQ˜¸ÿ°æ`“Ö¹¹èB}!Z]»RI´ºÒüÔªA.íîÆ”5±µ–„n@–Ý +ìdUãµÂ(ë±^!$ÆzAÓ3Z !ˆUúª Üt ÎÚ„¿$ŒhĪñéÅÞëmƒdx üÙ§ŠAÔoMR'>¯*Â'ŒP€V‘¤$jªXdÒ“—·ÈRˆà¹Ó§ÁÊç óÕקϔ»÷@¯­Gá)«¬¦rràmQÖÏ0 «Í‹à«‡;p¦>)¸?ÄS«Eh8X#éfU3³$Œ §8ô¬û‘Ø$l½ã^r`ê–{>Y•Q֣ë)rk57â©kÂ9ž×0_ZåùÉm=·Hµ’+¡U1fVí>>mô$FÇû$óž·"Þg©ïh ®ˆð»ÐW«GëŽÿò0-CÖ]b™³_†F \ÜM¬Í* —±S“éHì‹“0pf~ æMâO£õÚáþ.Q3Zoýě쎣÷Ú"Aä[U•Õðg|òýž†Ÿf­¶Ë"J8nMEaé³,…xrÍvðÊ]¨]¹Ú©âhÞ=½>ulLÿ€Gì…aJá  ·TÖ¨x0Ú:zY­¸Êz¹ _îSp­Ì~ r>ekÎY«ÃrµñÖ •…”q4 ÁiÞŽN»JÅÈBj\*Öíaòòb9ZÀHFk‚\B“Ö¯T¬{—ÑÈ=‹gíxçl-…xB1œÉ¼áH‚Å«"‚tßúH;D)ˆDèV‰W×™ë)žk‚äž‹ËÅeÖ÷;óÖú[`–Ñónmc'\ÈhýY¤ô(Rt«¼ç{k~³(ÌWM>zÆXGÀX¡Û=ª€$EÛ»EÎ ‹£‡+„{^^~ƒr÷ +ÛjcÒMÄàÛRððŸ–Ó<‹ýçãÍîtUjg5ßÓ°²8_M[¹ôýYemgmâ‘XrT Ö®,§ÙôH-@á\ÁŸf–’€-ªØ÷­ÙIØY†ñá'Ì~ß軧î;K¥ÜÎ’`s¦›¶Ö~ØÿœzKÔ–[Í¥ç`QÃLi,KI¡=Í2Òs¹lmí>g%Ùú,M bQV™é°k>õÁÙ94×çœÕM­8Œ= ^ >8âe‘ßFšÛøscj3œå9 ݈lz`Õ,eÁŸƒ…¢R­ßG“aÀöþÃxìÁ„hÓº<î—|œ-ç!qD)t5PÙæ,‹ç¯ÐÐ'1L6ÞŽ/“ä,"ÁjŠµ‘Y3ëÈŒö g-çÌÎÚÚ.:“¶ X¡Ñbº>Ì͉g͇?f×q¬¤Q&I=ªê`á“‹L¹rw”tVCÊÞ(C±êžèxzÂw`Ù^Hë­vGr1û†Kl3ÿ»¥Å­¾_Ôî–¶ÔVxfU MÅû(“¡Ò‚GF Ö31ä|™d­üZÓ }[`E¢HXáª*Fw‚äÞú•J¦ibwÅ`×wXxi%H¯^ wyþ4JAúý³L+ûcïå‚•šÖÌú±Vdgår;ß/4µ’"M¸œcŠ2P¥)®=XáÔû>Xdž;…I1ìhÙ¿ë`ùiÓH‹Ï_(¶‹«“"xAÀÏóë׊2=ÃÊ¶Ó !`“ÂʹëOÊÐcï)ßÖ3ýÐÂeæ´15-.ˆœ"—¯ˆ¸Læ}T¢Ø®h7^Á{iûKΚº&`•¦øž¬¯2A¼¸ +©°"³]~©1å¾aü7“—•!ˆUh3BÓîOц·ˆÎXHš‡¡|0++Îáü•*u©0×òM‹˜ÚýVÎsâe¦;Ç*6.\‹`­ñyÖð›Å¨Øq’O¹ÀX>M„}2Ì~£Ÿ’‡ê’*…yקùžkÇ~îÎ/²;_묎ƒD\ M«,çyV»k +µ/J™Ãït\Z>ã8—&Np%•‰ZÖ´{ŒÊ$õ9kTf?µÀw_ÈÊáüg^€)¾¥Ðô¿Ê›añóX¡^Îi›´Öáoë¬ h'qŽm;ÀX.’ ÿ?µúÙœæ žÆN> ,(¹îW`_q–kÒ“s•e¹ßHšOŠ ôÝe( lEð<¾î÷Òp*µÈKdÇ¡‰B˜Â𑾰ˆm¶ò´Ñ—Xy¹®¤Õ­+¥Z)Äà—›nHµ6ƒbµÚ}%Ý’ÎÁ²(qXï*“¬[!ëŠä;¾‹óBS^@=HræõÛ‰o6.“ýª¥hõ®4ê²VÔµÌãÓà?ûd[á:=¦†=ܶ\ ‡P‰ç¥b0=oØÝIë¸Y¯É¼!«· _ô‘äÌÔÍZu4jBðì-b,˧ÖQ'ÑÄAJì–£{?¯Ü‘±Nì–`D‚HÎȵ1Ư‘UD w£ëÊsÐZ{iºkÑŠ„¡…ŒeÚ@ðžUErgг/ÁWè 5b[)µà»»A.ÉÚ=Àþ½{ŸdZS%0EÒntœñ +nktO`¹~£FN¦ÕøŽL¾t“ïvÄzšac™†Ú9P$s’Ózïã\¹ÈÆ-Rs”kYwG¾k”’»¨Ïm”€_#’||'è« k*4ß·ã±y–Þ·|ø*™mŸÚ2I-êÀª µO³Å/¾wø&Iîeû4 Çæ]Ô]Tï ,×=s‘ÿZ`D@-B«ð ´{C0?JôÝt ËHhf›Bs›3 1nsQéÙ輄~•·bïóÁ½Å5Y¢ •Å¤Í™ÙÒ½ÿÑtÁ@Û2AM“ñ¬\’µéøw,2ž²¨ƒ¬æ÷–µRÐ̹ç–ÊLOkæö@ß[¨„ÕYâ}u™` ±@^ì~`åHPQ‡,Y(â€Ç5µ.N-7Áõ4^Ë1(áÄs<õ–zä"cç;,Hà Û žÜÄj0IÆYå1øu"ÀÂS¥ae§…ãòé·‰ù D«å”ì7”ù¯ªá’½lZRaE¦Lüj»›ڎ̹K#áÒfxØûidE{ Ä/;ýÖqvY(²¶ý5Mâ)2L…N…Åý†T1ü'#ŠÝµ`µìÿJ 3{ï ³ÞÝJ9X'°qSÓÍù çÞûxÉoo î4Î:vÑÈÊY vk ²°˜+¼¯Ò­{ëà× ¥È1Ô€atE~¼&Þ—ic¡IŽ,I•âvÛª<¹‡ûAV³šgyÃS(8 ½ö²|ò¯ýþý¯ß÷*òý‹Ê,—ÒÑw}õ|Kws€±N*ãTÎYMÅY»«`g7 ËϧJÇ®uïÈE&‚ˆúèXÛƒÑæJuoh,¯sVÇýØw.ƒœå ï:Xçœ5áиŽ €¯›Z~ŸoÎ9{çÖ²ôX`5S‰_mûjN OßÃî ú i•Ï¾×_hëøÎiÐ\ÎëT0ÁE“É™ÖQcOVx/Á*×YE°Ädøe`µ ¬T¡Æ¶>µõKu ºžú–ðÆj B¾ÃY×Áz}2 ãch[~lrïN™S/´„Z­šFX&†–ÿQÆž ÜKgÍ ,d.0´JÀJ9­µì ¶„ ·w û …ÎrZ~Agß´|®àª³ÆÓüßøNŸ ¹OÛ7ʿ冱É–iò»Â$¹õ :zz°Ö£Ëbxž7œq¨ÞßOg:k.`ù}»Ö’vPájKåS :ëdéVõÍWgôíÙðªÎ;Œ…CÒj<Ù~C Vò/ÀX®ÈçX-Gí¾gy°ü¾ñéû·Î°Jó†g­CûŒ³æ[‹PIU:XŠÇ°–à¬{=õ•‚íÞ‡H×Y£œÎ"ô¾g:U‡6úµò[èä&Câ¬Æf¸rõ^²ßì¬'¿R±Ã†\Ÿu¦³d>®ƒÕœ ÆzÇÕÖy°vÕ'%Ùžµ'¥v,˜-7‹Ë¤ÈX†\ë–3J%gÑb•oÚY §…` ãH‚¥í«­žZ¨wSh,G#LËyµú•Oÿ€wÖ3ÎÒtV=[Å(¼JÿÞ+‚åtø¼wª«qTÒÎÃ|GîväXVi½æÉuu…Õ·Û†Gœ\ÔE<‹Uµ™³ú)L„¹ºpÁ"#a! [×\áf$°|•“0·—¡ï&”ù˜ËV¶€n‰„½Çº™no. ÃUùr¯iPíFÀX)†ÞUK£1‹”f1C‘(˃•+ÙS~±™ßL¿¹%ý¾©c%bÉFÉ…úÞHèðb:#_&ÖÇSß?Ï™PW†.´ÀÊ4™6FÔµàé|¸á$O¬] +g`ÝÃðâž~¥ô¾>͇%â©Ro]:?˜o7¾•F£aYå!ꆙcÑLhºÃ‹ýyŸF”Xåv ¬T͆g´’Ýð»<9Á¸iž‚0´X á¾äæ²Òù.g–a|N‹)UQR?L+t¡/b5!OçéÂï—Á2lÅYg´rF» ‡²´]®Ý +(G.”ïƒ5ý0>Rß,û\h©±.¾&ÃÿDú–W8+«_¸›¬÷ßv3öY.‡¶f5Dýéw’fTP ¿we£oàDzävê‚ÆÂwåYW«áOfظ”kº*†ïÄ°‡h¼\Ü.ÍËbëÖÕ±J£o';ÂÎúºlM#ø4“²‡Åd!Ial¹gó•*îÐzþuU Mé¾GZÉpè_ËxA°Šï·¯)¬¨a~?iÚþ®‚>Ul×/Qñm7æêÝ‹¯i,·R1ý‹¤I°XsÎòÕ­¥8 Ô ›Ë”hpWIasÞ”v–º€1²K9XsÙÌ4k4êGòí²¹7£@oeÍ®+#G;Hž˜i£ùv®ûHõžxVT,ƒnd }‘ûÖ.Pcq°ªuuvªª:X‹š<¨5¨Ö3L©ur^ÐÅU¹ØÌXóî@®µ êYÔÊLž¢ŽQmâ1ªbgd]m7BjDð€åéH¨ªq«êY0{Ç~zúˆ,ÿWMRÓDÖAßãÖ»û”2¨«ƒZç]uÚìÖÆ é52¤†“0¨Ãd¹»sÌvdfyéŒ:Ü y+ß ×"Xf[?ÔU;çe0:ž„íPËö@ZV†UcÊãÛ,ÛÉO9f©Ë®¢†û†|¿¤È”å¸â¬c ñd•¡åŸŽÒð½—¨,r C\’,ÉU$ðó:géÓ§ãžGý,š]FŽð åF<¹ETTšYwŒ wr.g¶à( Ž*…HG a—õAÐKz0(Gº¥ aë$ÂŒè¢Ë,#sºŠ_çN\UK­‚0¤æ„IŠÏ©{¢VN í¬L=˲bÏtÉùîÖÄ®ÑtýºÞ‡…þzÎÝú*ÂÊŽ„ÒªMKê÷»Æš‹Æ¯Z÷…óÇèÀ=$ZÛ‘‰w’œÒ±*žuÊ°ŠÑéÌI•!š¦lžžr‡bH™Â³CÎݘZð Ô´¦†ñÔwï5jbÁY¨³ËßÒéq2– ²+ 0Hýø^ÍË ìÊacZuîJÎz¿uÔö†…«Ç4¢óÇÞ6× \0`ñ°QËâV΄Óéy²4RÊyÀê3ÊŸš?ɵy<ž¢chš§Zîܱ뻡Oœ Yé/ç”ßÍ@W¦Ÿ•~ìÒ’é¡®‹°X®ªÀº{uŽ,ø—ÀúÝ)‹?Êmx«­U·”Âê7¦¿4°Ž—bð,ÎYL€«þú¸;C´®÷S3NŠK®ž›$|Ir ¬EëÚëZ,©i·Œ'÷À×—DH°[~2[-ã,™7tßK8«:rîÑ3ü]$Z;è¯I`ý…¶…$ùW¦°é‡+ªŸ²°2û,öõ~C§]1¬X$ÅÕ&Ã5Ã…F|­;L‹–;sÎ÷É€ÝÐpûky¡~šdgå«ÕL _uV/ÌD÷)×Oð“¹LVÍç¶EV*MwÐîV¶€æÎó¼á™6h'ÿ7·ÐUB×ÉsT€¥|Z֩ﺭ ,ÒY=°ÎŒŠå‹3‹3°Œ+ç”jÕ…ëÎ\+š€³^1plæˆÖ2NZ­žLàÝT(¬þìëX§ËyCÅY¤³.‚uʃexÞ¨–Ñ!mEë|-+¨;zàÝ÷ÑÓI‚"g±Úé[:ËW`Mךïq®»ŸÄa§é,ǔΡ ¹oÚÂ'lôÓ/ð£ *Qß?¸Æ@qÖ•C]¯™w¶‹1Ü9HäÄå'-€WZ©Ä O5È'¾ÐYÂÎÒ΃ bx–«ºáéü0‡_-×óhS€[t—AÚÃNçö„,f·³ø°¨ÎM‡Kç”jÕ¦â¬Uºæ!ž\Ï øßëÑ‹gÝË€†)«O{0ºç:«4odvVó›3«­¸%ÒÐA¶É°z߶EÛ÷p뜈u¶Äû=+IDATîL¼Ø™±V¨j'඿ÔY)–g½ßEˆ7Õ´|‹Ü$y'¹Jq@Iý`R c íŠQ+ÓY´R³hÁK¥¸"—ܬ\+Þß<Ånv®¬ä¬ùñÔÂûÃÔr .Úí›$´ñÏqë‚õ'N›E±º`’°/t‹ë¬næÅvœ ïE¦*ïHïd+]Ó Ä³‰™J!´3-¡Þ U…¿:P­%Ük¹9SŽË— Òe ÑèºñIq©Ú‘ Îðäñá°aârdø_RA¼¼FgíÈh€¤†ÖŠ0u¨k­¶ÈW _¥-€Ùµp«uÇ·6ñ4#™öçô•{Òx&R7H………ŒET5™ÇÌ#ïxl'“@‚R ƒX€ óR­[—u ­ÔÁ|[kA.Sç»ÎëGgôêû®}6Ò©ëÜñ€¤$é_Ï|]ÄW€æH ¯.Ô·®EJ5°Œ,BlköçÁF¶˜ë'¸þæ`Q±"ÁX}„,UÎå±×½—òäƼlƒ+k5bw‘]¡zmà*ßJŸÃWÀ ¼ðÄ‚8LçjjPV½ƒwEXùî=ŸG³÷+¥O¥—¾pµÌØE«at1º}­¤þëwSŒªxqïRp˜mû‘ïÚxè=–Èçz+Žsáó’G¼ÂY^ÆYz&†ß8t–{•8Xõ‡éðoíVšúÑåMcŠ_ȵmÁ$£Ë_N0qƒaì¶^ÏrÉÅr¬X•Ï~/Ó’õ£ër&àZa–Ÿö/lݼ<¨~‘Ãm‚IŸÐRy0!|»ÊÚ_?×°¡yÿG§2§ÇÊün :_˜g ?=6–\—¯:f‹Émãµq{[³o„|Egiœõ·t(a`¥•¿‡yÒï Œs#ö¾¾ˆÉòÍN¿%†þ?ଞ)°²?ÿ^ÛdÒéÿ¬Nìý“7\^.ƒU ße–µtmÑ7KŸGG‡ý¿{d4ó*OßC ¥b‡?žB¿,b1Û¢ZïŠ/-T»]òvžB¥³bI£VmBM¢Õ²Öy· ÿ9º…~yë¢ÛƒÁjk$VÅ*t{; >&ýܸ ¨•fqUkÍH¨v_c.5ͪÚ*Š›F% UE&’³UU%l´ÅlüÈUµe€{ñíƒJß{=Ge«Y²p±S[ñèó‹|a"o­òkqß ac¶–á.êr|â #žµ™UiKã4èL"£¹Sãr©³j6®VEoÅñhyµ@£øÚ"¶R*™ TÞ/©äçRµÖTÔhË$Ùn'÷Wàa|Qí§RYwÉÞÙÉðI÷¨ªƒ‘<¾üáŒ5¡cÄOršO&g¬aêÈSR1Þ!ÎNeØ—k§ŽåYUýðVÒa6î…ÏŒI…éRm ]VáS‡ÀR/ô¢ÎÒ¿É Óï|¾gà}ÉY:¥™Î]˜'z,ù:K|ÇÓLé°´3Îú¬Ñ}ìþ:Rˆ%Ÿ:”Œw ¬‹:+÷ÛÑh>ÉIð X9qPœÅ$·;¯A,Mg¿ÒYÍÑý¨§û]1<ž<ï ¬ë:KÊ^ý[:«™‹ªbWۥクë¬ë4YÞ0¸¬³ŽÂÔ<ïÀÚ} 9?Rð’°ï鬦œ …LÝ%Î:OÚ¾8ÔUq–÷ 5—ÖSn6dÕbþ+(Õ¿®Î†¹õY¬®>ĪvNócf®U]ì5*YXíé;OÚeùÖrÎ’¶ß·í¬2°æg/©ü}U³¬AÞÎÊøE³³*}úŽ…Wp' 6³ýÎÁ¢õejZÎ}V=;vâK°®é,õqù ÍÒq $0ŽP>U^´àË “IÖV©Î’›$iÕcÙ¡®µÌGË(¥ Ç|M(¾HñÁ&±Rdõ®ê¬ $ß°°)T#a@!/³SÔp¥oˆîi9aè1"CÖÕ'//‰¡Ü§‰.&÷·EŽ¸ ,îÑ‹gUâ ùù<7+¿¶£½ÉÜ6ÌË:KR³ÈË#µf~\íK§‹Œ°ªöQ˜,ßJ„ ²5©”)æÖUR¹LgUUø¦Û­«j=;6 .8«ÎqÛ¢tÌDŒÇŠT€HUƒ¦ŠgU³†´ªLVeµYdÆR‹ÇuÏÆÍ“P?¯Òç„Ís„ÍϪ8nqsæÿna¥ÕÿÍñ¿¶ìçÿ+°þ_–?`ý üëåX?(ÀúA)€Õ3ýÄsûÁÞ4/|¤³ïz‰÷73ñ?(cM‚†ïþtîäÁ²Wc,o~xsSžYMá÷ççU/`éaï”î—Iøø ÃŒ7örüü<üß(my(Ýz~¥äÀJnDy»¹‰Ëv|ûð 7oã›ç0Ø?܌Ǘöü“­0VøÃßÜ,سÖžÓøöHÿ)žÏ¥³â.Xm‡xÙ?Iì_,“ GŠÓq“üG¬Öz^þð, r{}ìh\ÂýÆèG x* öÀ}7ÿþõéð$Ó¾Kœ~~BÄ¿¡ð°Ïÿ¬‰L ƒ±XqVÏôâ0á‡âï-ï°’CÜ™zÜóÁ²@ §–ES+³Ö-stL3í§&E·® ö|~4ÁÔŒRkL\Ï3Ißm#<¦Ö×~´—7ø ¸n5´Æ´f!× ‹rÝL¬42Sø ¿õ+ç¥öÔW„Gx´Í$LøÄ5±pP?ݶM3²Í=BoSc‹ €‡Iq’‹"ÛÒÎ Ï…ï‘N©o`¹Ÿ4>üèKÆ\.Æ“ÀÓ8\Pú7ã·aúˆš.?£†>´¸?ã·¢Gøaìè>hèžÇôë!›*Rj¡5·l÷âvx7ßÍÛMÖM¸=à_›hC$­øº·áRˆr‚ʨ¹yh¨e Ob`’âî™ø”ãç%´=?еãMÜžÒÓ¼mÒ2°-ñž‘†$;ih8v'`ýGB ‘e)ïb¬cÛ£ù+aΈ¡’¯´Ã˜-¨ÇžVðÊ{=¢à°Eí—ôAjŸ-f 3WÒø$iø0z=´`öùn:Z7ã8èaûójÒqñAö,‚æ<¿߉Ï:{êsMð¿cT,Ä7BK$·=z,P@ØiÒ!â€&´¾5´¯ÙçR3ãÞx¡ÈâƒÃûÜ<ʉG<¥xר—7ZyÇÓÝ"_ú$"0ÜËÝ0q ÌrŒëH«ý¦w hð¿ê°í¬XÀ@°ð½ ƒ§“ñÁ°ÆE³U  P1îÓ,:eIcqÎ’`¥ðì ß^¡åO¶á^Ó'a€’ÐŽIõ ù+…„š Œú¾“eÙBðèQÄäÕ ¼›+ÝÄYã*7¼plø´K_t âÐÐåE°¬7œì¬gmI6ö²¢•wcr`Ý3+ ÖJN~¤Ízñ\gmáÜ­øìÂmŠ€’´ÙÂÃQ¬b«ön&?R!!9om£b=3sj‡bò• ô8Ù¿=_놋áZ±4%¥¤ãÀ¨FÃJ·¢=dúp•ƒHœ¥íŒèÁ3<Ú«çñ[~‰µV%ý Mä)v (‘º´EÏ ƒ4ç,›ÀÂÇñœ íÆ)Þ´zã&'Xc$¾Á~#”ŠxJ1"Íè‹7À¼TÎb2JP…Ùø=_톃…`4È›>ÎcØùöLHÎR t–Gàw `áýøÚ°X‡Œ¾·å¬$ä@ˆ•ç“5³ô€ºw¼ ‰é –1Xî–ü GfÂ"E ‹Ôï“Â} ­ŸŸ6!w<Ésý„XXÅ­úÏ’GÞÙôY7þ>Îu#ÔÜÍò€­`ÞÙ$~ <ö ¬ªMØpcx‹ƒõ@‡~HÏ· 3AOSt}u1”œFžQ¡úçÒPL/\&R‹>"¯öøͱ0ÀoH]7D—\7??x`ñŽiäÚœæjBV¯Íä£ÒÀË6>»Ö ¼ðB7œ³DÙ4¸›|#'Z{û(f\oÉ«Ðož|XßU·f;„øÔóV8ðNC4‘ÞÔ”Û=È~@ÿ†r–']ª†ó¶½S°Åè*ñ‰=_Üò@^Ä›¼å晟âg¸ò9n†.*°vs˜€~¶žõnn…n¸ÅI¦ã9Œl$Ü1H²|–Àz¯yèIA~•$…\”Âœ»ã¯–Q?Ù<ƒæ *:ÖáÿöÐÞè¸Söp ‰Îغ«Ç›Ç¥°K'ñÁ CÀ¹/>û¤mÑ}ê÷ÂÇ›¯büæýRœni)Ùaáˈ  ô¸‰M¾ ÉÔºy‹'I¾œ^ÆËFøvóvñ‹i~ t`£ÓD—{_<À'Ÿdõ!nCþX¡x’^¿n´*a¬œÅPºX'5ûm-J:Á¿ùïôζ’Œ ™}ù'üh¶lh¦ôU¼­–¤.ôt´Ñî›éÙ6b÷MÍHåônªMþÚA´bpþx½Tt`È+ NÞvË žLm˜ÑbkK7‡vÀÈé,U–Ý9#üü’ï¦%Ê˃¸Œ]"wý•|{¼y@slµ^¸æ¬„$0—Æ7‘¢ùv¶5ë¿ Ö{ãŽÍósY$ü§!î Í0ç¡âÿ°:2XòOöEŠ‚®øXÌ8g?þ€Øaâ»>¸ÜR?)¬!‚€^‰ìþ7€…º§²Ý²oœ ðÎzÉêms(=Íø¿,,ÿÞtÙ…Þþ[Àú_)ÀúAùÖÊ°~PþÊ!§k6<IEND®B`‚code-0e2a0c2c8142/doc/images/roundup-1.png0000644000000000000000000006340110062724152016207 0ustar 00000000000000‰PNG  IHDR}—0“PLTE±±±­µ­¯¯¯7™S««« ){BF¥ " ¡¡¡D»fŸŸŸ4î———B$@#€‹‹‹q:‡‡‡+v@ÿðßÿâß1†I}}}ªÌÿÿd{{{/‚Gwww7–RJÎks{s <¤Ziii-eeecccÿÿ_gaaa___zii!O+M*WWW1œR#_4(o€€€iµµïããzzzU‹€ >©\ppplll C·d0A³b*ZZZ€€ÿÿÿLLLÿÿ/€FJ)BBB@@@>>>ïïïd4N4ŽNÿÐÊ/~ˆ;¢Xççç €000ááá@°`...º §>¬^ÝÝÝ'¯åÀÙÙÙÔåÿ&&&ÕÕÕG'ÍÍÍËËË!Y1'k:%g8.}D ½½½Bš§BÎk*u@···ÔÿcskÛFé™ IDATxœí½‹ƒeGyø±X‘viç*ACº¬Ø‰OÆñ¬ 0#;Q‰¤€h&Ѓ˜Ñ€Ù^kÚ‘‚mtQ¤qZAŃҺ°@Íh‘ð?¸çQUߣªÎ©sN{îãûM÷yÔ㫪ïüæ6€B1^‹âüùxœB‘€§š(ôTž§bÿÎ7Äé?ý×þ¯°HÜSûª‹ʬ‘(…" M:_k_<ëRl(tÞjßyý§ÿ–ú¯¢ŸÕ¾©+£ÿ¶ëßS•ä9í[Ö$H¡¨À´/Ø=ë¸O‘Œ.:ÿšÐ¾ô¬ EÝاڧȉñµ€ž† ~Ï’”0=&C½}ÑÀ>Ä×KûìëùÄ«l)y•}k‚&ö±§úkÔ'Ô«®©ìkHâE)ù¦D7öõÐ>ÓYšCy<‘$¡a-=Å !Y&"£¢i]½žR6.£kaý RR>õ½  Ywi)iËÂ`íó‡Ü>VF6$ä ø” ƒ›t°$Ì¢ !’Àá´UŒ’oÉ@²ö`hšö½æ'¢`ºTˆ8/žb‘5m@Ø‹Ð9rA©JâX­ä[.ûjö`h¢öy‰˜ýú±¢Ö<ÅÇ}eò,5“Î'¨ßwGd²¾Qö-ÝØÒ¾óOEØä)ûgˆQ ìc†"iö•×|§ ¾š=šcÎ+ºEFèþ>Åtè·¿¯þo\-¡ E](ôZõÿ(Köxj¼:)>^«g¾Ç¥ ß« Ų`¾<¨f_ù¥SWH±=8[Nu ûêï2xõÕ+ Å2pö,ˆ9¯²O±,œ= b½OÙ§XTûÓAµO1TûÓAµO1TûÓAµO1ZµïР¸ˆ1)êË*a(qæR¶â°9éa0¾ÙxkÑÂd¬)ñ Å Io¶ýå9’ë±"¾V¿Uû\®FöÉË&öõ«}bü0öI¶uzâ-Tíξ~ùW©ìkÑ>s }…å:Uõ£3s4¯mS¡¤RÌdU…+"‚¦hh‡kŧùÄD{…¤lfa(öébuÄ"ݶ:χ4‘¨}ô‰D ²N;†W‚¤ld_cÏ–°J#“ÊÍ`&Z½€¼;<ô)ê±cÒñ"“ܶ:ðŸ?~K÷µ²ï0àœ`}<‚øš¸½ÐÉ®ðÇmÀd2î°&£¥Xnô3ÍEZZ.=îÓ.–yupè±Â’µ/Þ¥^‘Ï*T!ûÁæÒe_£9ÿ³a™4‘ÉQR™á‡ß”›´ˆxŸx¼ñì»BŸu”}Éã¾X{“ÙdžOÍf{³¯:¤°†OQ;ûr3öQçø싸Qu×’}ö6̾qÆ}-ò€O¨áôbŸÿœ!š>˜Mö‚$Œevˆrö±AHƒÛVþóé5î»B­Dš×‘†}C\çìFÝX vk¡WØI\"•°Vx)“0„µ›ŒVˆg¦õ†œ;Â^Š}ŠÚݶ*Ïšp¡ï:BXÒ“]qþä†ïU}ÏÂrØ·êê•aö©öI,…ÛF>Õ>ÅJAµO1TûÓAµO1TûÓAµO1TûÓ!¨}gŠåÀ×¾©k¤ØxÚ7µ+¶žöM]!ÅAµOÑC¿4-Eµ¯%û°èĦL­–†¦Ö&à,ZŠj_KöaÑiM^ΊÔrÃ0ìu–±/ª}Ù‡EŒZΊÔrÃðê«oÀÙ4틾JÏu=j¹aÈÉ>Õ¾<µü4À§å¯²om´ïÖÑã;G·‚†ŽÛË9nŽÎU˨¡O¿×ÿ§ì›TûŽ/¢Ïõ¨¤^AÀ£€¡ã¹O?}Ç ÑÇ‘ÜçŽñØXË+G5ürÎÁ¹÷¾÷ܧ‹/ÃóŸþôóï=Ï+û&Õ¾’6œ:±çzçøÖ|~pppëøŽg踈)mø46ä¬PsëøøV –…… öÍï@!ºõ±±–WŽjCþgŽÎ•íóçÞû飗 –);aö…$«bßqÁ)b"ò\ ~T=o‘øH:®hy\ª[ɲ["Úrë äVqY'ì;:8Š³ïÎñqÁ»úØTË‚|FûŽ¤¡s%æ·ÊÓËçæåy Ù7®ž¹zrißq"û¼ÇQežä;¦ô ?×[…òߺU(_¡~R½ ý îÌnÍ}q+ ¨Pðöx~+̾Fí»rk~p§°RЊ÷j‰äCú!ûÞ[òm>?÷<=ósçžyûØwõ̵g¢üë¤}þ+¾¹|uî‚Œ~áçzt§&_A¿#+~h訦ßÁñ­ƒBá|q«{ÞƒR¹Êž7¦}…úÙw§Ì]ènu:ÂÜ~-‘|Ž~Dûž/ÙW¨ßËåùÜQñoËØ5÷Î4ò¯‹ö•=Y=\¿e;=úàªñwý4æòqÔÙKêQú…Ÿë‚ås?¾S¨ÐAÑ3C· ý üþ÷­‚‰j™nóÖ­®ã¾;¡î³žââVM¿ûæG ÌPÑÝÿæEÿ^Ю`ßöõ¼Prî*¼] âôë }åS7í¸ð}õ€Éƒ+ÆàÅ38ªŸìÁWù(ýÂÏõØv¨ŠNð/ÇЯоïÿÜñ¹ã[¢œZ4oQ»žöÅ´¯2}§¨iÁ¾ƒƒãì›_aÚWø ê>ÙNöšwõfAŠ‰W ú Ô>ÓãU²SM<%ûæÕXÉ&ªèÇžë’YúÅÙWKgÁš|‚ÆNû¾_ÈœŒ®êÂÈ×Aûʸ¢ÌcȾ£—ÏÝ)Øw®T¿’}wÎÝÙ*ö|#³ÅíÕÁÚçôÅ€Ì×¾z$dUσLÊÁ˜EÑ1b‡ÉšR‹ž×.4ßñGnvµ®÷ÌûŠ§ø ç¦K~lÎrT®×”,Úן}9÷òGÎÍ_~¹hKÑÿ¾|çåíb_ÑÙ^½Ç(_y,¡¾7]ûÊï ~fG·ªg_5à2¤VA¯ç-yWŸÈ8‰5¥²sǪNÁÄÐÈ Š¾µ(½"ß`ßñ±ü¹â‰Ÿ³ÌoUÍ+jpП}/ßùH¹ÒrçÜË/—C‘‚Šwþý6±ïFA6ƶ‚Ž7†i_I¿c3Ä.—#$ûŠÀù¼žv”OfdßÑ-sr3kJUN!k5?Ý䆳ü¸ ÝóÅï¯îüÊÓ¾BíØÈ}\ô×(ÂG·dtŹrâ2oaßQû>RÐíà#åxïÓeçûòÁGþýViß9Î+Ä/Ôõv™óÞ*ç’¼pñš`^*U˜Ï¯4²ÏåfM1Å”ï9Š¹nA³#¯s,æÅ”úù‚Xw~uÇÓ¾+¥lÑ‘Û Ùw«*¤‘}‚~s¡}·>r sp8wð‘-b_¡t7EÐÍk׆i_Å‹FöYاÑ}W â•êw§~«æ¯Øä|þùç‚Ú'¥Ï÷µ°¯X°«è»I>4Tnj)×>üƒ-bßÛžÒÝs5¸èÒí]Ç­£$ö]1O£'ûJ–ß)'³õäÆ+ç¸ñEÆ}\ú<íãhßÃ>w«åI>òž7€-bøsŒ›×ª}%/xáö]™ûÑdÂrܾ¢w=*çÕä&À>B>OûʉîܾýŸ{ÚWÎjÝ¿ã£!Ú‡ô›Ëæn9ûÞ¾êò†ûJð…´(û‚ÑÕ“ºU)h ûª%ã+2¥cƒÔ¾c²…êØÓ>žùÈ[L´u$WñZ^áäSö¡Ò‰~ ~µO¢ûªw··ÌÙE³¦¤–s‹ c5nÑñšGmgò 7©e-²^9ÛÎ>oåÆÐõ¾ :±/Íš2b9âC€Ô¡–Ûξ{Ä’KDúôÿu,»–†È›6A·È«ŽmÔ¾ik¹aÏy߆›”o _}tÔ¾øW ŽfM±œ©å†!ľ«×àúf·dâ·!°à—¦}qžM›2f9+RË C€}W¯]»vóêM7ô+{á3Õ.?~IÚ§PDà³̆f·ä\ÌwoÖAÞ&¿$íS("ðÙWmæ+~À°­Ü`Pþ›Ϊ}Š!ðØõf¾›Wß®^íB½ÛêÆ™›¿qíŒÜz Ú§ɾ«×®Þ(Tîæ=Õ´×vÂf)\=ÓÄ>Õ>E7Hö¹ÿC g®šÿPyíÑê¿ÕL¼ÚÀ>Õ>E7öݬ9Vu¿Å¼÷꣕ö]-·ûÕd<ÓÀ>Õ>E7ö•+Ç|p£\f1ÚwõÑš^•«.KѾ¦Ø4²ïx´îw Î]­þKo©€e¯[/@‹%¿¥hßÔSäß5²ïíŠcõ‹ÝBÏÔË|åè­zeù.KÒ¾/(6ÖȾ¢w-ÿyýŸˆnدq¹Yo:(p£¡çMû¦vš"šÙWônÞóvy€kÅHï*\µl¬çÃgnDÙ§Ú§hF3ûʯ̸Z/¯ÚwõÑߨÕÞ.'»p³êˆUû}Ñ̾Gë9n)s`—XÊ/ð+×_Ê-§òû„Tû]Ð6î»zÆñÞ†²ß…j¢aÇ}rÁOµOÑÍì{»êt­¾ÌÞ¾çÆÍ߸vµçUÿ­£þz)Öûl嫹ö >lKÐŒ„,±$áêÄ*¿áhaß=7+í»ç¦ùoEõ–æ’‘÷TïA ïzßáaœ^e\C¼cß!?·³r"û:Q¨[ÖÃpðv¡…}ÕÛŒ«À¿´ª¾jµ¹iÅ¥IûÚØ×}á[?ôÐݦ>ë.rš˜FÙGÐξ«öeǵ«æ»#ÏT¤»q­Z ¦}…ÊSutWÌ rÒ²¯Œ>$‚vhCëÓ0ÔüröÖi\ïmóÙÐCW‚LózgRبhëã 8,oœµmD ûnÖK,7î©çWoVK¯Õ‹0f-p€öváÉ =ä}qcÏë¨<¤÷_8< Ü‘”h9hó ‡Ó¾•CRÐHA®ÔŠƒÊ¾ ûÊý}uG[½ñ5(»Ûkõ¶ƒaã>ªmæ¤Cû¾ð?P°/t×Ì>/4”/v"™iÑ^‚mBû ^j¾YÌ<êÞµ3åš ”{ b‰¯ }õíá`öòùc?ö±Ù4vÀ¬üú¾µÒ>ÅôHdßÛÕÖ*¨§pÕñ©ö)º#•}o¿]ª¿ }O¨ÓUíStF:ûŒ6ƪö)º +ûš±$íû3Ŧ`<ö¥}S{L‘ã±O¿ÇEÑ MßR´¤ßa¥èŠäSíS¬TûÓÁÓ¾ªªP¤ÃÓ¾ üûŠÅ«¾öM]%ÅÖàU_û^U(–ó*¦ƒÎyÓAµO1BÚ7W(F€Xn¹Ö¾©k©ØLpò½ªÚ§X"Ξ½·Ä«õñUÕ>ÅQ³ïÕWÏö©ö)–ƒûTûËAž‚uö¬Ú§XBìSíS,%ë*Ò¹ Õ>ŲbŸjŸb9(HWq®¢ŸjŸb©±OµO±œ=Kþ7œjŸb©((wV²OµO±˜7m÷Þ«ï:KÇY¾o^µO±DPöé¸O±\˜Á^=éUíS,!ö©ö)–Õ>Åtè¯}; E2ÒÙ—¦}S·G±NPíSLÕ>ÅtPíSLÕ>ÅtPíSLÕ>ÅtPíSLÕ>ÅtPíSLÕ>ÅtPíSLÕ>ÅtPíSLÕ>ÅtPíSLÕ>ÅtPíSLÕ>ÅtPíSLÕ>ÅtPíÛ2üç©+@¡Ú·eøàþð¿üÃÏÿéÿÿš¦ü‹/¸øV}£Ú·øòø‡¿øS5üÄ#î~ükßýî×¼¾SíÛ2üåïþ¿ÿûÿ_uýÁ?$€à92Fì\|ü»%K¾ûøÅêVµo»ðÍQŸÿÝ/þÇÿø?þˆDOö‰J”,/¸+aöD8ÂW¿·^üšéyUû¶þ=øíßýò_þW&SrFD@,âÇKñ„ULQáî¿­iòï®nGѾ »™¬´Î‹¿ø_w~øO~ì’Ÿéw›\‡ézQÉ"ž¨Õ¼ˆ*ŒG”¸xáÂ…Jü¾[\”³ÞQ´o8ûáTVóâŠgøŸþgÁ¾ò¿Ù #^„}/X. ò±ˆjIåLƒ9¨ö½@Ù÷ø…ÇËGù·ÅE7ö-UûHÒúRé— ÿàÿ*ú_ø~ë¿Ø ì-Á’†s‰tÌŒ}Nà<¾zñ»¼ðà[¥ø}íÂ[ÅåÝ«¬}âRÙ— ÿþâ/wþEÑý:Ô”)ŽOT=©àÒl˵/aß… _|þök_û[(..\SûÊ ™ï°"jÎ 69µÅÙÇò„Œ*Zñß~÷¿‹:Ã>ìI…Ä…Iö¶³ïâ…/^¸x¡ÈSœª®w<í£AkŸ}s#Ùæ oÔäÙñ˜£f$|žfMñwÌK°_s!n°V¾¥ 3U·SO0${¢±çe³á‹Eg{÷‹;¾øâão½xwÑ _Wû8ÅæüÚ©£õI/‚Ñ´`+…ðx8aæ wkÿô=û ÖM:ìÔ¶â^xë4NN†4úOÔÆÜœ÷"øø[?~ñA¸{\íÛ PÊ]ï°™mPÝl8Ún6ê²Ô|Á¢æ&Œ&3w$¼N¸#è<)éºâƒŽ{ÿƒmok•Å²ž×¿ÖàƉ~KY6å½øà[?øàÝo=xwÇž·Ï¸/L)e;;ä:Ä>sj5jsì ë~²ve4»Âüæ¼øm²ýä{¿å‚ÁM/ž½ë ])FT³päc9*b>Á"vv Úí\¸ûâãwÿ£»/àG÷íĉÒIûZZ³&ÇŽ`§ÓŽLå§÷î7„}ÿÙ2ïŸÂÿþçÿó/þ‹0]¬ùõÞÚZöž÷ÁrÒ{áñ»KÝ»ûÂ…Nì˧}¶6s6îÆ>z5Œ}Ø!×íÙ öýë/ÿÇŠG¿øòÎ?ÿ×wçË¿ë¢Zv¬ˆ·¼ 9;|üî‹Å¸ïÅ‹ww]m }Cgæ4šó¬ƒÙGƒmÐf°ïÿüçßüsp„ø7¿µóïþ¡‹ƒñ÷÷½u7\€» Ö]¬.v–¤}~w‹ÄcÚåLpöù™Å5-ÅtPíSLÕ>E_¼þäGZPíSôÅ'Þõ˜»þè—^yå•O|¼›Õ>EoTû½ñ•û»ô@O\zè±Û_¹÷éûžyÿ3¿ù»^O6 Ú§è‰¾ÿ‘÷È v[Tí[ÜnDz«ô¥wÞøå@ª}ëvn½´„Z0¼^º4Єjßz`Ù÷îç¾}©ºøõ»:,03¨ö­*öÝ~¸ü™?L±töÍßýóg>:øÀ³=_øªö­ öݸÿ6|x~?Ü?ø~O —Ͼ{áŸÌçðÀ'¡ èø–Wµo]Pí%øðíÛ¾¿b_ù+°|ö=öIx_q:?û:À|þÀ{¾ÔÕ‚jßzàöüö#…ô•šW0ïáÃK¥~øÃ¥Þ_òá Ø7Ï›ïüæc?ùüàé' á{ö3÷v5 Ú·¸]Hö¼E' /U!ÅýÃeßw{ öÍïzÞù"À›ßyîÇ_9[tÀO?ù®ßüúOÒó«ö­ªž·@3î+oÃ#?ü<üpAÁÛSô¼órÕ¥Äw^àÒ3_,¯ÞxàÒgÀƒ´ïëm¥¤&Ì®Wò´Ô‰6Û“¥ °ï~xéþû_*ºax¤L1 û>W±ïo›_úúÍ7º¼ñ¡ôÉÇ í³~ûl[)© s§ë•<-u¢Íödi†‚ì{¤Ä¤ì{¬æÜK¿óío×W_|çSïNÏ>Pû^/ñÙÊqeÙU(¸ƒ9ò„P'´ÉÁÄ ºô1{®$›¡Ñ,M„UÅ´áÔ¬*M©kêŠn)nÌF‰ ûŠyï÷ž’}¯¿YëÝ»ïúVyþùs=}W‡ìµO€À‚ Í3'¿Qƒ6=MdˆsÜ,\L×Ê>GSg3fD†F³4ËÚ”ˆÁPUÓj )ÚGje±‚» *ü´’¼ÛŸß./~öÓn¹jßgkÌRÅÀKæ$¯ŸbÏTÚ‘¡ÙlPûZ*KšJ•XSôKsŠuaßk\>ïŸ=÷úÙrøÅ.SŽùPíû¬G–êä:ˆ%Äsâf™Žk‘'Ï4j_¸ø˜öE+ë †ªšVSôKsŠuaßCç«yÇ›\/¸|£[î|ï:ÈpÎcŸL6¹ ‰L8*¦øLÃåÚ fæb­ qµ¼õ>Åöâ¡ßñt¯ÄÏ~ÜňjŸ¢.}+Ä=€©ö)FÇ]o†Ù÷©ô/2˜«ö)úá™0ùàó¶6Wì;k¡Ú§HÂ¥'_Š°¯P?ùõ ((wV²OµOш_þÍÙóŒqo~æ; ?ûå}o¼yׯ¿ôó?HÞ_zöì½Õ>E.}û‹?þñ{ßzú—?~àsß~äÝŸxÞ3àK/ý(õ¿V†Ø§Ú§hBÁ¼ŸÎŸÁ—ú»„º÷¾îgûhÿ­çÿc‘jŸ¢+^û|hþÑûÜZ³Ýññùüëo”_šûúù_O³4Hû:þײùgÉvŽ.èZÎÐ|ý3JtnñÐ’ûº¸Þðí¯>ö“ßû"ÀsçáºÀüŸ*ç¼_ùãw=bhöuü¯eÎ5}YÔ—µEïŒ[<´ä¾. v¼óÌüÒï<ùãeß]”%ÿäc?º7…~µ·å6ÌÙ$´lpñ0“r€F€wìT¿H©¡û‚¶˜[‚¤*·”^"áâp†¦€$¼ö{ŸùÁÙÇæ÷ÁÍ¿Ÿ#1¯¿ÿCíÞsöͳ)Ëε/ û`Ha_úõΘŽFö%”¯"‰¦‰–þù¥Ï}ýÍŸ†Ï<0ò÷î+ÔÞ÷©Ÿ\šÏ¿tö¾‡ÌäÒ>¨·”Ø­¥àöHB}À“ÙŒ.”æc嘔öDŽíùøÁ&k+j3k¢ËÅjMµœ´Ø5Ó5º¥ÊÎE®¬“ð ”•²¹¸+>ú¡?øøüÝ?‡o¼öñûþæüO«ÿFY1ð7á[ÅñÒ}çSvúåÒ>\¨Û…(Á\c‹?ÈB‘–c#ÃÜkϾùæm•LRÚD—‹ÕzNÒ í#Ѭꑒ-=hB^gVébY©ÚKsDéÜ —¾ý³ÏÍøÆ·~ðÉâæü·ï{ÖF<_L·’YûÜÑ|ÒÝg­g_å7ë"šd>Ñó¿±òxéÑ|U.b¼?#OÊ 5yNŸ©dI#r74Ö«¦"üÒŤcá¬-îŠ×¾÷•óŠ÷üèçߙϿú±Ï|ÌÆt!ô@ísÓ{8|׸åL:wi ¿â‘Ðr,ÕRØçå ™o)ÐKaŸ4&Zìšé.“«L:Óüž‹mj—<÷Á»> Š;‘¡ IDATo”ã½ù·>ù±GæóoCý_Ú;b˜ö}¶}ôƒfÒ[ÏÄzÞùœg†@9@ÙGÄ¿¡|.Ò7ß\ `Ÿ¨©k‡°í·˜6“·8^e I¸aß!óJ5¹¸3ž|î¾úâ3Ÿ|£·‘lï:x·DFµ&ÜOïZo’âcÆÌ~67œp1JÄòͱ<Ï|s¶Z¬üºÅ¶ÔH왂_~c•‹€WŸš#Ç@ÍE¥ÐNc‹ññùG“V”›°‘ïya¼Œ¡½‹ËlcJtþÂð ›÷žúö&I½$½‹Ëlc-±‘Ú§Xlžö)Öª}Šé Ú§˜ýµï E2ÒÙ—¦}S·G±NPíSLÕ>ÅtPíSLÕ>ÅtPíSLÕ>ÅtPíSLÕ>ÅtPíSLÕ>ÅtPíSLÕ>ÅtPíSLÕ>ÅtPíSL‡ìÚPš…ú4ÔJÔbKY^lžª)‚(Fºƒ³kŸ)zø#†Ø´Ú}Ò¨‚Aºª»‚{£°¯Û¸oð#[M/K‰×ˆ¤®&ÙBrk_Õ Vߧԣæ¤×†ZÂÁ]àÉD\`s}€Þ°|`FMºnÝÄ&ù—¸Fz«ƒ™ЬöIÒg×>÷ »;Àüâ%¹ ñ¬æ¹ì• GÚ1£hKéWBø]üšØTC"¹ó[ûú³ÏTž“,À>î ÚRû c&^íû€•z¿ œ²÷ÌQ¦ŸÀ6;ʾ£¯©>òØÐäãÕÑ>¡ÐàfOœ}ÂR×={de_l|&¯ÓéÐ>Àêhk2«=e‘ôÏ%M˜_Ùç¸üëNrìðŸ„ÜÚÇæ˜]àjlYãf°u,*– §¼ÀŽ ²~ZéGÜ `ò”—8Û±€<Ùµo襫ŠÕCní[B•{ˆ•²o5±†Ú׫OWú­"rkß³ E2rkß …"ª}Šé[û¦nb Ú§˜ª}9ÁÚ_»cnOÆÕu몹¹›¤¶`nu‹Uûò·ßqÎð`·}æG.Uûò´ßú8Ä>çdçv V½>ìSík‡Ç¾gØ÷ìÖ±Ï~ Ýj_N¸1Ýœ°oNúÙg·ž}óg{±Oµ¯{^ë³mq~6ŸUíËŽ³O 7szRíËàŠK€}$έÅLRá%y§s^Ų1—ª}Š%bÎ/TûÓAµO1rkߟ(ÉÈ­}—ŠdäÖ¾©Û£X'äÖ¾ëJË×íe}oB/›S65JM™lÑ¿êijT”µÃŠÈ*Å«Èóµ¥î…Tsùµïºe˜;ÛìäëภØ×f­Çó„àecú>ì3ù@åDÄœœ[û ß.ÛC}á‡ÞÒ,›a¢‘å&³¯`PîÀ¾ÚGd¯¾¨:àË­äRE^ÓªÙ$¨»”úTê°&ê“”¦ ý7€)Œmj³½çFlhÅ€§ÄÜ5ér›ÔÁ `kVšÇкØVÑHß° æOkZÑJq·òÆÓÖ§Q´ üª ûsÙ†„œ}´‰Õ=?Hö‘–_6Ì1Œ°¸ÔšðLHÌ^&YÝó”FàòeQAÏP  ä.|é*"‹4èÇýD˸˜ýà2KÌÅÜ\Ìo~«ð´ÏÍ/.£^¿nYÙH?GA[Kò˜[ÙGžº• –O2ø ýG|»Ð¸+›UÐ#Óe™‚5÷ì Ž“+àʼnRS!ö]æaÌŸžAg Ð+—ÃÕ§ÍGû*ÓdÜgÆ~mC?ãks]«<£N2ûXÇ>ÓO‰0i%È>—•ÐQ°…W+Â>¬‚_ÝËöXâ1s äɵÑÈ>þ`ìäü!4#P8õ8fAû.û³Žtö¹ƒý'>|yØ'»Èìc d$‘}—ÁK›Ä¾Æ r›Ht¯œ8ûXµ…ûݸ‘&eôóªå ^DWöušó¦‰=/¡ GÑ18¶•e"Éí'Íg#±qÚeç$1:úLѵ֋Â×^Ù ‡…@£\v Ü-0PAåó–]Q<&À>îO¢«²"“ï{û(Isrkßu»¶,W›f½àzŠËþäŒü^¾l§k—I"3 ÁD61FÍò LÏŒ¸ê CyýHqeŸ »Äœ¡’ º)èeÏ&`Ëp4âHYjçXg—zLV4e…£Ç™üÚ·Ê€ö$kW\k!OÕ”7×`)–©9KníkªÚôX.û–SZ;ûP¨»d ±/j)š©9ËVi4»n-‘Ц^Ífj³ˆo̲]Ú§X-l•ö)V §}(ôt¡dŒ‚pÖMјóF±yÚôjTöñ•Ó¦šô‰Þlœöqö-¥¨žå(û6@ûØz§·°j£Àn+2‘—É**y©`“y™èª5¦v+÷t)˜®›|¤l¯¢ÛŒµ×>Àw8t¨àG9>R Ñ“—’^^&¦­u–ý2Z õ X}Lº.X{íC)ṌžEEhâŸ"—‚["Š•®v±·k¯}¶ó«¯/‡)r™1àr„ ì»Þ£éSäæ&”} k¯}¬[=ö]† Ee_…µ×>ÒÃÑÁ™¥ŽÏ>ÀeŸc cŸ7$$Õ ?² Сßå Ð>o«’#àîžàn+·ó‡Ü]šše"“iG³ÓjC—…pV”}ë®}Kö3e ¬½ö- ªSc@µ/ º6<rkßB¡HFn훺=ŠuBní›U(-W'¼-®ëÀYö6øW9lf3f ®4R+hÒeiO~í«8WšvËFüÍ \e°ÙÛX0cS%W‚™©•€nÉ›[û ßÃŒÞeÅHìË›WÙçcí[´o¶hg_Ù 6À?¸(ÎB¥[õ û {‡'J‰%k¶¾ÂB˜­Py¤F¤ÎL½TM‹46¨>¡‰¬g2t¾£híyÍHo6[´ö¼f¬eø² ì©ÛÌ"È+¨Zs° <² hrL¹À´Ásº'D‷€Æ`¸=ñº }ŒCáû«ÛœhFÐ>;±`Ú7K™u€8{”ö-ă%µÌÐdœa K$m¢ë¦ªù'…WÕšf\ü‚Í„q´¯2M»_×7ûÀ¦+CEò䉳o!’9ÝY=²*‡Ñ‹h"ÁR÷°Êqá ²g˜ aö™8à°IØ×ÜW²bÚ}°¨Ÿž¹g`>ø@ g)(Î>þØØ'2L†&ö±D^ÚAEûìÅôØbíSLŽÜÚÝa5s÷ËjøW¸Šeò‚:ËàûŠQûÖü=wªE7ÓÏPf~í‹ì°š¸Ã* Æ>„…24°ÇL³\öe±îµ¡K®å²oлïåÛ²‘ʾ¡ÄËŸClûúïï3]}f]7Ð8ñšƒÊ¾¿Ê®ÿ²|÷ Ž<ÃåÞ…[^&Fž]J rk´HkÓ‰Ejr²™Ù²´¼”‹èMy©3¢jX2‰`®lk†Îwí í°JØ]jž°y8îå„ŠƒÍäò¸+ WÌ( óNÜÈBä&c!X0/Ÿçâ´4Y½ð¥LÎ+=»[4`"L4#h_p‡ÕÂnñkÓ>þt(o"ìLMn>)½0qâF,7±ËÙ·XžôBT‰„\SÂÏ…´¾ RÙO¤? oCоx™®áŒ£}•i1ø³­Ú؇lƒ”V¶0¿@-ôcŸ£MŸ4©€«d ûX2?«u&öIgˆ¨öÙû¦†`í[„ÿ_G"û¬;SwX-x'Á½Ô}Þ’ö a°û€R{H‘‘}‹(exÚ£CU^.û:Íy½V37 lXq… Â>ìh˜0MëÒyÁžY1Äñ¸*™eB=U– ²ÛkAë´ààГ¸ Ycy¹3‚Gôâªï°Jÿÿ¼‹À+¶æœl‚Êçwv¥®½EšcèÐI) 2Nt=¦2OϦÀò¼N˜ÑVÉ XÄ,©4©Q4/‹ÂªÔ 8-X)XÖPòmø{ÞÁîXäå7`µjS"·öMÝeÅjÕ¦ÄFk_†¾aP‘”߀ժM…ÍÖ>Åjc£µO±âAûªy­ý¯ã3ò’—ÿ—J܆5|ýe@çÁ„ñ*„rÆ«µ:½ajMè"O4Mb™ùµoæü¼o±ZºáÂLbM“Ûð˜ûH›FDØ­…{QÐ7*RKkoS,Πί}¡½TôË ûh¢þHñ[oö¥YIõw{ŠM`_j Ùµ~_yãáv¸¸#y b+®ŠþR&Øx°¹ÄÒ?}‘¿ÀºîL}ùJíÂ]Ù6µ­[£Æ;XÐõ`·Ú°á‘MÝØûQQºÈ=.ør5m¥—¨a‡{b±›7­>e×>*eôë3Ä惙?î«;*¤ Ê™µð_ôºgÀÆy1ì}UlwsábAC4Oiïh ïy‰…¨—0êU} è7ü¢ƒ‰<;A/zí©ÃÇѾٌw¬3äÛíÌ^ûÒöš×\ó£ìc9}™¿ð¡p' `€¬ú¤i[qŒìK*dáu~À/Bicv¤)K4šöÉqŸÛᲘ~mÍ%û€±vmÀÂ=ᨣÀwÉ2„}±²iLŒ}  5ˆ‘8ú€GA˜}&c:²>ñ Æоð¬C°Ï.Å,šÙGˆOŸ=æÈ£‹z”D¬0ûšð(hbKÔR9¯QN'DWÞ•}é{›þŠËÂ…±õ>¾â‚òL†ëŒKü`3ñ¡Šs›7 s£åu„o€m¡ ³¢HL”}.e|´EžàR(ðÉ¢±mXñˆö!Z0Fñ®ƒý^²ÚŒª·°w9V›q³îFòc,“ÝŒCì¤ZÈnÄbbwÅ Ù üÜ° ¶°ODîÃâ]Ð:é 44X/·KØpΡÒ÷¼«€%kYðÅ0j1‚ö):b£Ùì -Tû&Çr–“—‚@S[—[ûžU(’‘[ûn(ÉPíSL‡ÜÚ7u{ëÕ>ÅtPíË êƒò²øuŽ©Ïõmb#·ÀmsókT·Xµ//,¯ì ¿s|–‚›×Pú«Ú—1öÖm/ûž“›ŽìSíKD3ûHÏ;ßöÍéoTûrcîÜ*Æ}fÌç´o[ÙG„Pµ/3¨ ÚGÙgà[à´ÁìSíKó@ó¬c;Ù‡c¾gUûrƒ;v¹Ïš~W¬¸lûȬc>gת}ŠÑáC缊åaºUíSLÕ>ÅtÈ­}¢P$#·ö*ÉÈ­}S·G±NÈ®}ׯ_¯-›‹ëåùº½·‡ëu,?õ@c¬¼ª“c¦Xö@° j(±Œòb+8ÍÍO7“ÅJgsùµÏñÈÏNÝáºý! ©¥Œ}€!+e¦öñ8i–˾LÖ—Ã>/8»öIö‰Kƾë$aæ†Æ’^Fó·™lfß’±üûcûziåa£%¥¾Š?Nm¨8°h¨{=07Õ± ÃÒáb:×C}càœz¶]çM2k´XkÓÕÑ@X àáò’TV´?Di«±Â®]2(ä* ~µ ó#k•57Ú;EI¬;fÓ5›'kûFÚÄꞨ§\>wôŠv9¨§è‰:H©QžÀ«{´$À¼Úp ‘K™tV˜GÈuÈI!Wñ,¬Õ.|Úgç6ð”&ºNNþÃ%·‰}€9ÈÍ)m²Ï¾Ø‰:eˆmξSA@¿dûx„\™NÇSi#|éQ¹7VB¡AVÉlÓ¥«x4ƒí]–öEz^@‹ù “ggŸéîœôãö9ŸÒ$œ%Ĩ«l ûèÃ%ç•aŸx„Ø<èÔ9ÉwÏŸ;­}¡YÇiûlí?ñá ³ï”É~¶†±/Ð[Ûœ}¬”ö}^§S±yüôáÇ(ì*žE<¡îìë¤}¤×µ‡Ð¬ƒÎ]m;€|rœÊIÄ}LJg–íã¾S6’ò]è3˹“Òœ%a“êNÝX¨)Ø—¡1ë„ØG=bgSÎÔÁA§Ú2w’öŽ }n)™¬6ãÌ–Ïrs,÷Õm&>bÓ3;f>%ƒ”Sw‡ÄfAflB'¥@‚ȧ™ÅT†6Öá”× 3H…DùrÂIj4Ä´uØ©(ˆÖÕUSŽbm&ZSj†Ûȯ}«†&K±Õau†HxC¦æ,Ùµoå ìë‡ûhÿ‘–©9ËÆkßà^)C±Õa‚unkH ¾1KníÛW(’‘[û¦nb0‚ö•af.Êëýê`ŽUŒIdŽPþŒð¯Èe[®5€i„×*0VcòkŸaZiÜfäʱ¯ÎE¿ñ\ÄØgžJˆ’<ÇZ±oßcDÂó"¿öv¹C}1ÛÄðDƒ0"ûd9¢°ûÖ -ì ÙµÏ Å®¾¨dŽÄÌfû>û*ͶÀ?¸G0÷ÕOÍŒ¨îl'AûöÖZÛw™ÀY3veaû¾¹.Á:À4Âkiø>ógd×>*e³Žõûö=/y°Ønqp~³™qÉù¯:¹ë}³OmøÖöIš–>^³· 6Ž·/ÆѾj›cߌ²oßR û@)Ï’Ø·¿O‰År3îÔî´:æòQJîÓ¼¼âÄ­¬˜· Ô* ciŸ÷Ù±ŸäÃ>þÌϬ Z؇YÚÙGÊÜßß']½Á´ÝÙ·Fô£€`«È'j ö¥j_xÖc›sà#÷O0¦™}âÚ‰}L5©—û³o}èÓ¸@Ãs¶)»ö…W\ö]vÅûûr¹¥úláHŒÏìl‚L:$á)'bÄÁ&»²Ö ×Y°W?>B’Ïl@|ç9Óói>d×>:×à«Í¸ëÏZ8ÏÜ7“ 7ë@:»XÃÅý}LgÌj‚HA¦@¾9L¼O3Û«ôžk/iö¬öœwõÑÃy¹Þ>8mÏ‚´oÕ¡ì7fÉ‚íÓ¾=Çu¡£c¢YÇÆhŸbe°}Ú§XŒ }vXíÏ2mqY6R{ŸÐâlpÁoC©s.¾3hMŒ5ðȯ}vXU¯ßƧ_NßEG´ˆÓò°/ßú›×,ˆ„çE~íë°ÃŠ„Ž‰Ø—\D("a–ƾ±]ûºì°"¡®­a±¯9h‡C7JÑ…_Œ£{¨ö÷ÙB*¾¥`k̘‹âk×äu‰]à&ý _­ÞQž%kWɯnf~¬ü«nûû*´í°ã>òNÛm—7Ûö¸ð½SÀâ¸y~Âìüu`xÈ °7˜–ïîQ$Œ¤õ°JÜ7Lô21Ô‚Õ˜…Ö:ÆѾäVüm›Ïú¼#ì#¥J~œur`DC'ÏÍ3³"9ÉïõØ"Zn?f[œì³ÁÚ‰’³`,íKÛã"Æ}œ}é;¬öɳ0zâÅíÛÏmû!‘ñØGº,–¶}þSEúMÈ>ÖpŸ}¯Ð1´¯Ë«(ûºí°Úç©ý¢D ²ÜÞG=Ê>¦‘ØçXX+ öÚØ—>ËbMXñwwX‰ž—ÇnT¿O&%ë>Í^>UèN‚=˜ŠÓ†Û…–Nê!M¬Š­ü^<7‰Ÿ· -ö\ªN&d×¾.;¬²¬6ÓÍLdºŠqÈhÓ©°Q`6híÓ_›˜î“¢¶È„Ø%å2" ÷-¹[gIniÂâ÷Yu3³kY{‰9‰Vpµç¼ŠDtgOöþ¶²r^ßóN7–HÏ1VU: {­› Ú7ºvaYÇû½1Ѭc]¿¿O±ºÈ­}S·G±NÈ­}õ4·´\ð¶¸æ·¹ûv¶ï9ô¾z\f`ß ¾žß?šŒ¼Kþ²ÌüÚW‘¬4í–$(cKcžƒÀ_në³ï´…}›CÈÌ-ÉϾÔq_Å·ÓÀ%pÉ Md_wã›Ã¾Ì˜TûNÚ7;meùSòG¸0~`_Èï¾ º cuÀýùLåþ|„g‡ fÄ_`†éŸ1V!Š‘+û·&¼ ¿â%ÐÝž:5vãhíyÍ@ofÙ×(}€¤8uÇÅ~í¾½’y xrE4p çÂÛ‘¥N=Ã~ñèõ@¨”Ý@€(øiíöW¹g›é7‚öÙyÓ>;èkb•¤S÷w²(?bì3ÊuJòsw¸”‚}&Å)¥(IŽ$¡„u¬«Ñî@èª)ß)õ :•§A¶·¨oH>Ï÷9Ø×Eû*Ó´ûåÝqƒšÙG{8®-ÔG„Äü¯\Ø@¬{é1¹ð¢ !w ]=ú¿€ÿYxö”xâ4èr-ví; Ì:ÜRK2û\í=@ÒôûpìAfxvBìÃϳèNiµ;°oõèàI€}dT‡I!ì[åEûNgŒ‚¤'nõ¡.yÆ4‰æº7ÆpŽÏäfK¥et•†)¥À]&¡4çŠ Ä¾ž%{6ûÒ´L2«Í¹—[NOÝ\ˆÃØ,ÔÑ m÷‚)N§'i¨)ÒÁ áSt=¦aIEèÊMyOiC]˜õ¥I`Ó±k¯EÖs䪡¹ùµorðŽAÑf÷lníËXµ¾"JŠÞ±/·g7PûV°g[C˜Û³¹µïD¡HFn훺=ŠuBní«'¹¥å™½¬ïMèÉ,sŠ™C λE†lÆ7dK3Þ3!É’˜§¡½Znä×¾Šo¥iw ·æ:'À|çôe_Óƒ[2ûºÖÜK2 ?¦d_긯âÛÉ Q¹†-—}Ãl®°¯G⥙2EûˆìÕUl.Zöd°$®°éL8Ø_ro ¨ÒàÉ$&ÑÎv‰ýl€i˜ñž“J0[¤ÜWbÛbóÖ°âÝ5±EêÆkÉ=OÚȆ3Â+Y1Šö‘_uaʈ8ûêv#ËO'$ˆ¥;ñµð—þP æ 9y™',º)›+ËKå'¦íðëÇHI’AÝ`Q»aǖƼƼ)‹`¾Ñ¢@,7'FÐ>:¿pìs½o"ûÌ?ʳ~ìsÑ'NBˆ-–} !K‘lî) ã–q"ÍA8†7ŒGbkNÜÑ„:ÆÝÈFp.ùTvö¥Wrbí«L“qŸérg'­ì³Î ³õqöIŠpžœP fœ0?§±e‚æâì;@^Zóû¨AÆ8Ÿ}®*]Øg£ ˜# FоÖaÙç:ã@øÙ±/àM¼°Ï ´¬çÓØ|¾ýÙ'¹Dšé=èp˜æDÙGšc_´RÔ÷öÅrdÁ(ÚWüÄÔð®Ó¬ƒ:–è¦3,{bèt—*Ê>p¬ïÄ> fÜKìŠ Žîh£Å¸ÏÏæˆwìÚy „mÁ>άH¯äDní›Ùµe¹Ú|Òξž`ã“êl­’ù)™Ó;}îtLÈv4îòcb›Üš?A['~uÉ\“Ó’»~}ªrBkƈµá³\ᕬȯ}Š pµÝÈ­}S·g…ÁË­†jßcáv-¡Ú§˜ª}Šé°!Ú7΂€bdlŠöå×¢}ʾµÄºkŸ}Óaêñ}€¿fz‚+ª',hÙ•V¬½ö±`ôµ0fÒ­Cü­ÒKøŠD¬»ö‰×¯'”X¤;f/0Í5Ù“¤˜›¥}b;P3û0F16Kû±”}k€õ×>¶ <öÕg2Ö#cÀ“ôMŠµ×>·7(¼«‰ÏyÉž5±I1Ö^ûºCé¶2Xíë eßÊ`û´OûÚÕAníËú[Š Gn훺=ŠuBní‹ý•@òõÍÙ¿»Ù¼‹†4~LóŸÕð¯ pËä5T”ü‘FStB²ók_ð¯Î0t4ò…Ùü²™˜KaÂBØÇã@¦™š}Éærk_ìïuØëîÜè^FR.åwSÙ—`#”x¾5xRí ý•Àò‘ïDü~wôÿXþ!ƒjµÙÝ£0îO Ø(þ5Øß7r±Ä†‹0%‘?$€ÀF ØÄÖ*¦ñ¬ñªžžzvThñÎ-²e\Hàþ\ð?œ0Ñ_ ìù÷yqho›|pJ(è|k}jÿ: U) ©½/þ=BèDz-DH}ÂGãbN© ßyšDûxMXÌœÈ-Ûæ|°`^~Ìõ~‚P{§û+ÉÚü+§Ž–Mô;¥ÄgJÚÆ>GÆû'žºP>\rçh‡B$ªN?J>)½0qâFÂ-ô*ˆ5ÙÄæF`Ý®™}ãÜí×D–Ú}²®`Ÿ«ùö¹^?òa A®Íäc2Ò_ ú·ÉÓØÇš+Ø'ØöºîÙú:¤+ûDl'öñO;°ýØç¨ÝX‡°> X1Úæ@==/‡0Šöù%Ðt¹ =¯u,³ƒpw½Ì(G}ä´ IDAT†iœ}¿HÙWŸI62:µ’Sb€[;/øTÖx½<®JfÉŠ[€¬-¡eÜçüáÌÉö’ÊЖñ…ýFní‹ý•@oÑ9èÓõËdÎLŸï¼q²h;ŒfÏ}ð½Y*)ŠMPA¤ tϳF§t®N*è¦ìläA?4•i2iÚi3ùxqÆ­¼:²½Ä—ÌÛãü•@}Ï‹ˆ?ÇœY†¢7s“ œ É­}«¶ÂØVö¡Îæj_4ô%³ ïG»–Ì»ª}Šé Ú§˜Ùµïz‰Óút½,áúutêNã Ï€,1Ï·å!cãš—v8òk_ųS<ŸšCM@{ mÍÅ+ûò6ÒÍe×¾SÃ<÷{j¨fIH‚R“اHÄ(ìë }>ûMì#ëIdýÒÃï:€ìE¡KŸ@–„íÉ-ªÒE_ºVÌ×séjóòç¬K„] ÷‚Nùò¶[·–ëÐÔ‹ÀVã½AÃFÑ>Ñóâð´‘}€ì3ï/ÜJ¹{oƒ’ 0ùèqR’dtƒ¦>vlù´„%‰ ²Ã*òjNùSAûÈl£ªQ7íC vÚaEœáÊjyzj‘¼ü‚SZÍgß)o#ñPà£É:¸Ï“P¦Eû*X¦1ª5ûÀ*w}´KÄOi@³ sJìú‘‚ÎŒqÛÅ>|QŒÁ¢§ ^ô Ð4üº²¯Ë¸¯D°›mek®`ŸLk/@ æ”ö ìCö‹¢¶„}4H²:@Üç‚}§‚Ô#ké%¬¸P¶Ñážk;;¸ÆGwô+Æ}~6g—õ€>³×›Šûzî°Â¡Ÿô©xchõUtwµ™ …C»’ÈÆi|J Îq wUöm&2ï°:™žçs'¿öM€ æÅt8"ὑ]û¦€²o„Øg{Ó\ØíÛèNq*¬Ø«4í[(ÉÈ­}S·G±NAûÊÿ9´˜™‹òzQ̱Šq7™Pþˆ‘¤ ¼]#¤V–µ0Ùxb“®1yjáùµÏ0­4î3rU_ÎãÐO´:×à«Í¸½È·ÚL¦¦¶‹º°\6w$ ™®òI#qª}¨˜†% MW1Ι¡¥Ó8¬…0EM3[dBê’‹r™ :@Iò£+½"‘×aÆVIØàõuõϯ}Š-†/†ÁP‹´O±½uÅ Ý¿jŸ"qcï¯Ú§˜ª}Šé0‚ö5î°rsÝ|;\ÀÎpS“g+y£Ðaq¦5yª‹ók_ã+»Î—q{Ÿ\lϣР6V ©mbëQLyÁùµ¯q‡•ØhÕ¡±ÑhHIÕÁàÒl¬2²/µ„ìÚ׺Ã*Î>ºhKÖPÝ1ú®ÃÅóÕX±0kO‘¥aúrDUÄÖ¦ðJëZ£Á 2Ñ$;¬ºíï«Þac¾qïhyÜë<`®@Ó×h‡½2á6þ¦bw›„˜XCƒ‰<;~ª…ðèÂ…£}­;¬Ø WGw‰ÕobßÂk¢w)"¸t2ŠÕŸÚ`–Mdß"ä%!ñA_Åì=º`^]ÂÞfw7ãa1öQÎpö-ˆp£WÆ`ŸíZ"Q[Ã>Œ1Ù£ÄÈÚ׼Êy5of‰'Ú4s&ö-¢ÎæfcÔÈ>ìsB!ºò‘´¯y‡ÕŒvÆ^Õ݇ÄVI,žvø© m["ŸAðN˜›ç÷±%QrßúF!8à£=€Id4ˆ‡‚v˜ïŒ‘DXÆúÿ¼±V$$ÛŠàÇ vrµ »|øÜIDs˼,Š‘ ìøõƪï°Úæ÷¼FµñìŠãîAû6ʾD„ºâ†~Bµ/·¶<ÆÛa•¦}û E2rkßÔíQ¬Fоr:»?3åõ~uØ·—åµ;/þFF-sƲ5XlA™¯gֶʆÒz²}ëІüÚg˜Vww;›¹£¯ÑMM<èM[¤¡p/ â<ãý¾Ì ey-€Hx^ä×¾šUȾúbVß:¦×°SË{³/ÍJL:šÍ…R¤³/É~J™íåDÙ7²kŸáÊ^}1›qö…¤¯Öy«ù¶áø€\.0]”×€!u&g×]Ù6µ-ÒT Y °OŠ¨‚M6ÜÖÍF…*ê.1Ví»D¬%ØGbsE#Imhæú}‘ÅP_?æAví£¬š¹Qžû±¿û>ý€tæ;êx<Ø\@s‚——Œ`Jä \,17Ä,ÐÞóû¢^¨WõýX>&Dàý¸«k.i¤´Â²PßS¿÷ý•ãhŸaѾ}2©Kö臭·.r—è@}ûûþCÒðP©%f†h#Ø—T ÉÂë*›&vZŠG‘O2žæ`–=ßcAÁF7q·7ÆÒ>9î³c?dŸíö}öÑ>ø ìœ ìÛge11öí­AŒÄ ܈¨ˆÉfÄ ±F²´ÀŠÚ—¹!âOr³Ð ùµ/<ë@ö±@áçÐ û裒k]Ùç×™çcYY›ýÙ'åÌCK5i…3ûƘó†V\ö÷YDxÚ‹„m$:ØÞ‘fª?“Ø‹í‹g¿ñÞ8Æš ±¢HL”}.el$ÅgâcCJ öEÐ|”}lǬ/ ½H¹áù9ŽìÚGç|µÙÎ:LT®€é*èœÒ ÁqÖë’ù‡:Óy'°;;0À{6öíílÙ¸ŠîÓ:ó|6§µo±™+©Ð¾¬ð8 Œûx>2·9˜Or!¿ö)ÂÈ*“ÁélŒ }Š 6„}¨Ä Ú·$d­Oˆ‰fª}ŠÜPíSLÕ>÷â qxƒqÒ¡NƒmÕ¾gÜ‚4Ï p¥èŠmÕ¾föí+û–‚õ×>\ÝÇþÒ_‘¥‹ÂtÍ”/Ñâ‹0ý¯±I—‘Y‘øú‰ÙQ¤`íµ/ö‹¿Z Þû,Ú†ÉLà˜-‹d…çµÉX{í#¯µ8ÅðÍ‹ÚwìÙç91q€}û,ÿ¾ˆ£Ì…¬¯¢6ë¯}x¢4¦(>¦“›Jö÷±o¬†n"6Sû˜¾ù]«²oE°þÚW?z„êð(¾A~‰ÔŽ á#º}Ñs‹1¦¿ùJ‘‚µ×>1çeÛª\”ërmX%C;¸¯÷6áö";¢s&üƒ+T‘€µ×¾4ù $™ë¯}IMÉ79¶Cû´3\MäÖ¾…"¹µoêö(Ö Ùµ¯úD'õiV–0›a½Ÿ¶Í©éÀO “©ö— H«T‘,1åÚWñìÏ'æ0«~Üï‘óQBØd´ˆÓÖ‘}©• 5/‚ìÚwb˜ç~O Õ,#IÐ’0û’‹E¬$µ0%û:hŸÏ>d`û*Á¶ª R¾¥ÀX¨{²úT3öcÁžêx÷CrFù¶0g´tQZ;ñÂÀ³díñ* 憰3!­*à‡Ë 쎅¢}¢çu#½Y#ûêZ›¸ Gš?_`“ïavšlJzÂì,7¦‚ -`o0-RÊ3ÃÂHZÿ«4>¨¬3]9µÚaíVe0†öÉÙjŸìŒCN :”g1öÙOó¡GcÓ’,ÁÜ.mHNò{F!å'[ª¬Òøð*ã|"ÑÅúLzª>¢}f”sxÑÄ>|,õgé°s%'÷Àq'VmÚ؇,ðhÃN,yöù$Dú­ûl”pDW;aOue_—q_ Oè#ã>VçàäH½bí-O¤ZÙÇ: ^pˆ}L:°ÏƒH­€Ú[öyŽèj§É±£jŸš{ ¯¸Ø¡»½©«ËDøáÄݹÖñq‰Ã§jÝI°SqÚp[¢0ÀÒI=€”)¢Ð.+•ÿ,‘}| F,[hÇ=KM¤%e×>>ê«ùêiYtî²àÒÚd3u4CQqqŒÑ@ ÁÝŸ™¢¦™-2osÉE¹Ì†ˆra®D,ÈEñêŒ êomÀx-Iü žþÇÚûüÚ§HíÞ¶ÙµO‘2ÌØZ¨öM†%õ©« Õ>ÅtPíSL‡ìÚ׺ÃjÙ{ È ‹|·#44¿öµì°:é¶à’CØÌ ÑÅÌ)Ù7h ½ï¢}#<½!&•}y1Šö5í°:‰³½Äq ¼æ0yäb³]ãÞÿÉ<. ý´²ÀŒ>‰&ì9!'`´çÂdxŸ“UFˆ}6ªË«ŽAûŒåÈ«“†qžàD²ú$Â>|ð@,DqöÑÇr’Â>‘aÕgŸçÆœUûB;¬Nâã>;ôwæÚǘ y!Oün×PB—Þ~ä0hfzµ®ã¾L;¬:"»ö%í°Ê·âǶïàf ?Ó’ýM„, ²;'Ä´)Ö¤Óeœ¡xVÖ5vâ~B<Ôe‡U7ä×¾Éáuνõ.]‘†ìÚ7= Er’õ*}›‹ Ô>1)’h¤²¹µo¡P$#·öMÝÅ:!»öUSÚE}š•%ÌÈåÂdl@Q#sÄyñ$!ËñÄ ÙÖaFÓE“©¦FоŠz Gž>ìCitê–¹³•'e[g`³è ¸øA(m£îjðRŒ¢}fŒsxÕ0îs¼ðØG涢?ì“ä`! ÐÀ­fŸ‰Â"/m›ñÈ#hŸ©H÷Y«¬d¡Y³ö¹‘Ÿr!KñiäùvëÙÇyiÛì,HJEŒª}nȱ°ãQWc®}ì@³‘O•h­÷ãlÄÙgÕD&Þ8ö…| š‡ž#ƒã°öX˜ÏXÙµú*ªÑèEîÕfËÚ:Ãñ'«bRK¦ÅôÎF/ÀÁÄlkÒjæ7‰0TFR;¸`@¼„a®ˆüÚ§P¤"»ö)ÉPíSL‡ÜÚ÷¬B‘ŒÜÚwC¡H†jŸb:äÖ¾©Û£X'¨ö)¦ƒjßh Þ0¾±¿ÏnŸ«æöP·¼n½jßX(|î0´£ Ü._Õä›b€jßhˆ±oî„`kP®?ûTûº"ÚónŸ›ÌÇ {^× «ö…šls.zî´M¾2j7§º÷¬jߨhìy·ÊWŽj}Ù§Ú× :ë ˜»“jßr@½a}c]dU`kÀÆz.@µO± xÄÐ9¯by˜‡nUûÓAµO1rkߟ(ÉÈ­}{ E2rkßÔíQ¬Fоò¿íîÍÌEy½W̑ʤË@(p©UX[}7 ùµÏ0­4N؆W3Œ¨ ˜½MM„@X»›ˆ)Ù—ª}5›}õ…㜠œÉDKAˆ}cØÝD¬ö2¡ØÕ³Y;û*i·úΛŠQ,Qx¢Ç*YõCðõWb,Õ• ¨ H»&œ&¡_Z°­Õ•kS‡ÎìÚG¥l6ñžda¦u¡œaÎõ@uϘËÜÓköS€EË̲G’Ó\6mìn±­–í¥ãhß ‡wŽ}³6öakÑØæ(ûœ ¡PYñÃ_Â9–c†í‘â$Å0#‹ÚëÉ,ž“˜KXksb,í“ã>;öóÇ…„}ÀŽ•j‘À¸öUg¤0ƒ>ûhêojOPŒÚõ£6“}6 hkó"¿ö…g)쪄gÎ-Qöú%²oOY ètb×R›Ì>Oés"»ö…W\ö\¥_q¡¢éî?0JÎ:À’•ü gˆûp'rˆ,&9Á‹Â™Ç°O6—¶–¸/3²kkðÕf\gÆÁ_†ÕfËLÃR Ú³³Z2…#T’0‹»riœåº\›foŒg³LØù?®PG`3ó"¿ömÖ›j+ƒ´o ìËÕ¾>XïµåÕjŸb:¨ö)¦ÃÚ—°Ãª:çÙaïûöŽC^]ËÜ^zÞó&í°Úõ¾¡ôkp‰ q³'«‰ò Œ‚8ûÂþÊ„ìÚ—´Ã*¸Üâ¶X˜FÓ1öebÖ!=ãä ˜ j óÁ±œ}" h>ʾµÞÁåImHó2#»ö%î°šåXëÛÛ³“JÜeBÍ°ç”ø(Áíˆ"ó8pÖÜ<HX`Rjnù|ÙŸP;c®†lλ*;¸Ðc²6«°Ãj-ßóŽ,£a]ëÝ#hß*a]ŸâºÖ»#6[ûÆ]£ëZï®ØpíS¬46[û«ìÚG6±àk·»ÅMxݦ+üßm½Á×_Â1É]Y>Ï_ðŒà‚†¹ Xé\nr]ótã“®¸tÛã²GùüÕ¿ßo5pé%ʾ†˜HDÛ²B0V®ÇùFÄ¢]ö `l&Ú¬ÃzŸ`Ÿ¸dì›Ñ”wKöõ(Êg_jÎȤ—™k0 #kŸ÷Ö—ÈÝÎøÂkªxÍA;º‰. óuÝ=wÅ÷ñ¥azGÞ®°åa¶ÌÞEMbõ°v¬‚ª.’ÓUmwdõ"U£+Þ¤¾í]&ÖÁ÷XaÏŠ‘µÏÛoÅÙ·ÇFì¥Rò+òôyÇß‘+²hÏåôïìɽyàïßÀ+˜èÿ´U’ò«.Š V›Wº$‹$3]± í#û­¸öíÕ¯Ü;7ûÔÐäyÇØ·'!Dc0ÀŠˆ+4pÇóï±'´íÊFŠ’ô´vÖĪ$,X/&òX{ZÛfø¦>a¥åÄr´/ÒóÖWΤ{Á¸G£ÚÙ'øcßž0àßñÿðÏBȶm˜§ÇÓÓÚEØ©:扰Vž1nûlÔJì°ê§}¡YÇ^;û:í°ò?µá˜~ì£ãÆFöy´ ²¯±Ç W}«O”}@˜}^i91’öñmU³ûfv׳ßóÂ[ѱ6&ÚÛÃTrˆŠ!«nø  vç¦ÖZ€}¬TN+ tŸ—Ö J^zã>?Û-ƒ—ȯác©öXi9‘]û¼mUd¿ ä§k.¸ÉM eŒ°„®¯ðÎMW Øît"ó˺TœuR#{67¸Db†½çÊ¡U IÝ8ý\Oo3Ðy.°˜v/b¸‡ˆ³Ó/¿ömh74’õ­EvíÛ8¸>ëc^ ¨öµbŒeÖeØ^¨ö)¦ƒjŸb:Œ }¾Ã OCóÜx ³Fíø6«[tÅe„ï°ÚËF>dCíÝrÙ—Åúê0x Öûº|‡Õð½U>šÙ·d(ûš‘]ûä›]sü+I>²ì+‰þÁF× tÞ¬œšT¸poW`m^ºŠËÄ4£H<\^ÊõlhÈ‹Uc‹Ã¬=˘3oì­â«¾ÃJ¼å`¼ë°Ãʾ "}+ì‘‘Ó¹ðrñöR ÜÿR& 祕ö«F42xCaõvXðVòû À¬?ƒbìÛ£´ ³oo/ð¤÷DÀÞž{—E^Â9=¥Ÿ IÓàeÊ~*ðË¡Z2ûð„/öö¸ rb,í“ã>·™…uÇ,obŸV¾hÙDü=”}Ô(9È>Zé@Ô”ì³Q+±Ãj„ï°Š³¯×+"œ}Œi ìCíóë%ÍeÕ·¨ÑgŸ×ŒœÈ®}]¾Ã*Ôób£qd´gwìуô‡Eòîíñn×wE¶*5° I’}rø y]h8|ÂIð*EëĔٵï©jþ« 1l ò6/ÙÇJSGÚuïîüÊ·*Eö°,Q¾œ,’Eó²(¬10ÌE‰~Üs­ðçìX™¼È¯}ëˆÞLŽÕªÍÈAûÖʾÕÀVj[8]Æjn:V«6cc;µO±ØJíS¬Fоn%phúÏÄzôqñÂFYX-Lºâ2h½/¼ÃÊ,ù Bö;yáÁ¸––µ07%Öa½¯Ã«MÓ+¾h– Âh_§V{œ}ô5oªxÍ!;·TÞd¸Š[Ç7 îö5±H>Š=²G`M!üqãh_§VâE}µ”ºÃÊeu¯1ˆ ?âåÝ^$œçv‘|\WÇøuïy…Vo‡UíKý+¢ãqLÙaŽgo­|Y™ô·0á•.؇—´D I7…}x².ÛãþÈ‹±´/i‹õ;Xù'R˜Î>`)¨Ñvöaî&ö!ù6–}6j%vX%Ke7}þÎzG¶ÔV,'Èëêžñ­}—{Ô¦;îííª´Vˆ³O8!/²k_×Vb‘^Ò+““ èÈHÅ1oûäv+6îóöQ‘âöìtf3Ø·ê;¬:ýÞ´Vô»t‡ÏQÜž Æö@™dv¦G‡q6·‰”{¬¬5:ëusäµmê*î°Zé÷¼ý²Î¼YgŒ }S@Ù·–Ø íØë­w§¹ÆÈ­}» E2rkßÔíQ¬Fоr»;3åõnu0Ç*¦:³»¾è™¼cƛٌYƒ]’{ñ$Í%zÞ±Y›G_û ÓJãî0#W†o3v×)ŽÐe>a_0cS%Bú³o×cDÂó"¿öÕ|âÂf´cP‡6`5Ø—7o7öå@ ûÆBví³Òfæ¢ê€yÌ.»°m ‹=€ y NTœ¡¾Ã îØ8wÅs”¶X~kvY ±dÍÖWX³*ÔˆT™©—~i±"°{Z7R¾«©‰€Ííµ‰çGæAví£t2þŠc‚}¶Ï¥ÉÍ ˆ?ìÓ¯îùÁùÍås'Ø…]g “üŠäصOÝñÈ& É1å.þ  žÓ=8¼±4Ãí‰×…eØ…ÐOÐ «‰K'\ãû*ÆÑ>C.¢}»f&‚ãÀÀ¬Ä˜»£ìÛ¥ŒØuŸPÀÓ.1Éš³îCM,± 2p—FÇI[´:²Ò±ªùy%ÁÖÇ]ð¢ `I‚z"ÐäPór`,íóûWÆ>?‰õažYÙœ¦»ü:‘}¬î¨°À]Zp,‘`­«ô.Î ûdQ¹59™}¬â~… f¢òk_lt—È>ûœì?äF”}샛•}øLž¥@¢8ûx¥Ø'3¸a\mÈE¨É©ì ÖßsE&d×¾ðŠË® kéyh/âú;†¦’ÇÌS¤Cæ]¦TÌ.)a—1î 4äï‰ìÚGç|µW q`8ºâçfŠ–¹t–JN.1<ä@xïÆçË4Óâ s—D¶]¯†î3³»K ÚŽò£€Ô—Ä«ì¦ÎÑY/ЂÍÂýØ-%ókßÂIâàD½K_ämåÚ·y"9Ãõ*}›½‘·•1ö½J¤\„|IDAT±íÚ—6ÔÎ:Ýl_,eÖá˜W^n»ö)FB´ç­8w劽ÚníSŒƒtö%jßõ…áúh/Ì]‡Wæ8Øø½B¿n‚¯è¤–Õn¬CùKíoÝ”<0V]¢ì«Iç.Òµ¯"ÕîÕu<\·ËI{; Q®ð²,Ê G´½ ¯€,y²á± "áy‘ξÔqŸe^ˆ}îþºˆ†fF c_·²I+5ÀUbßXˆ³¯d=wÔ¾û®ãýu”GdYö×4% ]£[u©øb-Yêå+f Õ™ µØËá—ÅV­éÊ-¿£E‘Šò5ê]öraYýïêí°ìë }‘ž—¨Üõ]¿çÓK97Êá#¡©X„=Ù+o‹®dQQ‹<¦m‹ÖînøŽT—³K’R—&¬I¢e~S³¡}÷¾jNµÏÎ0lœ}n¢šu€=˜Ï4EÙgâŒÆÐ+ÆãcŸÜ€nùŒÁi t#zÔ6){\ІìúU Õ=ÒÙ×eÜW¢±çÅ3e°ƒÛc…þa/#I8}†ÞÓt)»ÏÓ8ߢ=51ıOðïÑÙöåUšðÆ6±¹j(šØwïÙ>ïyØÇùæÍ9ÈC4ìÛŦ‚HÒ™}þ‡— ßšÙ·UEšFðï\q‚C¶¹¡1lR¨©K~×áÞ´õÒ>K:»ÌâŒÆn[È.‹³'Ï&Íï²+Á>°^¾ŠÅ °TG™Ô2±;7‹aÂÊx¥fš&`a^éb¼œµ>ö½Ï[PÏhŸB± ö/ñ”²O±<ÚW²®÷2¨Ú§X"Jí+P³¯÷b…b9(Ç}–}Õ¸ïU…bI8šó*KÁÙÐzŸB1mÂw¥b_@ûÚ5sâ–)Vm½î•˜öµwØ·L±úJÔÁqƒ+å¿+qí; €ù¼:¨.Î*ûÆÀÔ3Ð|([bßÑq…#d_Pû*¦YöÍ_xá…ƒ#eßX8ûo*Þ•ì;¦¸RÝ_©/›µ¯dšÁ¯jöä;‚£@Ù76}ظƒRñ[´ïW•è•8¨´¯¸{¡¼?z¡Qö‚ dß±¾Uýí3òk÷•âW³¯’¾R Õƒê¤ìȾ+–~Ç5û’Æ}†}vÒQªÞ\Ù7.6‘}dž|†}†|iÚWŽ÷*í+Ì ìµç ɾ£’~ÇGNû궶iÔì+ÈWMy Ù;‚š’ʾQ°‰ì+E¯ýÙž×µµe½¯ó‘Õ¾‚~óy5Töƒ dŸœu˜Åæ6íóÖšk>V”Tö‚³­ï˜Öek¼õ¾’}vá¯YûR³ŠT¤/-’µ/éUŠBÑ€6 »Ó>…b0Ú$ìŠîïSL†’žöB±4í{M¡X"¸ö½¦ÿôßRÿí ã|÷æ´UP¬õ »!÷ÜógŸ}>gŸ}ö>÷ãˆ5º÷C ð÷Aæ¯>_£ï> Ã\µçä}_´§$ sÅžckô}ÑÉ k0ßZƒù†ÐÌ7„Ö`¾!´ó ¡5˜o­Á|Ch æBk0ßZƒù†ÐÌ7„Ö`^L¯¿t쥗ŽëŽdt#Š©°äþŠu¿´çd÷ÌKéõ×_Úµëõ—^¾íîÞ…(‚}ÿRÈî—[RýX÷ë -c×ÌKˆ†íõ×wí ݾ÷ì³Ï^Þ¶{×­pùŽWC8vßrÜÇݺ+T|lÿe¨÷Þëáò×ÿ’pkwu¯Á¼ˆ^Ú¬RXt×ýÒ­Ï>þÊc¯üôÙ[)3Ò½+î×<öØc·ÇÑ8w¿÷—W{ì‘7ã(œ»½÷%?þìSái¹¥uïZÓæÅôÒþ[ö¿úzȼv¿tÇ›?ÿË=|üî+¿¾õ% å;ûË—¼ùów)œåÇO=öØ4ηþâtú•7Ÿúÿh»”Þÿ³óbê¾å½;.¿Jëò±îýϾrúËŸ¾rû#§ypí¾ãקOßyûí·CnÌÅëqwR >{ûé7ïèF¨?rúËWNÿô]Èz†ù–x@¶|±6ŸÌûªêdL—‡w_S ª¯œN+ùÊétV”|ÏC¿¡Ôý^Ü«»â.ߊ’¯_þéé‘~>òñé//¿Þýâ³èæ×?Eؾykw÷{¿>ýÊ_ž}÷Íg\_í~éò§}{óôéÇãySnv„ðŽ[ŽÅÀ¼§Šì9yìäI„õÉ=Ý\ê&t=¾ÄF(+‹•p–P™ôßÉc'£µ~„*¹kWÜ­·£lÄÏOÿâÎÓŸ¾ðŒ{½äÕñ_P|úÎ;º»Ÿºýô=Ï~ùæ¯ø¿Ø_ò:(ócï¾r>§Ž¬H÷ëûß{¯•¨ï]±0o$*ºó6H7J¡¼œN€®{6l,9)݈´öd÷Æ%{Jª"‚ù«={Ɖ¼“yyÝÝyyÇŽI7æmÈ+9 ò~h¼¾%uß÷ê‹qûÑXf°¿ûì»Ï>jJÁüÊÇïR(Ÿ¾ý©îî;n?ýÓï¼ó秣0‡é æ]w¼¸¾]õÞ-·¾¸æ*¸5ÏÛcEWç±’ÃPRRAÜÒI@×`V ?zL‹Œhrž³)w7‚<Ôø˜jU }ÎìCËᤴ$¤éÇ(eß°¾¥ÿº7†RXÔ Ú t+•F0?ò‹7ãÞ„-ó»qï¾rÏ_˜‘6ÿ¶¿wß¼nOŒ`¦§à±wý ó‹ï½øâþ;ößòâ{û¯‚Ù ¨nìvîΘ%DÕ±ÃÎc¹ÎœRÔóa¢¤ÄùUw7ý7܉`>|rœ–|ElØHÜ_"Aê\bÝ Ù“WQr²¤BZ"-Ùw?_Ió6žÜ·Ý°H¤ÝÝ%y_•l¨ØpR*­ªø!ÍM÷ëïÅQDYÖ—îߌû 2¶÷€¶ ‹ŸÆ}ŒÔ÷±÷ÃŒ<ûØ»_~ùʳ`FÞE°ÞzåÛÿòfܯaÀ¥ƒýô–[n¹õ–]¯^fÏž "/¬ô1€ù+â+ØæNÂ9"'Ë={‰ ÇÂ0;7”ä‡C0øÇ`H¥ÐjieÅÀN²!·D"=œwÿ«'¯ªÁøþû^ÉxšŽ¯à/oÃøI‰¤dÜÚ-ùÕ¹ûØ4Ê—_EŽ/ÇOùëW~ñS@÷€í½g~úÝ/_Û{OÜKÝ°ç}|ÏãoÞó—ŸŸþù³·"÷åéÛ?þÅœ9|»n½eÿ‹¯îÚ-£1Ž`–Ö=µÃ„dcÅÆ“ŸÒ“×Ã'÷|æ# 3ØfØ)fTÔí˜=`qJ6zˆÏ`ZrK6ÜŸWµÇSâÙ“—W@–X)]Í=™·1OZ±¡;´]R’')tßÿQ‰µdDúáüú-fXäû_½…Âyÿ³?}ì•Ó¯<öå³l/ÝúëG~þëgìžË»(/Sãô#àVS~ô³_RfãqÐuŠßþ÷^|õÕW_Ü¿x ¬"îG0Kˆ{Uã³”hã»øHJ| OZ «¤d4òò>"Ææ‡AÑ«ˆñû B K¡‚@®!À\‘w?‚ù˜´9óxIÞÆs À|죒 ¬ðg%yÝæ ? Ìïíê2xjèdâU*gÜ_Þ}üÝ{ÂQß±[ãîüé—LG#H?þéãßwÇKá¨ðžÇüž¸ý‘Øü½Woyõ½;^<¶Èovn,qZ÷T9óöä9 ÏW`„á:^"qJ÷Œ;K:W@Å’“ÝPlÀoF;b÷ÉN"×9~²{Üy°Ï‡)°$%ªŽUXóŽåYÇ¥yî/)¹¿)ë¸5<šJ*ŽUIÆK¤¹yÝmØ(º%Ç~@˜мWѱÑþ×_¥Ãí]H¿Ãg Ï/^Ú=³ØLÌ‹á³$tæwGôìèä{ïÝúÞ­À06 DA&õA+€J‚×þèŠSwô›>ö;y,\vºîÃ0¨ *.±‚tƒ±•voÌ;yŒâŠzJºQª!í¶n8YB1@ßǤ’ÔãÞ¿ 9˜á[ÂG¡ÝÇ^zé¥è¹(d îëß/®ópò–×!`\Í`{|ÀE|òJhÐò¬±eÌÍÆÜÅöìÐ…Ï@¯þ®œ(V'£¯*Òºù]ÔÖüµ ®ß¦dùUÄ5„s¹kt-ŠÀ¼Fß7­Á¼*Dëìõi æU!w rpn¥Ï§t_ò5˜W‡”Á`0>111>XŒ—"½ó*‘Óív‡M‡3ؾç5˜W‡ÜAŠjÊÁh(˃5KŠ×`^*Ç|Èwsûjñ*—–ÿýÀ¬ô)¯¦òoð–IÎ}Ù__áïfßµ® o¥¹•pJ÷u+üýÀ¬$œ‰åAŸ²&Öɽʈ~Kj;ãlÝWi¾.·¿'˜…â…ñ\³{!ªÂ«s0®•Àâd²r¢üš*ý÷³»üBY«ážI¼|Æ™xFèvó³W f‚ãÇiU&–%:¯aÀM(T–/1â X'g”WyÚÇÝ|!v"˜È?#DCo¯R7eóÝ50­å¡Jh)©B'!„[è°ÆéÞ_Þ^Nå;„˜³Õ!Lt–)XŒpñ¨n›{JÌmôX„­NŸ¯¬IŒÀœMÈZ1³r_kÛ…ø¶¶àeå*Ã|¹{9î2·ýj÷%s¢[©ô5|ÂYÖ2áÑ#qƒÃI´µ)Ýîl¢¦¾0ŠK"*ðñí„Óä‚9Z:…î^\Ôzt»±DøÙ´6û HrÂ(j'¯Öø6¨¤¤`öQž¬CÙšß®ä»JJ-ÊÛ(×é€yhOT:}²6göbáøJ¾OßæVè¿œPf+¹>nχº¡av‰3‰í N‡¬|Á\–X^¹š0ÇÇÅ]h%”•qeAßÕ¥a˜™;±DÌÉå·óùôH”h$­ Â6· ²•B‚ž¬Öx%sTÖ˜AϸmA®;Ê«CÛ`Öœí Â3ñ„ `.WR0gsÁ6æ`kºc`F«&é¦9¤Í4ÌÄ!ß ¼Áˆ#•SÂÅ»¹J³:I¶Rý»‘LN>ߺ¡aÛB™m'tÍEY=˜ûâ.Ôʲ¸Ë×rÅÃ0û`]Rè®9Ã?j ¬ ćl(¡]绣0C f>·¦º:ù”†yµSÚ\NœAX'‚6Ó0ÓFƒïFÖŒÅCùB3mui…yQòiCFÃ)„)ióQ‘möá„ ºí„ÐGÁLõïãƒåk%|Ü(Ì× àê„'ˆøqqe­­`›¯QHì“àvn.Æç+JP¡›R?*p‚Â`‰Î3W c¥F¨ÀÇŲÛË0´Œ/;£¼ÊÏ`ÊÖ` ·}!0´†a5CË;¸€)ƒÐ£¯*µÆ¢Ù‚B÷ CZî¦ò è–G6ôq ‡9F†64%\%ÔŽéÁì‹çrkÂ0Ç·&^MüUÓf"g´r¯ s˜Ü0»ÔÀr"Öûsƒ`SÐÒ†üE^‚2ë°à°È©AІ^§ÎEì(Ð •#õ .òpPMªAùâƒ[7ZóAhà&”±öªëFÆfR‚£1Ÿ²üZ´:gÐ]v\˜dkÇúß¹1s\”⯮°ó*Py,ÈqqmW×XƒyhaÊqíW×Xƒù»SÍ…Å0W^­Îk0Wrbܲлѕæ3qÂ…ÊöÇÚCªÕ¦šËåm4Ìà ;Û}ûʉ6Ç5¹:©'6×åôµgn1 ¾¾Î2ª,‡Í±®_Ùx]ÿÆrÙ|•_§ÌÆ:.qí€qâûŠÑ©VüµD ä…È­<9ðr.žJB—:D × çÅ’>[ÒvIwa6ËtX®híE Ñ"\šÓsØ¡Ž ïZ‚}³(X\YMÍ…}Á ¡ðϹO¸Ïp5Œœiø|×8ñ 0q¸ÑÁ%:/ð¡s1'¶x¦ãáË×ía±€MBqtz„8›ˆ eÝíåJß’g ü%ƒ±©Y†FåR†Ã.³cÇý¡ŒÄ«#j'Åðt-c÷â+ʱH²íÃqgû™VBv†p„åhåÿ3‹*zBÃkw¶¶a|7ÖænoUòÛ܉\G Ìn>óA©Ì™ØîãÆ·båA®»†ŸO |ÐéÑ·”ÈÆgóËQ:±*}B UqÓC5¿ÆÍ º±Vw;F›°D®;È碞|Ô!àÕΧFçærãk¸AààŽç¶·rƒJ¾OÉBÔZAÇ?íDÛ>e<*wgŸ &¶s݆Ñ0SgˆA0^ bürè—ž¡/k«ÉæƇaFl0eb; YY#l«á·Á p…ÆË8õhk'•A_v mbe9¡l¿&ÌÔ©V¶’ïh+ç/ÔÄ/,”Ç/p1÷_f¾¯ïÈæû¸åg°3n>æ<ãàòf3×Íç»ÛÏ`ÙN®°]Éçf£ '#hm˜ãœ\¾Ã-,p[}gœm\nØpÔºÈl-8…¨(þŒ›NÇó1÷¤ÙÙ5Ùm5BnfÐfŸÙÑÚš]lç/¸1~bùft†³AT®0ÛÉ:œ­À¦uÁ×Êu¸©“SZ›‰hl„Aè™ßÞlÊõ $”9Ý­ævw+u¦N”_†aFñ=’ð>!—hÅ‚‰mmBŒX ´9¾­­ sòñÂìò «1‚¯t;j‚BBHÁ܆Ѭ¢að¹?;Ñ)Ä„0L!šm4êÐ>¾±ö`[«sÁ鳘]lÐpÊi6mBt< E5¢øgÁlŒò èQYÎ-/ç*£rÌÙ55¾øÖ`bPØN`Âxç 30ó9³ ˜qø H­)®|¢|Á™‚ñ‘)›v‚OÀ¸Ê}ñŸh¶*³• ŸX†6;ù•è ų{†²ÏWoâ4Ìnz³ fgcn#”Üöšv¬ã. 9œ>DD _ØÖ(1'ì,ùœ­üòx>õ,ÅIq Z³ù5XÛæpðƒínç–;±,»=Z%ØJpkø­åÜörŒK PÛòøö…X6ÜDÚl+Aå dRÛkø‰5|Ê”†ä‚%Zù¾G"Ìs{°[ˆT"ßßÊOl RýÒ Á``A·-† ¼1ny°EO¸nt›Kû›µÙYNt_õp ÌaRR.‚“:A Ç–ÒtQØ“Xâ*!½²G×¥Ùñ¹±á¤j„z sÜ„’ÅÈHé¡D9×M¥”Ô‰+z¡EI}º)A•4°P=qñ&­¤#T¢ŒtHrVT>Å)4<§{I•oO7 ÓwSLwäË|Ó§ëÿpUg넳’_Yv?2ºòÌî/L×+Œjóº#£›Ö=õõÚFÏ|bݽÝmÚ±îî‡ò©]ã®ÊMH£©ªôu“êô½éŠü®‡Ö]ÙÊ\Õ1~?„¤Ì¿›’ýàúM¡a]¯®jöÁÝù4W0³Qþé‘üÌÙ¯ýîüü+›þä¡Ë•óüb`÷Tùòƒ™—ó×í>¢:ˆÚî^!ô‹ü#w=³þ™MGò¿x(ÿëò<“ÿàú»ÖÅ}²[~ewþúÏÈ¿È¿ùÏPv¬_¿{wÜ3WTù^yêrþÀAÕî+ùù_\¢M]¨¼;÷ë®Û}×úüÏ|±~ ¶8 s_œéÂò3¿æ+ëÚ<ðÅ3Gâ®ÌŒ®›}(îÈ•»ã®¯¼R©Ú±pÛt0îÓÙüÝ»¼`Šûä“/òÆ=´nÝ3»/ï~0î‹ ~qyÇ‘¸Ý—zj÷â¬|æf×çMÏÄù†wÄôû¸OU0Úß«fUO9r¹g×m¨¼2».óàÀÝ•ë\~PË+b4ž2]þô™Ê¯ûƒù•ªÙüM¿ß4+ïSÍŽªraÇ‘ »/ß•ùÌïãîÊÌ¿Ùa¾ëJfåà•¸»?Í—Ç=”¿î¡¸‡ÖÏ^¹0{U¸ióÀh~æèâ¾ø4ný샟Æ]-jó3—¬êëºÝôPÜÁÍ랺rð®u>¨Üt÷…ü»®ÄÙ}Ùá!f7³ò¡#GV®S]xèî+³`‡.ïþäò• ‰{æ èåJ¥éHÜŽJÕÍó¦ƒG.¨®Ä©23?ûýú ëãæg²þwU¸)Ô®òÊæÙÙ/âLøøZãË­åñʚě hab|vvk{v[ðGb›ùÈ×_Â^?ôA™tî,âRrƒ\$U‹…ùð'ÿ§­ÿ+Æo®io[£ï‹è_×B0”VÑßß_Ñ_Q¾ÃM-“*¾M“o×ÕÊi]|?R¤yÂ0ëo»í¶@Ãm/¼p[Cà¿.ö¿p[ZÕ–þ´ETÑ>ii‘l`ù Ûú1i?ªFÉKçSý¤õ{É^È¥&32˜ Ô¤š1©rº2\¤dZŠ²èï¯*î§Å€¦¡J†Š˜r¸l we˜–ÖK2Š›{Ñ=#­?ÔšQfM ¦ßë/¥ÑôW1èÆô8#CªH ƒnW¯·>-…L!Ëš+`2û«™ ¼ŸÒÝÞz i,g¬¬º—‘9–#Ê“2˜Þ4ÒO¦5y{¥ F™”YïO¹·¾W”©(¦ŒUW2¥Í)^ïPYŠ'ªÍ·}ÀéÁü`Ú Üÿø—ÀbœûSš{ÇÆ Wfõv¬0¯b0sÈ¡êê!ÒÛÜ‚¹¿@±ÑŸ#" šÇRüŠ‚1Òkîï­&«™Ò±‚²ú‚FïP±9‡á/Vô+ÒŽç0«ëSrÈê¡â1° `uÊÈ‚œæ泺z¬šå”ø½"ÿC *š£(..`÷ú©ú~fqAæôx¿4‡qÎï÷7ç4Ÿ*ð’^c¬@ ÂÛü¿  }Žy£¢˜I‰1Ö/­Ú8Vì÷2DÒfXòÀ¥€YÌ,Né¥5xóH¥ÒâE±?‡A0€AqYAsñP}AŠ™É,¨ôVU—åô÷ú½d³·¾ž‘3V\VÜ\ÌôóÞzÐ& ' s p1Ðßÿ eáìç¼z-œÅ0÷zA+ Ò¼)¢Ì¡æb?¨Ié%™Õ0ñ4ÌL°NÅCç Wzî8™VQÌ8w\š–‚ìVuu¯¿BZéÍcnLŒs)3óœ(‡QPÌÈ©¯®?7C„y’VVKƒ1O«¨'EÞúœþ”sdŽ¬ŽWÔ ›tÁPoo/#§ŸY,:×,MSˆªüi½ io¯—qn(&§ùœ?ÍKV7Ã2G ÓêI†÷K«RŠÑ ’ýHŒæs½ýÌ‚”sõ^o&Y2`ˆL˜ 2MP„Ïñ¦¤¤LÒqé¹foïPÚ˜èxcã9F5RùJi¯è^°Ì4i³·ºÚÛ›’ff/îc¦ù{ë›+( "Fã³^è¿í…´Û_h¸øAZÚmœ‹}°T›ÁÆ“½¤·žÙœR|fKTœBV5‹ªÈ”j£Sˆ½)i°€rüõ½0ÍÕŒ±4s}Ž¢ª·™Y «Ô±±òxeµ¢¸y¨@‘Ó_•É(óŠÆÆšµC9°Ô¥ŠýUŒfF5(¨¡â8I‘RE•Ÿ$RP–b²¸¿B‘’S\ágzÇÒ@ÙIš¢9§¾Y!ÕB9cŒª6Zý‹Æ€aZ&Ù\O*ü~­ß«)¤°æ‘ÕÕÍcõ ÀŒ^˜<½2ÆrR¤¤M¶¢^‘f&{ÜÛL ©þ^¿ÿ\½¢ºBQÝKfBOÍ)õ9¤?´9E¡=žÂl†åY­¨ï%Is#§š’  º¶¼ÀI«‹ ”f°ábà…%ÊŒVúTÐ>B½ÏQ~ýAê&‘ýR†·@–•ÕW‹rDõ^‘´Ÿ$µäñâŠf4€¬‰¼äqPP£Ú›&jN#E`a7æ@ÍŠ´ææ´zQA5p(fTW£ö9Ðºß«’¢\Ä‘†˜V{¥(ƒ*K)ªî­®Oy›¡\‹ºNCl¼Ð>GÔ\ÝLJ¥"/,´~/ƒDâæ'«Õˆm5Q,%™9ýôXÀöQã*H©¯¦‡Ä(Hch›™Ð ¯º€Q{Á—`T‡1€¬°`ÈfXIŽÅ0$zðÑ-0öN¢ŽJZÄ›Y 3º!ÀÑwøC{ @ðÝ_Öj/XX1è ÒCLêB9DP‚>¨#äA.|B5Q;HÓN•…˜ м¸9K½4§óPå@…/ý1]Û ¬ IDAT C@µæ±0»4ZôGfzýÞþhFA=µÒ…ô2άê © LK2Cé z´0÷z‘„¨l-¤Ÿ’""A檮‚ô»Q?-ôTš úzzŠ–ÍbÑ»Änõ^§§åQE5YpµòÀúJ[”Û¿DÐþmqÔ™-&s–v yÞþë—o0÷{«)L‡Áí]ˆCNN= ž,Ž ¿Xº¥þœúÌRãåæÆv;Ûý½×˜©˜¼«ËWæð"Jë•Ž¡ïŠ±âã´ ‰Øj½öÓ똊Òh“± ½t€ÖKÂ×Û?T.¼ìkh…ÿ¥Qk¿·`le«ä U†¹ö™´‚ãh{`øÑ.Òîv•·RÊ(¦ZùiŠ‚œ›\WÛh0üÕýõ f}ñXDÃiCŠ†¢2H…¨Z‘3Æì…Ъy¬Øo½Wáõ+cþ±IŽùÍ9¨¨_4; uý 2ų15{ûSƆ¼9÷2ÆÌ~­¹^ª + UN™¢8Í|oJ5ãGsÁê0,@!S1:¦DIô]€DÑ}¥IéD¸ DÅ œÑÌ´â´´H½btæJ±ˆ”÷Ð]®’ìßEBCcµZá«7”¢n¾õZÃíC\h®TA4'\!T© ÷†ÛõÆ0 Ói뉖|)o,ENèð'žxÇŽŒ>ñ„‡|r+¥¾£ð…Ûí+kI}]‹Êú®ÊZ¹¬ßH}_S°’1âa˜Ÿ»téÐê'íº´õÐ(~ôÒè H]UŸ½G8¯3©q\m€<ô‡êQ$X|jß*}‘!”æˆGKé–\GuOÙç[ÔpéTGøêVgWÕtÿxìŒÂ­< ÆªekafâÄÞ£‡Žª·¾¥þð-âÒ^â¹ÿ;ziŸÅõíø`dõájZ Íuvõ`ŸšÍV÷ Ò œgÍ©í:Àa‡2A[‡³áN0hge³Ý(Žö uˆܪÓñl5{ͶÛ)‡òP©N‡÷A+pSíÔ¶×õ©1[À¶§;ZØvŠ¯€= [-|ÃÄ6±@* ãºÁø n»‘ó'€Çî[&ÎQ˜÷î}âÐQÁ¼õOì¸ôá—N=ôÖ">8/ð'ö'7YG€æ8-&¬ÅdjÁæZ(FY¾iûÀfž€'0™tØì¼Á4Àql^>¿Yf°Ï›88&›m‘;f1ÜáÀÎã8gÞÄfqä:ýì,Ë„ŸµsL:¹|@µÙ øx<k~sÇÑÍæ³ÕU‹Ì€ÍšÅIèÃL˜™;;'k9o6eØÊ,Õ7bc0´Èd,Îf¹j»‘ÇÓÓ ®HæÀôªž@•/c/çm>´s¯š‚ùçíx`Çõ¥­‹¹àǾÓãê9£“05ÛðFƒ#Ђv«†ó˜ž·]Åžc«¶Ï°¢¯°“TA¾]¥7ðð¢tY߬Že(ÂØ*‘%É[Šä£1 wp9:Œ0±[XªtÖ7o7¥«ÕàëØ~êb}8®çØMv•Ýdä´`ƒl 8ZX&<À™í›[e£aÀ‹`ƒ¶|»|PÎs¶€r=n7ÎÁåç±€z¥0ŸxëCúÃ'Ô¼EìÝzé¨~¸Äf¨˜KÇí,“i–gb;Ôv™Å1¥™8,‚™ÇÖaz:ÛtÞ¡æ8:‚V F`}lì¼)~ÎŽ pþ”nP›ì¦D˜2@(½È`Ho1È°½IßXF(W³Xj5¯E­6pÔP×4h‚5Šc<£@®æ:Ó kÁ^_ Æ6æ@œÕ…¹O®Æ ˜~”ÇáÙù° b@v[­.*"ƒ&"°R˜ŸØºU}éÒè¡ø¥OìÜñÄ[—žƒË&¸Þ Sͱq–Þˆq°¾t5KeêÃÒ·s°íE&´bqÌ<ÏÓÍÊU:s‹\.kQajCffPsæÿ´™ÅÐÉŠæôlXÝr“άÛÜnJÇq‡œƒñxr ßlbŸÏ4eòó9˜Ã¤›eçóp56›Èq¨p»Œc2ÕÆUÀZÎálæmn1<K—YÄÓcE«k4ÐMQÑì<ÆšÿÓ< ›OÄÎS¿)g2'r8ÓÀvU S¿B£ñÄÞ‚ÑoØqôÄÞ½;À½%xnéþö*Kœ‚Ogu}ºt;»hО®-2ÀÔŒ`b‹tEz}‘}0 Ó™E*Ž¡¥ˆÝ—Þ‚v­tƒ.=½(žƒå-:C‹^®o)2èŠt°Ã@‹¡ÈŽ³¡¡ L¡]^z‹ Èˆ³t,»ô ø·¡ÃU¶Ív$Ÿ1×#áñ¢@Ø•atö¢ô>ÜX&ÊQ˜Õ8Zó¸BMûlßÂiF, !¸Zˆõ¡’è ùyÔ•'˜ô=ÕJqf<åžÑ%P-&5ÕN@ÕU‡É0wðwúd¬Hñ·w™ƒ¡p ã¡Ýáê;thP8-?XÄø[SXÉ©/uHvCK QoToP‡ \LêØÀci!ÞgX¦¿Œ‹Y¸.´ê,›Oæ~^Æž8úá‡îÅñ¶¢Ôsßg¼Å€8ô±PZgBßvÓ`¬ð}¬ÈÚŽÒP¾Ø‰ì37Fü&{ÑÕ},e¶âÁØM×›B´w¯€afÀ=$\zN½uï[;Ÿ½tè­­[ŸÛùÄ.Ô…Kls(H oj= £ð¾À ø!ö>d xFu8ÊSstÛ9á û‹šðXH}!LWÓÙƒq0¼Œr"$³SÐb4®¹À$‚i.Š†œaÉQBÝ¡W›ŠÔx,“ðÕØ jõ jÙúëЩ/¥º£à7¼ávñ.ˆ Û±$ÒÙ8„Gøù9È(Â9œ…mG5úL<–IŽXÄ“ËT¼nÈ7ªûxérv €ú"–Zç8Šñf‹@cäéjÇÔÇ–_}‹‰…¥ƒOƒf›8vž©E1ºÁdÄå(6Ùnâ™ÔFy€ÍKçä¬A^`Ž#vrÓv(RAÑ ÐtPî`©1y‹Ñ„™p;&·¯í+ÂŽÁ>9xš²v„·Á1`ÜÎS±9˜)†¢œ-Ï7êM<#ÎÃL+‡y+#Txrië¿î8±ó@¾f9G×b‚‘¡1«xzµQg2ßH7a!¿ÙT4(Ç1VÀÁês˜ZŒéŽœ£Òñô¼_A Ù70UßlѬÎa*â[xìÍFÄ1>§›7‚#®Þ.g`‚¶ƒƒ˜.7 s:fÄŠ8¸\çÐÉŒ³-8.ç©ñ¼vø óüÙÁ"ÕêÀ<;beÍpx²¢Y»Š£gr‡Š`±Ë1½Á0ue¬Í½ÙsE†Íƒò¹Úd0ø†9 ÑY#fàÈ1Ô¥ì<§Âh—ø Efû@Ñ‚S +xP®7àç±9€™cP«Q¹cÃZÙQX98§ÖCDõÊçwTM±ˆ9öœ:`ü•¬] ¼¶§ù°ÞŽ™L: Ð>‘nxA‡C\Lx,ƒ]—ŸŸÏƒ(T­fqˆ¹AžÚ¸ÒðD½w¯úÐ õÖêO.ØñÖ‰—ö>±ó­%0sþ$3õáÀæ ReízÄLð¡Î4 ¬Yû,[ˆéØl» °H‘t š9{À¨2X,Ðæàf¸o˜aÐqÞ „LÆ>G ï¼AÅâ@ˆ-3éÑ3 ózÝâà˜0ý€a"ßÍúÍ ’ª"°û&ˆÉpö,[,ô&0õªí:ã|ü|‹©EçPÃbLjÇ Šå(bÉY}³ñó¨)g»ž£2γѲ«1ÊúT,µ“úÌñ` Mz$­àèf〛 Èu<5O'¨ l;¬§e¶ÏÑ7P´B˜Ÿ“ñÜ¥—ö½´uëV|怒ϗXz@gïkÑÛq¸ ²}8»EëØêÁAõyjOƱ|=nTa`Y¸n€Çáñ8&•ž¥‚U­nQõù¸Q> Ws0¶Š£î39TP8ª0– ¥9}ò9P⎜ xq8r¹Š3¨£àÀæòU,žÉ„¼¿°¾¦–PlŽœ×28€Aìb—óL¿*¢XTz¹CU„Éõª¢–‡ÝîàèXȵ@Ó_Í  *ƒÃÄq¯¢_9L<]Ž™Ø*Sº.€Qç`s,¶|~£ÒƒÐj;5FWº^®báÑ=|‘DÈñUx5‡G ð´è5µ4Ô-}Ô1Z,tc5ƒü€œÊ –¦é"AO¿ÒÙl5¸ç¡gSÔy\8òPu\­T£Ãˆ6~ýXyy„«asÄÃëG¼5ªÞ ¡öVõè¨ñ£;?Tzî¹­hKÅ l|Ä×Sa.{T`„ÍÂÛ0…ªžcja÷éY¸Ý¨C±€Q0Ø"0œ—›ÎÛl»ž­ï3R«?Œ¶Î€÷ñÔ}F{Û Çϳt-ƒà¯¨1#ølÈÕBBg”ëú ƒ£N0¨3²ts<6®7´#¨dÔÁÑjaC¯zûy½@ÿ' uÕСÀ8ø]pÆGƒ‘‚·BŸÇÆðqn0ž7p‚vø3;džJ8«Eßg=‘pƒ^7ËèŒöyƒ.3 *}î-õÞKž8ôÄV\ýhó!p¢÷îܺƒÚzMDSê¾ùvÛÀî›Tëd},=€qŠ0 DÁ92xY¿š7ªì& 6-¶à ¸<]ÎÓa|GËfÇÀ¬Ê|Çç`»n‘Í›úLöͪ|VŽ³ ™¦L=ìšòYñøs-™s™z]&x óó¦€ÉaàÈTóé<ðÖ^\°õèÖ?Äq€ùÄÞ¨ Ì‡@ ±Á x¢(0Í›Lz°Fr6ƒûÄIÕÿ²£ž4™ìª9äí°°Ù¾95ËhÌÂ.†éurphq\ /JOWÚ^©cÇÞìÏçÛ/€m`󡶀×ÇBOeæúäûÆkI¨YEF#2lh¥ÃqLÐQAˆƒmèÓ¡\—>`,Òãfà¾Ìv9ÈúòÙù ¡Ü4güUh»cP §–³åÛ9‘ðD >:¦g±Gål™ÓÂ1ÿ â´¢®é(=:Ú Fc+e4ðQ|«`8Ïê{‰­[/l}‚2jN‘é¼nNÍV•cíª"“Á.ÀóÙv^>nR Úç‘1Ì×é1ý.·›ça^q½\gêSmÇôXËQ•Z½ÝD‡g¸@e¶ËûLHÈÁ”ƒm“ æMéìä‚Wë‹XœíÀM ˆíŠ"i˜1ËÕ’›Ï‡Éåy_€UÄRó`28z W_÷E‹åÀ¬Â1ˆùÏ;¨‡TŽAÂ>X´Ý¡So©UEFŸâŽAô€eÀç¢íÛ±Ív‡:€êAGlóŽl=t4´î<Öâ“C'GOP[à J-0=ØLü(f2âF–ÝĆøÁÞ‡õ `ÄdºðtÙ¬I7Ë“™frôJ'ƒpnn`€§7µÈå6HŸm1c8nš…% Ò8«P3k’éy*ܾc™uósPÛ`‚¢ÍrL¦S›ÀüÌC8¦j™3¨‹fy›[f9hjôj}æœÌd6Èpl³L†ž'Ç8СC…q¾ÌxþülºQ&ãf[f„œ”Ñ@©”í*SfÔ8;™ ­Ê¤—± ˜lçvÖUMf]̈?ñÜsGqÁŽpÝñŽ#ŸnÇô&qèÔ´?­¦}5í¤G” f]ßѾÁ>½ž­£pï3ôõ Zì-xËyÞ›Ú ìÐ/ì+lì°qÙõ£v=h&4B­GõºA”«ï£˜@ =Úî uK‹…ƒø ^ß‚Øÿ£°Í²õ-ÛÚ =A¹~ ®tø]^E‚­žÍ†®p%r‹!ôVJ ôz Ñ÷Ô&TÑëuì\Ÿ.gë"WƒmÐGÂG`]ž„ƒ«†'1g¹‘à˜ -|½øÀXÉZ"Å„˜±g ›P;µiÖ úb£ÂïBøâ>£Ù‘€3’¥“©Ã—;° {©ša˜ãì?[²°ðƒŽÀ±°½9ãà.*ŒþlIâ‚ãGNÙ7O÷KEYà‡aÞl¿´”¨_5ŠI†~åˆÏýàÑMHÂð×åwè@ÒVe l0ÈUBºCÿ'b¬ÆWÓ¦lúƒJ_üM¶P˜ØÎ ¹Áš6~<÷GôË]ñmÎøììl‡ÒÇ%‚ß]T ãƒî>†þ÷ïñÙΚ›eôs›Â6¥°½[ƒ~'íG3ß9Û¸‰‰í¾r®3žHtÇ;ãù­ínw°ÕY“èŒw¸kn¦ƒmB>Z~è·ñ‚üÉÏý!óænu`ññm¾r>hs¼;Ñ:ËÝÁ.Ñ$³o2˜k03—Ÿ]Îÿñüx%Èív'bè7›ƒî 2‘*˹îøò·2±ho#Λ æÄDúÇ+ã‘þ1i3úåf>õ Î\~¿ËÆZ¹\”Û΢vSÙf~ WˆÔ­`?ZD¿ª˜N ýüxøÉo¾ß"Ç0ê’-ä·Åþ9Ÿ»F«IüÿIÁê‹üw’\ Pn.úË¥SÔ'’Cå~]£Rnôû³H…ÜkÕ‰I_Å'7¶Îr$Y¶|_SyÕ¸™Å²z<–Áã1~b4X!ee=F‹¥÷>1zrY,‰ç›ÈÕ%¾*¯ËŠ¾-—'·Vâj¨E·ÖZMl•Ü®hZÒµ¸ÜJ×J,‘î­1ÕWF.ËÕò]—VÞMCƒëšù½ã˜ßyîso3žcý‹‘õA®õÏFÏO>Éýó'?‚þ‹å1þ×OrQß®q«Õ:N ßjõ¸ ÃcwA ýלãµÌqȃÎPÎ8¸ÆÉ\\j/Š%Ö±.—D¡;ϸуZCÅFqƒ‡ô NTKÒ.¦¥]q#êÅåñw‰-¨!Åš„Ô* ò(IbI®'´+—´@†ËëuMjÑ=]’q 9©m°h=Òë‹È.íd­·*f2º,0) DTÛX«%5.‹hRÓ¥%~¨i!a È.‘Dìuu‰¼X£†´ÖNŠ ~ "qcm­V’K7ËE`(öÖŠÇ­‰¶ÖJj/Š@í.j-RL8žZ‘ÖuQ$–€“¢.V¬‹€¹F]Kš=P´,œ=âP7tºV,éÒŠ¬µ" ÈGZºHO‹FÛ£Ô¸´Ð¹+Bã"%­v²’Ìk%–I‘·ñ*˜5YÏ;?yç° PrÃ;ÿÂò¤ÿä'VY;©%-ã†WÔàg4¸Äb‘¶VKQ­—Ö¯s­˜¬•˜%󵵚J±È2o©Ôfv1ÄÌÚ\¨áahü Ťwžá·*ÈÌ‹Ìyr^+fjÌÐÞÃœg0'šùÚI¯Øe5kÄ"/¬‡ˆdvÕŠ™ ¢¡ZR«µš»†º*µe¡€á¯õ2Åó ã’yÒl‘‰Ì¤Ë%.›åk 0«$3¢ùJRae2⮲I&•Y–ƒ³Ç⧺q!‚1”YfR+c"LÍÐ<©e2E ·x’©íråfŠÆjµµ"35®¡\IZÌñ¼ˆÙÉÐ.‚ˆ†™õ‘Òf#³ÕsN[î9ÏOX.q­D;6鱊¼fy‘ár5ˆIKíxr¨ÖBºè¥æg6bÞF†U¤ðt‘ã ¾ŒF¯Ê¨y`40ŵ#$¾"-¢†F­ÅÊðø™°¸´b˜‘ÇÌh„%âi4 V°#óâZÐc‘µAÛUÛ(ÒÀ¿¯´b0=ÚZËáÚÊ\—§ÁìÕzDš‘ ˜4º$Œ¯ éE ã°È"’XD‡¡3WôÚˆz…¦Ë9INvM2 ­„qXÛEZà Æ“©!DšFRT;9>ÏtI2µãV—ÈzQÛå‹Ç¡¼´½Òâq3½â\¦Ëk4ÎI4Èh€ææþs!˜=°U¦çj<Ÿh\b²±Ö¯±jµ"ƒ xuez'IX«è3I//‰&˜Ñ0–ÛÀ€o«ÕÂИ˜bÉB™¸µˆ`1ZÌJ64ŠºrV‹Y‹²ÂЬ™Ì‹)®ÁDy¬f±`&/r’Ù0&ó¤Ë3ßu¸ÁB2]ó4^dh,f†K2iÖø¡ÀDÃÜK¤KTëe\4Ãæà_Ìæ܆†„bhh»Ìäš®F‘ö°ÄÒ`ÖZ»Êº\®!$ŒËÃtib—Æ[&aºjÖI†' óáþüΟY’XÉmïüù¤À{<Ÿ| ñÿœnµþäX¾gòâ¸G#ÑtY ÿq‹Xì™´¸ºº@­é…èiPšÜ1‘Ì‚ÅÃô‹´ /“¨ˆ˜€³ç¢Â+V˜sÅ~…×E* 2­K#‚õÕ™L¿Õ3.Vˆ´f¦%V«VQ«•I\’1†H£U05cÚZ…Å<¤ðjeE­8s ÀRˆ,ZÅP®g0w¦¢kLD90rš1Ò¥ƒÎj™¤X¡u5€8]c¤D<¯•x\ †¢aF#°ˆ‡`¹1Å1¨CDÊ,Ñ-ð0òù¬ÖÜ\è@‚¾ …n"¹ºw—'t·ÒÛ7ÚjÇCž" ]1—j7¹¦%<4[Ø<%Ðî!“ªà¡]TtO¹ªVú«–ª€ôŠvH= .+äæZ˜¡u­A cÕˆjfÕÀæL±Ž¸¾ˆ=%ˆã‘,cjtC*­aÒƒÁ]šLK­"¥5À ¤¢Æl ¢B¹Wä¶j¨6Pó_>ûkˆ>ûŒºù ]ÿúûlyô×qªz¸õgMNt}D±£‹©ÌPi8­êþ¯!ŸÇäö‘0K‚¸Ähøè³pÍ8¶Ï¿†YGD_Òë²òÙGTíÄ?ŠÀ¢]¨‰õY¨¯ñ† îG!©Ç¹Yü†˜ñýõ³ÜÂ0;§moŸµÙlgÏÂåŸÎ¢Ä?Ù(: 7o‡ÒË¢©é©ÔŽ¥é˜ï)êò­Y­! BýG’Óß’W泟?úô)ŸíÔ©GOýÇÛ;_›þCå寰Ùþã¿?ûóGŸ÷-ŸeSéH·’ef˜@—º©THËF¨¬m3ÑòT[gÇ·büí(! ðÝÖ‰’M¥„í¾ H$ßG|+^‘ozöÔÓpyù °Ì¿Ûùö£Oî|›ªÝQú0è‚y¤4pž™î¨ëLé¹o$™^Ïé3懓:&¦²¶d$tŽtf€ògÍ$'÷ oéiÚ’53Q—Q˜Ô15eK¥Ú†gR;R÷nN&¦f†SG ¼n¦ŽHH¶ýr&kËHápa!@¼%k*#uªn:µ£s_á Ó欇‡ï+-œIjªëDrgLu$%v$6uʶ Ï|3ƒŠÀüüËÓÓ£ñ2Å“¶—ÿø¥ÍÐÛ£åÓï¿A×îé :’lÓ Ãò¦á™Û€œP:œ”4\šPŠ*4¥vv¤&ötÖM ¥©Óu1=b+L¾¯1’:2EØ’ ‘+•MÕÍt=û`r€8L4Íc¢´ÇV—áÂŽ©ÔáÂabd¦˜ÌD¾ÔU†óz4Ub$wötôtt&ƒÜuDRRB' ixËÄpÒÊöæˆm~ÿ¿¼ñüYÛÿøþ“ÎzÙöôçÓåOžÒ½}ê÷ßþüéPíÂÂÔ¬º[BaÏprÇTìÃSÃI[JK·$ SJÖ±­ib8£©®G–T×±ígÉ…ÛReÉ u²žº&¢p[Ó6ÛHÖ?—N Cå¤á¦™Òm#=uu=ûþ¹´.«pÛ/'R·v$lé”uNdÀ4tÈ’§dpk+MÎ.…« çõhz"y_gViéDÒpBÆð¶é¬ä}…#uYÉ=Û¶”fýóÊxEº—xÛöOï€ËÛþÓfóÙ|¼l;ð¾ííËç—”šœ”œ`ëINMN½.LššINš¶%÷Ø’l…¥ 3¶éääÔ䋤&§R R“¹žd¨Ûå3I©¶} DgÒÌTr§ V ì™ÉS3I°å'Ëä…2©s: Éšš”ßòòçOOoyãó7l|òÔw¹teÞÏ4PBg(Þ"–Xã鬩äˆôÉ©Q7:9Ô Ñ™pu¬VjKH—¡nùb¤fÁWÕy)ħ3Èàõ~·(ðÿ½ö¶mú€oúÀ³ÿa³=ýä£àÔÙPx²»?>ýŸ´G×sŸ :´oÍ Ð|žÂ-I[’K·$ОÆTGÇTOiFgOFhr …3û2Rm[ÀöufŒÚêš:’“§› ë’ê’3l3uu¶„¦ûfš’F€ã–¤Ž™O€sÓti²-a¤gb¢³0™Â™Œ¦i[G]VB‡­'A=3’ÑÑQ¸¥.#)©c"§ižl¿L*íNªKÊ@ÞÌTSSì«u÷ ÃŽaÜÈò­ÒtSÇ0ÑQ8•ÑaX] n§ë@j39£îÛFÓ¶÷ßxúÀçO~áÉÛŸÿŽ†ùìS§¶¼êù—©Úy ð¤)¡®â5øÇÃà7''ƒßL©XÝHÆp¡,)i[’l¦©<Œ©‰ám¿“;3’0.ROgÒx #DSaVGݾ$ÙTFiÒt]ÂDgÆpLKÏÄðDjàÝTØ4S8Ü9]$MmKÚ½Ž ”vÊR›:3¦dIààÙ2:J““’ PJÝ÷ϲԑà5µ-¡'©4y"iüÁ¦;RÐØ2 H§ÿáŽ8ÝÓ¨×Òžra< üøÐMuuu3²®ûv~óÿû7›Mwê êL`¶½ñèÓT;àç¾'mïÓg=k6U—<ÑÔá0QXØÑ™4ÒSŽë’{¦ K‰TPƒÎÔ}°žg² ï³Q.©# Å q„"Sm ÏVv‚Êg@X3Å0Óhttv@X¸%#L×ȯ«³ÍtÜ—D@”¡Bé}0àê&$LÓ )^¥²- %MDÌüðÌôp'ê¦nº¼ÄÒ¬ù©&"¡§´pº´®†„ú,LH*,M{-ëü–Q óŸo9û¹oúhã;uöìOÙl￶åìïÞ~úì©OÓg=èLcÊÖ‘<[àÌJÎC¦2¦`Á^@H;œ*›™ÊJsbÃ+Ü £žÆ£DûÜO=zêwå§ÞŸö==ýò©SÎ~þäYØO¥jOO¡£6t¢œ:“ 73…(#5RT…Ô¬_–ÖeLÙJ':lÃT¼– Æe¦©Ó¶¥n‰_ö<œÑ4üpòHÇHVRiVaVò0ºïÈJN΂%ÝÔT÷30ËSY3¥#=YÉÈL÷LÔmæYS¶º‰äº¬Î*ŒìÜ6’œq8·t8«0Ö5¥N£À4#ŒZO♬á:ÛpÝpSVag‘º"o·i¤Žc8¡'#+ bÓÔHFViRVj)(Ö·„yEÍn""J'¦²’¯o À*¯6uîKíX×ÌoÙòðÃÃß*(šZ>-ir [b;ˆÍ¤ïVÜç–‡E¢Âku*æ2SW>ŒçëÔŠþùg×Úõ„afÿöî»­½Ö»k½ôÿ€œß.óéd”,‹hjèG£±2-K(éiÐDo6H觛š˜ºËymE¿®¢g9o \“4×-q_³GËõžæF¹^ù·{þo.Íóÿàyþoÿø¼Æe}^ó·¿ýëó¿]Ì=Ŧޞ‹Ìã çŽCy—YÜH½æF¿J–+¢^nëÊE•è|«ÙkFoÃAß?‰^CCoÚ5hEµ]µèe;Qý’ª>‰˜‡^„Cï£Qo«YCïÞ[k™s±bòä2 OOx”Ô›Ž®Ðûr®˜4ýGe¡x¢­®†ùðïßû¼Õõš¿þëo?ú·øëïÿ¯ÆêÒüf±žxº4.KÃx®Æ¥‘À„¢7=‰ r»\ p7“‰X"é²B^äÅ"öHÄϘVM»¬‹µËZÛ¥íru¡·- ‹g²Á㱈º,]ääE—eRãÍõˆÑ `£ðæZ»ºº4V±&Wc™ô\DÀSEš.Ë8béï gËÒ`Ñxè4¤( àã‘Lv5H sHÃð\'Ñ˪“]bm#Œ8ÒêZ0ÿÃ¿Þ 0ÿí·ýÍßþöïÖß?ÿ›‡\žßܽeIv‰DI™F;)®…Ä.«br’Ԋч´¸$ ‘E$bt)rE¤DaMÎ{æE"‹L¤q‰þ¡®1ÏõšVí˜Hìòø™ "¦¨a²ŒdÔŠ,Z‘×"š›%ZÑ eLDZ¤d|žÑPÖ¥1»D™óâL…hÜ£aˆ&³63Ó«1j¿µQø˜Å~q#Sƒ^¡kW22-! ô¨—é8A®W_À ³ßÃÉ`µˆP¶'â_|ßeà4 ŵ’ø9¥0pâ‹ Q"ÌÂrC‘X’ŠÐ÷8Þ:­ŸP%8‹€{>—ZÛD_["m½×¨•¨k›X™>÷07`4º7d™M¤=%ZÕ Q˜Ù‘ð\ü iBl:èÁ)Z€a‰8¿®ÑIìfTå?°N$H°sƒ|̧gg³»³l°UíW_²ê]ÿ—‹þ?6`N#‘Q"\Ø»é ˜vÜÌÇ' Hì‰:x.˜Ó:–ú¤®TÆ8ãy¦„Ì ¤±Q&° ãŠü¹4ò‚´«¨Ö‚äÄ¢hÝ3qšRF„Ö¾fFyAÆ ¦¸NŠ\0ÿ%æ¡”a¦uMh¦~nD—³l»Fë8˜ŠeÀãÄPì‚Ó\r¸¦Äg88˜BâTq–ÔiÍDÜ°EµTªÓ:U~‚))#5OzQø Åé§Áü?ÄãB?SqIEND®B`‚code-0e2a0c2c8142/doc/implementation.txt0000644000000000000000000000362610062724152016173 0ustar 00000000000000==================== Implementation notes ==================== :Version: $Revision: 1.6 $ [see also the roundup package docstring] There have been some modifications to the spec. I've marked these in the source with 'XXX' comments when I remember to. In short: Class.find() - may match multiple properties, uses keyword args. Class.filter() - isn't in the spec and it's very useful to have at the Class level. CGI interface index view specifier layout part - lose the '+' from the sorting arguments (it's a reserved URL character ;). Just made no prefix mean ascending and '-' prefix descending. ItemClass - renamed to IssueClass to better match it only having one hypderdb class "issue". Allowing > 1 hyperdb class breaks the "superseder" multilink (since it can only link to one thing, and we'd want bugs to link to support and vice-versa). template - the call="link()" is handled by special-case mechanisms in my top-level CGI handler. In a nutshell, the handler looks for a method on itself called 'index%s' or 'item%s' where %s is a class. Most items pass on to the templating mechanism, but the file class _always_ does downloading. It'll probably stay this way too... template - call="link(property)" may be used to link "the current item" (from an index) - the link text is the property specified. template - added functions that I found very useful: List, History and Submit. template - items must specify the message lists, history, etc. Having them by default was sometimes not wanted. template - index view determines its default columns from the template's ``tal:condition="request/show/"`` directives. template - menu() and field() look awfully similar now .... ;) roundup_admin.py - the command-line tool has a lot more commands at its disposal ----------------- Back to `Table of Contents`_ .. _`Table of Contents`: index.html code-0e2a0c2c8142/doc/index.txt0000644000000000000000000000515410062724152014253 0ustar 00000000000000======================================================= Roundup: an Issue-Tracking System for Knowledge Workers ======================================================= Contents ======== - Features__ - Installation__ and Upgrading__ existing installs - `Frequently Asked Questions`__ - `User Guide`__ - `Configuring and Customising Roundup`__ - `Administering Roundup Trackers`__ - `Roundup's Design`__ (original__) - `Developing Roundup`__ - `Roundup Tracker Templates`__ - Contact_ - Acknowledgements_ - License_ __ features.html __ installation.html __ upgrading.html __ FAQ.html __ user_guide.html __ customizing.html __ admin_guide.html __ design.html __ spec.html __ developers.html __ tracker_templates.html Contact ======= For general support enquiries about usage, a mailing list is available: roundup-users@sourceforge.net If you've got a great idea for roundup, or have found a bug, please submit an issue to the tracker at: http://sourceforge.net/tracker/?group_id=31577 For discussions about developing or enhancing roundup: roundup-devel@sourceforge.net The admin for this project is Richard Jones: richard@users.sourceforge.net but he should only be contacted directly when none of the above avenues of contact are suitable. Acknowledgements ================ Go Ping, you rock! Also, go Bizar Software and ekit.com for letting me implement this system on their time. Thanks also to the many people on the mailing list, in the sourceforge project and those who just report bugs: Thomas Arendsen Hein, Anthony Baxter, Marlon van den Berg, Bo Berglund, Cameron Blackwood, Jeff Blaine, Duncan Booth, Seb Brezel, Titus Brown, Godefroid Chapelle, Roch'e Compaan, Joe Cooper, Kelley Dagley, Paul F. Dubois, Jeff Epler, Tom Epperly, Tamer Fahmy, Hernan Martinez Foffani, Stuart D. Gathman, Ajit George, Frank Gibbons, Johannes Gijsbers, Gus Gollings, Dan Grassi, Engelbert Gruber, Juergen Hermann, Tobias Hunger, Simon Hyde, Christophe Kalt, Brian Kelley, James Kew, Sheila King, Bastian Kleineidam, Axel Kollmorgen, Detlef Lannert, Andrey Lebedev, Henrik Levkowetz, David Linke, Fredrik Lundh, Georges Martin, Gordon McMillan, John F Meinel Jr, Truls E. Næss, Patrick Ohly, Luke Opperman, Eddie Parker, Will Partain, Ewout Prangsma, Bernhard Reiter, Roy Rapoport, John P. Rouillard, Ollie Rutherfurd, Toby Sargeant, Florian Schulze, Klamer Schutte, Dougal Scott, Stefan Seefeld, Jeffrey P Shell, Joel Shprentz, Terrel Shumway, Emil Sit, Alexander Smishlajev, Nathaniel Smith, Mitchell Surface, Mike Thompson, Darryl VanDorp, J Vickroy. License ======= See COPYING.txt in the software distribution for the licensing terms. code-0e2a0c2c8142/doc/installation.txt0000644000000000000000000005642610062724152015655 0ustar 00000000000000================== Installing Roundup ================== :Version: 1.76 .. contents:: :depth: 2 Overview ======== Broken out separately, there are several conceptual pieces to a Roundup installation: Roundup trackers Trackers consist of issues (be they bug reports or otherwise), tracker configuration file(s), web HTML files etc. Roundup trackers are initialised with a "Template" which defines the fields usable/assignable on a per-issue basis. Descriptions of the provided templates are given in `choosing your template`_. Roundup support code Installed into your Python install's lib directory Roundup scripts These include the email gateway, the roundup HTTP server, the roundup administration command-line interface, etc. Prerequisites ============= Roundup requires Python 2.1.3 or newer with a functioning anydbm or bsddb module. Download the latest version from http://www.python.org/. It is highly recommended that users install the latest patch version of python as these contain many fixes to serious bugs. If you want to use Berkeley DB bsddb3 with Roundup, use version 3.3.0 or later. Download the latest version from http://pybsddb.sourceforge.net/. If you're on windows, you will either need to be using the ActiveState python distribution (at http://www.activestate.com/Products/ActivePython/), or you'll have to install the win32all package separately (get it from http://starship.python.net/crew/mhammond/win32/). Non-Python2.3 users may need to `install the "CSV" module`_. Install the "CSV" module ------------------------ .. hint:: CSV stands for Comma-Separated-Value. These files are used by all manner of programs (eg. spreadsheets) to exchange data. The "CSV" module is required if you wish to import or export data in the tracker, or if you wish to use the online generic class editing facility. If you're using a version of Python older than 2.3, then you will need to install the "CSV" module from `Object Craft`_. Users of Python2.3 and later don't need to. If you have a C compiler installed, then download the source and follow their installation instructions (simply ``python setup.py install``.) If you're on Windows and don't have a C compiler, then you'll need to download the pre-compiled ``csv.pyd`` file and install it. To install, just copy it to your Python installation in the ``lib\site-packages`` directory. For Python 2.2, this would be:: c:\python22\lib\site-packages Once the CSV module is installed, you *must* restart roundup-server if it is already running, or the new module won't be detected. If you're on some other platform and don't have a C compiler, you'll need to ask for help on the roundup-users mailing list. .. _`Object Craft`: http://object-craft.com.au/ Getting Roundup =============== Download the latest version from http://roundup.sf.net/. If you're using WinZIP's "classic" interface, make sure the "Use folder names" check box is checked before you extract the files. Testing your Python ------------------- .. note:: The Windows installer doesn't include the ``run_tests.py`` or ``demo.py`` scripts - you will need to download the source to use them. Once you've unpacked roundup's source, run ``python run_tests.py`` in the source directory and make sure there are no errors. If there are errors, please let us know! If the above fails, you may be using the wrong version of python. Try ``python2 run_tests.py``. If that works, you will need to substitute ``python2`` for ``python`` in all further commands you use in relation to Roundup -- from installation and scripts. For The Really Impatient ======================== Note: user of the Windows installer may not use the ``demo.py`` script. If you just want to give Roundup a whirl Right Now, then simply run ``python demo.py``. This will set up a simple demo tracker on your machine. When it's done, it'll print out a URL to point your web browser at so you may start playing. Three users will be set up: 1. anonymous - the "default" user with permission to do very little 2. demo (password "demo") - a normal user who may create issues 3. admin (password "admin") - an administrative user who has complete access to the tracker Installation ============ .. note:: Some systems, such as Debian and NetBSD, already have Roundup installed. Try running the command "roundup-admin" with no arguments, and if it runs you may skip the `Basic Installation Steps`_ below and go straight to `configuring your first tracker`_. Set aside 15-30 minutes. Please make sure you're using a supported version of Python -- see `testing your python`_. There's several steps to follow in your installation: 1. `basic installation steps`_ if Roundup is not installed on your system 2. `configuring your first tracker`_ that all installers must follow 3. then optionally `configure a web interface`_ 4. and optionally `configure an email interface`_ 5. `UNIX environment steps`_ to take if you're installing on a shared UNIX machine and want to restrict local access to roundup 6. `additional language codecs`_ For information about how Roundup installs, see the `administration guide`_. Basic Installation Steps ------------------------ To install the Roundup support code into your Python tree and Roundup scripts into /usr/local/bin (substitute that path for whatever is appropriate on your system). You need to have write permissions for these locations, eg. being root on unix:: python setup.py install If you would like to place the Roundup scripts in a directory other than ``/usr/local/bin``, then specify the preferred location with ``--install-script``. For example, to install them in ``/opt/roundup/bin``:: python setup.py install --install-scripts=/opt/roundup/bin You can also use the ``--prefix`` option to use a completely different base directory, if you do not want to use administrator rights. If you choose to do this, you may have to change Python's search path (sys.path) yourself. Configuring your first tracker ------------------------------ 1. To create a Roundup tracker (necessary to do before you can use the software in any real fashion), you need to set up a "tracker home": a. (Optional) If you intend to keep your roundup trackers under one top level directory which does not exist yet, you should create that directory now. Example:: mkdir /opt/roundup/trackers b. Either add the Roundup script location to your ``PATH`` environment variable or specify the full path to the command in the next step. c. Install a new tracker with the command ``roundup-admin install``. You will be asked a series of questions. Descriptions of the provided templates can be found in `choosing your template`_ below. Descriptions of the available backends can be found in `choosing your backend`_ below. The questions will be something like (you may have more templates or backends available):: Enter tracker home: /opt/roundup/trackers/support Templates: classic Select template [classic]: classic Back ends: anydbm, bsddb Select backend [anydbm]: anydbm The "support" part of the tracker name can be anything you want - it is going to be used as the directory that the tracker information will be stored in. You will now be directed to edit the tracker configuration and initial schema. At a minimum, you must set ``MAILHOST``, ``TRACKER_WEB``, ``MAIL_DOMAIN`` and ``ADMIN_EMAIL``. The configuration file uses Python syntax, so almost every value must be ``'quoted'`` using single or double quotes. If you get stuck, and get configuration file errors, then see the `tracker configuration`_ section of the `customisation documentation`_. If you just want to get set up to test things quickly (and follow the instructions in step 3 below), you can even just set the TRACKER_WEB variable to:: TRACKER_WEB = 'http://localhost:8080/support/' The URL *must* end in a '/', or your web interface *will not work*. See `Customising Roundup`_ for details on configuration and schema changes. You may change any of the configuration after you've initialised the tracker - it's just better to have valid values for this stuff now. d. Initialise the tracker database with ``roundup-admin initialise``. You will need to supply an admin password at this step. You will be prompted:: Admin Password: Confirm: Note: running this command will *destroy any existing data in the database*. In the case of MySQL and PostgreSQL, any exsting database will be dropped and re-created. Once this is done, the tracker has been created. 2. At this point, your tracker is set up, but doesn't have a nice user interface. To set that up, we need to `configure a web interface`_ and optionally `configure an email interface`_. If you want to try your new tracker out, assuming ``TRACKER_WEB`` is set to ``'http://localhost:8080/support/'``, run:: roundup-server support=/opt/roundup/trackers/support then direct your web browser at: http://localhost:8080/support/ and you should see the tracker interface. Choosing Your Template ---------------------- Classic Template ~~~~~~~~~~~~~~~~ The classic template is the one defined in the `Roundup Specification`_. It holds issues which have priorities and statuses. Each issue may also have a set of messages which are disseminated to the issue's list of nosy users. Minimal Template ~~~~~~~~~~~~~~~~ The minimal template has the minimum setup required for a tracker installation. That is, it has the configuration files, defines a user database and the basic HTML interface to that. It's a completely clean slate for you to create your tracker on. Choosing Your Backend --------------------- The actual storage of Roundup tracker information is handled by backends. There's several to choose from, each with benefits and limitations: ========== =========== ===== ============================== Name Speed Users Support ========== =========== ===== ============================== anydbm Slowest Few Always available bsddb Slow Few Usually available bsddb3 Slow Few Needs install (pybsddb_) sqlite Fastest(*) Few Needs install (PySQLite_) metakit Fastest(*) Few Needs install (metakit_) postgresql Fast Many Needs install/admin (psycopg_) mysql Fast Many Needs install/admin (MySQLdb_) ========== =========== ===== ============================== **sqlite** and **metakit** These use the embedded database engines PySQLite_ and metakit_ to provide very fast backends. They are not suitable for trackers which will have many simultaneous users. **postgresql** Backend for popular RDBMS PostgreSQL. You must read doc/postgresql.txt for additional installation steps and requirements. **mysql** Backend for popular RDBMS MySQL. You must read doc/mysql.txt for additional installation steps and requirements. You may defer your decision by setting your tracker up with the anydbm backend (which is guaranteed to be available) and switching to one of the other backends at any time using the instructions in the `administration guide`_. Regardless of which backend you choose, Roundup will attempt to initialise a new database for you when you run the roundup-admin "initialise" command. In the case of MySQL and PostgreSQL you will need to have the appropriate privileges to create databases. Configure a Web Interface ------------------------- There are three web interfaces to choose from: 1. `web server cgi-bin`_ 2. `stand-alone web server`_ 3. `Zope product - ZRoundup`_ You may need to give the web server user permission to access the tracker home - see the `UNIX environment steps`_ for information. You may also need to configure your system in some way - see `platform-specific notes`_. Web Server cgi-bin ~~~~~~~~~~~~~~~~~~ A benefit of using the cgi-bin approach is that it's the easiest way to restrict access to your tracker to only use HTTPS. Access will be slower than through the `stand-alone web server`_ though. If your Python isn't install as "python" then you'll need to edit the ``roundup.cgi`` script to fix the first line. If you're using IIS on a Windows platform, you'll need to run this command for the cgi to work (it turns on the PATH_INFO cgi variable):: adsutil.vbs set w3svc/AllowPathInfoForScriptMappings TRUE The ``adsutil.vbs`` file can be found in either ``c:\inetpub\adminscripts`` or ``c:\winnt\system32\inetsrv\adminsamples\`` or ``c:\winnt\system32\inetsrv\adminscripts\`` depending on your installation. Copy the ``cgi-bin/roundup.cgi`` file to your web server's ``cgi-bin`` directory. You will need to configure it to tell it where your tracker home is. You can do this either: through an environment variable set the variable TRACKER_HOMES to be a colon (":") separated list of name=home pairs (if you're using apache, the SetEnv directive can do this) directly in the ``roundup.cgi`` file itself add your instance to the TRACKER_HOMES variable as ``'name': 'home'`` The "name" part of the configuration will appear in the URL and identifies the tracker (so you may have more than one tracker per cgi-bin script). Make sure there are no spaces or other illegal characters in it (to be safe, stick to letters and numbers). The "name" forms part of the URL that appears in the tracker config TRACKER_WEB variable, so make sure they match. The "home" part of the configuration is the tracker home directory. Stand-alone Web Server ~~~~~~~~~~~~~~~~~~~~~~ This approach will give you the fastest of the three web interfaces. You may investigate using ProxyPass or similar configuration in apache to have your tracker accessed through the same URL as other systems. The stand-alone web server is started with the command ``roundup-server``. It has several options - display them with ``roundup-server -h``. The tracker home configuration is similar to the cgi-bin - you may either edit the script to change the TRACKER_HOMES variable or you may supply the name=home values on the command-line after all the other options. To make the server run in the background, use the "-d" option, specifying the name of a file to write the server process id (pid) to. Zope Product - ZRoundup ~~~~~~~~~~~~~~~~~~~~~~~ ZRoundup installs as a regular Zope product. Copy the ZRoundup directory to your Products directory either in INSTANCE_HOME/Products or the Zope code tree lib/python/Products. When you next (re)start up Zope, you will be able to add a ZRoundup object that interfaces to your new tracker. Configure an Email Interface ---------------------------- If you don't want to use the email component of Roundup, then remove the "``nosyreaction.py``" module from your tracker "``detectors``" directory. See `platform-specific notes`_ for steps that may be needed on your system. There are three supported ways to get emailed issues into the Roundup tracker. You should pick ONE of the following, all of which will continue my example setup from above: As a mail alias pipe process ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Set up a mail alias called "issue_tracker" as (include the quote marks): "``|/usr/bin/python /usr/local/bin/roundup-mailgw ``" In some installations (e.g. RedHat 6.2 I think) you'll need to set up smrsh so sendmail will accept the pipe command. In that case, symlink ``/etc/smrsh/roundup-mailgw`` to "``/usr/local/bin/roundup-mailgw``" and change the command to:: |roundup-mailgw /opt/roundup/trackers/support To test the mail gateway on unix systems, try:: echo test |mail -s '[issue] test' support@YOUR_DOMAIN_HERE As a regular job using a mailbox source ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Set ``roundup-mailgw`` up to run every 10 minutes or so. For example:: 0,10,20,30,40,50 * * * * /usr/local/bin/roundup-mailgw /opt/roundup/trackers/support mailbox Where the ``mail_spool_file`` argument is the location of the roundup submission user's mail spool. On most systems, the spool for a user "issue_tracker" will be "``/var/mail/issue_tracker``". As a regular job using a POP source ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To retrieve from a POP mailbox, use a *cron* entry similar to the mailbox one:: 0,10,20,30,40,50 * * * * /usr/local/bin/roundup-mailgw /opt/roundup/trackers/support pop where pop_spec is "``username:password@server``" that specifies the roundup submission user's POP account name, password and server. On windows, you would set up the command using the windows scheduler. As a regular job using an IMAP source ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To retrieve from an IMAP mailbox, use a *cron* entry similar to the POP one:: 0,10,20,30,40,50 * * * * /usr/local/bin/roundup-mailgw /opt/roundup/trackers/support imap where imap_spec is "``username:password@server``" that specifies the roundup submission user's IMAP account name, password and server. You may optionally include a mailbox to use other than the default ``INBOX`` with "``imap username:password@server mailbox``". If you have a secure (ie. HTTPS) IMAP server then you may use ``imaps`` in place of ``imap`` in the command to use a secure connection. As with the POP job, on windows, you would set up the command using the windows scheduler. UNIX Environment Steps ---------------------- Each tracker ideally should have its own UNIX group, so create a UNIX group (edit ``/etc/group`` or your appropriate NIS map if you're using NIS). To continue with my examples so far, I would create the UNIX group 'support', although the name of the UNIX group does not have to be the same as the tracker name. To this 'support' group I then add all of the UNIX usernames who will be working with this Roundup tracker. In addition to 'real' users, the Roundup email gateway will need to have permissions to this area as well, so add the user your mail service runs as to the group (typically "mail" or "daemon"). The UNIX group might then look like:: support:*:1002:jblaine,samh,geezer,mail If you intend to use the web interface (as most people do), you should also add the username your web server runs as to the group. My group now looks like this:: support:*:1002:jblaine,samh,geezer,mail,apache The tracker "db" directory should be chmod'ed g+sw so that the group can write to the database, and any new files created in the database will be owned by the group. An alternative to the above is to create a new user who has the sole responsibility of running roundup. This user: 1. runs the CGI interface daemon 2. runs regular polls for email 3. runs regular checks (using cron) to ensure the daemon is up 4. optionally has no login password so that nobody but the "root" user may actually login and play with the roundup setup. Additional Language Codecs -------------------------- If you intend to send messages to Roundup that use Chinese, Japanese or Korean encodings the you'll need to obtain CJKCodecs from http://cjkpython.berlios.de/ Maintenance =========== Read the separate `administration guide`_ for information about how to perform common maintenance tasks with Roundup. Upgrading ========= Read the separate `upgrading document`_, which describes the steps needed to upgrade existing tracker trackers for each version of Roundup that is released. Further Reading =============== If you intend to use Roundup with anything other than the defualt templates, if you would like to hack on Roundup, or if you would like implementation details, you should read `Customising Roundup`_. Running Multiple Trackers ========================= Things to think about before you jump off the deep end and install multiple trackers, which involve additional URLs, user databases, email addresses, databases to back up, etc. 1. Do you want a tracker per product you sell/support? You can just add a new property to your issues called Product, and filter by that. See the customisation example `adding a new field to the classic schema`_. 2. Do you want to track internal software development issues and customer support issues separately? You can just set up an additional "issue" class called "cust_issues" in the same tracker, mimicing the normal "issue" class, but with different properties. See the customisation example `tracking different types of issues`_. Platform-Specific Notes ======================= Windows command-line tools -------------------------- To make the command-line tools accessible in Windows, you need to update the "Path" environment variable in the Registry via a dialog box. On Windows 2000 and later: 1) Press the "Start" button. 2) Choose "Settings" 3) Choose "Control Panel" 4) Choose "System" 5) Choose "Advanced" 6) Choose "Environmental Variables" 7) Add: "\Scripts" to the "Path" environmental variable. Where in 7) is the root directory (e.g., ``C:\Python22\Scripts``) of your Python installation. I understand that in XP, 2) above is not needed as "Control Panel" is directly accessible from "Start". I do not believe this is possible to do in previous versions of Windows. Windows Server -------------- To have the Roundup web server start up when your machine boots up, set the following up in Scheduled Tasks (note, the following is for a cygwin setup): Run ``c:\cygwin\bin\bash.exe -c "roundup-server TheProject=/opt/roundup/trackers/support"`` Start In ``C:\cygwin\opt\roundup\bin`` Schedule At System Startup To have the Roundup mail gateway run periodically to poll a POP email address, set the following up in Scheduled Tasks: Run ``c:\cygwin\bin\bash.exe -c "roundup-mailgw /opt/roundup/trackers/support pop roundup:roundup@mail-server"`` Start In ``C:\cygwin\opt\roundup\bin`` Schedule Every 10 minutes from 5:00AM for 24 hours every day Stop the task if it runs for 8 minutes Sendmail smrsh -------------- If you use Sendmail's ``smrsh`` mechanism, you will need to tell smrsh that roundup-mailgw is a valid/trusted mail handler before it will work. This is usually done via the following 2 steps: 1. make a symlink in ``/etc/smrsh`` called ``roundup-mailgw`` which points to the full path of your actual ``roundup-mailgw`` script. 2. change your alias to ``"|roundup-mailgw "`` Linux ----- Make sure you read the instructions under `UNIX environment steps`_. Python 2.1.1 as shipped with SuSE7.3 might be missing module ``_weakref``. Solaris ------- You'll need to build Python. Make sure you read the instructions under `UNIX environment steps`_. ------------------------------------------------------------------------------- Back to `Table of Contents`_ Next: `User Guide`_ .. _`table of contents`: index.html .. _`user guide`: user_guide.html .. _`roundup specification`: spec.html .. _`tracker configuration`: customizing.html#tracker-configuration .. _`customisation documentation`: customizing.html .. _`Adding a new field to the classic schema`: customizing.html#adding-a-new-field-to-the-classic-schema .. _`Tracking different types of issues`: customizing.html#tracking-different-types-of-issues .. _`customising roundup`: customizing.html .. _`upgrading document`: upgrading.html .. _`administration guide`: admin_guide.html .. _pybsddb: http://pybsddb.sourceforge.net/ .. _pysqlite: http://pysqlite.sourceforge.net/ .. _metakit: http://www.equi4.com/metakit/ .. _Psycopg: http://initd.org/software/initd/psycopg .. _MySQLdb: http://sourceforge.net/projects/mysql-python code-0e2a0c2c8142/doc/mysql.txt0000644000000000000000000000505510062724152014311 0ustar 00000000000000============= MySQL Backend ============= :version: $Revision: 1.9 $ This notes detail the MySQL backend for the Roundup issue tracker. Prerequisites ============= To use MySQL as the backend for storing roundup data, you also need to install: 1. MySQL RDBMS 4.0.16 or higher - http://www.mysql.com. Your MySQL installation MUST support InnoDB tables (or Berkeley DB (BDB) tables if you have no other choice). If you're running < 4.0.16 (but not <4.0) then you'll need to use BDB to pass all unit tests. Edit the ``roundup/backends/back_mysql.py`` file to enable DBD instead of InnoDB. 2. Python MySQL interface - http://sourceforge.net/projects/mysql-python .. note:: The InnoDB implementation has a bug__ that Roundup tickles. See __ http://bugs.mysql.com/bug.php?id=1810 Running the MySQL tests ======================= Roundup tests expect an empty MySQL database. Two alternate ways to provide this: 1. If you have root permissions on the MySQL server, you can create the necessary database entries using the follwing SQL sequence. Use ``mysql`` on the command line to enter:: CREATE DATABASE rounduptest; USE rounduptest; GRANT ALL PRIVILEGES ON rounduptest.* TO rounduptest@localhost IDENTIFIED BY 'rounduptest'; FLUSH PRIVILEGES; 2. If your administrator has provided you with database connection info, you can modify MYSQL_* constants in the file test/test_db.py with the correct values. The MySQL database should not contain any tables. Tests will not drop the database with existing data. Additional configuration ======================== To initialise and use the MySQL database backend, roundup's configuration file (config.py in the tracker's home directory) should have the following entries:: MYSQL_DBHOST = 'localhost' MYSQL_DBUSER = 'rounduptest' MYSQL_DBPASSWORD = 'rounduptest' MYSQL_DBNAME = 'rounduptest' MYSQL_DATABASE = ( MYSQL_DBHOST, MYSQL_DBUSER, MYSQL_DBPASSWORD, MYSQL_DBNAME ) Fill in the first four entries with values for your local MySQL installation before running "roundup-admin initialise". Use the commands in the `Running the MySQL tests` to set up a database if you have privilege, or ask your local administrator if not. Showing MySQL who's boss ======================== If things ever get to the point where that test database is totally hosed, just:: $ su - # /etc/init.d/mysql stop # rm -rf /var/lib/mysql/rounduptest # /etc/init.d/mysql start and all will be better (note that on some systems, ``mysql`` is spelt ``mysqld``). code-0e2a0c2c8142/doc/original_overview.html0000644000000000000000000011451310062724152017023 0ustar 00000000000000 Roundup: an Issue-Tracking System for Knowledge Workers
[Software Carpentry logo]
[ACL Logo]
[CodeSourcery Logo]
Copyright (c) 2000 Ka-Ping Yee. This material may be distributed only subject to the terms and conditions set forth in the Software Carpentry Open Publication License, which is available at:
http://www.software-carpentry.com/openpub-license.html

Roundup

An Issue-Tracking System for Knowledge Workers

Ka-Ping Yee

lfw discorporated
ping@lfw.org

Contents

Overview

We propose an issue-tracking system called Roundup, which will manage a number of issues (with properties such as "description", "priority", and so on) and provide the ability to (a) submit new issues, (b) find and edit existing issues, and (c) discuss issues with other participants. The system will facilitate communication among the participants by managing discussions and notifying interested parties when issues are edited.

This design draws on experience from an existing implementation which we will refer to as "the Roundup prototype". The graphical interface we have in mind will resemble the main display of the prototype.

Background

A typical software project requires the management of many tasks, usually distributed among several collaborators. In fact, any project team could use a tool for sorting out and discussing all the relevant issues. A common approach is to set up some kind of "to-do" list that people can share.

However, to address the overall problem we need much more than just a shared to-do list; we need to manage a growing body of knowledge and experience to help a team collaborate effectively on a project. The issue-tracking tool becomes a nexus for communication: the Grand Central Station of the group intelligence.

The primary focus of this design is to help developers work together well, not to provide a customer service interface to the developers. This is not to say that the design is to be made unsuitable for customers to use. Rather, it is assumed that many of the same qualities that are good for supporting development (see below) are also good for non-developers using the system. Additional niceties for providing a safe or simplified interface to clients are intentionally deferred for later consideration.

A good issue-tracking system should have at least the following properties:

With a nod to the time-honoured computer science tradition of "filling in the fourth quadrant", we note that there are really four kinds of information flow going on here. The three mentioned qualities really address the first three quadrants of this 2-by-2 matrix, respectively:

  1. User push: a user submits information to the system.
  2. User pull: a user queries for information from the system.
  3. System push: the system sends information out to users.
  4. System pull: the system solicits information from users.
An example of the fourth kind of flow is voting. Voting isn't described in this design, but it should be noted as a potential enhancement.

  1. Low barrier to participation. The usefulness of the tool depends entirely on the information people contribute to it. It must be made as easy as possible to submit new issues and contribute information about existing issues.

  2. Straightforward navigation. It should be easy for users to extract information they need from the system to direct their decisions and tasks. They should be able to get a decent overview of things as well as finding specific information when they know what they're after.

  3. Controlled information flow. The users must have control over how much information and what information they get. A common flaw of some issue-tracking systems is that they inundate users with so much useless e-mail that people avoid the system altogether.


Guiding Principles

Simplicity. It is a strong requirement that the tool be accessible and understandable. It should be fairly obvious what different parts of the interface do, and the inner mechanisms should operate in ways that most users can easily predict.

Efficiency. We aim to optimize for minimum effort to do the most common operations, and best use of resources like screen real estate to maximize the amount of information that we summarize and present.

Generality. We try to avoid making unnecessary assumptions that would restrict the applicability of the tool. For example, there is no reason why one might not also want to use this tool to manage a design process, non-software projects, or organizational decisions.

Persistence. We prefer hiding or reclassifying information to deleting it. This helps support the collection of statistics later. If records are never destroyed, there is little danger in providing access to a larger community, and logging yields accountability, which may encourage better behaviour.

Okay, enough ranting. Let's get down to business.

Data Model

Roundup stores a number of items, each of which can have several properties and an associated discussion. The properties can be used to classify or search for items. The discussion is a sequence of e-mail messages. Each item is identified by a unique number, and has an activity log which records the time and content of edits made on its properties. The log stays fairly small since the design intentionally provides only small data types as item properties, and encourages anything large to be attached to e-mail where it becomes part of the discussion. The next section explains how items are organized.

The Hyperdatabase

In my opinion, forcing items into fixed categories is one of the most serious problems with the Roundup prototype. The hyperdatabase is an experimental attempt to address the problem of information organization, whose scope goes beyond just Roundup.
Often when classifying information we are asked to select exactly one of a number of categories or to fit it into a rigid hierarchy. Yet things only sometimes fall into one category; often, a piece of information may be related to several concepts. For example, forcing each item into a single topic category is not just suboptimal but counterproductive: seekers of that item may expect to find it in a different category and conclude that the item is not present in the database -- which has them worse off than if the items were not categorized at all.

Some systems try to alleviate this problem by allowing nodes to appear at multiple locations in a tree, as with "aliases" or "symbolic links" in a filesystem, for example. This does help somewhat, but we want to be even more flexible by allowing the organization of nodes into sets that may freely intersect. Rather than putting each node at exactly one place in an overall "grand scheme", a node can belong to as many sets as are appropriate. If we choose to represent the sets themselves as nodes and set membership as a link between nodes, we're now ready to present the definition of a hyperdatabase.

Perhaps it's too pretentious a name? You could say this is just like an object database. The hyperdatabase is hardly much of an invention; the intent is merely to emphasize querying on links rather than properties. (I haven't heard of this being done with object databases before, but plead ignorance if there's already a good name for this idea.)
A hyperdatabase is a collection of nodes that may be hyperlinked to each other (hence the name "hyperdatabase"). Each node carries a collection of key-value pairs, where some of the values may be links to other nodes. Any node may have an arbitrary number of outgoing and incoming links. Hyperdatabases are able to efficiently answer queries such as "what nodes link to this node?" and "what nodes does this node link to?"

Rationale

There are several reasons for building our own kind of database for Roundup rather than using an existing one. Requiring the installation of a full-blown third-party SQL database system would probably deter many potential users from attempting to set up Roundup; yet a real relational database would be too complicated to implement on our own. On the other hand, a hyperdatabase can be implemented fairly easily using one of the Python DBM modules, so we can take the "batteries-included" approach and provide it as part of the system. It's easier to build and understand than a true relational database (in accordance with our guiding principle of simplicity), but provides most of the query functionality we want.

A hyperdatabase is well suited for finding the intersection of a number of sets in which items belong. We expect that most of the queries people want to do will be of this form, rather than complicated SQL queries. For example, a typical request might be "show me all critical items related to security". The ability to store arbitrary key-value pairs and links on nodes gives it more flexibility than an RDBMS. Users are not going to be making thousands of queries per second, so it makes sense to optimize for simplicity and flexibility rather than performance.

Roundup's Hyperdatabase

For our application, we store each item as a node in a hyperdatabase. The item's properties are stored as key-value pairs on its node. Four types of properties are allowed: string, date, choice, and reference.

The string type is for short, free-form strings. String properties are not intended to contain large amounts of text, and it is recommended that they be presented as one-line fields to encourage brevity.

The date type is for calendar dates and times.

The choice type denotes a single selection from a number of options. A choice property entails a link from the node possessing the property to the node representing the chosen option.

The reference type is for a list of links to any number of other nodes in the in the database. A reference property, for example, can be used to refer to related items or topic categories relevant to an item.

For Roundup, all items have five properties that are not customizable:

  • a string property named description
  • a reference property named superseder
  • a reference property named nosy
  • a date property named creation
  • a date property named activity

The description property is a short one-line description of the item. The detailed description can go in the first e-mail message of the item's discussion spool.

The superseder property is used to support the splitting, joining, or replacing of items. When several items need to be joined into a single item, all the old items link to the new item in their superseder property. When an item needs to be split apart, the item references all the new items in its superseder propety. We can easily list all active items just by checking for an empty superseder property, and trace the path of an item's origins by querying the hyperdatabase for links.

The nosy property contains a list of the people who are interested in an item. This mechanism is explained in the section on Nosy Lists.

The creation property records the item's creation time. The activity property records the last time that the item was edited or a mail message was added to its discussion spool. These two properties are managed by Roundup and are not available to be edited like other properties.

Users of the system are also represented by nodes in the hyperdatabase, containing properties like the user's e-mail address, login name, and password.

The Default Schema

Roundup could be distributed with a few suggested schemas for different purposes. One possible enhancement to the software-development schema is a reference property named implements for connecting development items to design requirements which they satisfy, which should be enough to provide basic support for traceability. Clearly there is also potential for adding properties for related source files, check-ins, test results, regression tests for resolved items, and so on, though these have not yet been sufficiently well thought out to specify here.

It is hoped that the hyperdatabase together with the specializations mentioned above for Roundup will be applicable in a variety of situations (in accordance with our guiding principle of generality).

To address the problem at hand, we need a specific schema for items applied particularly to software development. Again, we are trying to keep the schema simple: too many options make it tougher for someone to make a good choice. The schema is written here in the same form that it would appear in a configuration file. 

    fixer = Reference()             # people who will fix the problem

    topic = Reference()             # relevant topic keywords

    priority = Choice("critical",   # panic: work is stopped!
                      "urgent",     # important, but not deadly
                      "bug",        # lost work or incorrect results
                      "feature",    # want missing functionality
                      "wish")       # avoidable bugs, missing conveniences

    status = Choice("unread",       # submitted but no action yet
                    "deferred",     # intentionally set aside
                    "chatting",     # under review or seeking clarification
                    "need-eg",      # need a reproducible example of a bug
                    "in-progress",  # understood; development in progress
                    "testing",      # we think it's done; others, please test
                    "done-cbb",     # okay for now, but could be better
                    "resolved")     # fix has been released

The fixer property assigns responsibility for an item to a person or a list of people. The topic property places the item in an arbitrary number of relevant topic sets (see the section on Browsing and Searching).

As previously mentioned, each item gets an activity log. Whenever a property on an item is changed, the log records the time of the change, the user making the change, and the old and new values of the property. This permits the later gathering of statistics (for example, the average time from submission to resolution).

We do not specify or enforce a state transition graph, since making the system rigid in that fashion is probably more trouble than it's worth. Experience has shown that there are probably two convenient automatic state transitions:

  • from unread to chatting when e-mail is written about an item
  • from testing to resolved when a new release of the software is made
Beyond these, in accordance with our principle of generality, we allow access to the hyperdatabase API so that scripts can automate transitions themselves or be triggered by changes in the database.

User Interface

Roundup provides its services through two main interfaces: e-mail and the Web. This division is chosen to optimize the most common tasks.

E-mail is best suited for the submission of new items since most people are most comfortable with composing long messages in their own favourite e-mail client. E-mail also permits them to mention URLs or attach files relevant to their submission. Indeed, in many cases people are already used to making requests by sending e-mail to a mailing list of people; they can do exactly the same thing to use Roundup without even thinking about it. Similarly, people are already familiar with holding discussions in e-mail, and plenty of valuable usage conventions and software tools already exist for that medium.

The Web, on the other hand, is best suited for summarizing and seeking information, because it can present an interactive overview of items. Since the Web has forms, it's also the best place to edit items.

Submission and Discussion

Nosy lists have actually been tried in practice, and their emergent properties have turned out to be very effective. They are one of the key strengths of the Roundup prototype, and often cause me to wonder if all mailing lists ought to work this way. Roundup could even replace Hypermail.

The system needs an address for receiving mail and an address that forwards mail to all participants. Each item has its own list of interested parties, known as its nosy list. Here's how nosy lists work:

  1. New items are always submitted by sending an e-mail message to Roundup. The "Subject:" field becomes the description of the new item. The message is saved in the mail spool of the new item, and copied to the list of all participants so everyone knows that a new item has been added. The new item's nosy list initially contains the submitter.
  2. All e-mail messages sent by Roundup have their "Reply-To:" field set to Roundup's address, and have the item's number in the "Subject:" field. Thus, any replies to the initial announcement and subsequent threads are all received by Roundup. Roundup notes the item number in the "Subject:" field of each incoming message and appends the message to the appropriate spool.
  3. Any incoming e-mail tagged with an item number is copied to all the people on the item's nosy list, and any users found in the "From:", "To:", or "Cc:" fields are automatically added to the nosy list. Whenever a user edits an item's properties in the Web interface, they are also added to the nosy list.

The effect is like each item having its own little mailing list, except that no one ever has to worry about subscribing to anything. Indicating interest in an issue is sufficient, and if you want to bring someone new into the conversation, all you need to do is Cc: a message to them. It turns out that no one ever has to worry about unsubscribing, either: the nosy lists are so specific in scope that the conversation tends to die down by itself when the issue is resolved or people no longer find it sufficiently important.

Each nosy list is like an asynchronous chat room, lasting only a short time (typically five or ten messages) and involving a small group of people. However, that group is the right group of people: only those who express interest in an item in some way ever end up on the list, so no one gets spammed with mail they don't care about, and no one who wants to see mail about a particular item needs to be left out, for they can easily join in, and just as easily look at the mail spool on an item to catch up on any messages they might have missed.

We can take this a step further and permit users to monitor particular topics or classifications of items by allowing other kinds of nodes to also have their own nosy lists. For example, a manager could be on the nosy list of the priority value node for "critical", or a developer could be on the nosy list of the topic value node for "security". The recipients are then determined by the union of the nosy lists on the item and all the nodes it links to.

Using many small, specific mailing lists results in much more effective communication than one big list. Taking away the effort of subscribing and unsubscribing gives these lists the "feel" of being cheap and disposable. The transparent capture of the mail spool attached to each issue also yields a nice knowledge repository over time.

Editing

Since Roundup is intended to support arbitrary user-defined schema for item properties, the editing interface must be automatically generated from the schema. The configuration for Roundup will include a template describing how to lay out the properties to present a UI for inspecting and editing items. For example: 

    <table width="100%">
    <tr><td align=right>Description:</td>
        <td><?property description size=70></td></tr>
    <tr><td align=right>Status:</td>
        <td><?property status></td></tr>
    </table>

To display the editing form for an item, Roundup substitutes an HTML form widget for each <?property ...> tag, and transfers attributes (such as size=70 in the above example) from the processing tag to the form widget's tag. Each type has its own appropriate editing widget:

  • string properties appear as text fields
  • date properties appear as text fields
  • choice properties appear as selection lists
  • reference properties appear as multiple-selection lists with a text field for adding a new option

We foresee the use of custom date fields for things like deadlines, so input fields for date properties should support some simple way of specifying relative dates (such as "three weeks from now").

The superseder property is a special case: although it is more efficient to store a superseder property in the superseded item, it makes more sense to provide a "supersedes" edit field on the superseding item. So we need a special widget on items for this purpose (perhaps something as simple as a text field containing a comma-separated list of item numbers will do). Links in the superseder property should appear on both the superseding and superseded items to facilitate navigating an item's pedigree.

After the editing widgets, the item inspection page shows a "note" text box and then a display of the messages in the discussion spool, like the Roundup prototype. This field lets you enter a note explaining your change when you edit the item, and the note is included in the notification message that goes out to tell the interested parties on the nosy list of your edits.

Browsing and Searching

The ideal we would like to achieve is to make searching as much like browsing as possible: the user simply clicks about on things that seem interesting, and the information narrows down comfortably until the goal is in sight. This is preferable to trying to digest a screen filled with widgets and buttons or entering a search expression in some arcane algebraic syntax.

Though the generation of each page amounts to a database query, so that the underlying mechanism is still a series of queries and responses, the user interface never separates the query from the response, so the experience is one of stepwise refinement.
While a one-shot search may be appropriate when you're looking for a single item and you know exactly what you want, it's not very helpful when you want an overview of things ("Gee, there are a lot more high-priority items than there were last week!") or trying to do comparisons ("I have some time today, so who is busiest and could most use some help?")

The browsing interface presents filtering functionality for each of the properties in the schema. As with editing, the interface is generated from a template describing how to lay out the properties. Each type of property has its own appropriate filtering widget:

  • string properties appear as text fields supporting case-insensitive substring match
  • date properties appear as a text field with an option to choose dates after or before the specified date
  • choice properties appear as a group of selectable options (the filter selects the union of the sets of items associated with the active options)
  • reference properties appear as a group of selectable options (the filter selects the intersection of the sets of items associated with the active options)

For a reference property like topic, one possibility is to show, as hyperlinks, the keywords whose sets have non-empty intersections with the currently displayed set of items. Sorting the keywords by popularity seems reasonable. Clicking on a keyword then narrows both the list of items and the list of keywords. This gives some of the feel of walking around a directory tree -- but without the restriction of having to select keywords in a particular hierarchical order, and without the need to travel all the way to the leaves of the tree before any items are visible.

Below the filtering form is a listing of items, with their properties displayed in a table. Rows in the table can also be generated from a template, as with the editing interface. This listing is the central overview of the system, and it should aim to maximize the density of useful information in accordance with our guiding principle of efficiency. For example, Bugzilla initially displays seven or eight items of the index, but only after the user has waded through three bewildering screens of form widgets. Jitterbug can't even fit any items at all in the first screenful, as it's taken up by artwork and adminstrative debris. In contrast, in the Roundup prototype, 25 high-priority issues are immediately visible, with most of the screen space devoted to their descriptions. Colour indicates the status of each item to help the eye sift through the index quickly.

In both Jitterbug and Bugzilla, items are sorted by default by ID, a meaningless field. Sorting by ID puts the issues in order by ascending submission date, which banishes recent issues far away at the bottom of the list. The Roundup prototype sorts items in sections by priority, and then within sections by the date of last activity. This reveals at a glance where discussion is most active, and provides an easy way for anyone to move an issue up in the list.

The page produced by a given set of browsing options constitutes a view. The options should all be part of the query parameters in the URL so that views may be bookmarked. A view specifies:

  • search strings for string properties
  • date ranges for date properties
  • acceptable values for choice properties
  • required values for reference properties
  • one or more sort keys
  • a list of properties for which to display filtering widgets

On each sort key there is the option to use sections -- that is, instead of making the property's value a column of the table, each possible value for the property is displayed at the top of a section and all the items having that value for that property are grouped underneath. This avoids wasting screen space with redundant information.

We propose that our default view should be:

  • all options on for priority and fixer
  • all options on except "resolved" for status
  • no options on for topic
  • primary sort by priority in sections
  • secondary sort by decreasing activity date

The starting URL for Roundup should immediately present the listing of items generated by this default view, with no preceding query screen.

Development Plan

The hyperdatabase is clearly a separable component which can be developed and tested independently to an API specification.

As soon as the API to the hyperdatabase is nailed down, the implementation of the Roundup database layer on top of the hyperdatabase can begin. (This refers to the data types and five fixed properties specific to Roundup.) This layer can also be tested separately.

When the interface to the Roundup hyperdatabase is ready, development can begin on the user interface. The mail handler and the Web interface can be developed in parallel and mostly independently of each other.

The mail handler can be set up for testing fairly easily: mail messages on its standard input can be synthesized; its output is outgoing mail, which can be captured by replacing the implementation of the "send mail" function; and its side effects appear in the hyperdatabase, which has a Python API.

The Web interface is not easily testable in its entirety, though the most important components of it can be unit tested, such as the component that translates a view specification into a list of items for display, and the component that performs replacements on templates to produce an editing or filtering interface.

Open Issues

The description of the hyperdatabase above avoids some issues regarding node typing that need to be better specified. It is conceivable that eventually Roundup could support multiple kinds of items with their own schemas.

To permit integration with external tools, it is probably a good idea to provide a command-line tool that exposes the hyperdatabase API. This tool will be left for a later phase of development and so isn't specified in detail here.

Generating the user interface from a template is like applying an XSL stylesheet to XML, and if there's a standard Python module for performing these transformations, we could use XML instead.

More thinking is needed to determine the best filtering interface for reference properties. The proposed interface works well for topic keywords, but it isn't clear what to do when there are too many keywords to display them all.

There has been a variety of reactions to the hyperdatabase from reviewers: some like it, some are neutral, and some would prefer a "standard" RDBMS solution. For those in the latter camp, note that it's still possible to build the Roundup database layer around an RDBMS if we really need to. The rest of the design, in particular the "nosy list" mechanism, remains intact.

The possibility of malice by registered users has been disregarded. The system is intended to be used by a co-operative group.

This design tries to address as many as possible of the suggested requirements mentioned on the contest page:

  • configuring states: Edit the schema.
  • setting state transition rules: We don't enforce any rules.
  • assigning responsibility: Set the fixer property.
  • splitting and joining: Use the superseder property.
  • hiding information: Add a property and a pre-defined view that filters on it.
  • secure protocols: Naturally HTTPS would be nice, though it's largely a webserver configuration issue; secure e-mail is not addressed.
  • archiving old issues: Tag them with a property.
  • identifying repeated issues: Use the superseder property.
  • connecting state changes to external operations: We provide an API to the database and the notification mechanism so it can be scripted.
  • non-Latin alphabets: Unicode in Python 1.6 will handle this for string properties, and we can leverage existing standards for internationalizing e-mail messages.
  • images and other binaries: Attach them to e-mail messages.
  • inspecting item state: Use the editing interface.
  • translation between system-dependent formats: This is not addressed.
  • performing searches: Use the browsing and filtering interface.
  • collecting statistics: Information is gathered in the activity log, though tools to summarize it are not described here.

Summary

Roundup is an issue-tracking system that also functions as a communications center and a knowledge repository. It combines the strengths of e-mail and the Web to try to provide the best possible user interaction.

  • The submission and discussion of items by e-mail, permitting participants to use an easy and familiar tool, achieves our goal of low barrier to participation.
  • The generic link-based structuring of data and use of incremental filtering rather than one-shot querying makes for straightforward navigation.
  • The use of nosy lists (a powerful replacement for e-mail discussion lists) to manage communication on a fine-grained level provides controlled information flow.

The use of a "hyperdatabase" as the core model for the knowledge repository gives us the flexibility to extend Roundup and apply it to a variety of domains by providing new item schemas and user-interface templates.

Roundup is self-contained and easy to set up, requiring only a webserver and a mailbox. No one needs to be root to configure the webserver or to install database software.

This design is based on an existing deployed prototype which has proven its strengths and revealed its weaknesses in heavy day-to-day use by a real development team.

Acknowledgements

My thanks are due to Christina Heyl, Jesse Vincent, Mark Miller, Christopher Simons, Jeff Dunmall, Wayne Gramlich, and Dean Tribble for reviewing this paper and contributing their suggestions.

   [Home]       [FAQ]       [License]       [Rules]       [Resources]       [Archives]   

Last modified 2001/04/06 11:50:59.9063 US/Mountain
code-0e2a0c2c8142/doc/overview.txt0000644000000000000000000005672010062724152015017 0ustar 00000000000000======================================================= Roundup: an Issue-Tracking System for Knowledge Workers ======================================================= :Authors: Ka-Ping Yee (original_), Richard Jones (implementation) .. _original: original_overview.html .. contents:: Introduction ============ Roundup is an issue-tracking system called which will manage a number of issues (with properties such as "description", "priority", and so on) and provides the ability to: (a) submit new issues, (b) find and edit existing issues, and (c) discuss issues with other participants. Roundup facilitates communication among the participants by managing discussions and notifying interested parties when issues are edited. Background ---------- A typical software project requires the management of many tasks, usually distributed among several collaborators. In fact, any project team could use a tool for sorting out and discussing all the relevant issues. A common approach is to set up some kind of "to-do" list that people can share. However, to address the overall problem we need much more than just a shared to-do list; we need to manage a growing body of knowledge and experience to help a team collaborate effectively on a project. The issue-tracking tool becomes a nexus for communication: the Grand Central Station of the group intelligence. The primary focus of this design is to help developers work together well, not to provide a customer service interface to the developers. This is not to say that the design is to be made unsuitable for customers to use. Rather, it is assumed that many of the same qualities that are good for supporting development (see below) are also good for non-developers using the system. Additional niceties for providing a safe or simplified interface to clients are intentionally deferred for later consideration. A good issue-tracking system should have at least the following properties: **Low barrier to participation** The usefulness of the tool depends entirely on the information people contribute to it. It must be made as easy as possible to submit new issues and contribute information about existing issues. **Straightforward navigation** It should be easy for users to extract information they need from the system to direct their decisions and tasks. They should be able to get a decent overview of things as well as finding specific information when they know what they're after. **Controlled information flow** The users must have control over how much information and what information they get. A common flaw of some issue-tracking systems is that they inundate users with so much useless e-mail that people avoid the system altogether. With a nod to the time-honoured computer science tradition of "filling in the fourth quadrant", we note that there are really four kinds of information flow going on here. The three mentioned qualities really address the first three quadrants of this 2-by-2 matrix, respectively: 1. User push: a user submits information to the system. 2. User pull: a user queries for information from the system. 3. System push: the system sends information out to users. 4. System pull: the system solicits information from users. An example of the fourth kind of flow is voting. Voting isn't described in this design, but it should be noted as a potential enhancement. Guiding Principles ------------------ **Simplicity** It is a strong requirement that the tool be accessible and understandable. It should be fairly obvious what different parts of the interface do, and the inner mechanisms should operate in ways that most users can easily predict. **Efficiency** We aim to optimize for minimum effort to do the most common operations, and best use of resources like screen real estate to maximize the amount of information that we summarize and present. **Generality** We try to avoid making unnecessary assumptions that would restrict the applicability of the tool. For example, there is no reason why one might not also want to use this tool to manage a design process, non-software projects, or organizational decisions. **Persistence** We prefer hiding or reclassifying information to deleting it. This helps support the collection of statistics later. If records are never destroyed, there is little danger in providing access to a larger community, and logging yields accountability, which may encourage better behaviour. Data Model ========== Roundup stores a number of *items*, each of which can have several properties and an associated discussion. The properties can be used to classify or search for items. The discussion is a sequence of e-mail messages. Each item is identified by a unique number, and has an activity log which records the time and content of edits made on its properties. The log stays fairly small since the design intentionally provides only small data types as item properties, and encourages anything large to be attached to e-mail where it becomes part of the discussion. The next section explains how items are organized. The Hyperdatabase ----------------- Often when classifying information we are asked to select exactly one of a number of categories or to fit it into a rigid hierarchy. Yet things only sometimes fall into one category; often, a piece of information may be related to several concepts. For example, forcing each item into a single topic category is not just suboptimal but counterproductive: seekers of that item may expect to find it in a different category and conclude that the item is not present in the database -- which has them *worse* off than if the items were not categorized at all. Some systems try to alleviate this problem by allowing items to appear at multiple locations in a tree, as with "aliases" or "symbolic links" in a filesystem, for example. This does help somewhat, but we want to be even more flexible by allowing the organization of items into sets that may freely intersect. Rather than putting each item at exactly one place in an overall "grand scheme", a item can belong to as many sets as are appropriate. If we choose to represent the sets themselves as items and set membership as a link between items, we're now ready to present the definition of a hyperdatabase. A *hyperdatabase* is a collection of *items* that may be hyperlinked to each other (hence the name "hyperdatabase"). Each item carries a collection of key-value pairs, where some of the values may be links to other items. Any item may have an arbitrary number of outgoing and incoming links. Hyperdatabases are able to efficiently answer queries such as "what items link to this item?" and "what items does this item link to?" Rationale --------- There are several reasons for building our own kind of database for Roundup rather than using an existing one. Requiring the installation of a full-blown third-party SQL database system would probably deter many potential users from attempting to set up Roundup; yet a real relational database would be too complicated to implement on our own. On the other hand, a hyperdatabase can be implemented fairly easily using one of the Python DBM modules, so we can take the "batteries-included" approach and provide it as part of the system. It's easier to build and understand than a true relational database (in accordance with our guiding principle of *simplicity*), but provides most of the query functionality we want. A hyperdatabase is well suited for finding the intersection of a number of sets in which items belong. We expect that most of the queries people want to do will be of this form, rather than complicated SQL queries. For example, a typical request might be "show me all critical items related to security". The ability to store arbitrary key-value pairs and links on items gives it more flexibility than an RDBMS. Users are not going to be making thousands of queries per second, so it makes sense to optimize for simplicity and flexibility rather than performance. .. img: images/hyperdb.png Roundup's Hyperdatabase ----------------------- For our application, we store each item as a item in a hyperdatabase. The item's properties are stored as key-value pairs on its item. Several types of properties are allowed: *string*, *number*, *boolean*, *date*, *interval, *link*, and *multlink*. Another type, *password*, is a special type of string and it's only used internally to Roundup. The *string* type is for short, free-form strings. String properties are not intended to contain large amounts of text, and it is recommended that they be presented as one-line fields to encourage brevity. A *number* is a special type of string that represents a numeric value. A *boolean* is further constrained to be a *true* or *false* value. The *date* type is for calendar dates and times. An *interval* is the time between two dates. The *link* type denotes a single selection from a number of options. A *link* property entails a link from the item possessing the property to the item representing the chosen option. The *multilink* type is for a list of links to any number of other items in the in the database. A *multilink* property, for example, can be used to refer to related items or topic categories relevant to an item. For Roundup, all items have four properties that are not customizable: 1. a *date* property named **creation** 2. a *link* property named **creator** 3. a *date* property named **activity** These properties represent the date of the creation of the item, who created it, and when the last change was made. Further, all *issue* items have an additional four properties: 1. a *string* property named **title** 2. a *multilink* property named **nosy** 3. a *multilink* property named **messages** 4. a *multilink* property named **files** 5. a *multilink* property named **superseder** The **title** property is a short one-line description of the item. The detailed description can go in the first e-mail message of the item's messages spool. The **nosy** property contains a list of the people who are interested in an item. This mechanism is explained in the section on `Submission and Discussion`_. Each message added to the item goes in the **messages** spool - any attached files go in the **files** spool. The **superseder** property is used to support the splitting, joining, or replacing of items. When several items need to be joined into a single item, all the old items link to the new item in their **superseder** property. When an item needs to be split apart, the item references all the new items in its **superseder** propety. We can easily list all active items just by checking for an empty **superseder** property, and trace the path of an item's origins by querying the hyperdatabase for links. Users of the system are also represented by items in the hyperdatabase, containing properties like the user's e-mail address, login name, and password. The Default Schema ------------------ It is hoped that the hyperdatabase together with the specializations mentioned above for Roundup will be applicable in a variety of situations (in accordance with our guiding principle of *generality*). To address the problem at hand, we need a specific schema for items applied particularly to software development. Again, we are trying to keep the schema simple: too many options make it tougher for someone to make a good choice:: # IssueClass automatically gets these properties: # title = String() # messages = Multilink("msg") # files = Multilink("file") # nosy = Multilink("user") # superseder = Multilink("issue") # (it also gets the Class properties creation, activity and creator) issue = IssueClass(db, "issue", assignedto=Link("user"), topic=Multilink("keyword"), priority=Link("priority"), status=Link("status")) The **assignedto** property assigns responsibility for an item to a person or a list of people. The **topic** property places the item in an arbitrary number of relevant topic sets (see the section on `Browsing and Searching`_). The **prority** and **status** values are initially: =========== ===================================== Priority Description =========== ===================================== "critical" panic: work is stopped! "urgent" important, but not deadly "bug" lost work or incorrect results "feature" want missing functionality "wish" avoidable bugs, missing conveniences =========== ===================================== ============= ===================================== Status Description ============= ===================================== "unread" submitted but no action yet "deferred" intentionally set aside "chatting" under review or seeking clarification "need-eg" need a reproducible example of a bug "in-progress" understood; development in progress "testing" we think it's done; others, please test "done-cbb" okay for now, but could be better "resolved" fix has been released ============= ===================================== As previously mentioned, each item gets an activity log. Whenever a property on an item is changed, the log records the time of the change, the user making the change, and the old and new values of the property. This permits the later gathering of statistics (for example, the average time from submission to resolution). We do not specify or enforce a state transition graph, since making the system rigid in that fashion is probably more trouble than it's worth. Experience has shown that there are probably two convenient automatic state transitions: 1. from **unread** to **chatting** when e-mail is written about an item 2. from **testing** to **resolved** when a new release of the software is made Beyond these, in accordance with our principle of *generality*, we allow access to the hyperdatabase API so that scripts can automate transitions themselves or be triggered by changes in the database. User Interface ============== Roundup provides its services through two main interfaces: e-mail and the Web. This division is chosen to optimize the most common tasks. E-mail is best suited for the submission of new items since most people are most comfortable with composing long messages in their own favourite e-mail client. E-mail also permits them to mention URLs or attach files relevant to their submission. Indeed, in many cases people are already used to making requests by sending e-mail to a mailing list of people; they can do exactly the same thing to use Roundup without even thinking about it. Similarly, people are already familiar with holding discussions in e-mail, and plenty of valuable usage conventions and software tools already exist for that medium. The Web, on the other hand, is best suited for summarizing and seeking information, because it can present an interactive overview of items. Since the Web has forms, it's also the best place to edit items. Submission and Discussion ------------------------- The system needs an address for receiving mail and an address that forwards mail to all participants. Each item has its own list of interested parties, known as its *nosy list*. Here's how nosy lists work: 1. New items are always submitted by sending an e-mail message to Roundup. The "Subject:" field becomes the description of the new item. The message is saved in the mail spool of the new item, and copied to the list of all participants so everyone knows that a new item has been added. The new item's nosy list initially contains the submitter. 2. All e-mail messages sent by Roundup have their "Reply-To:" field set to Roundup's address, and have the item's number in the "Subject:" field. Thus, any replies to the initial announcement and subsequent threads are all received by Roundup. Roundup notes the item number in the "Subject:" field of each incoming message and appends the message to the appropriate spool. 3. Any incoming e-mail tagged with an item number is copied to all the people on the item's nosy list, and any users found in the "From:", "To:", or "Cc:" fields are automatically added to the nosy list. Whenever a user edits an item's properties in the Web interface, they are also added to the nosy list. The effect is like each item having its own little mailing list, except that no one ever has to worry about subscribing to anything. Indicating interest in an issue is sufficient, and if you want to bring someone new into the conversation, all you need to do is "Cc:" a message to them. It turns out that no one ever has to worry about unsubscribing, either: the nosy lists are so specific in scope that the conversation tends to die down by itself when the issue is resolved or people no longer find it sufficiently important. Each nosy list is like an asynchronous chat room, lasting only a short time (typically five or ten messages) and involving a small group of people. However, that group is the *right* group of people: only those who express interest in an item in some way ever end up on the list, so no one gets spammed with mail they don't care about, and no one who *wants* to see mail about a particular item needs to be left out, for they can easily join in, and just as easily look at the mail spool on an item to catch up on any messages they might have missed. We can take this a step further and permit users to monitor particular topics or classifications of items by allowing other kinds of items to also have their own nosy lists. For example, a manager could be on the nosy list of the priority value item for "critical", or a developer could be on the nosy list of the topic value item for "security". The recipients are then determined by the union of the nosy lists on the item and all the items it links to. Using many small, specific mailing lists results in much more effective communication than one big list. Taking away the effort of subscribing and unsubscribing gives these lists the "feel" of being cheap and disposable. The transparent capture of the mail spool attached to each issue also yields a nice knowledge repository over time. Editing ------- Since Roundup is intended to support arbitrary user-defined schema for item properties, the editing interface must be automatically generated from the schema. The configuration for Roundup will include a template describing how to lay out the properties to present a UI for inspecting and editing items. For example:: Priority priority Status status To display the editing form for an item, Roundup inserts an HTML form widget where it encounters an expression like ``tal:content="structure context/priority/menu"``. Each type has its own appropriate editing widget: - *string* and *number* properties appear as text fields - *boolean* properties appear as a yes/no selection - *date* and *interval* properties appear as text fields - *link* properties appear as selection lists - *multilink* properties appear as multiple-selection lists or text fields with pop-up widgets for larger selections. We foresee the use of custom date fields for things like deadlines, so input fields for *date* properties support a simple way of specifying relative dates (such as "3w" for "three weeks from now"). The **superseder** property is a special case: although it is more efficient to store a **superseder** property in the superseded item, it makes more sense to provide a "supersedes" edit field on the superseding item. We use a special widget on items for this purpose (a text field containing a comma-separated list of items). Links in the **superseder** property appear on both the superseding and superseded items to facilitate navigating an item's pedigree. After the editing widgets, the item inspection page shows a "note" text box and then a display of the messages in the discussion spool. This field lets you enter a note explaining your change when you edit the item, and the note is included in the notification message that goes out to tell the interested parties on the nosy list of your edits. Browsing and Searching ---------------------- The ideal we would like to achieve is to make searching as much like browsing as possible: the user simply clicks about on things that seem interesting, and the information narrows down comfortably until the goal is in sight. This is preferable to trying to digest a screen filled with widgets and buttons or entering a search expression in some arcane algebraic syntax. While a one-shot search may be appropriate when you're looking for a single item and you know exactly what you want, it's not very helpful when you want an overview of things ("Gee, there are a lot more high-priority items than there were last week!") or trying to do comparisons ("I have some time today, so who is busiest and could most use some help?") The browsing interface presents filtering functionality for each of the properties in the schema. As with editing, the interface is generated from a template describing how to lay out the properties. Each type of property has its own appropriate filtering widget: - *string* properties appear as text fields supporting case-insensitive substring match - *date* properties appear as a text field which accepts a date range with start, end or both - *link* properties appear as a group of selectable options (the filter selects the *union* of the sets of items associated with the active options) - *multilink* properties appear as a group of selectable options (the filter selects the *intersection* of the sets of items associated with the active options) For a *multilink* property like **topic**, one possibility is to show, as hyperlinks, the keywords whose sets have non-empty intersections with the currently displayed set of items. Sorting the keywords by popularity seems reasonable. Clicking on a keyword then narrows both the list of items and the list of keywords. This gives some of the feel of walking around a directory tree -- but without the restriction of having to select keywords in a particular hierarchical order, and without the need to travel all the way to the leaves of the tree before any items are visible. Below the filtering form is a listing of items, with their properties displayed in a table. Rows in the table are generated from a template, as with the editing interface. This listing is the central overview of the system, and it should aim to maximize the density of useful information in accordance with our guiding principle of *efficiency*. Colour may be used to indicate the status of each item to help the eye sift through the index quickly. Roundup sorts items in groups by priority, and then within groups by the date of last activity. This reveals at a glance where discussion is most active, and provides an easy way for anyone to move an issue up in the list. The page produced by a given set of browsing options constitutes an *index*. The options should all be part of the query parameters in the URL so that views may be bookmarked. An index specifies: - search strings for string properties - date ranges for date properties - acceptable values for choice properties - required values for reference properties - a sorting key - a grouping key - a list of properties for which to display filtering widgets Our default index is: - all **status** values except "resolved" - show **priority** and **fixer** - grouping by **priority** in sections - sorting by decreasing **activity** date The starting URL for Roundup immediately presents the listing of items generated by this default index, with no preceding query screen. code-0e2a0c2c8142/doc/postgresql.txt0000644000000000000000000000341510062724152015345 0ustar 00000000000000========================== PostgreSQL/psycopg Backend ========================== This is notes about PostreSQL backend based on the psycopg adapter for roundup issue tracker. Prerequisites ============= To use PostgreSQL as backend for storing roundup data, you should additionally install: 1. PostgreSQL 7.x - http://www.postgresql.org/ 2. The psycopg python interface to PostgreSQL: http://initd.org/software/initd/psycopg Running the PostgreSQL unit tests ================================= The user that you're running the tests as will need to be able to access the postgresql database on the local machine and create and drop databases. Edit the ``test/test_postgresql.py`` database connection info if you wish to test against a different database. The test database will be called "rounduptest". Additional configuration ======================== To initialise and use PostgreSQL database roundup's configuration file (config.py in the tracker's home directory) should be appended with the following constants (substituting real values, obviously):: POSTGRESQL_DATABASE = {'database': 'rounduptest'} if not local, or a different user is to be used, then more information may be supplied:: POSTGRESQL_DATABASE = { 'host': 'localhost', 'port': 5432, 'database': 'roundup' 'user': 'roundup', 'password': 'roundup', } Also note that you can leave some values out of ``POSTGRESQL_DATABASE``: 'host' and 'port' are not necessary when connecting to a local database and 'password' is optional if postgres trusts local connections. The user specified in ``user`` must have rights to create a new database and to connect to the "template1" database, used while initializing roundup. Have fun with psycopg, Federico Di Gregorio code-0e2a0c2c8142/doc/roundup-admin.10000644000000000000000000000146210062724152015245 0ustar 00000000000000.TH ROUNDUP-ADMIN 1 "24 January 2003" .SH NAME roundup-admin \- administrate roundup trackers .SH SYNOPSIS \fBroundup-admin\fP [\fIoptions\fP] \fI\fP \fI\fP .SH OPTIONS .TP \fB-i\fP \fIinstance home\fP specify the issue tracker "home directory" to administer .TP \fB-u\fP the user[:password] to use for commands .TP \fB-c\fP when outputting lists of data, just comma-separate them .SH FURTHER HELP roundup-admin -h roundup-admin help -- this help roundup-admin help -- command-specific help roundup-admin help all -- all available help .SH AUTHOR This manpage was written by Bastian Kleineidam for the Debian distribution of roundup. The main author of roundup is Richard Jones . code-0e2a0c2c8142/doc/roundup-favicon.ico0000644000000000000000000000257610062724152016223 0ustar 00000000000000h( °°°¡¡¡êêê+++ttt ®®®ŸŸŸ)))rrrccc»»»'''ÈÈÈRRRÕÕÕnnnâââ{{{ÓÓÓlllNNNˆˆˆààत¤===üüü•••...†††ÞÞÞÏÏÏYYYúúúÜÜÜÍÍͯ¯¯HHH‘‘‘‚‚‚ÚÚÚËËËUUUžžž€€€ØØØÉÉÉ «««œœœÖÖÖ```QQQ$$$ãã㧧§ÿÿÿ˜˜˜"""ÒÒÒ´´´îîîÐÐÐÁÁÁ………ÝÝÝÎÎÎB .B+ 6BBBBBBBBBH /CHB14B%BBBB9 #BBB8:3GBBBF B05/%ABBBBK'7 -! BBBBBF"MBBBBBBBBIDMG2 2,BBBBBBBB(B5BBBBBBBBB&H6BBBBBBBBBBBBB*LEI+BBBBBBBBBIN*)BHJ0BBBBBBB5BH5NBBBBBBÐÿÁ—ƒ‡€?À?ð?ð?ðàáËÿàñÏì?code-0e2a0c2c8142/doc/roundup-mailgw.10000644000000000000000000000352610062724152015440 0ustar 00000000000000.TH ROUNDUP-MAILGW 1 "24 January 2003" .SH NAME roundup-mailgw \- mail gateway for roundup .SH SYNOPSIS \fBroundup-mailgw\fP \fI\fP [\fImethod\fP] .SH OPTIONS .TP \fB-C\fP \fIhyperdb class\fP specify a tracker class - one of msg (the default), issue, file, user - to manipulate with -S options .TP \fB-S\fP \fIproperty=value[;property=value] pairs\fP specify the values to set on the class specified by -C using the same format as the Subject line property manipulations .SH DESCRIPTION The roundup mail gateway may be called in one of three ways: .IP \(bu with an instance home as the only argument, .IP \(bu with both an instance home and a mail spool file, or .IP \(bu with both an instance home and a pop server account. .PP \fBPIPE\fP .br In the first case, the mail gateway reads a single message from the standard input and submits the message to the roundup.mailgw module. \fBUNIX mailbox\fP .br In the second case, the gateway reads all messages from the mail spool file and submits each in turn to the roundup.mailgw module. The file is emptied once all messages have been successfully handled. The file is specified as: \fImailbox /path/to/mailbox\fP \fBPOP\fP .br In the third case, the gateway reads all messages from the POP server specified and submits each in turn to the roundup.mailgw module. The server is specified as: \fIpop username:password@server\fP .br The username and password may be omitted: \fIpop username@server\fP \fIpop server\fP .br are both valid. The username and/or password will be prompted for if not supplied on the command-line. \fBAPOP\fP Same as POP, but using Authenticated POP: \fIapop username:password@server\fP .SH AUTHOR This manpage was written by Bastian Kleineidam for the Debian distribution of roundup. The main author of roundup is Richard Jones . code-0e2a0c2c8142/doc/roundup-server.10000644000000000000000000000226510062724152015465 0ustar 00000000000000.TH ROUNDUP-SERVER 1 "24 January 2003" .SH NAME roundup-server \- start roundup server .SH SYNOPSIS \fBroundup-server\fP [\fIoptions\fP] [\fBname=\fP\fItracker home\fP]* .SH OPTIONS .TP \fB-n\fP \fIhostname\fP sets the host name .TP \fB-p\fP \fIport\fP sets the port to listen on .TP \fB-l\fP \fIfile\fP sets a filename to log to (instead of stdout) .TP \fB-d\fP \fIfile\fP daemonize, and write the server's PID to the nominated file .TP \fB-h\fP print help .TP \fBname=\fP\fItracker home\fP Sets the tracker home(s) to use. The name is how the tracker is identified in the URL (it's the first part of the URL path). The tracker home is the directory that was identified when you did "roundup-admin init". You may specify any number of these name=home pairs on the command-line. For convenience, you may edit the TRACKER_HOMES variable in the roundup-server file instead. Make sure the name part doesn't include any url-unsafe characters like spaces, as these confuse the cookie handling in browsers like IE. .SH AUTHOR This manpage was written by Bastian Kleineidam for the Debian distribution of roundup. The main author of roundup is Richard Jones . code-0e2a0c2c8142/doc/spec.html0000644000000000000000000016253010062724152014225 0ustar 00000000000000 Software Carpentry Track: Roundup
[Software Carpentry logo]
[ACL Logo]
[CodeSourcery Logo]

Roundup

An Issue-Tracking System for Knowledge Workers

Ka-Ping Yee
ping@lfw.org

Implementation Guide

Contents

  1. Introduction
  2. The Layer Cake
  3. Hyperdatabase
    1. Dates and Date Arithmetic
    2. Items and Classes
    3. Identifiers and Designators
    4. Property Names and Types
    5. Interface Specification
    6. Application Example
  4. Roundup Database
    1. Reserved Classes
      1. Users
      2. Messages
      3. Files
    2. Item Classes
    3. Interface Specification
    4. Default Schema
  5. Detector Interface
    1. Interface Specification
    2. Detector Example
  6. Command Interface
    1. Interface Specification
    2. Usage Example
  7. E-mail User Interface
    1. Message Processing
    2. Nosy Lists
    3. Setting Properties
    4. Workflow Example
  8. Web User Interface
    1. Views and View Specifiers
    2. Displaying Properties
    3. Index Views
      1. Index View Specifiers
      2. Filter Section
      3. Index Section
      4. Sorting
    4. Item Views
      1. Item View Specifiers
      2. Editor Section
      3. Spool Section
  9. Deployment Scenarios
  10. Acknowledgements

1. Introduction

This document presents a description of the components of the Roundup system and specifies their interfaces and behaviour in sufficient detail to guide an implementation. For the philosophy and rationale behind the Roundup design, see the first-round Software Carpentry submission for Roundup. This document fleshes out that design as well as specifying interfaces so that the components can be developed separately.

2. The Layer Cake

Lots of software design documents come with a picture of a cake. Everybody seems to like them. I also like cakes (i think they are tasty). So i, too, shall include a picture of a cake here.

E-mail Client

Web Browser

Detector Scripts

Shell

E-mail User Interface

Web User Interface

Detector Interface

Command Interface

Roundup Database Layer

Hyperdatabase Layer

Storage Layer

The colourful parts of the cake are part of our system; the faint grey parts of the cake are external components.

I will now proceed to forgo all table manners and eat from the bottom of the cake to the top. You may want to stand back a bit so you don't get covered in crumbs.

3. Hyperdatabase

The lowest-level component to be implemented is the hyperdatabase. The hyperdatabase is intended to be a flexible data store that can hold configurable data in records which we call items.

The hyperdatabase is implemented on top of the storage layer, an external module for storing its data. The storage layer could be a third-party RDBMS; for a "batteries-included" distribution, implementing the hyperdatabase on the standard bsddb module is suggested.

3.1. Dates and Date Arithmetic

Before we get into the hyperdatabase itself, we need a way of handling dates. The hyperdatabase module provides Timestamp objects for representing date-and-time stamps and Interval objects for representing date-and-time intervals.

As strings, date-and-time stamps are specified with the date in international standard format (yyyy-mm-dd) joined to the time (hh:mm:ss) by a period ("."). Dates in this form can be easily compared and are fairly readable when printed. An example of a valid stamp is "2000-06-24.13:03:59". We'll call this the "full date format". When Timestamp objects are printed as strings, they appear in the full date format with the time always given in GMT. The full date format is always exactly 19 characters long.

For user input, some partial forms are also permitted: the whole time or just the seconds may be omitted; and the whole date may be omitted or just the year may be omitted. If the time is given, the time is interpreted in the user's local time zone. The Date constructor takes care of these conversions. In the following examples, suppose that yyyy is the current year, mm is the current month, and dd is the current day of the month; and suppose that the user is on Eastern Standard Time.

  • "2000-04-17" means <Date 2000-04-17.00:00:00>
  • "01-25" means <Date yyyy-01-25.00:00:00>
  • "2000-04-17.03:45" means <Date 2000-04-17.08:45:00>
  • "08-13.22:13" means <Date yyyy-08-14.03:13:00>
  • "11-07.09:32:43" means <Date yyyy-11-07.14:32:43>
  • "14:25" means <Date yyyy-mm-dd.19:25:00>
  • "8:47:11" means <Date yyyy-mm-dd.13:47:11>
  • the special date "." means "right now"

Date intervals are specified using the suffixes "y", "m", and "d". The suffix "w" (for "week") means 7 days. Time intervals are specified in hh:mm:ss format (the seconds may be omitted, but the hours and minutes may not).

  • "3y" means three years
  • "2y 1m" means two years and one month
  • "1m 25d" means one month and 25 days
  • "2w 3d" means two weeks and three days
  • "1d 2:50" means one day, two hours, and 50 minutes
  • "14:00" means 14 hours
  • "0:04:33" means four minutes and 33 seconds

The Date class should understand simple date expressions of the form stamp + interval and stamp - interval. When adding or subtracting intervals involving months or years, the components are handled separately. For example, when evaluating "2000-06-25 + 1m 10d", we first add one month to get 2000-07-25, then add 10 days to get 2000-08-04 (rather than trying to decide whether 1m 10d means 38 or 40 or 41 days).

Here is an outline of the Date and Interval classes. 

class Date:
    def __init__(self, spec, offset):
        """Construct a date given a specification and a time zone offset.

        'spec' is a full date or a partial form, with an optional
        added or subtracted interval.  'offset' is the local time
        zone offset from GMT in hours.
        """

    def __add__(self, interval):
        """Add an interval to this date to produce another date."""

    def __sub__(self, interval):
        """Subtract an interval from this date to produce another date."""

    def __cmp__(self, other):
        """Compare this date to another date."""

    def __str__(self):
        """Return this date as a string in the yyyy-mm-dd.hh:mm:ss format."""

    def local(self, offset):
        """Return this date as yyyy-mm-dd.hh:mm:ss in a local time zone."""

class Interval:
    def __init__(self, spec):
        """Construct an interval given a specification."""

    def __cmp__(self, other):
        """Compare this interval to another interval."""
        
    def __str__(self):
        """Return this interval as a string."""

Here are some examples of how these classes would behave in practice. For the following examples, assume that we are on Eastern Standard Time and the current local time is 19:34:02 on 25 June 2000. 

>>> Date(".")
<Date 2000-06-26.00:34:02>
>>> _.local(-5)
"2000-06-25.19:34:02"
>>> Date(". + 2d")
<Date 2000-06-28.00:34:02>
>>> Date("1997-04-17", -5)
<Date 1997-04-17.00:00:00>
>>> Date("01-25", -5)
<Date 2000-01-25.00:00:00>
>>> Date("08-13.22:13", -5)
<Date 2000-08-14.03:13:00>
>>> Date("14:25", -5)
<Date 2000-06-25.19:25:00>
>>> Interval("  3w  1  d  2:00")
<Interval 22d 2:00>
>>> Date(". + 2d") - Interval("3w")
<Date 2000-06-07.00:34:02>

3.2. Items and Classes

Items contain data in properties. To Python, these properties are presented as the key-value pairs of a dictionary. Each item belongs to a class which defines the names and types of its properties. The database permits the creation and modification of classes as well as items.

3.3. Identifiers and Designators

Each item has a numeric identifier which is unique among items in its class. The items are numbered sequentially within each class in order of creation, starting from 1. The designator for an item is a way to identify an item in the database, and consists of the name of the item's class concatenated with the item's numeric identifier.

For example, if "spam" and "eggs" are classes, the first item created in class "spam" has id 1 and designator "spam1". The first item created in class "eggs" also has id 1 but has the distinct designator "eggs1". Item designators are conventionally enclosed in square brackets when mentioned in plain text. This permits a casual mention of, say, "[patch37]" in an e-mail message to be turned into an active hyperlink.

3.4. Property Names and Types

Property names must begin with a letter.

A property may be one of five basic types:

  • String properties are for storing arbitrary-length strings.
  • Date properties store date-and-time stamps. Their values are Timestamp objects.
  • A Link property refers to a single other item selected from a specified class. The class is part of the property; the value is an integer, the id of the chosen item.
  • A Multilink property refers to possibly many items in a specified class. The value is a list of integers.

None is also a permitted value for any of these property types. An attempt to store None into a String property stores the empty string; an attempt to store None into a Multilink property stores an empty list.

3.5. Interface Specification

The hyperdb module provides property objects to designate the different kinds of properties. These objects are used when specifying what properties belong in classes. 

class String:
    def __init__(self):
        """An object designating a String property."""

class Date:
    def __init__(self):
        """An object designating a Date property."""

class Link:
    def __init__(self, classname):
        """An object designating a Link property that links to
        items in a specified class."""

class Multilink:
    def __init__(self, classname):
        """An object designating a Multilink property that links
        to items in a specified class."""

Here is the interface provided by the hyperdatabase. 

class Database:
    """A database for storing records containing flexible data types."""

    def __init__(self, storagelocator, journaltag):
        """Open a hyperdatabase given a specifier to some storage.

        The meaning of 'storagelocator' depends on the particular
        implementation of the hyperdatabase.  It could be a file name,
        a directory path, a socket descriptor for a connection to a
        database over the network, etc.

        The 'journaltag' is a token that will be attached to the journal
        entries for any edits done on the database.  If 'journaltag' is
        None, the database is opened in read-only mode: the Class.create(),
        Class.set(), and Class.retire() methods are disabled.
        """

    def __getattr__(self, classname):
        """A convenient way of calling self.getclass(classname)."""

    def getclasses(self):
        """Return a list of the names of all existing classes."""

    def getclass(self, classname):
        """Get the Class object representing a particular class.

        If 'classname' is not a valid class name, a KeyError is raised.
        """

class Class:
    """The handle to a particular class of items in a hyperdatabase."""

    def __init__(self, db, classname, **properties):
        """Create a new class with a given name and property specification.

        'classname' must not collide with the name of an existing class,
        or a ValueError is raised.  The keyword arguments in 'properties'
        must map names to property objects, or a TypeError is raised.
        """

    # Editing items:

    def create(self, **propvalues):
        """Create a new item of this class and return its id.

        The keyword arguments in 'propvalues' map property names to values.
        The values of arguments must be acceptable for the types of their
        corresponding properties or a TypeError is raised.  If this class
        has a key property, it must be present and its value must not
        collide with other key strings or a ValueError is raised.  Any other
        properties on this class that are missing from the 'propvalues'
        dictionary are set to None.  If an id in a link or multilink
        property does not refer to a valid item, an IndexError is raised.
        """

    def get(self, itemid, propname):
        """Get the value of a property on an existing item of this class.

        'itemid' must be the id of an existing item of this class or an
        IndexError is raised.  'propname' must be the name of a property
        of this class or a KeyError is raised.
        """

    def set(self, itemid, **propvalues):
        """Modify a property on an existing item of this class.
        
        'itemid' must be the id of an existing item of this class or an
        IndexError is raised.  Each key in 'propvalues' must be the name
        of a property of this class or a KeyError is raised.  All values
        in 'propvalues' must be acceptable types for their corresponding
        properties or a TypeError is raised.  If the value of the key
        property is set, it must not collide with other key strings or a
        ValueError is raised.  If the value of a Link or Multilink
        property contains an invalid item id, a ValueError is raised.
        """

    def retire(self, itemid):
        """Retire an item.
        
        The properties on the item remain available from the get() method,
        and the item's id is never reused.  Retired items are not returned
        by the find(), list(), or lookup() methods, and other items may
        reuse the values of their key properties.
        """

    def history(self, itemid):
        """Retrieve the journal of edits on a particular item.

        'itemid' must be the id of an existing item of this class or an
        IndexError is raised.

        The returned list contains tuples of the form

            (date, tag, action, params)

        'date' is a Timestamp object specifying the time of the change and
        'tag' is the journaltag specified when the database was opened.
        'action' may be:

            'create' or 'set' -- 'params' is a dictionary of property values
            'link' or 'unlink' -- 'params' is (classname, itemid, propname)
            'retire' -- 'params' is None
        """

    # Locating items:

    def setkey(self, propname):
        """Select a String property of this class to be the key property.

        'propname' must be the name of a String property of this class or
        None, or a TypeError is raised.  The values of the key property on
        all existing items must be unique or a ValueError is raised.
        """

    def getkey(self):
        """Return the name of the key property for this class or None."""

    def lookup(self, keyvalue):
        """Locate a particular item by its key property and return its id.

        If this class has no key property, a TypeError is raised.  If the
        'keyvalue' matches one of the values for the key property among
        the items in this class, the matching item's id is returned;
        otherwise a KeyError is raised.
        """

    def find(self, propname, itemid):
        """Get the ids of items in this class which link to a given item.
        
        'propname' must be the name of a property in this class, or a
        KeyError is raised.  That property must be a Link or Multilink
        property, or a TypeError is raised.  'itemid' must be the id of
        an existing item in the class linked to by the given property,
        or an IndexError is raised.
        """

    def list(self):
        """Return a list of the ids of the active items in this class."""

    def count(self):
        """Get the number of items in this class.

        If the returned integer is 'numitems', the ids of all the items
        in this class run from 1 to numitems, and numitems+1 will be the
        id of the next item to be created in this class.
        """

    # Manipulating properties:

    def getprops(self):
        """Return a dictionary mapping property names to property objects."""

    def addprop(self, **properties):
        """Add properties to this class.

        The keyword arguments in 'properties' must map names to property
        objects, or a TypeError is raised.  None of the keys in 'properties'
        may collide with the names of existing properties, or a ValueError
        is raised before any properties have been added.
        """

3.6. Application Example

Here is an example of how the hyperdatabase module would work in practice. 

>>> import hyperdb
>>> db = hyperdb.Database("foo.db", "ping")
>>> db
<hyperdb.Database "foo.db" opened by "ping">
>>> hyperdb.Class(db, "status", name=hyperdb.String())
<hyperdb.Class "status">
>>> _.setkey("name")
>>> db.status.create(name="unread")
1
>>> db.status.create(name="in-progress")
2
>>> db.status.create(name="testing")
3
>>> db.status.create(name="resolved")
4
>>> db.status.count()
4
>>> db.status.list()
[1, 2, 3, 4]
>>> db.status.lookup("in-progress")
2
>>> db.status.retire(3)
>>> db.status.list()
[1, 2, 4]
>>> hyperdb.Class(db, "issue", title=hyperdb.String(), status=hyperdb.Link("status"))
<hyperdb.Class "issue">
>>> db.issue.create(title="spam", status=1)
1
>>> db.issue.create(title="eggs", status=2)
2
>>> db.issue.create(title="ham", status=4)
3
>>> db.issue.create(title="arguments", status=2)
4
>>> db.issue.create(title="abuse", status=1)
5
>>> hyperdb.Class(db, "user", username=hyperdb.Key(), password=hyperdb.String())
<hyperdb.Class "user">
>>> db.issue.addprop(fixer=hyperdb.Link("user"))
>>> db.issue.getprops()
{"title": <hyperdb.String>, "status": <hyperdb.Link to "status">,
 "user": <hyperdb.Link to "user">}
>>> db.issue.set(5, status=2)
>>> db.issue.get(5, "status")
2
>>> db.status.get(2, "name")
"in-progress"
>>> db.issue.get(5, "title")
"abuse"
>>> db.issue.find("status", db.status.lookup("in-progress"))
[2, 4, 5]
>>> db.issue.history(5)
[(<Date 2000-06-28.19:09:43>, "ping", "create", {"title": "abuse", "status": 1}),
 (<Date 2000-06-28.19:11:04>, "ping", "set", {"status": 2})]
>>> db.status.history(1)
[(<Date 2000-06-28.19:09:43>, "ping", "link", ("issue", 5, "status")),
 (<Date 2000-06-28.19:11:04>, "ping", "unlink", ("issue", 5, "status"))]
>>> db.status.history(2)
[(<Date 2000-06-28.19:11:04>, "ping", "link", ("issue", 5, "status"))]

For the purposes of journalling, when a Multilink property is set to a new list of items, the hyperdatabase compares the old list to the new list. The journal records "unlink" events for all the items that appear in the old list but not the new list, and "link" events for all the items that appear in the new list but not in the old list.

4. Roundup Database

The Roundup database layer is implemented on top of the hyperdatabase and mediates calls to the database. Some of the classes in the Roundup database are considered item classes. The Roundup database layer adds detectors and user items, and on items it provides mail spools, nosy lists, and superseders.

4.1. Reserved Classes

Internal to this layer we reserve three special classes of items that are not items.

4.1.1. Users

Users are stored in the hyperdatabase as items of class "user". The "user" class has the definition: 

hyperdb.Class(db, "user", username=hyperdb.String(),
                          password=hyperdb.String(),
                          address=hyperdb.String())
db.user.setkey("username")

4.1.2. Messages

E-mail messages are represented by hyperdatabase items of class "msg". The actual text content of the messages is stored in separate files. (There's no advantage to be gained by stuffing them into the hyperdatabase, and if messages are stored in ordinary text files, they can be grepped from the command line.) The text of a message is saved in a file named after the message item designator (e.g. "msg23") for the sake of the command interface (see below). Attachments are stored separately and associated with "file" items. The "msg" class has the definition: 

hyperdb.Class(db, "msg", author=hyperdb.Link("user"),
                         recipients=hyperdb.Multilink("user"),
                         date=hyperdb.Date(),
                         summary=hyperdb.String(),
                         files=hyperdb.Multilink("file"))

The "author" property indicates the author of the message (a "user" item must exist in the hyperdatabase for any messages that are stored in the system). The "summary" property contains a summary of the message for display in a message index.

4.1.3. Files

Submitted files are represented by hyperdatabase items of class "file". Like e-mail messages, the file content is stored in files outside the database, named after the file item designator (e.g. "file17"). The "file" class has the definition: 

hyperdb.Class(db, "file", user=hyperdb.Link("user"),
                          name=hyperdb.String(),
                          type=hyperdb.String())

The "user" property indicates the user who submitted the file, the "name" property holds the original name of the file, and the "type" property holds the MIME type of the file as received.

4.2. Item Classes

All items have the following standard properties: 

title=hyperdb.String()
messages=hyperdb.Multilink("msg")
files=hyperdb.Multilink("file")
nosy=hyperdb.Multilink("user")
superseder=hyperdb.Multilink("item")

Also, two Date properties named "creation" and "activity" are fabricated by the Roundup database layer. By "fabricated" we mean that no such properties are actually stored in the hyperdatabase, but when properties on items are requested, the "creation" and "activity" properties are made available. The value of the "creation" property is the date when an item was created, and the value of the "activity" property is the date when any property on the item was last edited (equivalently, these are the dates on the first and last records in the item's journal).

4.3. Interface Specification

The interface to a Roundup database delegates most method calls to the hyperdatabase, except for the following changes and additional methods. 

class Database:
    # Overridden methods:

    def __init__(self, storagelocator, journaltag):
        """When the Roundup database is opened by a particular user,
        the 'journaltag' is the id of the user's "user" item."""

    def getclass(self, classname):
        """This method now returns an instance of either Class or
        ItemClass depending on whether an item class is specified."""

    # New methods:

    def getuid(self):
        """Return the id of the "user" item associated with the user
        that owns this connection to the hyperdatabase."""

class Class:
    # Overridden methods:

    def create(self, **propvalues):
    def set(self, **propvalues):
    def retire(self, itemid):
        """These operations trigger detectors and can be vetoed.  Attempts
        to modify the "creation" or "activity" properties cause a KeyError.
        """

    # New methods:

    def audit(self, event, detector):
    def react(self, event, detector):
        """Register a detector (see below for more details)."""

class ItemClass(Class):
    # Overridden methods:

    def __init__(self, db, classname, **properties):
        """The newly-created class automatically includes the "messages",
        "files", "nosy", and "superseder" properties.  If the 'properties'
        dictionary attempts to specify any of these properties or a
        "creation" or "activity" property, a ValueError is raised."""

    def get(self, itemid, propname):
    def getprops(self):
        """In addition to the actual properties on the item, these
        methods provide the "creation" and "activity" properties."""

    # New methods:

    def addmessage(self, itemid, summary, text):
        """Add a message to an item's mail spool.

        A new "msg" item is constructed using the current date, the
        user that owns the database connection as the author, and
        the specified summary text.  The "files" and "recipients"
        fields are left empty.  The given text is saved as the body
        of the message and the item is appended to the "messages"
        field of the specified item.
        """

    def nosymessage(self, itemid, msgid):
        """Send a message to the members of an item's nosy list.

        The message is sent only to users on the nosy list who are not
        already on the "recipients" list for the message.  These users
        are then added to the message's "recipients" list.
        """

4.4. Default Schema

The default schema included with Roundup turns it into a typical software bug tracker. The database is set up like this: 

pri = Class(db, "priority", name=hyperdb.String(), order=hyperdb.String())
pri.setkey("name")
pri.create(name="critical", order="1")
pri.create(name="urgent", order="2")
pri.create(name="bug", order="3")
pri.create(name="feature", order="4")
pri.create(name="wish", order="5")

stat = Class(db, "status", name=hyperdb.String(), order=hyperdb.String())
stat.setkey("name")
stat.create(name="unread", order="1")
stat.create(name="deferred", order="2")
stat.create(name="chatting", order="3")
stat.create(name="need-eg", order="4")
stat.create(name="in-progress", order="5")
stat.create(name="testing", order="6")
stat.create(name="done-cbb", order="7")
stat.create(name="resolved", order="8")

Class(db, "keyword", name=hyperdb.String())

Class(db, "issue", fixer=hyperdb.Multilink("user"),
                   topic=hyperdb.Multilink("keyword"),
                   priority=hyperdb.Link("priority"),
                   status=hyperdb.Link("status"))

(The "order" property hasn't been explained yet. It gets used by the Web user interface for sorting.)

The above isn't as pretty-looking as the schema specification in the first-stage submission, but it could be made just as easy with the addition of a convenience function like Choice for setting up the "priority" and "status" classes: 

def Choice(name, *options):
    cl = Class(db, name, name=hyperdb.String(), order=hyperdb.String())
    for i in range(len(options)):
        cl.create(name=option[i], order=i)
    return hyperdb.Link(name)

5. Detector Interface

Detectors are Python functions that are triggered on certain kinds of events. The definitions of the functions live in Python modules placed in a directory set aside for this purpose. Importing the Roundup database module also imports all the modules in this directory, and the init() function of each module is called when a database is opened to provide it a chance to register its detectors.

There are two kinds of detectors:

  • an auditor is triggered just before modifying an item
  • a reactor is triggered just after an item has been modified

When the Roundup database is about to perform a create(), set(), or retire() operation, it first calls any auditors that have been registered for that operation on that class. Any auditor may raise a Reject exception to abort the operation.

If none of the auditors raises an exception, the database proceeds to carry out the operation. After it's done, it then calls all of the reactors that have been registered for the operation.

5.1. Interface Specification

The audit() and react() methods register detectors on a given class of items. 

class Class:
    def audit(self, event, detector):
        """Register an auditor on this class.

        'event' should be one of "create", "set", or "retire".
        'detector' should be a function accepting four arguments.
        """

    def react(self, event, detector):
        """Register a reactor on this class.

        'event' should be one of "create", "set", or "retire".
        'detector' should be a function accepting four arguments.
        """

Auditors are called with the arguments: 

audit(db, cl, itemid, newdata)
where db is the database, cl is an instance of Class or ItemClass within the database, and newdata is a dictionary mapping property names to values. For a create() operation, the itemid argument is None and newdata contains all of the initial property values with which the item is about to be created. For a set() operation, newdata contains only the names and values of properties that are about to be changed. For a retire() operation, newdata is None.

Reactors are called with the arguments: 

react(db, cl, itemid, olddata)
where db is the database, cl is an instance of Class or ItemClass within the database, and olddata is a dictionary mapping property names to values. For a create() operation, the itemid argument is the id of the newly-created item and olddata is None. For a set() operation, olddata contains the names and previous values of properties that were changed. For a retire() operation, itemid is the id of the retired item and olddata is None.

5.2. Detector Example

Here is an example of detectors written for a hypothetical project-management application, where users can signal approval of a project by adding themselves to an "approvals" list, and a project proceeds when it has three approvals. 

# Permit users only to add themselves to the "approvals" list.

def check_approvals(db, cl, id, newdata):
    if newdata.has_key("approvals"):
        if cl.get(id, "status") == db.status.lookup("approved"):
            raise Reject, "You can't modify the approvals list " \
                          "for a project that has already been approved."
        old = cl.get(id, "approvals")
        new = newdata["approvals"]
        for uid in old:
            if uid not in new and uid != db.getuid():
                raise Reject, "You can't remove other users from the "
                              "approvals list; you can only remove yourself."
        for uid in new:
            if uid not in old and uid != db.getuid():
                raise Reject, "You can't add other users to the approvals "
                              "list; you can only add yourself."

# When three people have approved a project, change its
# status from "pending" to "approved".

def approve_project(db, cl, id, olddata):
    if olddata.has_key("approvals") and len(cl.get(id, "approvals")) == 3:
        if cl.get(id, "status") == db.status.lookup("pending"):
            cl.set(id, status=db.status.lookup("approved"))

def init(db):
    db.project.audit("set", check_approval)
    db.project.react("set", approve_project)

Here is another example of a detector that can allow or prevent the creation of new items. In this scenario, patches for a software project are submitted by sending in e-mail with an attached file, and we want to ensure that there are text/plain attachments on the message. The maintainer of the package can then apply the patch by setting its status to "applied". 

# Only accept attempts to create new patches that come with patch files.

def check_new_patch(db, cl, id, newdata):
    if not newdata["files"]:
        raise Reject, "You can't submit a new patch without " \
                      "attaching a patch file."
    for fileid in newdata["files"]:
        if db.file.get(fileid, "type") != "text/plain":
            raise Reject, "Submitted patch files must be text/plain."

# When the status is changed from "approved" to "applied", apply the patch.

def apply_patch(db, cl, id, olddata):
    if cl.get(id, "status") == db.status.lookup("applied") and \
        olddata["status"] == db.status.lookup("approved"):
        # ...apply the patch...

def init(db):
    db.patch.audit("create", check_new_patch)
    db.patch.react("set", apply_patch)

6. Command Interface

The command interface is a very simple and minimal interface, intended only for quick searches and checks from the shell prompt. (Anything more interesting can simply be written in Python using the Roundup database module.)

6.1. Interface Specification

A single command, roundup, provides basic access to the hyperdatabase from the command line.

  • roundup get [-list] designator[,designator,...] propname
  • roundup set designator[,designator,...] propname=value ...
  • roundup find [-list] classname propname=value ...

Property values are represented as strings in command arguments and in the printed results:

  • Strings are, well, strings.
  • Date values are printed in the full date format in the local time zone, and accepted in the full format or any of the partial formats explained above.
  • Link values are printed as item designators. When given as an argument, item designators and key strings are both accepted.
  • Multilink values are printed as lists of item designators joined by commas. When given as an argument, item designators and key strings are both accepted; an empty string, a single item, or a list of items joined by commas is accepted.

When multiple items are specified to the roundup get or roundup set commands, the specified properties are retrieved or set on all the listed items.

When multiple results are returned by the roundup get or roundup find commands, they are printed one per line (default) or joined by commas (with the -list) option.

6.2. Usage Example

To find all messages regarding in-progress issues that contain the word "spam", for example, you could execute the following command from the directory where the database dumps its files: 

shell% for issue in `roundup find issue status=in-progress`; do
> grep -l spam `roundup get $issue messages`
> done
msg23
msg49
msg50
msg61
shell%

Or, using the -list option, this can be written as a single command: 

shell% grep -l spam `roundup get \
    \`roundup find -list issue status=in-progress\` messages`
msg23
msg49
msg50
msg61
shell%

7. E-mail User Interface

The Roundup system must be assigned an e-mail address at which to receive mail. Messages should be piped to the Roundup mail-handling script by the mail delivery system (e.g. using an alias beginning with "|" for sendmail).

7.1. Message Processing

Incoming messages are examined for multiple parts. In a multipart/mixed message or part, each subpart is extracted and examined. In a multipart/alternative message or part, we look for a text/plain subpart and ignore the other parts. The text/plain subparts are assembled to form the textual body of the message, to be stored in the file associated with a "msg" class item. Any parts of other types are each stored in separate files and given "file" class items that are linked to the "msg" item.

The "summary" property on message items is taken from the first non-quoting section in the message body. The message body is divided into sections by blank lines. Sections where the second and all subsequent lines begin with a ">" or "|" character are considered "quoting sections". The first line of the first non-quoting section becomes the summary of the message.

All of the addresses in the To: and Cc: headers of the incoming message are looked up among the user items, and the corresponding users are placed in the "recipients" property on the new "msg" item. The address in the From: header similarly determines the "author" property of the new "msg" item. The default handling for addresses that don't have corresponding users is to create new users with no passwords and a username equal to the address. (The web interface does not permit logins for users with no passwords.) If we prefer to reject mail from outside sources, we can simply register an auditor on the "user" class that prevents the creation of user items with no passwords.

The subject line of the incoming message is examined to determine whether the message is an attempt to create a new item or to discuss an existing item. A designator enclosed in square brackets is sought as the first thing on the subject line (after skipping any "Fwd:" or "Re:" prefixes).

If an item designator (class name and id number) is found there, the newly created "msg" item is added to the "messages" property for that item, and any new "file" items are added to the "files" property for the item.

If just an item class name is found there, we attempt to create a new item of that class with its "messages" property initialized to contain the new "msg" item and its "files" property initialized to contain any new "file" items.

Both cases may trigger detectors (in the first case we are calling the set() method to add the message to the item's spool; in the second case we are calling the create() method to create a new item). If an auditor raises an exception, the original message is bounced back to the sender with the explanatory message given in the exception.

7.2. Nosy Lists

A standard detector is provided that watches for additions to the "messages" property. When a new message is added, the detector sends it to all the users on the "nosy" list for the item that are not already on the "recipients" list of the message. Those users are then appended to the "recipients" property on the message, so multiple copies of a message are never sent to the same user. The journal recorded by the hyperdatabase on the "recipients" property then provides a log of when the message was sent to whom.

7.3. Setting Properties

The e-mail interface also provides a simple way to set properties on items. At the end of the subject line, propname=value pairs can be specified in square brackets, using the same conventions as for the roundup set shell command.

8. Web User Interface

The web interface is provided by a CGI script that can be run under any web server. A simple web server can easily be built on the standard CGIHTTPServer module, and should also be included in the distribution for quick out-of-the-box deployment.

The user interface is constructed from a number of template files containing mostly HTML. Among the HTML tags in templates are interspersed some nonstandard tags, which we use as placeholders to be replaced by properties and their values.

8.1. Views and View Specifiers

There are two main kinds of views: index views and item views. An index view displays a list of items of a particular class, optionally sorted and filtered as requested. An item view presents the properties of a particular item for editing and displays the message spool for the item.

A view specifier is a string that specifies all the options needed to construct a particular view. It goes after the URL to the Roundup CGI script or the web server to form the complete URL to a view. When the result of selecting a link or submitting a form takes the user to a new view, the Web browser should be redirected to a canonical location containing a complete view specifier so that the view can be bookmarked.

8.2. Displaying Properties

Properties appear in the user interface in three contexts: in indices, in editors, and as filters. For each type of property, there are several display possibilities. For example, in an index view, a string property may just be printed as a plain string, but in an editor view, that property should be displayed in an editable field.

The display of a property is handled by functions in a displayers module. Each function accepts at least three standard arguments -- the database, class name, and item id -- and returns a chunk of HTML.

Displayer functions are triggered by <display> tags in templates. The call attribute of the tag provides a Python expression for calling the displayer function. The three standard arguments are inserted in front of the arguments given. For example, the occurrence of 

    <display call="plain('status', max=30)">
in a template triggers a call to 
    plain(db, "issue", 13, "status", max=30)
when displaying item 13 in the "issue" class. The displayer functions can accept extra arguments to further specify details about the widgets that should be generated. By defining new displayer functions, the user interface can be highly customized.

Some of the standard displayer functions include:

  • plain: display a String property directly; display a Date property in a specified time zone with an option to omit the time from the date stamp; for a Link or Multilink property, display the key strings of the linked items (or the ids if the linked class has no key property)
  • field: display a property like the plain displayer above, but in a text field to be edited
  • menu: for a Link property, display a menu of the available choices
  • link: for a Link or Multilink property, display the names of the linked items, hyperlinked to the item views on those items
  • count: for a Multilink property, display a count of the number of links in the list
  • reldate: display a Date property in terms of an interval relative to the current date (e.g. "+ 3w", "- 2d").
  • download: show a Link("file") or Multilink("file") property using links that allow you to download files
  • checklist: for a Link or Multilink property, display checkboxes for the available choices to permit filtering

8.3. Index Views

An index view contains two sections: a filter section and an index section. The filter section provides some widgets for selecting which items appear in the index. The index section is a table of items.

8.3.1. Index View Specifiers

An index view specifier looks like this (whitespace has been added for clarity): 

/issue?status=unread,in-progress,resolved&
        topic=security,ui&
        :group=+priority&
        :sort=-activity&
        :filters=status,topic&
        :columns=title,status,fixer

The index view is determined by two parts of the specifier: the layout part and the filter part. The layout part consists of the query parameters that begin with colons, and it determines the way that the properties of selected items are displayed. The filter part consists of all the other query parameters, and it determines the criteria by which items are selected for display.

The filter part is interactively manipulated with the form widgets displayed in the filter section. The layout part is interactively manipulated by clicking on the column headings in the table.

The filter part selects the union of the sets of items with values matching any specified Link properties and the intersection of the sets of items with values matching any specified Multilink properties.

The example specifies an index of "issue" items. Only items with a "status" of either "unread" or "in-progres" or "resolved" are displayed, and only items with "topic" values including both "security" and "ui" are displayed. The items are grouped by priority, arranged in ascending order; and within groups, sorted by activity, arranged in descending order. The filter section shows filters for the "status" and "topic" properties, and the table includes columns for the "title", "status", and "fixer" properties.

Associated with each item class is a default layout specifier. The layout specifier in the above example is the default layout to be provided with the default bug-tracker schema described above in section 4.4.

8.3.2. Filter Section

The template for a filter section provides the filtering widgets at the top of the index view. Fragments enclosed in <property>...</property> tags are included or omitted depending on whether the view specifier requests a filter for a particular property.

Here's a simple example of a filter template. 

<property name=status>
    <display call="checklist('status')">
</property>
<br>
<property name=priority>
    <display call="checklist('priority')">
</property>
<br>
<property name=fixer>
    <display call="menu('fixer')">
</property>

8.3.3. Index Section

The template for an index section describes one row of the index table. Fragments enclosed in <property>...</property> tags are included or omitted depending on whether the view specifier requests a column for a particular property. The table cells should contain <display> tags to display the values of the item's properties.

Here's a simple example of an index template. 

<tr>
    <property name=title>
        <td><display call="plain('title', max=50)"></td>
    </property>
    <property name=status>
        <td><display call="plain('status')"></td>
    </property>
    <property name=fixer>
        <td><display call="plain('fixer')"></td>
    </property>
</tr>

8.3.4. Sorting

String and Date values are sorted in the natural way. Link properties are sorted according to the value of the "order" property on the linked items if it is present; or otherwise on the key string of the linked items; or finally on the item ids. Multilink properties are sorted according to how many links are present.

8.4. Item Views

An item view contains an editor section and a spool section. At the top of an item view, links to superseding and superseded items are always displayed.

8.4.1. Item View Specifiers

An item view specifier is simply the item's designator: 

/patch23

8.4.2. Editor Section

The editor section is generated from a template containing <display> tags to insert the appropriate widgets for editing properties.

Here's an example of a basic editor template. 

<table>
<tr>
    <td colspan=2>
        <display call="field('title', size=60)">
    </td>
</tr>
<tr>
    <td>
        <display call="field('fixer', size=30)">
    </td>
    <td>
        <display call="menu('status')>
    </td>
</tr>
<tr>
    <td>
        <display call="field('nosy', size=30)">
    </td>
    <td>
        <display call="menu('priority')>
    </td>
</tr>
<tr>
    <td colspan=2>
        <display call="note()">
    </td>
</tr>
</table>

As shown in the example, the editor template can also request the display of a "note" field, which is a text area for entering a note to go along with a change.

When a change is submitted, the system automatically generates a message describing the changed properties. The message displays all of the property values on the item and indicates which ones have changed. An example of such a message might be this: 

title: Polly Parrot is dead
priority: critical
status: unread -> in-progress
fixer: (none)
keywords: parrot,plumage,perch,nailed,dead

If a note is given in the "note" field, the note is appended to the description. The message is then added to the item's message spool (thus triggering the standard detector to react by sending out this message to the nosy list).

8.4.3. Spool Section

The spool section lists messages in the item's "messages" property. The index of messages displays the "date", "author", and "summary" properties on the message items, and selecting a message takes you to its content.

9. Deployment Scenarios

The design described above should be general enough to permit the use of Roundup for bug tracking, managing projects, managing patches, or holding discussions. By using items of multiple types, one could deploy a system that maintains requirement specifications, catalogs bugs, and manages submitted patches, where patches could be linked to the bugs and requirements they address.

10. Acknowledgements

My thanks are due to Christy Heyl for reviewing and contributing suggestions to this paper and motivating me to get it done, and to Jesse Vincent, Mark Miller, Christopher Simons, Jeff Dunmall, Wayne Gramlich, and Dean Tribble for their assistance with the first-round submission.

   [Home]       [FAQ]       [License]       [Rules]       [Configure]       [Build]       [Test]       [Track]       [Resources]       [Archives]   

Last modified 2001/04/06 11:50:59.9063 US/Mountain
code-0e2a0c2c8142/doc/tracker_templates.txt0000644000000000000000000000303310062724152016647 0ustar 00000000000000========================= Roundup Tracker Templates ========================= :Version: $Revision: 1.1 $ The templates distributed with Roundup are stored in the "share" directory nominated by Python. On Unix this is typically ``/usr/share/roundup/templates/`` (or ``/usr/local/share...``) and on Windows this is ``c:\python22\share\roundup\templates\``. The template loading looks in four places to find the templates: 1. *share* - eg. ``/share/roundup/templates/*``. This should be the standard place to find them when Roundup is installed. 2. ``/../templates/*``. This will be used if Roundup's run in the distro (aka. source) directory. 3. ``/*``. This is for when someone unpacks a 3rd-party template. 4. ````. This is for someone who "cd"s to the 3rd-party template dir. Templates contain: - modules __init__.py, dbinit.py, config.py, interfaces.py - directories html and detectors (with appropriate contents) - TEMPLATE-INFO.txt which is our template "marker" file, which contains the name of the template, a description of the template and its intended audience. An example TEMPLATE-INFO.txt:: Name: classic Description: This is a generic issue tracker that may be used to track bugs, feature requests, project issues or any number of other types of issues. Most users of Roundup will find that this template suits them, with perhaps a few customisations. Intended-For: All first-time Roundup users code-0e2a0c2c8142/doc/upgrading.txt0000644000000000000000000011170610062724152015125 0ustar 00000000000000====================================== Upgrading to newer versions of Roundup ====================================== Please read each section carefully and edit your tracker home files accordingly. Note that there is information about upgrade procedures in the `administration guide`_. If a specific version transition isn't mentioned here (eg. 0.6.7 to 0.6.8) then you don't need to do anything. If you're upgrading from 0.5.6 to 0.6.8 though, you'll need to check the "0.5 to 0.6" and "0.6.x to 0.6.3" steps. .. contents:: Migrating from 0.7.1 to 0.8.0 ============================= 0.8.0 8-bit character set support --------------------------------- Added support for custom encodings in http data. Inside Roundup, all strings are stored and processed in utf-8. Unfortunately, some older browsers do not work properly with utf8-encoded pages (e.g. Netscape Navigator 4 displays wrong characters in form fields). This version allows to change the character set for http transfers. To do so, you may add the following code to your ``page.html`` template:: (substitute ``koi8-r`` with appropriate charset for your language). Charset preference is kept in the browser cookie ``roundup_charset``. Lines ``meta http-equiv`` added to the tracker templates in version 0.6.0 are misleading and should be removed. Actual charset is sent in the true http header. Migrating from 0.7.2 to 0.7.3 ============================= 0.7.3 Configuration ------------------- If you choose, you may specify the directory from which static files are served (those which use the URL component ``@@file``). Currently the directory defaults to the ``TEMPLATES`` configuration variable. You may define a new variable, ``STATIC_FILES`` which overrides this value for static files. Migrating from 0.7.0 to 0.7.2 ============================= 0.7.2 DEFAULT_TIMEZONE is now required -------------------------------------- The DEFAULT_TIMEZONE configuration variable is now required. Add the following to your tracker's ``config.py`` file:: # You may specify a different default timezone, for use when users do not # choose their own in their settings. DEFAULT_TIMEZONE = 0 # specify as numeric hour offest Migrating from 0.7.0 to 0.7.1 ============================= 0.7.1 Permission assignments ---------------------------- If you allow anonymous access to your tracker, you might need to assign some additional View (or Edit if your tracker is that open) permissions to the "anonymous" user. To do so, find the code in your ``dbinit.py`` that says:: for cl in 'issue', 'file', 'msg', 'query', 'keyword': p = db.security.getPermission('View', cl) db.security.addPermissionToRole('User', p) p = db.security.getPermission('Edit', cl) db.security.addPermissionToRole('User', p) for cl in 'priority', 'status': p = db.security.getPermission('View', cl) db.security.addPermissionToRole('User', p) Add add a line:: db.security.addPermissionToRole('Anonymous', p) next to the existing ``'User'`` lines for the Permissions you wish to assign to the anonymous user. Migrating from 0.6 to 0.7 ========================= 0.7.0 Permission assignments ---------------------------- Due to a change in the rendering of web widgets, permissions are now checked on Classes where they previously weren't (this is a good thing). You will need to add some additional Permission assignments for your regular users, or some displays will break. After the following in your tracker's ``dbinit.py``:: # Assign the access and edit Permissions for issue, file and message # to regular users now for cl in 'issue', 'file', 'msg', 'query', 'keyword': p = db.security.getPermission('View', cl) db.security.addPermissionToRole('User', p) p = db.security.getPermission('Edit', cl) db.security.addPermissionToRole('User', p) add:: for cl in 'priority', 'status': p = db.security.getPermission('View', cl) db.security.addPermissionToRole('User', p) 0.7.0 Getting the current user id --------------------------------- The Database.curuserid attribute has been removed. Any code referencing this attribute should be replaced with a call to Database.getuid(). 0.7.0 ZRoundup changes ---------------------- The templates in your tracker's html directory will need updating if you wish to use ZRoundup. If you've not modified those files (or some of them), you may just copy the new versions from the Roundup source in the templates/classic/html directory. If you have modified the html files, then you'll need to manually edit them to change all occurances of special form variables from using the colon ":" special character to the at "@" special character. That is, variables such as:: :action :required :template :remove:messages ... should become:: @action @required @template @remove@messages ... Note that ``tal:`` statements are unaffected. So are TAL expression type prefixes such as ``python:`` and ``string:``. Please ask on the roundup-users mailing list for help if you're unsure. Migrating from 0.6.x to 0.6.3 ============================= 0.6.3 Configuration ------------------- You will need to copy the file:: templates/classic/detectors/__init__.py to your tracker's ``detectors`` directory, replacing the one already there. This fixes a couple of bugs in that file. Migrating from 0.5 to 0.6 ========================= 0.6.0 Configuration ------------------- Introduced EMAIL_FROM_TAG config variable. This value is inserted into the From: line of nosy email. If the sending user is "Foo Bar", the From: line is usually:: "Foo Bar" the EMAIL_FROM_TAG goes inside the "Foo Bar" quotes like so:: "Foo Bar EMAIL_FROM_TAG" I've altered the mechanism in the detectors __init__.py module so that it doesn't cross-import detectors from other trackers (if you run more than one in a single roundup-server). This change means that you'll need to copy the __init__.py from roundup/templates/classic/detectors/__init__.py to your /detectors/__init__.py. Don't worry, the "classic" __init__ is a one-size-fits-all, so it'll work even if you've added/removed detectors. 0.6.0 Templating changes ------------------------ The ``user.item`` template (in the tracker home "templates" directory) needs to have the following hidden variable added to its form (between the ```` and ```` tags:: 0.6.0 Form handling changes --------------------------- Roundup's form handling capabilities have been significantly expanded. This should not affect users of 0.5 installations - but if you find you're getting errors from form submissions, please ask for help on the Roundup users mailing list: http://lists.sourceforge.net/lists/listinfo/roundup-users See the customisation doc section on `Form Values`__ for documentation of the new form variables possible. __ customizing.html#form-values 0.6.0 Multilingual character set support ---------------------------------------- Added internationalization support. This is done via encoding all data stored in roundup database to utf-8 (unicode encoding). To support utf-8 in web interface you should add the folowing line to your tracker's html/page and html/_generic.help files inside tag:: Since latin characters in utf-8 have the same codes as in ASCII table, this modification is optional for users who use only plain latin characters. After this modification, you will be able to see and enter any world character via web interface. Data received via mail interface also converted to utf-8, however only new messages will be converted. If your roundup database contains some of non-ASCII characters in one of 8-bit encoding, they will not be visible in new unicode environment. Some of such data (e.g. user names, keywords, etc) can be edited by administrator, the others (e.g. messages' contents) is not editable via web interface. Currently there is no tool for converting such data, the only solution is to close appropriate old issues and create new ones with the same content. 0.6.0 User timezone support --------------------------- From version 0.6.0 roundup supports displaying of Date data in user' local timezone if he/she has provided timezone information. To make it possible some modification to tracker's schema and HTML templates are required. First you must add string property 'timezone' to user class in dbinit.py like this:: user = Class(db, "user", username=String(), password=Password(), address=String(), realname=String(), phone=String(), organisation=String(), alternate_addresses=String(), queries=Multilink('query'), roles=String(), timezone=String()) And second - html interface. Add following lines to $TRACKER_HOME/html/user.item template:: Timezone timezone After that all users should be able to provide their timezone information. Timezone should be a positive or negative integer - offset from GMT. After providing timezone, roundup will show all dates values, found in web and mail interfaces in local time. It will also accept any Date info in local time, convert and store it in GMT. 0.6.0 Search page structure --------------------------- In order to accomodate query editing the search page has been restructured. If you want to provide your users with query editing, you should update your search page using the macros detailed in the customisation doc section `Searching on categories`__. __ customizing.html#searching-on-categories Also, the url field in the query class no longer starts with a '?'. You'll need to remove this question mark from the url field to support queries. There's a script in the "tools" directory called ``migrate-queries.py`` that should automatically change any existing queries for you. As always, make a backup of your database before running such a script. 0.6.0 Notes for metakit backend users ------------------------------------- Roundup 0.6.0 introduced searching on ranges of dates and intervals. To support it, some modifications to interval storing routine were made. So if your tracker uses metakit backend and your db schema contains intervals property, searches on that property will not be accurate for db items that was stored before roundup' upgrade. However all new records should be searchable on intervals. It is possible to convert your database to new format: you can export and import back all your data (consult "Migrating backends" in "Maintenance" documentation). After this operation all your interval properties should become searchable. Users of backends others than metakit should not worry about this issue. Migrating from 0.4.x to 0.5.0 ============================= This has been a fairly major revision of Roundup: 1. Brand new, much more powerful, flexible, tasty and nutritious templating. Unfortunately, this means all your current templates are useless. Hopefully the new documentation and examples will be enough to help you make the transition. Please don't hesitate to ask on roundup-users for help (or complete conversions if you're completely stuck)! 2. The database backed got a lot more flexible, allowing Metakit and SQL databases! The only decent SQL database implemented at present is sqlite, but others shouldn't be a whole lot more work. 3. A brand new, highly flexible and much more robust security system including a system of Permissions, Roles and Role assignments to users. You may now define your own Permissions that may be checked in CGI transactions. 4. Journalling has been made less storage-hungry, so has been turned on by default *except* for author, recipient and nosy link/unlink events. You are advised to turn it off in your trackers too. 5. We've changed the terminology from "instance" to "tracker", to ease the learning curve/impact for new users. 6. Because of the above changes, the tracker configuration has seen some major changes. See below for the details. Please, **back up your database** before you start the migration process. This is as simple as copying the "db" directory and all its contents from your tracker to somewhere safe. 0.5.0 Configuration ------------------- First up, rename your ``instance_config.py`` file to just ``config.py``. Then edit your tracker's ``__init__.py`` module. It'll currently look like this:: from instance_config import * try: from dbinit import * except ImportError: pass # in installdir (probably :) from interfaces import * and it needs to be:: import config from dbinit import open, init from interfaces import Client, MailGW Due to the new templating having a top-level ``page`` that defines links for searching, indexes, adding items etc, the following variables are no longer used: - HEADER_INDEX_LINKS - HEADER_ADD_LINKS - HEADER_SEARCH_LINKS - SEARCH_FILTERS - DEFAULT_INDEX - UNASSIGNED_INDEX - USER_INDEX - ISSUE_FILTER The new security implementation will require additions to the dbinit module, but also removes the need for the following tracker config variables: - ANONYMOUS_ACCESS - ANONYMOUS_REGISTER but requires two new variables which define the Roles assigned to users who register through the web and e-mail interfaces: - NEW_WEB_USER_ROLES - NEW_EMAIL_USER_ROLES in both cases, 'User' is a good initial setting. To emulate ``ANONYMOUS_ACCESS='deny'``, remove all "View" Permissions from the "Anonymous" Role. To emulate ``ANONYMOUS_REGISTER='deny'``, remove the "Web Registration" and/or the "Email Registration" Permission from the "Anonymous" Role. See the section on customising security in the `customisation documentation`_ for more information. Finally, the following config variables have been renamed to make more sense: - INSTANCE_HOME -> TRACKER_HOME - INSTANCE_NAME -> TRACKER_NAME - ISSUE_TRACKER_WEB -> TRACKER_WEB - ISSUE_TRACKER_EMAIL -> TRACKER_EMAIL 0.5.0 Schema Specification -------------------------- 0.5.0 Database backend changes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Your select_db module in your tracker has changed a fair bit. Where it used to contain:: # WARNING: DO NOT EDIT THIS FILE!!! from roundup.backends.back_anydbm import Database it must now contain:: # WARNING: DO NOT EDIT THIS FILE!!! from roundup.backends.back_anydbm import Database, Class, FileClass, IssueClass Yes, I realise the irony of the "DO NOT EDIT THIS FILE" statement :) Note the addition of the Class, FileClass, IssueClass imports. These are very important, as they're going to make the next change work too. You now need to modify the top of the dbinit module in your tracker from:: import instance_config from roundup import roundupdb from select_db import Database from roundup.roundupdb import Class, FileClass class Database(roundupdb.Database, select_db.Database): ''' Creates a hybrid database from: . the selected database back-end from select_db . the roundup extensions from roundupdb ''' pass class IssueClass(roundupdb.IssueClass): ''' issues need the email information ''' pass to:: import config from select_db import Database, Class, FileClass, IssueClass Yes, remove the Database and IssueClass definitions and those other imports. They're not needed any more! Look for places in dbinit.py where ``instance_config`` is used too, and rename them ``config``. 0.5.0 Journalling changes ~~~~~~~~~~~~~~~~~~~~~~~~~ Journalling has been optimised for storage. Journalling of links has been turned back on by default. If your tracker has a large user base, you may wish to turn off journalling of nosy list, message author and message recipient link and unlink events. You do this by adding ``do_journal='no'`` to the Class initialisation in your dbinit. For example, your *msg* class initialisation probably looks like this:: msg = FileClass(db, "msg", author=Link("user"), recipients=Multilink("user"), date=Date(), summary=String(), files=Multilink("file"), messageid=String(), inreplyto=String()) to turn off journalling of author and recipient link events, add ``do_journal='no'`` to the ``author=Link("user")`` part of the statement, like so:: msg = FileClass(db, "msg", author=Link("user", do_journal='no'), recipients=Multilink("user", do_journal='no'), date=Date(), summary=String(), files=Multilink("file"), messageid=String(), inreplyto=String()) Nosy list link event journalling is actually turned off by default now. If you want to turn it on, change to your issue class' nosy list, change its definition from:: issue = IssueClass(db, "issue", assignedto=Link("user"), topic=Multilink("keyword"), priority=Link("priority"), status=Link("status")) to:: issue = IssueClass(db, "issue", nosy=Multilink("user", do_journal='yes'), assignedto=Link("user"), topic=Multilink("keyword"), priority=Link("priority"), status=Link("status")) noting that your definition of the nosy Multilink will override the normal one. 0.5.0 User schema changes ~~~~~~~~~~~~~~~~~~~~~~~~~ Users have two more properties, "queries" and "roles". You'll have something like this in your dbinit module now:: user = Class(db, "user", username=String(), password=Password(), address=String(), realname=String(), phone=String(), organisation=String(), alternate_addresses=String()) user.setkey("username") and you'll need to add the new properties and the new "query" class to it like so:: query = Class(db, "query", klass=String(), name=String(), url=String()) query.setkey("name") # Note: roles is a comma-separated string of Role names user = Class(db, "user", username=String(), password=Password(), address=String(), realname=String(), phone=String(), organisation=String(), alternate_addresses=String(), queries=Multilink('query'), roles=String()) user.setkey("username") The "queries" property is used to store off the user's favourite database queries. The "roles" property is explained below in `0.5.0 Security Settings`_. 0.5.0 Security Settings ~~~~~~~~~~~~~~~~~~~~~~~ See the `security documentation`_ for an explanation of how the new security system works. In a nutshell though, the security is handled as a four step process: 1. Permissions are defined as having a name and optionally a hyperdb class they're specific to, 2. Roles are defined that have one or more Permissions, 3. Users are assigned Roles in their "roles" property, and finally 4. Roundup checks that users have appropriate Permissions at appropriate times (like editing issues). Your tracker dbinit module's *open* function now has to define any Permissions that are specific to your tracker, and also the assignment of Permissions to Roles. At the moment, your open function ends with:: import detectors detectors.init(db) return db and what we need to do is insert some commands that will set up the security parameters. Right above the ``import detectors`` line, you'll want to insert these lines:: # # SECURITY SETTINGS # # new permissions for this schema for cl in 'issue', 'file', 'msg', 'user': db.security.addPermission(name="Edit", klass=cl, description="User is allowed to edit "+cl) db.security.addPermission(name="View", klass=cl, description="User is allowed to access "+cl) # Assign the access and edit permissions for issue, file and message # to regular users now for cl in 'issue', 'file', 'msg': p = db.security.getPermission('View', cl) db.security.addPermissionToRole('User', p) p = db.security.getPermission('Edit', cl) db.security.addPermissionToRole('User', p) # and give the regular users access to the web and email interface p = db.security.getPermission('Web Access') db.security.addPermissionToRole('User', p) p = db.security.getPermission('Email Access') db.security.addPermissionToRole('User', p) # May users view other user information? Comment these lines out # if you don't want them to p = db.security.getPermission('View', 'user') db.security.addPermissionToRole('User', p) # Assign the appropriate permissions to the anonymous user's Anonymous # Role. Choices here are: # - Allow anonymous users to register through the web p = db.security.getPermission('Web Registration') db.security.addPermissionToRole('Anonymous', p) # - Allow anonymous (new) users to register through the email gateway p = db.security.getPermission('Email Registration') db.security.addPermissionToRole('Anonymous', p) # - Allow anonymous users access to the "issue" class of data # Note: this also grants access to related information like files, # messages, statuses etc that are linked to issues #p = db.security.getPermission('View', 'issue') #db.security.addPermissionToRole('Anonymous', p) # - Allow anonymous users access to edit the "issue" class of data # Note: this also grants access to create related information like # files and messages etc that are linked to issues #p = db.security.getPermission('Edit', 'issue') #db.security.addPermissionToRole('Anonymous', p) # oh, g'wan, let anonymous access the web interface too p = db.security.getPermission('Web Access') db.security.addPermissionToRole('Anonymous', p) Note in the comments there the places where you might change the permissions to restrict users or grant users more access. If you've created additional classes that users should be able to edit and view, then you should add them to the "new permissions for this schema" section at the start of the security block. Then add them to the "Assign the access and edit permissions" section too, so people actually have the new Permission you've created. One final change is needed that finishes off the security system's initialisation. We need to add a call to ``db.post_init()`` at the end of the dbinit open() function. Add it like this:: import detectors detectors.init(db) # schema is set up - run any post-initialisation db.post_init() return db You may verify the setup of Permissions and Roles using the new "``roundup-admin security``" command. 0.5.0 User changes ~~~~~~~~~~~~~~~~~~ To support all those schema changes, you'll need to massage your user database a little too, to: 1. make sure there's an "anonymous" user - this user is mandatory now and is the one that unknown users are logged in as. 2. make sure all users have at least one Role. If you don't have the "anonymous" user, create it now with the command:: roundup-admin create user username=anonymous roles=Anonymous making sure the capitalisation is the same as above. Once you've done that, you'll need to set the roles property on all users to a reasonable default. The admin user should get "Admin", the anonymous user "Anonymous" and all other users "User". The ``fixroles.py`` script in the tools directory will do this. Run it like so (where python is your python 2+ binary):: python tools/fixroles.py -i fixroles 0.5.0 CGI interface changes --------------------------- The CGI interface code was completely reorganised and largely rewritten. The end result is that this section of your tracker interfaces module will need changing from:: from roundup import cgi_client, mailgw from roundup.i18n import _ class Client(cgi_client.Client): ''' derives basic CGI implementation from the standard module, with any specific extensions ''' pass to:: from roundup import mailgw from roundup.cgi import client class Client(client.Client): ''' derives basic CGI implementation from the standard module, with any specific extensions ''' pass You will also need to install the new version of roundup.cgi from the source cgi-bin directory if you're using it. 0.5.0 HTML templating --------------------- You'll want to make a backup of your current tracker html directory. You should then copy the html directory from the Roundup source "classic" template and modify it according to your local schema changes. If you need help with the new templating system, please ask questions on the roundup-users mailing list (available through the roundup project page on sourceforge, http://roundup.sf.net/) 0.5.0 Detectors --------------- The nosy reactor has been updated to handle the tracker not having an "assignedto" property on issues. You may want to copy it into your tracker's detectors directory. Chances are you've already fixed it though :) Migrating from 0.4.1 to 0.4.2 ============================= 0.4.2 Configuration ------------------- The USER_INDEX definition introduced in 0.4.1 was too restrictive in its allowing replacement of 'assignedto' with the user's userid. Users must change the None value of 'assignedto' to 'CURRENT USER' (the string, in quotes) for the replacement behaviour to occur now. The new configuration variables are: - EMAIL_KEEP_QUOTED_TEXT - EMAIL_LEAVE_BODY_UNCHANGED - ADD_RECIPIENTS_TO_NOSY See the sample configuration files in:: /roundup/templates/classic/instance_config.py and:: /roundup/templates/extended/instance_config.py and the `customisation documentation`_ for information on how they're used. 0.4.2 Changes to detectors -------------------------- You will need to copy the detectors from the distribution into your instance home "detectors" directory. If you used the classic schema, the detectors are in:: /roundup/templates/classic/detectors/ If you used the extended schema, the detectors are in:: /roundup/templates/extended/detectors/ The change means that schema-specific code has been removed from the mail gateway and cgi interface and made into auditors: - nosyreactor.py has now got an updatenosy auditor which updates the nosy list with author, recipient and assignedto information. - statusauditor.py makes the unread or resolved -> chatting changes and presets the status of an issue to unread. There's also a bug or two fixed in the nosyreactor code. 0.4.2 HTML templating changes ----------------------------- The link() htmltemplate function now has a "showid" option for links and multilinks. When true, it only displays the linked item id as the anchor text. The link value is displayed as a tooltip using the title anchor attribute. To use in eg. the superseder field, have something like this::
View: The stylesheets have been cleaned up too. You may want to use the newer versions in:: /roundup/templates/