Roundup

User Guide

Hint

This document will refer to issues as the primary store of information in the tracker. This is the default of the classic template, but may vary in any given installation.

Your Tracker in a Nutshell

Your tracker holds information about issues in bundles we call items. An item may be an issue (a bug or feature request) or a user. The issue-ness or user-ness is called the item’s class. So, for bug reports and features, the class is “issue”, and for users the class is “user”.

Each item in the tracker has an ID number that identifies it along with its item class. To identify a particular issue or user, we combine the class with the number to create a unique label, so that user 1 (who, incidentally, is always the “admin” user) is referred to as “user1”. Issue number 315 is referred to as “issue315”. We call that label the item’s designator.

Items in the database are never deleted, they’re just “retired”. You can still refer to them by ID - hence removing an item won’t break references to the item. It’s just that the item won’t appear in any listings.

Accessing the Tracker

You may access your tracker through one of three ways:

  1. through the web interface,
  2. through the e-mail gateway, or
  3. using the command line tool.

The last is usually only used by administrators. Most users will use the web and e-mail interfaces. All three are explained below.

Issue life cycles in Roundup

New issues may be submitted via the web or e-mail.

By default, the issue will have the status “unread”. If another message is received for the issue, its status will change to “chatting”.

The “home” page for a tracker will generally display all issues which are not “resolved”.

If an issue is closed, and a new message is received then it’ll be reopened to the state of “chatting”.

The full set of prority and status values are:

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

Entering values in your Tracker

All interfaces to your tracker use the same format for entering values. This means the web interface for entering a new issue, the web interface for searching issues, the e-mail interface and even the command-line administration tool.

String and Numeric properties

These fields just take a simple text value, like It's broken.

Boolean properties

These fields take a value which indicates “yes”/”no”, “true”/”false”, “1”/”0” or “on”/”off”.

Date properties

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.

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.

  • “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”

When searching, a plain date entered as a search field will match that date exactly in the database. We may also accept ranges of dates. You can specify range of dates in one of two formats:

  1. English syntax:

    [From <value>][To <value>]

    Keywords “From” and “To” are case insensitive. Keyword “From” is optional.

  2. “Geek” syntax:

    [<value>];[<value>]

Either first or second <value> can be omitted in both syntaxes.

For example, if you enter string “from 9:00” to “Creation date” field, roundup will find all issues, that were created today since 9 AM.

The <value> may also be an interval, as described in the next section. Searching of “-2m; -1m” on activity field gives you issues which were active between period of time since 2 months up-till month ago.

Other possible examples (consider local time is 2003-03-08.22:07:48):

  • “from 2-12 to 4-2” means <Range from 2003-02-12.00:00:00 to 2003-04-02.00:00:00>
  • “FROM 18:00 TO +2m” means <Range from 2003-03-08.18:00:00 to 2003-05-08.20:07:48>
  • “12:00;” means <Range from 2003-03-08.12:00:00 to None>
  • “tO +3d” means <Range from None to 2003-03-11.20:07:48>
  • “2002-11-10; 2002-12-12” means <Range from 2002-11-10.00:00:00 to 2002-12-12.00:00:00>
  • “; 20:00 +1d” means <Range from None to 2003-03-09.20:00:00>
  • “2003” means <Range from 2003-01-01.00:00:00 to 2003-12-31.23:59:59>
  • “2003-04” means <Range from 2003-04-01.00:00:00 to 2003-04-30.23:59:59>

Interval properties

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

Simple support for collision detection

Item edit pages remember when the item was last edited. When a form is submitted, the user will be informed if someone else has edited the item at the same time they tried to.

Web Interface

Note

This document contains screenshots of the default look and feel. Your site may have a slightly (or very) different look, but the functionality will be very similar, and the concepts still hold.

The web interface is broken up into the following parts:

  1. lists of items,
  2. display, edit or entry of an item, and
  3. searching page.

Lists of Items

The first thing you’ll see when you log into Roundup will be a list of open (ie. not resolved) issues. This list has been generated by a bunch of controls under the covers but for now, you can see something like:

_images/index_logged_out.png

The screen is divided up into three sections. There’s a title which tells you where you are, a sidebar which contains useful navigation tools and a body which usually displays either a list of items or a single item from the tracker.

