1 ===================
2 Customising Roundup
3 ===================
5 :Version: $Revision: 1.22 $
7 .. This document borrows from the ZopeBook section on ZPT. The original is at:
8 http://www.zope.org/Documentation/Books/ZopeBook/current/ZPT.stx
10 .. contents::
13 What You Can Do
14 ---------------
16 Customisation of Roundup can take one of five forms:
18 1. `instance configuration`_ file changes
19 2. database, or `instance schema`_ changes
20 3. "definition" class `database content`_ changes
21 4. behavioural changes, through detectors_
22 5. `access controls`_
24 The third case is special because it takes two distinctly different forms
25 depending upon whether the instance has been initialised or not. The other two
26 may be done at any time, before or after instance initialisation. Yes, this
27 includes adding or removing properties from classes.
30 Instances in a Nutshell
31 -----------------------
33 Instances have the following structure:
35 +-------------------+--------------------------------------------------------+
36 |instance_config.py |Holds the basic instance_configuration |
37 +-------------------+--------------------------------------------------------+
38 |dbinit.py |Holds the instance_schema |
39 +-------------------+--------------------------------------------------------+
40 |interfaces.py |Defines the Web and E-Mail interfaces for the instance |
41 +-------------------+--------------------------------------------------------+
42 |select_db.py |Selects the database back-end for the instance |
43 +-------------------+--------------------------------------------------------+
44 |db/ |Holds the instance's database |
45 +-------------------+--------------------------------------------------------+
46 |db/files/ |Holds the instance's upload files and messages |
47 +-------------------+--------------------------------------------------------+
48 |detectors/ |Auditors and reactors for this instance |
49 +-------------------+--------------------------------------------------------+
50 |html/ |Web interface templates, images and style sheets |
51 +-------------------+--------------------------------------------------------+
53 Instance Configuration
54 ----------------------
56 The instance_config.py located in your instance home contains the basic
57 configuration for the web and e-mail components of roundup's interfaces. This
58 file is a Python module. The configuration variables available are:
60 **INSTANCE_HOME** - ``os.path.split(__file__)[0]``
61 The instance home directory. The above default code will automatically
62 determine the instance home for you.
64 **MAILHOST** - ``'localhost'``
65 The SMTP mail host that roundup will use to send e-mail.
67 **MAIL_DOMAIN** - ``'your.tracker.email.domain.example'``
68 The domain name used for email addresses.
70 **DATABASE** - ``os.path.join(INSTANCE_HOME, 'db')``
71 This is the directory that the database is going to be stored in. By default
72 it is in the instance home.
74 **TEMPLATES** - ``os.path.join(INSTANCE_HOME, 'html')``
75 This is the directory that the HTML templates reside in. By default they are
76 in the instance home.
78 **INSTANCE_NAME** - ``'Roundup issue tracker'``
79 A descriptive name for your roundup instance. This is sent out in e-mails and
80 appears in the heading of CGI pages.
82 **ISSUE_TRACKER_EMAIL** - ``'issue_tracker@%s'%MAIL_DOMAIN``
83 The email address that e-mail sent to roundup should go to. Think of it as the
84 instance's personal e-mail address.
86 **ISSUE_TRACKER_WEB** - ``'http://your.tracker.url.example/'``
87 The web address that the instance is viewable at. This will be included in
88 information sent to users of the tracker.
90 **ADMIN_EMAIL** - ``'roundup-admin@%s'%MAIL_DOMAIN``
91 The email address that roundup will complain to if it runs into trouble.
93 **FILTER_POSITION** - ``'top'``, ``'bottom'`` or ``'top and bottom'``
94 Where to place the web filtering HTML on the index page.
96 **ANONYMOUS_ACCESS** - ``'deny'`` or ``'allow'``
97 Deny or allow anonymous access to the web interface.
99 **ANONYMOUS_REGISTER** - ``'deny'`` or ``'allow'``
100 Deny or allow anonymous users to register through the web interface.
102 **ANONYMOUS_REGISTER_MAIL** - ``'deny'`` or ``'allow'``
103 Deny or allow anonymous users to register through the mail interface.
105 **MESSAGES_TO_AUTHOR** - ``'yes'`` or``'no'``
106 Send nosy messages to the author of the message.
108 **ADD_AUTHOR_TO_NOSY** - ``'new'``, ``'yes'`` or ``'no'``
109 Does the author of a message get placed on the nosy list automatically?
110 If ``'new'`` is used, then the author will only be added when a message
111 creates a new issue. If ``'yes'``, then the author will be added on followups
112 too. If ``'no'``, they're never added to the nosy.
114 **ADD_RECIPIENTS_TO_NOSY** - ``'new'``, ``'yes'`` or ``'no'``
115 Do the recipients (To:, Cc:) of a message get placed on the nosy list?
116 If ``'new'`` is used, then the recipients will only be added when a message
117 creates a new issue. If ``'yes'``, then the recipients will be added on
118 followups too. If ``'no'``, they're never added to the nosy.
120 **EMAIL_SIGNATURE_POSITION** - ``'top'``, ``'bottom'`` or ``'none'``
121 Where to place the email signature in messages that Roundup generates.
123 **EMAIL_KEEP_QUOTED_TEXT** - ``'yes'`` or ``'no'``
124 Keep email citations. Citations are the part of e-mail which the sender has
125 quoted in their reply to previous e-mail.
127 **EMAIL_LEAVE_BODY_UNCHANGED** - ``'no'``
128 Preserve the email body as is. Enabiling this will cause the entire message
129 body to be stored, including all citations and signatures. It should be
130 either ``'yes'`` or ``'no'``.
132 **MAIL_DEFAULT_CLASS** - ``'issue'`` or ``''``
133 Default class to use in the mailgw if one isn't supplied in email
134 subjects. To disable, comment out the variable below or leave it blank.
136 **HEADER_INDEX_LINKS** - ``['DEFAULT', 'UNASSIGNED', 'USER']``
137 Define what index links are available in the header, and what their
138 labels are. Each key is used to look up one of the index specifications
139 below - so ``'DEFAULT'`` will use ``'DEFAULT_INDEX'``.
141 Example ``DEFAULT_INDEX``::
143 {
144 'LABEL': 'All Issues',
145 'CLASS': 'issue',
146 'SORT': ['-activity'],
147 'GROUP': ['priority'],
148 'FILTER': ['status'],
149 'COLUMNS': ['id','activity','title','creator','assignedto'],
150 'FILTERSPEC': {
151 'status': ['-1', '1', '2', '3', '4', '5', '6', '7'],
152 },
153 }
155 This defines one of the index links that appears in the
156 ``HEADER_INDEX_LINKS`` list.
158 **LABEL** - ``'All Issues'``
159 The text that appears as the link label.
160 **CLASS** - ``'issue'``
161 The class to display the index for.
162 **SORT** - ``['-activity']``
163 Sort by prop name, optionally preceeded with '-' to give descending or
164 nothing for ascending sorting.
165 **GROUP** - ``['priority']``
166 Group by prop name, optionally preceeded with '-' or to sort in descending
167 or nothing for ascending order.
168 **FILTER** - ``['status']``
169 Selects which props should be displayed in the filter section.
170 Default is all.
171 **COLUMNS** - ``['id','activity','title','creator','assignedto']``
172 Selects the columns that should be displayed. Default is all.
173 **FILTERSPEC** - *a dictionary giving the filter specification*
174 The ``FILTERSPEC`` gives the filtering arguments. This selects the values
175 the node properties given by propname must have.
177 Where the ``FILTERSPEC`` value is ``'CURRENT USER'``, it will be replaced
178 by the id of the logged-in user. For example::
180 'FILTERSPEC': {
181 'status': ['-1', '1', '2', '3', '4', '5', '6', '7'],
182 'assignedto': 'CURRENT USER',
183 },
185 **HEADER_ADD_LINKS** - ``['issue']``
186 List the classes that users are able to add nodes to.
188 **HEADER_SEARCH_LINKS** - ``['issue']``
189 List the classes that users can search.
191 **SEARCH_FILTERS** - ``['ISSUE_FILTER', 'SUPPORT_FILTER']``
192 List search filters per class. Like the INDEX entries above, each key is
193 used to look up one of the filter specifications below - so ``'ISSUE'``
194 will use ``'ISSUE_FILTER'``.
196 Example ``ISSUE_FILTER``::
198 ISSUE_FILTER = {
199 'CLASS': 'issue',
200 'FILTER': ['status', 'priority', 'assignedto', 'creator']
201 }
203 **CLASS** - ``'issue'``
204 The class that the search page is for.
205 **FILTER** - ``['status', 'priority', 'assignedto', 'creator']``
206 Selects which props should be displayed on the filter page. Default is
207 all.
209 The default instance_config.py is given below - as you
210 can see, the MAIL_DOMAIN must be edited before any interaction with the
211 instance is attempted.::
213 # roundup home is this package's directory
214 INSTANCE_HOME=os.path.split(__file__)[0]
216 # The SMTP mail host that roundup will use to send mail
217 MAILHOST = 'localhost'
219 # The domain name used for email addresses.
220 MAIL_DOMAIN = 'your.tracker.email.domain.example'
222 # the next two are only used for the standalone HTTP server.
223 HTTP_HOST = ''
224 HTTP_PORT = 9080
226 # This is the directory that the database is going to be stored in
227 DATABASE = os.path.join(INSTANCE_HOME, 'db')
229 # This is the directory that the HTML templates reside in
230 TEMPLATES = os.path.join(INSTANCE_HOME, 'html')
232 # A descriptive name for your roundup instance
233 INSTANCE_NAME = 'Roundup issue tracker'
235 # The email address that mail to roundup should go to
236 ISSUE_TRACKER_EMAIL = 'issue_tracker@%s'%MAIL_DOMAIN
238 # The web address that the instance is viewable at
239 ISSUE_TRACKER_WEB = 'http://your.tracker.url.example/'
241 # The email address that roundup will complain to if it runs into trouble
242 ADMIN_EMAIL = 'roundup-admin@%s'%MAIL_DOMAIN
244 # Somewhere for roundup to log stuff internally sent to stdout or stderr
245 LOG = os.path.join(INSTANCE_HOME, 'roundup.log')
247 # Where to place the web filtering HTML on the index page
248 FILTER_POSITION = 'bottom' # one of 'top', 'bottom', 'top and bottom'
250 # Deny or allow anonymous access to the web interface
251 ANONYMOUS_ACCESS = 'deny' # either 'deny' or 'allow'
253 # Deny or allow anonymous users to register through the web interface
254 ANONYMOUS_REGISTER = 'deny' # either 'deny' or 'allow'
256 # Deny or allow anonymous users to register through the mail interface
257 ANONYMOUS_REGISTER_MAIL = 'deny' # either 'deny' or 'allow'
259 # Send nosy messages to the author of the message
260 MESSAGES_TO_AUTHOR = 'no' # either 'yes' or 'no'
262 # Does the author of a message get placed on the nosy list automatically?
263 # If 'new' is used, then the author will only be added when a message
264 # creates a new issue. If 'yes', then the author will be added on followups
265 # too. If 'no', they're never added to the nosy.
266 ADD_AUTHOR_TO_NOSY = 'new' # one of 'yes', 'no', 'new'
268 # Do the recipients (To:, Cc:) of a message get placed on the nosy list?
269 # If 'new' is used, then the recipients will only be added when a message
270 # creates a new issue. If 'yes', then the recipients will be added on followups
271 # too. If 'no', they're never added to the nosy.
272 ADD_RECIPIENTS_TO_NOSY = 'new' # either 'yes', 'no', 'new'
274 # Where to place the email signature
275 EMAIL_SIGNATURE_POSITION = 'bottom' # one of 'top', 'bottom', 'none'
277 # Keep email citations
278 EMAIL_KEEP_QUOTED_TEXT = 'no' # either 'yes' or 'no'
280 # Preserve the email body as is
281 EMAIL_LEAVE_BODY_UNCHANGED = 'no' # either 'yes' or 'no'
283 # Default class to use in the mailgw if one isn't supplied in email
284 # subjects. To disable, comment out the variable below or leave it blank.
285 # Examples:
286 MAIL_DEFAULT_CLASS = 'issue' # use "issue" class by default
287 #MAIL_DEFAULT_CLASS = '' # disable (or just comment the var out)
289 Instance Schema
290 ---------------
292 Note: if you modify the schema, you'll most likely need to edit the
293 `web interface`_ HTML template files and `detectors`_ to reflect
294 your changes.
296 An instance schema defines what data is stored in the instance's database. The
297 two schemas shipped with Roundup turn it into a typical software bug tracker
298 (the extended schema allowing for support issues as well as bugs). Schemas are
299 defined using Python code. The "classic" schema looks like this::
301 pri = Class(db, "priority", name=String(), order=String())
302 pri.setkey("name")
303 pri.create(name="critical", order="1")
304 pri.create(name="urgent", order="2")
305 pri.create(name="bug", order="3")
306 pri.create(name="feature", order="4")
307 pri.create(name="wish", order="5")
309 stat = Class(db, "status", name=String(), order=String())
310 stat.setkey("name")
311 stat.create(name="unread", order="1")
312 stat.create(name="deferred", order="2")
313 stat.create(name="chatting", order="3")
314 stat.create(name="need-eg", order="4")
315 stat.create(name="in-progress", order="5")
316 stat.create(name="testing", order="6")
317 stat.create(name="done-cbb", order="7")
318 stat.create(name="resolved", order="8")
320 keyword = Class(db, "keyword", name=String())
321 keyword.setkey("name")
323 user = Class(db, "user", username=String(), password=String(),
324 address=String(), realname=String(), phone=String(),
325 organisation=String())
326 user.setkey("username")
327 user.create(username="admin", password=adminpw,
328 address=instance_config.ADMIN_EMAIL)
330 msg = FileClass(db, "msg", author=Link("user"), recipients=Multilink
331 ("user"), date=Date(), summary=String(), files=Multilink("file"))
333 file = FileClass(db, "file", name=String(), type=String())
335 issue = IssueClass(db, "issue", assignedto=Link("user"),
336 topic=Multilink("keyword"), priority=Link("priority"), status=Link
337 ("status"))
338 issue.setkey('title')
340 XXX security definitions
342 Classes and Properties - creating a new information store
343 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
345 In the instance above, we've defined 7 classes of information:
347 priority
348 Defines the possible levels of urgency for issues.
350 status
351 Defines the possible states of processing the issue may be in.
353 keyword
354 Initially empty, will hold keywords useful for searching issues.
356 user
357 Initially holding the "admin" user, will eventually have an entry for all
358 users using roundup.
360 msg
361 Initially empty, will all e-mail messages sent to or generated by
362 roundup.
364 file
365 Initially empty, will all files attached to issues.
367 issue
368 Initially emtyp, this is where the issue information is stored.
370 We define the "priority" and "status" classes to allow two things: reduction in
371 the amount of information stored on the issue and more powerful, accurate
372 searching of issues by priority and status. By only requiring a link on the
373 issue (which is stored as a single number) we reduce the chance that someone
374 mis-types a priority or status - or simply makes a new one up.
376 Class and Nodes
377 :::::::::::::::
379 A Class defines a particular class (or type) of data that will be stored in the
380 database. A class comprises one or more properties, which given the information
381 about the class nodes.
382 The actual data entered into the database, using class.create() are called
383 nodes. They have a special immutable property called id. We sometimes refer to
384 this as the nodeid.
386 Properties
387 ::::::::::
389 A Class is comprised of one or more properties of the following types:
390 * String properties are for storing arbitrary-length strings.
391 * Password properties are for storing encoded arbitrary-length strings. The
392 default encoding is defined on the roundup.password.Password class.
393 * Date properties store date-and-time stamps. Their values are Timestamp
394 objects.
395 * A Link property refers to a single other node selected from a specified
396 class. The class is part of the property; the value is an integer, the id
397 of the chosen node.
398 * A Multilink property refers to possibly many nodes in a specified class.
399 The value is a list of integers.
401 FileClass
402 :::::::::
404 FileClasses save their "content" attribute off in a separate file from the rest
405 of the database. This reduces the number of large entries in the database,
406 which generally makes databases more efficient, and also allows us to use
407 command-line tools to operate on the files. They are stored in the files sub-
408 directory of the db directory in your instance.
410 IssueClass
411 ::::::::::
413 IssueClasses automatically include the "messages", "files", "nosy", and
414 "superseder" properties.
415 The messages and files properties list the links to the messages and files
416 related to the issue. The nosy property is a list of links to users who wish to
417 be informed of changes to the issue - they get "CC'ed" e-mails when messages
418 are sent to or generated by the issue. The nosy reactor (in the detectors
419 directory) handles this action. The superceder link indicates an issue which
420 has superceded this one.
421 They also have the dynamically generated "creation", "activity" and "creator"
422 properties.
423 The value of the "creation" property is the date when a node was created, and
424 the value of the "activity" property is the date when any property on the node
425 was last edited (equivalently, these are the dates on the first and last
426 records in the node's journal). The "creator" property holds a link to the user
427 that created the issue.
429 setkey(property)
430 ::::::::::::::::
432 Select a String property of the class to be the key property. The key property
433 muse be unique, and allows references to the nodes in the class by the content
434 of the key property. That is, we can refer to users by their username, e.g.
435 let's say that there's an issue in roundup, issue 23. There's also a user,
436 richard who happens to be user 2. To assign an issue to him, we could do either
437 of::
439 roundup-admin set issue assignedto=2
441 or::
443 roundup-admin set issue assignedto=richard
445 Note, the same thing can be done in the web and e-mail interfaces.
447 create(information)
448 :::::::::::::::::::
450 Create a node in the database. This is generally used to create nodes in the
451 "definitional" classes like "priority" and "status".
454 Examples of adding to your schema
455 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
457 TODO
460 Detectors - adding behaviour to your tracker
461 --------------------------------------------
462 .. _detectors:
464 The detectors in your instance fire before (*auditors*) and after (*reactors*)
465 changes to the contents of your database. They are Python modules that sit in
466 your instance's ``detectors`` directory. You will have some installed by
467 default - have a look. You can write new detectors or modify the existing
468 ones. The existing detectors installed for you are:
470 **nosyreaction.py**
471 This provides the automatic nosy list maintenance and email sending. The nosy
472 reactor (``nosyreaction``) fires when new messages are added to issues.
473 The nosy auditor (``updatenosy``) fires when issues are changed and figures
474 what changes need to be made to the nosy list (like adding new authors etc)
475 **statusauditor.py**
476 This provides the ``chatty`` auditor which changes the issue status from
477 ``unread`` or ``closed`` to ``chatting`` if new messages appear. It also
478 provides the ``presetunread`` auditor which pre-sets the status to
479 ``unread`` on new nodes if the status isn't explicitly defined.
481 See the detectors section in the `design document`__ for details of the
482 interface for detectors.
484 __ design.html
486 Sample additional detectors that have been found useful will appear in the
487 ``detectors`` directory of the Roundup distribution:
489 **newissuecopy.py**
490 This detector sends an email to a team address whenever a new issue is
491 created. The address is hard-coded into the detector, so edit it before you
492 use it (look for the text 'team@team.host') or you'll get email errors!
495 Database Content
496 ----------------
498 Note: if you modify the content of definitional classes, you'll most likely
499 need to edit the instance `detectors`_ to reflect your changes.
501 Customisation of the special "definitional" classes (eg. status, priority,
502 resolution, ...) may be done either before or after the instance is
503 initialised. The actual method of doing so is completely different in each
504 case though, so be careful to use the right one.
506 **Changing content before instance initialisation**
507 Edit the dbinit module in your instance to alter the nodes created in using
508 the create() methods.
511 **Changing content after instance initialisation**
512 Use the roundup-admin interface's create, set and retire methods to add,
513 alter or remove nodes from the classes in question.
517 Web Interface
518 -------------
520 The web interface works behind the cgi-bin/roundup.cgi or roundup-server
521 scripts. In both cases, the scripts determine which instance is being accessed
522 (the first part of the URL path inside the scope of the CGI handler) and pass
523 control on to the instance interfaces.Client class which handles the rest of
524 the access through its main() method. This means that you can do pretty much
525 anything you want as a web interface to your instance.
527 Figuring out what is displayed
528 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
530 Most customisation of the web view can be done by modifying the templates in
531 the instance **html** directory. There are several types of files in there:
533 page
534 defines the overall look of your tracker. When you
535 view an issue, it appears inside this template. When you view an index, it
536 also appears inside this template.
537 home
538 the default page displayed when no other page is indicated by the user
539 home.classlist
540 a special version of the default page that lists the classes in the tracker
541 *classname*.item
542 displays an item of the *classname* class
543 *classname*.index
544 displays a list of *classname* items
545 *classname*.search
546 displays a search page for *classname* items
547 _generic.index
548 used to display a list of items where there is no *classname*.index available
549 _generic.help
550 used to display a "class help" page where there is no *classname*.help
551 user.register
552 a special page just for the user class that renders the registration page
553 style.css
554 a static file that is served up as-is
556 How requests are processed
557 ~~~~~~~~~~~~~~~~~~~~~~~~~~
559 The basic processing of a web request proceeds as follows:
561 1. figure out who we are, defaulting to the "anonymous" user
562 2. figure out what the request is for - we call this the "context"
563 3. handle any requested action (item edit, search, ...)
564 4. render a template, resulting in HTML output
566 In some situations, exceptions occur:
568 - HTTP Redirect (generally raised by an action)
569 - SendFile (generally raised by determine_context)
570 here we serve up a FileClass "content" property
571 - SendStaticFile (generally raised by determine_context)
572 here we serve up a file from the tracker "html" directory
573 - Unauthorised (generally raised by an action)
574 here the action is cancelled, the request is rendered and an error
575 message is displayed indicating that permission was not
576 granted for the action to take place
577 - NotFound (raised wherever it needs to be)
578 this exception percolates up to the CGI interface that called the client
580 Determining web context
581 ~~~~~~~~~~~~~~~~~~~~~~~
583 To determine the "context" of a request, we look at the URL and the special
584 request variable ``:template``. The URL path after the instance identifier
585 is examined. Typical URL paths look like:
587 1. ``/tracker/issue``
588 2. ``/tracker/issue1``
589 3. ``/tracker/_file/style.css``
590 4. ``/cgi-bin/roundup.cgi/tracker/file1``
591 5. ``/cgi-bin/roundup.cgi/tracker/file1/kitten.png``
593 where the "instance identifier" is "tracker" in the above cases. That means
594 we're looking at "issue", "issue1", "_file/style.css", "file1" and
595 "file1/kitten.png" in the cases above. The path is generally only one
596 entry long - longer paths are handled differently.
598 a. if there is no path, then we are in the "home" context.
599 b. if the path starts with "_file" (as in example 3,
600 "/tracker/_file/style.css"), then the additional path entry,
601 "style.css" specifies the filename of a static file we're to serve up
602 from the instance "html" directory. Raises a SendStaticFile
603 exception.
604 c. if there is something in the path (as in example 1, "issue"), it identifies
605 the tracker class we're to display.
606 d. if the path is an item designator (as in examples 2 and 4, "issue1" and
607 "file1"), then we're to display a specific item.
608 e. if the path starts with an item designator and is longer than
609 one entry (as in example 5, "file1/kitten.png"), then we're assumed
610 to be handling an item of a
611 FileClass, and the extra path information gives the filename
612 that the client is going to label the download with (ie
613 "file1/kitten.png" is nicer to download than "file1"). This
614 raises a SendFile exception.
616 Both b. and e. stop before we bother to
617 determine the template we're going to use. That's because they
618 don't actually use templates.
620 The template used is specified by the ``:template`` CGI variable,
621 which defaults to:
623 - only classname suplied: "index"
624 - full item designator supplied: "item"
627 Performing actions in web requests
628 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
630 When a user requests a web page, they may optionally also request for an
631 action to take place. As described in `how requests are processed`_, the
632 action is performed before the requested page is generated. Actions are
633 triggered by using a ``:action`` CGI variable, where the value is one of:
635 login
636 Attempt to log a user in.
637 logout
638 Log the user out - make them "anonymous".
639 register
640 Attempt to create a new user based on the contents of the form and then log
641 them in.
642 edit
643 Perform an edit of an item in the database. There are some special form
644 elements you may use:
646 :link=designator:property and :multilink=designator:property
647 The value specifies a node designator and the property on that
648 node to add _this_ node to as a link or multilink.
649 __note
650 Create a message and attach it to the current node's
651 "messages" property.
652 __file
653 Create a file and attach it to the current node's
654 "files" property. Attach the file to the message created from
655 the __note if it's supplied.
656 :required=property,property,...
657 The named properties are required to be filled in the form.
659 new
660 Add a new item to the database. You may use the same special form elements
661 as in the "edit" action.
663 editCSV
664 Performs an edit of all of a class' items in one go. See also the
665 *class*.csv templating method which generates the CSV data to be edited, and
666 the "_generic.index" template which uses both of these features.
668 search
669 Mangle some of the form variables.
671 Set the form ":filter" variable based on the values of the
672 filter variables - if they're set to anything other than
673 "dontcare" then add them to :filter.
675 Also handle the ":queryname" variable and save off the query to
676 the user's query list.
678 Each of the actions is implemented by a corresponding *actionAction* (where
679 "action" is the name of the action) method on
680 the roundup.cgi.Client class, which also happens to be in your instance as
681 interfaces.Client. So if you need to define new actions, you may add them
682 there (see `definining new web actions`_).
684 Each action also has a corresponding *actionPermission* (where
685 "action" is the name of the action) method which determines
686 whether the action is permissible given the current user. The base permission
687 checks are:
689 login
690 Determine whether the user has permission to log in.
691 Base behaviour is to check the user has "Web Access".
692 logout
693 No permission checks are made.
694 register
695 Determine whether the user has permission to register
696 Base behaviour is to check the user has "Web Registration".
697 edit
698 Determine whether the user has permission to edit this item.
699 Base behaviour is to check the user can edit this class. If we're
700 editing the "user" class, users are allowed to edit their own
701 details. Unless it's the "roles" property, which requires the
702 special Permission "Web Roles".
703 new
704 Determine whether the user has permission to create (edit) this item.
705 Base behaviour is to check the user can edit this class. No
706 additional property checks are made. Additionally, new user items
707 may be created if the user has the "Web Registration" Permission.
708 editCSV
709 Determine whether the user has permission to edit this class.
710 Base behaviour is to check the user can edit this class.
711 search
712 Determine whether the user has permission to search this class.
713 Base behaviour is to check the user can view this class.
716 Repurcussions of changing the instance schema
717 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
719 If you choose to change the `instance schema`_ you will need to ensure the web
720 interface knows about it:
722 1. Index, item and search pages for the relevant classes may need to have
723 properties added or removed,
724 2. The "page" template may require links to be changed, as might the "home"
725 page's content arguments.
727 Overall Look - "page" template
728 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
730 The "page" template in your instances
731 roundup.cgi_client.Class. This class is mixed-in to your instance through the
732 instance's interfaces module. This means you can override the header and
733 footer with your own code. This allows you to use a sidebar navigation scheme,
734 for example.
737 How the templates work
738 ~~~~~~~~~~~~~~~~~~~~~~
740 Roundup's templates consist of special attributes on your template tags. These
741 attributes form the Template Attribute Language, or TAL. The commands are:
744 tal:define="variable expression; variable expression; ..."
745 Define a new variable that is local to this tag and its contents. For
746 example::
748 <html tal:define="title request/description">
749 <head><title tal:content="title"></title></head>
750 </html>
752 In the example, the variable "title" is defined as being the result of the
753 expression "request/description". The tal:content command inside the <html>
754 tag may then use the "title" variable.
756 tal:condition="expression"
757 Only keep this tag and its contents if the expression is true. For example::
759 <p tal:condition="python:request.user.hasPermission('View', 'issue')">
760 Display some issue information.
761 </p>
763 In the example, the <p> tag and its contents are only displayed if the
764 user has the View permission for issues. We consider the number zero, a
765 blank string, an empty list, and the built-in variable nothing to be false
766 values. Nearly every other value is true, including non-zero numbers, and
767 strings with anything in them (even spaces!).
769 tal:repeat="variable expression"
770 Repeat this tag and its contents for each element of the sequence that the
771 expression returns, defining a new local variable and a special "repeat"
772 variable for each element. For example::
774 <tr tal:repeat="u user/list">
775 <td tal:content="u/id"></td>
776 <td tal:content="u/username"></td>
777 <td tal:content="u/realname"></td>
778 </tr>
780 The example would iterate over the sequence of users returned by
781 "user/list" and define the local variable "u" for each entry.
783 tal:replace="expression"
784 Replace this tag with the result of the expression. For example::
786 <span tal:replace="request/user/realname"></span>
788 The example would replace the <span> tag and its contents with the user's
789 realname. If the user's realname was "Bruce" then the resultant output
790 would be "Bruce".
792 tal:content="expression"
793 Replace the contents of this tag with the result of the expression. For
794 example::
796 <span tal:content="request/user/realname">user's name appears here</span>
798 The example would replace the contents of the <span> tag with the user's
799 realname. If the user's realname was "Bruce" then the resultant output
800 would be "<span>Bruce</span>".
802 tal:attributes="attribute expression; attribute expression; ..."
803 Set attributes on this tag to the results of expressions. For example::
805 <a tal:attributes="href string:user${request/user/id}">My Details</a>
807 In the example, the "href" attribute of the <a> tag is set to the value of
808 the "string:user${request/user/id}" expression, which will be something
809 like "user123".
811 tal:omit-tag="expression"
812 Remove this tag (but not its contents) if the expression is true. For
813 example::
815 <span tal:omit-tag="python:1">Hello, world!</span>
817 would result in output of::
819 Hello, world!
821 Note that the commands on a given tag are evaulated in the order above, so
822 *define* comes before *condition*, and so on.
824 Additionally, a tag is defined, tal:block, which is removed from output. Its
825 content is not, but the tag itself is (so don't go using any tal:attributes
826 commands on it). This is useful for making arbitrary blocks of HTML
827 conditional or repeatable (very handy for repeating multiple table rows,
828 which would othewise require an illegal tag placement to effect the repeat).
830 The expressions you may use in the attibute values may be one of the following
831 three forms:
833 Path Expressions - eg. ``item/status/checklist``
834 These are object attribute / item accesses. Roughly speaking, the path
835 ``item/status/checklist`` is broken into parts ``item``, ``status``
836 and ``checklist``. The ``item`` part is the root of the expression.
837 We then look for a ``status`` attribute on ``item``, or failing that, a
838 ``status`` item (as in ``item['status']``). If that
839 fails, the path expression fails. When we get to the end, the object we're
840 left with is evaluated to get a string - methods are called, objects are
841 stringified. Path expressions may have an optional ``path:`` prefix, though
842 they are the default expression type, so it's not necessary.
844 XXX | components of expressions
846 XXX "nothing" and "default"
848 String Expressions - eg. ``string:hello ${user/name}``
849 These expressions are simple string interpolations (though they can be just
850 plain strings with no interpolation if you want. The expression in the
851 ``${ ... }`` is just a path expression as above.
853 Python Expressions - eg. ``python: 1+1``
854 These expressions give the full power of Python. All the "root level"
855 variables are available, so ``python:item.status.checklist()`` would be
856 equivalent to ``item/status/checklist``, assuming that ``checklist`` is
857 a method.
859 Information available to templates
860 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
862 The following variables are available to templates.
864 .. taken from roundup.cgi.templating.RoundupPageTemplate docstring
866 *context*
867 The current context. This is either None, a wrapper around a
868 hyperdb class (an HTMLClass) or a wrapper around a hyperdb item (an
869 HTMLItem).
870 *request*
871 Includes information about the current request, including:
872 - the url
873 - the current index information (``filterspec``, ``filter`` args,
874 ``properties``, etc) parsed out of the form.
875 - methods for easy filterspec link generation
876 - *user*, the current user node as an HTMLItem instance
877 - *form*
878 The current CGI form information as a mapping of form argument
879 name to value
880 *instance*
881 The current instance
882 *db*
883 The current database, through which db.config may be reached.
884 *nothing*
885 XXX a special variable
886 *default*
887 XXX a special variable
889 The context variable
890 ::::::::::::::::::::
892 The *context* variable is one of three things based on the current context
893 (see `determining web context`_ for how we figure this out):
895 1. if we're looking at a "home" page, then it's None
896 2. if we're looking at a specific hyperdb class, it's an HTMLClass instance
897 3. if we're looking at a specific hyperdb item, it's an HTMLItem instance
899 If the context is not None, we can access the properties of the class or item.
900 The only real difference between cases 2 and 3 above are:
902 1. the properties may have a real value behind them, and this will appear if
903 the property is displayed through ``context/property`` or
904 ``context/property/field``.
905 2. the context's "id" property will be a false value in the second case, but
906 a real, or true value in the third. Thus we can determine whether we're
907 looking at a real item from the hyperdb by testing "context/id".
910 The request variable
911 ::::::::::::::::::::
913 The request variable is packed with information about the current request.
915 .. taken from roundup.cgi.templating.HTMLRequest docstring
917 =========== ================================================================
918 Variable Holds
919 =========== ================================================================
920 form the CGI form as a cgi.FieldStorage
921 env the CGI environment variables
922 url the current URL path for this request
923 base the base URL for this instance
924 user a HTMLUser instance for this user
925 classname the current classname (possibly None)
926 template the current template (suffix, also possibly None)
927 form the current CGI form variables in a FieldStorage
928 =========== ================================================================
930 **Index page specific variables (indexing arguments)**
932 =========== ================================================================
933 Variable Holds
934 =========== ================================================================
935 columns dictionary of the columns to display in an index page
936 show a convenience access to columns - request/show/colname will
937 be true if the columns should be displayed, false otherwise
938 sort index sort column (direction, column name)
939 group index grouping property (direction, column name)
940 filter properties to filter the index on
941 filterspec values to filter the index on
942 search_text text to perform a full-text search on for an index
943 =========== ================================================================
946 Displaying Properties
947 ~~~~~~~~~~~~~~~~~~~~~
949 Properties appear in the user interface in three contexts: in indices, in
950 editors, and as search arguments.
951 For each type of property, there are several display possibilities.
952 For example, in an index view, a string property may just be
953 printed as a plain string, but in an editor view, that property may be
954 displayed in an editable field.
957 Index Views
958 ~~~~~~~~~~~
960 This is one of the class context views. It is also the default view for
961 classes. The template used is "*classname*.index".
963 Index View Specifiers
964 :::::::::::::::::::::
966 An index view specifier (URL fragment) looks like this (whitespace has been
967 added for clarity)::
969 /issue?status=unread,in-progress,resolved&
970 topic=security,ui&
971 :group=+priority&
972 :sort=-activity&
973 :filters=status,topic&
974 :columns=title,status,fixer
976 The index view is determined by two parts of the specifier: the layout part and
977 the filter part. The layout part consists of the query parameters that begin
978 with colons, and it determines the way that the properties of selected nodes
979 are displayed. The filter part consists of all the other query parameters, and
980 it determines the criteria by which nodes are selected for display.
981 The filter part is interactively manipulated with the form widgets displayed in
982 the filter section. The layout part is interactively manipulated by clicking on
983 the column headings in the table.
985 The filter part selects the union of the sets of items with values matching any
986 specified Link properties and the intersection of the sets of items with values
987 matching any specified Multilink properties.
989 The example specifies an index of "issue" nodes. Only items with a "status" of
990 either "unread" or "in-progres" or "resolved" are displayed, and only items
991 with "topic" values including both "security" and "ui" are displayed. The items
992 are grouped by priority, arranged in ascending order; and within groups, sorted
993 by activity, arranged in descending order. The filter section shows filters for
994 the "status" and "topic" properties, and the table includes columns for the
995 "title", "status", and "fixer" properties.
997 Filtering of indexes
998 ::::::::::::::::::::
1000 TODO
1002 Searching Views
1003 ~~~~~~~~~~~~~~~
1005 This is one of the class context views. The template used is typically
1006 "*classname*.search".
1008 TODO
1010 Item Views
1011 ~~~~~~~~~~
1013 The basic view of a hyperdb item is provided by the "*classname*.item"
1014 template. It generally has three sections; an "editor", a "spool" and a
1015 "history" section.
1019 Editor Section
1020 ::::::::::::::
1022 The editor section is used to manipulate the item - it may be a
1023 static display if the user doesn't have permission to edit the item.
1025 Here's an example of a basic editor template (this is the default "classic"
1026 template issue item edit form - from the "issue.item" template)::
1028 <table class="form">
1029 <tr>
1030 <th nowrap>Title</th>
1031 <td colspan=3 tal:content="structure python:context.title.field(size=60)">title</td>
1032 </tr>
1034 <tr>
1035 <th nowrap>Priority</th>
1036 <td tal:content="structure context/priority/menu">priority</td>
1037 <th nowrap>Status</th>
1038 <td tal:content="structure context/status/menu">status</td>
1039 </tr>
1041 <tr>
1042 <th nowrap>Superseder</th>
1043 <td>
1044 <span tal:replace="structure python:context.superseder.field(showid=1, size=20)" />
1045 <span tal:replace="structure python:db.issue.classhelp('id,title', label='list', width=500)" />
1046 <span tal:condition="context/superseder">
1047 <br>View: <span tal:replace="structure python:context.superseder.link(showid=1)" />
1048 </span>
1049 </td>
1050 <th nowrap>Nosy List</th>
1051 <td>
1052 <span tal:replace="structure context/nosy/field" />
1053 <span tal:replace="structure python:db.user.classhelp('username,realname,address,phone', label='list', width=500)" />
1054 </td>
1055 </tr>
1057 <tr>
1058 <th nowrap>Assigned To</th>
1059 <td tal:content="structure context/assignedto/menu">
1060 assignedto menu
1061 </td>
1062 <td> </td>
1063 <td> </td>
1064 </tr>
1066 <tr>
1067 <th nowrap>Change Note</th>
1068 <td colspan=3>
1069 <textarea name="__note" wrap="hard" rows="5" cols="60"></textarea>
1070 </td>
1071 </tr>
1073 <tr>
1074 <th nowrap>File</th>
1075 <td colspan=3><input type="file" name="__file" size="40"></td>
1076 </tr>
1078 <tr>
1079 <td> </td>
1080 <td colspan=3 tal:content="structure context/submit">
1081 submit button will go here
1082 </td>
1083 </tr>
1084 </table>
1087 When a change is submitted, the system automatically generates a message
1088 describing the changed properties. As shown in the example, the editor
1089 template can use the "__note" and "__file" fields, which are added to the
1090 standard change note message generated by Roundup.
1092 Spool Section
1093 :::::::::::::
1095 The spool section lists related information like the messages and files of
1096 an issue.
1098 TODO
1101 History Section
1102 :::::::::::::::
1104 The final section displayed is the history of the item - its database journal.
1105 This is generally generated with the template::
1107 <tal:block tal:replace="structure context/history" />
1109 *To be done:*
1111 *The actual history entries of the node may be accessed for manual templating
1112 through the "journal" method of the item*::
1114 <tal:block tal:repeat="entry context/journal">
1115 a journal entry
1116 </tal:block>
1118 *where each journal entry is an HTMLJournalEntry.*
1121 Access Controls
1122 ---------------
1124 A set of Permissions are built in to the security module by default:
1126 - Edit (everything)
1127 - View (everything)
1129 The default interfaces define:
1131 - Web Registration
1132 - Web Access
1133 - Web Roles
1134 - Email Registration
1135 - Email Access
1137 These are hooked into the default Roles:
1139 - Admin (Edit everything, View everything, Web Roles)
1140 - User (Web Access, Email Access)
1141 - Anonymous (Web Registration, Email Registration)
1143 And finally, the "admin" user gets the "Admin" Role, and the "anonymous" user
1144 gets the "Anonymous" assigned when the database is initialised on installation.
1145 The two default schemas then define:
1147 - Edit issue, View issue (both)
1148 - Edit file, View file (both)
1149 - Edit msg, View msg (both)
1150 - Edit support, View support (extended only)
1152 and assign those Permissions to the "User" Role. New users are assigned the
1153 Roles defined in the config file as:
1155 - NEW_WEB_USER_ROLES
1156 - NEW_EMAIL_USER_ROLES
1158 You may alter the configuration variables to change the Role that new web or
1159 email users get, for example to not give them access to the web interface if
1160 they register through email.
1162 You may use the ``roundup-admin`` "``security``" command to display the
1163 current Role and Permission configuration in your instance.
1165 Adding a new Permission
1166 ~~~~~~~~~~~~~~~~~~~~~~~
1168 When adding a new Permission, you will need to:
1170 1. add it to your instance's dbinit so it is created
1171 2. enable it for the Roles that should have it (verify with
1172 "``roundup-admin security``")
1173 3. add it to the relevant HTML interface templates
1174 4. add it to the appropriate xxxPermission methods on in your instance
1175 interfaces module
1179 -----------------
1181 Back to `Table of Contents`_
1183 .. _`Table of Contents`: index.html