You may either register or log in. Reg21; or Rli>Interval properties

  • Simple support for collision detection
  • Web Interface
  • E-Mail Gateway
  • Command Line Tool
  • Hint

    This document will refer to issues as the primary store of information in the tracker. This is the default of the classic template, but may vary in any given installation.

    Your Tracker in a Nutshell

    Your tracker holds information about issues in bundles we call items. An item may be an issue (a bug or feature request) or a user. The issue-ness or user-ness is called the item’s class. So, for bug reports and features, the class is “issue”, and for users the class is “user”.

    Each item in the tracker has an ID number that identifies it along with its item class. To identify a particular issue or user, we combine the class with the number to create a unique label, so that user 1 (who, incidentally, is always the “admin” user) is referred to as “user1”. Issue number 315 is referred to as “issue315”. We call that label the item’s designator.

    Items in the database are never deleted, they’re just “retired”. You can still refer to them by ID - hence removing an item won’t break references to the item. It’s just that the item won’t appear in any listings.

    Accessing the Tracker

    You may access your tracker through one of three ways:

    1. through the web interface,
    2. through the e-mail gateway, or
    3. using the command line tool.

    The last is usually only used by administrators. Most users will use the web and e-mail interfaces. All three are explained below.

    Issue life cycles in Roundup

    New issues may be submitted via the web or e-mail.

    By default, the issue will have the status “unread”. If another message is received for the issue, its status will change to “chatting”.

    The “home” page for a tracker will generally display all issues which are not “resolved”.

    If an issue is closed, and a new message is received then it’ll be reopened to the state of “chatting”.

    The full set of prority and status values are:

    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

    Entering values in your Tracker

    All interfaces to your tracker use the same format for entering values. This means the web interface for entering a new issue, the web interface for searching issues, the e-mail interface and even the command-line administration tool.

    String and Numeric properties

    These fields just take a simple text value, like It's broken.

    Boolean properties

    These fields take a value which indicates “yes”/”no”, “true”/”false”, “1”/”0” or “on”/”off”.

    Date properties

    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.

    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.

    • “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”

    When searching, a plain date entered as a search field will match that date exactly in the database. We may also accept ranges of dates. You can specify range of dates in one of two formats:

    1. English syntax:

      [From <value>][To <value>]

      Keywords “From” and “To” are case insensitive. Keyword “From” is optional.

    2. “Geek” syntax:

      [<value>];[<value>]

    Either first or second <value> can be omitted in both syntaxes.

    For example, if you enter string “from 9:00” to “Creation date” field, roundup will find all issues, that were created today since 9 AM.

    The <value> may also be an interval, as described in the next section. Searching of “-2m; -1m” on activity field gives you issues which were active between period of time since 2 months up-till month ago.

    Other possible examples (consider local time is 2003-03-08.22:07:48):

    • “from 2-12 to 4-2” means <Range from 2003-02-12.00:00:00 to 2003-04-02.00:00:00>
    • “FROM 18:00 TO +2m” means <Range from 2003-03-08.18:00:00 to 2003-05-08.20:07:48>
    • “12:00;” means <Range from 2003-03-08.12:00:00 to None>
    • “tO +3d” means <Range from None to 2003-03-11.20:07:48>
    • “2002-11-10; 2002-12-12” means <Range from 2002-11-10.00:00:00 to 2002-12-12.00:00:00>
    • “; 20:00 +1d” means <Range from None to 2003-03-09.20:00:00>
    • “2003” means <Range from 2003-01-01.00:00:00 to 2003-12-31.23:59:59>
    • “2003-04” means <Range from 2003-04-01.00:00:00 to 2003-04-30.23:59:59>

    Interval properties

    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

    Simple support for collision detection

    Item edit pages remember when the item was last edited. When a form is submitted, the user will be informed if someone else has edited the item at the same time they tried to.

    Web Interface

    Note

    This document contains screenshots of the default look and feel. Your site may have a slightly (or very) different look, but the functionality will be very similar, and the concepts still hold.

    The web interface is broken up into the following parts:

    1. lists of items,
    2. display, edit or entry of an item, and
    3. searching page.

    Lists of Items

    The first thing you’ll see when you log into Roundup will be a list of open (ie. not resolved) issues. This list has been generated by a bunch of controls under the covers but for now, you can see something like:

    _images/index_logged_out.png

    The screen is divided up into three sections. There’s a title which tells you where you are, a sidebar which contains useful navigation tools and a body which usually displays either a list of items or a single item from the tracker.

    You may either register or log in. Reg21; or Rli>Interval properties

  • Simple support for collision detection
  • Web Interface
  • E-Mail Gateway
  • Command Line Tool
  • Hint

    This document will refer to issues as the primary store of information in the tracker. This is the default of the classic template, but may vary in any given installation.

    Your Tracker in a Nutshell

    Your tracker holds information about issues in bundles we call items. An item may be an issue (a bug or feature request) or a user. The issue-ness or user-ness is called the item’s class. So, for bug reports and features, the class is “issue”, and for users the class is “user”.

    Each item in the tracker has an ID number that identifies it along with its item class. To identify a particular issue or user, we combine the class with the number to create a unique label, so that user 1 (who, incidentally, is always the “admin” user) is referred to as “user1”. Issue number 315 is referred to as “issue315”. We call that label the item’s designator.

    Items in the database are never deleted, they’re just “retired”. You can still refer to them by ID - hence removing an item won’t break references to the item. It’s just that the item won’t appear in any listings.

    Accessing the Tracker

    You may access your tracker through one of three ways:

    1. through the web interface,
    2. through the e-mail gateway, or
    3. using the command line tool.

    The last is usually only used by administrators. Most users will use the web and e-mail interfaces. All three are explained below.

    Issue life cycles in Roundup

    New issues may be submitted via the web or e-mail.

    By default, the issue will have the status “unread”. If another message is received for the issue, its status will change to “chatting”.

    The “home” page for a tracker will generally display all issues which are not “resolved”.

    If an issue is closed, and a new message is received then it’ll be reopened to the state of “chatting”.

    The full set of prority and status values are:

    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

    Entering values in your Tracker

    All interfaces to your tracker use the same format for entering values. This means the web interface for entering a new issue, the web interface for searching issues, the e-mail interface and even the command-line administration tool.

    String and Numeric properties

    These fields just take a simple text value, like It's broken.

    Boolean properties

    These fields take a value which indicates “yes”/”no”, “true”/”false”, “1”/”0” or “on”/”off”.

    Date properties

    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.

    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 th