Welcome to the sysadmin tracker for Roundup. This tracker is designed
to handle issues generated in a system administration or help desk
environment. It is released under the GPL license see the
Tracker License section for details.
It is more complex than the classic tracker, but has things that I
have wanted in my trackers. Some of the functions were inspired by
equivalent functionality in rt while some other things I have wanted
in various trackers (req, reqng, queuemh, rt1, clearquest, remedy)
through the years.
Compared to the classic tracker, this tracker has:
- Well defined relationships between issues including:
- dependson - shows dependencies and prevents issues from
being resolved if they have any unresolved
issues that they depend on.
- grouping (merging) - used to update multiple
similar issues as a group.
- seealso - used to link issues that are related in some
way.
- Two notification (nosy) lists for issues:
- Watcher list (aka nosy) - This list receives replies to the
issue and is intended for non-implementation level conversations
with the requestor. It is also used to notify the requestor of
milestone achievements.
- Technical List (aka verynosy) - This list is meant for
technical discussion of how to implement solutions, and
coordination of implementation as well as detailed
implementation notes.
- Two types of messages: replies and comments.
- reply messages - are used to interact with the requestor
and are sent to both the the Watcher and Technical lists.
- comment messages - are used to interact with other technical
people, and are sent to only the Technical list.
- The repair role has been defined and is used to restrict which
users are visible in the assignedto list box, or which users can
be assigned to an issue via email. Also there is an auditor (that
is not installed by default) that will assign the first person,
with the repair role, to respond to an issue to that issue. See
unused/autotake.py.
- Issues can be assigned to queues. Each queue can have its own
list of email address for announcing a new unassigned item in the
queue.
- Users assigned an issue by a third party (like a manager or
first line support person) are sent email with the initial
message ans the last three messages to get them to come up to speed
as quickly as possible.
- Issues support tracking the amount of time spent solving the
issue. (Not available via email yet)
- Issue has the extra attributes for:
- scheduling:
- startdate - date on which work should start
- leadtime - amount of time the work should take
- duedate - date on which work needs to be done
- workingorder - set a numeric order to issue. Useful to
determine which issue gets worked on first when
you have multiple issues at the same priority.
Must be an integer > 0. The system doesn't care
if you use 1000 for the first item to be
worked, or 1 for the first item. That is up to
local policy.
- summary info:
- fyi - string used to keep critical info (e.g. server serial
numbers, external call ticket numbers) quickly available
without having to search through issues.
- billing:
- billinfo - text attribute for storing billing information
- notification:
- needsreply - for indicating on the index when a new message
that needs to be replied to has been received on
an issue. There are some times when you just
can't monitor email to get change
notification. This is a quick and dirty way of
being notified via the web interface.
- automatic actions:
- actiondate - date on which action will occur
- actionstatus - the [optional] new
status for the issue after the action triggers.
- actioncomment - the [optional]
comment message that will be added to the issue when the
action triggers.
- can change user who opened/requested issue:
- requestedby - set the user who requested this issue.
It has a matching detector that by default will
set it to the creator of an issue. Also it adds
the requestedby person to the nosy list.
By default this attribute will have the same value
as the creator property, but this attribute can be
changed unlike the creator. This means it can be
set to a different user if you have a help desk
that takes calls and enters issues on behalf of
another person.
- In the web interface, each message displayed has a replyto link
that will reload the issue with the change note text area
filled with a quoted attributed version of the message you are
replying to.
- In the web interface each message that is sent can be carbon copied to
arbitrary email addresses.
- Wherever issue numbers show up, they also display an indication of
the state of the issue. This is settable in the status class.
- The tracker administrator can configure what status transitions are
allowed. E.G. you can force new to transition to only open,
stalled or hold. Then those states can transition to resolved
to enforce a particular status path.
- The tracker administrator can limit setting a state to particular users.
(Note is is shown in the web interface, but an error is produced
when it is set. This is considered a bug.)
- It comes preloaded with searches for displaying (in a limited way)
relations between issues, scheduling showing due dates,
showing watcher and technical lists.
- Users can add any query they want by name to their list of
queries.
- It has a printable link that makes it easier to print out issues
for review.
- It has an auto refresh mode that automatically refreshes the screen
at a user selectable interval. Great for keeping up to date on new
and changed issues.
- All pages have a full text search and goto item forms to ease
locating particular issues.
- Index pages (search results) provide a count of number of issues
and your location within the list from a patch by Patrick Ohly.
- Date spec modified to support yyyy/mm/dd (and more importantly
mm/dd) from patch by Luke Opperman.
- The user's item page has a fixed format list of non-resolved issues
requested by this user as well as a link to the index page of all
issues requested by the user to allow interactive sorting and
grouping capability.
- The user index page includes a link to a search for all the
user's issues.
- On the index pages, all columns that are links to users are now
hyperlinked to the user.
- The ability to do the funcions requested below. Used
implementation from K Schutte from the roundup list.
On Mon, 18 Aug 2003 09:50 pm, K Schutte wrote:
How should I set up Roundup such that for any new issue with topic
I am put on the nosy list?
Does this also work when with an existing issue the topic is added?
How can this be arranged such that any user (that is, including those
who can't edit Python) can specify on which topics they will be added
on the nosy list?
- Publishing of an rss newsfeed keeping you up to date on changes
in the tracker.
This section describes general usage of the tracker and explains the
attributes and related entries. It assumes that you have read, or can
read the roundup user documentation.
A requestor sends email to the sysadmin tracker email address. The people
responsible for watching the tracker and its queues are automatically
sent a new issue email.
Then the queue wrangler for the week uses the web interface to set the
issue priority and to assign somebody to the issue. This assigned
person is called the assignee. The assignee automatically receives a
"this issue is assigned to you email", and the issue will occur on the
assignee's issues list. The assignee then replies to the assignment
email and asks the requestor for some additional information. The
issue is automatically moved to the open state.
The assignee then uses the web interface to add a few other technical
people to the Technical (verynosy) list and creates a "comment"
message asking for ideas on the best way to solve the problem. The
technical people receiving this comment reply to it creating more
comments until somebody realizes that they need input from the issue
creator. The assignee sends a "reply" message using the web interface
and asks the requestor (who is automatically put on the Watcher list)
for the information. All of the people on the Technical list see the
email and its response. One of the technical people replies to this
email and solicits further info from the requestor.
Then some more conversations occur using "comment" messages until a
solution is reached. The assignee realizes that he needs help from
another group and creates a new dependson issue to assign part of the
work to another person. The assignee then stalls the issue.
Once the other work is done, and the depended issue is resolved, the
issue is automatically moved from stalled to open, and our assignee
finishes the issue, adds a comment detailing how the issue was solved
and passes it off to another (QA) person in the group by reassigning
the issue which moves it off his list of open issues.
Then the new assignee creates a reply to the issue creator telling him
that the problem is solved, and asking him to verify the fix. He also
moves the issue to the testing status. The requestor sends email
saying that the issue is resolved, the assignee then changes the
status to resolved and it is automatically removed from his list of
open issues.
In this example we see there are two ways to interact with the issue:
- web interface
- email interface
with a few exceptions, all of the features of the tracker can be
accessed via either interface. We will discuss the web interface first
than the email interface.
If you send email to the tracker email address, an entry in the user
database is made for your email address. If the administrator has set
the MESSAGES_TO_AUTHOR to include new, or yes, you will receive a
return email that verifies the creation of the
issue and will provide you an easy way to add information to this
issue by replying to the return email.
You can also register for the web interface if you wish by using the
register link. If you have forgotten your password, a new randomly
generated one will be sent to you by following the process from the
"Forgotten your password?" link. Both of these mechanisms send email
to the registered address and use a web link in the email to verify
the account creation or resetting of the password.
We will discuss using the web interface.
The left hand menu has a number of items in it including:
- Goto Box - Type you issue number in the box and hit the "show
issue" button to jump to an issue.
- Text Search Box - enter a word or words in the box (not including
words with punctuation other than _) and a list of issues will be
shown where one of the messages in the issue includes all the
words you typed into the box.
- User's Saved Searches - If you have saved any searches (by using
the search page and naming the search), it will be listed here
for quick reference.
- Issue menu - Links for seeing unassigned issues, creating a new
issue, showing all issues and searching for issues using specific
criteria are located here.
- Keyword Menu - You can add new keywords for use in the Topics
filed from the link in this box. If you are a tracker
administrator you can edit the keywords as well.
- Admin box - If you are a regular user you can display a list of
all users of the system. If you are an admin, you can pull up
edit menus for all classes in the tracker and add users.
- User Box - This box identifies who is logged in, allows you to
see your details, your issue list and allows you to logout.
- Help Box - this box provides links to roundup documentation
on the roundup web site, and a link to this documentation on the
tracker you are using.
- Actions box - this box allows you to select a printable copy of
your page. If you are viewing an issue, you can also eliminate
the issue history which helps save on paper. Use your browser's
back button to get out of printable mode.
- Auto Refresh box - this box lets you automatically refresh the
current screen with a user configurable time. It is useful for
watching updates to a particular issue, or monitoring a selected
list of issues. You can select from 10 sec, 20 sec, 30 sec, 1
min (Default), 1.5 min, 2 min, 5 min, 10 min, 20 min, 30 min, 1
hour and 2 hour intervals. Then press the AutoRefresh
button. If you are already automatically refreshing the page,
it will display the refresh interval and a link to turn off
auto refresh.
The AutoRefresh box should be part of the actions box, but because of
issues with HTML, it needs to be a separate box.
When you log in, you will see a list of open issues. You can click on
the "My Issues" link in the User box to see all issues assigned to
you. You can view an issue by clicking on its title or entering its
ID number using the goto box.
Using either of these methods will bring up the default issue
view. There is also a view for advanced administration of the issue
including assigning a scheduled action, storing billing info etc.
This advanced administration view is called the
edit fields view. These two views are discussed
below.
This view shows the basic fields, message entry fields, total time log
(if times have been entered for the issue), message list, files list
and history list.
The basic fields include:
- Title
- Priority
- Due Date
- Status
- Lead time
- Assigned to
- Watcher List
- Queue
- Technical list
- FYI
- Depends on
- Groups
- See also
- Topics
See Attribute Descriptions for full
information on these fields. The message entry
fields are:
- Message type
- Time spent
- Cc
- Change note
- File
The Time Log Total section is shown only if one of the messages was
entered with time information. The display consists of three columns:
- Date - the date the time log entry was created
- Period - amount of time spent
- Logged by - user who logged the time
The messages section displays the full text of any messages that are
linked to this issue. Each issue has a header. The header consists of:
- a msg link to the full message entry (this includes message history,
attached files, message type, time spent, recipient list etc.)
- the author's name
- the remove link that will remove the message from the issue
(if you have the admin Role) [**FIXME is this correct, it doesn't
do anything for me]
- the creation date for the entry (in local time of the user entry
has the proper timezone set, see User Timezone)
- the reply to link that will reload the page with the quoted
message in the change note field. This makes it easy to reply to
a message in the web interface using in-line comments to the
message.
Next is the list of files that are associated with the messages in the
issue. It is displayed only if there are files associated with the
messages in the issue.
[Admins take note: earlier versions of roundup had a bug where file
attachments sent via the email interface were linked into the
messages, but were not linked into the issue. You can create a shell
script using the roundup-admin command to fix this. See the admin
chapter below.]
Then at the very bottom of the page is the history of all the changes
made to the issue.
- Date - date and time of the change
- User - the user who made the change
- Action - there are a number of values including
- set - set a attribute value
- link/unlink - add/remove an item to a link or multilink type attribute
- create - create the entry
- Args - the argument that were actually changed. For most
arguments its attributename: oldvalue -> newvalue where newvalue
will be the most current value. For items that are multilinks,
set is used to show linking and unlinking by preceding the
identifier with a + (added to attribute) or - (removed from attribute).
Since you can change multiple items in a single modification of the
issue, only one Date/user line is shown for each modification. There
can be multiple action/args entries that were done with only a single
modification transaction.
In this view, you have access to more fields, and also some embedded
searches to provide a better feel for how the issue relates to other
issues. It does not provide a message entry box, nor does is show the
message associated with the issue or a history of changes to the
issue.
The fields shown are the basic fields shown in the main issue view:
- Title
- Priority
- Due Date
- Status
- Lead time
- Assigned to
- Watcher List
- Queue
- Technical list
- FYI
- Depends on
- Groups
- See also
- Topics
Below that is the "Additional Fields" section including:
- Requested By
- Start Date
- Billing Info
- Working Order
- Needs Reply
Below that is the "Action Fields" section that implements some
basic actions that can be scheduled for a future time. This section
consists of the fields:
- Action Date
- Action Status
- Action Comment
See the section
Attribute Descriptions for full
details on these fields.
Below this section is the Issue Relationships section that provides a
five column summary of related issues. The columns are:
- ID (issue ID)
- Title
- Status
- Priority
- Activity (date of last activity on issue)
The email interface uses specially formatted tags on the subject line
to link a given email to a message. This tag occurs first on the
subject line (words like Re:, Fwd: preceding the tag are ignored) and
looks like '[issue345]'. The tag consists of an open left square
bracket, the word 'issue' the issue number (with no space between the
word issue and the number) and a closing right square bracket.
When you reply to an email, it preserves the subject line. Your reply
email will be addressed to one of the trackers email addresses. There
are two addresses associated with a sysadmin tracker. They correspond
to the two types of messages:
reply and comment.
The comment address usually has the phrase '_comment' just before the
at '@' sign in the email address. When you reply goes to this address,
only people on the Technical List will see it. By default, the
requestor is not on this list. If you want to send an email that the
requestor will see, just remove the '_comment' from the to address and
it will go the the reply address that includes the people on the
Watcher list (where the requestor is) and the Technical List.
You can also set the attributes of
the issue by including a tag of the form
'[attributename1=value;attributename2=value2]' at the end of the
subject line. If you are using Microsoft Outlook, this may not work
because of a significant bug in that product. See the
roundup documentation for more information on setting attributes via
the email interface.
Any text you type in the body of the message will be saved as a
message in the issue. The message type is determined from the address
you send the email to as described above. Attached files will be
recorded as attachments in the issue and will be forwarded to the
Watcher or Technical lists depending on the message type.
You can send your email to real people by adding them on the Cc or To
or Bcc lines of your mail program. These people will not receive an
email message from the tracker. For their replies to be recorded, they
will have to include the tracker email address in their
replies. Usually this can be done by selecting the "reply to all"
functionality of their mailer.
The RSS announcement interface
Thanks to http://markpasc.org/code/rsswriter the sysadmin tracker has
an XML rss 2.0 feed at TRACKER_WEB/_file/rss.xml. You can point
Bottomfeeder, Feedreader, Liferea, or any other RSS reader including
those available for TWiki as a plugin to get up to the minute info on
the top 30 newly changed issues.
This section discusses how to work with issues and the attributes of
those issues.
There are 6 issue priorities available in the shipped tracker. Some
of the ideas below are taken from the rt user's guide.
- critical
- This needs to be fixed immediately, stop whatever else you
are doing and fix it. It has a high severity and high impact with
no workaround. Lots of people are affected, or a critical person
can't do their job. E.G. the main file server is down and nobody can
work till it is functioning again.
- urgent
- High severity and moderate impact with no workaround. E.G. the
only mail server is down, no email can be sent/received.
- high
- moderate severity, and moderate impact there may or may not be a
workaround. e.g. the source code control system is down. People
can still compile, test they just can't check the code in, the
next scheduled check-in/release to test is still 4 days away.
- routine
- priority of the routine day to day issues. Low severity,
moderate impact, there may or may not be a workaround for these
issues.
- low
- Low severity, low impact, should have a workaround, or no
workaround is needed.
- minimum
- Low severity, no impact, no workaround is needed.
The priorities above are defined in terms of severity and impact. I
tried (and may have failed 8-)) to create a relatively simple single
entry priority rating. Severity is a measure of how bad the problem
is, and how difficult it will be to solve. Impact is a measure of how
it interferes with people getting their jobs done.
The total failure of a mail server is pretty severe, but it may not be
a high priority if you have three redundant mail server, and email is
still flowing. So that one mail server being down is moderate impact,
and there is a workaround in place (i.e. mail is still flowing). So
this would be a high priority.
Also you may want to look at the workingorder
attribute to further order the outstanding issues.
There are 9 defined statuses in the default sysadmin tracker they are:
- New - the default status for a newly created issue. It also
means that no work has been done on the issue yet.
- Open - the issue has (usually) been assigned to somebody and work
(even if it is just gathering information) has started on the
issue. The issue is set to this state automatically by the
detectors when an entry is in the New, Stalled, Resolved, Dead or
Delete states, and a message is added from somebody other then
the original creator.
- Stalled - work can not progress on this issue because the worker
is waiting for information from some other party.
- Hold - work is not progressing on this issue because of a
decision to hold off working on the issue. Another decision to
continue working the issue is needed before the issue is
reopened. Automatic reopening can be done by setting an action.
- Testing - a fix is in place for the issue, but we are waiting for
the customer to agree that the fix is sufficient to resolve this
issue.
- Resolved - The issue has been resolved. This resolution may be
that the issue is fixed, is unfounded etc.
- Duplicate - this issue is closed (no work will be performed on
it) because its a duplicate of another issue. To be a duplicate,
it should have been submitted by the same person for the same
originating incident.
- Dead - the issue has been closed because we choose not to work
on it.
- Delete - the issue should never have been opened. Delete issues are
candidates for being deleted from the system.
When looking at related issues, it is very useful to know what state
the related issues are in. To do this compactly, the issue numbers
are displayed with a final letter that indicates the state of the
issue. These letters can be set by the administrator, but by default
are:
Letter | Status |
N | new |
O | open |
S | stalled |
H | hold |
T | testing |
R | resolved |
C | duplicate (copy) |
D | dead |
d | delete |
The four action attributes:
- actiondate
- actionstatus
- actioncomment
- actionclearonmessage
provide a limited mechanism for scheduling an action on an issue. It
allows setting an actiondate, actionstatus and actioncomment that are
cleared after the actiondate has occurred. The actionclearonmessage
attribute will cause the actiondate to be cleared if a message is
submitted to the issue. This is useful for resolving a message after
say three days if there is no activity. If there is activity, the
automatic resolution is disabled. Actions will not be performed for
resolved, duplicate, or deleted issues.
If an action is pending, you will see an "action pending" link next to
the issue number at the top of the [[#DefaultIssueView][default issue
view]] screen. Clicking on that link will take to you to the
edit fields view at the action fields section.
For this to work, your roundup administrator must run a
script daily to actually perform the actions.
To automatically resolve an issue on a given date, set the actionstatus
to resolved and the actiondate to the date you wish to resolve the
ticket on. This is useful if you state that you will resolve a ticket
in N days if there is no response. Note that you are still responsible
for clearing the action if there is a response and you don't want the
ticket to resolve. It may also be a good idea to set the actioncomment
to "issue 345 automatically closed after N days without a response."
This way you will get the email and can reopen the ticket by replying,
or by manually setting its status in the web interface.
To remind you about a ticket on its start date, set the actiondate
attribute to the start date, and add an actioncomment of "Start issue
345 today", and leave the actionstatus as '- no selection -'. On the
given day, the actioncomment will be added to the issue, and an email
will be sent to everybody on the Technical List (which included you
the assignee by default).
These fields can also be assigned in the subject line of an email to
the issue if you don't have access to the web interface.
The sysadmin tracker uses two types of change notes/messages. These
two types are replies and comments. The reason for this is to reduce
the amount of email that people get on an issue. On a given issue,
only 1 or two messages may have to go to the requestor, but there may
be dozens of messages recording how the work was done and intermediate
steps taken in finishing it. By recording this intermediate info, the
issue can be referred to later if a similar problem crops up. Then the
issue can be used as the standard way of solving (or not solving) the
problem. Message types are used as follows:
- reply messages - are used to interact with the requestor
and are forwarded to both the the Watcher and
Technical lists.
- comment messages - are used to interact with other technical
people, and are forwarded to only the Technical list.
Associated with a message of any type are the following attributes:
- Time spent - records an interval of how long it took to do what
is described in the message. This interval is associated with
the message as well as being associated with the issue that the
message is sent to.
- Cc - Sends a copy of the message to parties not on
the Watcher or Technical lists. This is useful if you have a
manager should be notified about a particular issue (need to
purchase a replacement disk drive), but doesn't need to be on the
regular lists. This field accepts a list of email addresses. The
message that the people on the Cc field receive is processed by
the tracker before being sent, so the from address is the
tracker address.
- Change note - the actual text of your message. If the change note
is empty, no change notification email is sent.
- File - upload a (single) file with your message. This file is
linked to the message and to the issue. It is also sent as an
attachment to all the people who receive the change notification
email.
This tracker defines three different relationships between issues:
Either the dependson or groups relation replaces the classic tracker
"superseder" property whose meaning seems to be incompletely defined.
The sections below define each type.
If issue A has issue B listed in issue A's dependson multilink
property, issue A can't be resolved until B is resolved.
When the last unresolved issue in A's dependson property is resolved,
issue A will have its state changed to open. In this case a comment
is added to the issue that it is being opened so verynosy (technical
list) notifications are sent out since assigned to people are on the
technical list.
If one of issue A's dependson issues is unresolved, issue A will be
reopened if issue A is resolved.
If issue A has issue B and issue C listed in issue A's group it
means that updates (messages, status changes etc) to issue A should
be applied to issues B and C. You would use it when you have multiple
issues that are all solved by the same solution. Think of it as a
merging of issues that preserves the individuality of the issues and
permits un-merging if issue C turns out to not be solved by the
solution to issue B.
It implements forwards and backwards (downward and upward) message
propagation. This will make sure that the grouping issues will get
the message so that their nosy people can be notified of changed.
It should work like:
A -----+--------- B --------+------- C --------+------- D
| | +------- E
| +-------- F
| +-------- G --------+--------- H
| +--------- I
+--------- J ---+-- K
+-- L
email sent to H should go up the grouping chain to G, B, A. Email sent
to G will go down to H, I and up to B, A. Email sent to A will go down
to all issues A-L. This means that an issue that groups another
issue will see all the messages made to its groupees. Also all the
groupees will see the messages sent to the grouping issue.
A general grouping solution. Since issues can be
hyperlinked in the message bodies, this is somewhat
redundant, but it is useful in that programs can easily
find the links to publish an issue and all related
issues without having to grovel through all of the messages.
On the left hand pane in the Administration section, you can access a
index page of users with the "User List" link. Then use your browser's
search capability to find the right user. When you click on the
username link, you will transfer to the user's page. If you click on
the tickets link in the username column, you will see a list of open
tickets grouped by status. This is a standard issue index page so you
can sort and group then differently. This is useful to find out what
the caller is submitting, what is currently open etc.
If you chose to go the user's page, you will be able to view the
following fields:
- Name - the user's real name.
- Login Name - the login name listed as the user in all fields.
- Phone - phone number of person.
- Organisation - the orgsanisation/department etc of the user.
- Timezone - times in roundup are stored in GMT. This is added (or
subtracted if negative) from the times when they are listed in
the web interface. See the timezone section below
for some issues.
- Nosy Topics - If an issue is created or modified to have the
topic listed here, the user on this page will be added to the nosy
list automatically.
Displayed at the top of the page is a link to the same view as
the tickets link in the user index page so that you can quickly see
prior ticket by this user.
In the future other searches including issues where the user is nosy
on the ticket etc will also be supported.
Even though you may not be able to view all of the fields on another
user's page, you can view your own by selecting the "My Details" link
in the left hand column. The fields are:
- Name - the user's real name.
- Login Name - the login name listed as the user in all fields.
- Login/Confirm password - type in your password for the web
interface and type it in a second time to confirm the entry.
- Phone - phone number of person.
- Organisation - the orgsanisation/department etc of the user.
- Timezone - times in roundup are stored in GMT. This is added (or
subtracted if negative) from the times when they are listed in
the web interface. See the timezone section below
for some issues.
- E-mail address - email is sent to this address. It is the primary
email address of the user.
- Alternate email addresses - often people have multiple addresses
that they can send email from. E.G. on the machine foo, I may be
foo@exampleSTOPSPAM.org, but I receive my email at
rouilj@exampleSTOPSPAM.org. The email addresses listed here will allow
the proper user to be assigned to the inbound email even if it is
sent from a different system.
Below these fields a table of your available/assigned queries is
displayed. This table provides the ability to edit, display or remove
the query from your list of queries. At the bottom of the page is
shown a history of changes to the user.
The timezone is a pure number. It is not a timezone like EST5EDT. You
will have to change your offset when the clocks change.
Also the timezone is added to all times regardess of the date. E.G. If
I look at an issue with messages from December, which should be -4
hours from GMT in July when its -5 hours from GMT, the time will be
modified by -5 hours (my current timezone setting) rather then the -4
hours that it should be modified by.
Clicking on the link at the top of a user's page, or on the
(tickets)
link next to the user's name in the user list
will provide a list of tickets that the user has requested.
The attributes shown in issue and message views are listed in alphabetic
order below. For each attribute, the display title is given first, and the
internal attribute name is given in parenthesis after the display
name. The internal attribute name is what is displayed in pull down lists.
After that is the type of attribute for which you should look at the
standard roundup documentation to find out how to interact with that
attribute type.
The actionclearonmessage attribute is a boolean value that if set will
cause the actiondate to be cleared if a message is submitted to the
issue.
The comment to be sent when the action occurs. It will be added to the
issue. Note that there is no actionreply, so the text entered here
will not be sent to people on the Watcher list.
A date whose time is ignored, only the date
portion is used. On that day the action will occur.
- Type: Constrained (Link to Status)
The issue will be changed to this status when the action
triggers.
- Type: Constrained (Link to User)
The name of the person currently working or responsible for this
issue. If you want to have multiple people responsible, you can group
issues together, of use the dependson relation to divide the issue
into multiple parts.
Store billing info for this issue.
- Type: String, comma separated list of email addresses
This field is only shown in the web interface. It DOES NOT exist in
the database. It provides a way to send a message to people not on a nosy
list for the issue. It is equivalent to sending email to the tracker
with other recipients on the To or Cc lines of the email. Enter a
comma separated list of valid email addresses. It will not accept
user names, you must use email addresses. This is also a fast way of
creating a new user at the given email address.
- Type: Constrained (Link to Issues)
The list of issues that this issue depends on. The issues will be
listed with a letter after their names. See #IssueStatusIndicators
for information on the letters. Also see #IssueRelationshipsDependson
for further details.
The date the issue should be completed on.
FYI (fyi)
Used to record summary notes and details that get buried in the issue
trail. Useful for noting ticket Id's for phone calls, serial numbers
of equipment etc.
- Type: Constrained (Link to Issues)
The list of issues that this issue depends on. The issues will be
listed with a letter after their names. See #IssueStatusIndicators
for information on the letters. Also see #IssueRelationshipsGroups for
further details.
The estimated amount of time that solving this issue will
take. In theory, the due date - the lead time is the theoretical
start date for the issue.
So in theory this is the same as the difference between the Start Date
and the Due Date. However, it may be advantageous to have an issue
done before the due date. In this case, the math won't work out, but
the actual completion date will be the start date plus the lead time.
With a suitable escalation program, (not yet written), this can be
used with the due date to escalate the priority of the issue.
- Type: Constrained (Link to Messagetype)
When creating a new note/message you need to select the message
type. If you select 'reply - to all', it will be emailed to all the
users on the Technical and Watchers lists. If you select 'comment - to
technical', the new message will be emailed only to the people on the
technical list.
Note that right now both types of messages are visible to all users in
the web interface. This will change in the future with the comment
messages being shown to a more restricted group of people.
Set to true if issue is not new and the last person to add a message
is not the assignedto person. If there is no assignedto person, then
set to true if last message addition not done by person on technical
(verynosy) list. This causes different display of issues that need to
be responded to. It is useful if you are working in the field, and
have a browser, but no email access to be notified of responses to
issues.
- Type: Constrained (Link to Priority)
Used to set the priority of the issue. The defined priorities are
defined in #IssuePriority.
- Type: Constrained (Link to Queue)
Categorizing an issue to be handled by a particular group of
people. Associated with each queue is a default announcement list that
is independent of the Watcher or Technical lists. This default list is
used to announce the issue if nobody is assigned to the issue.
- Type: Constrained (Link to User)
Used to record the person who requested this issue. It's auditor sets
it to the creator of issue by default. It is useful for help desk
purposes, where the person creating the issue is not the person
requesting the issue.
Unlike the creator attribute associated with an issue, this can be changed
to reflect the person actually requesting the issue rather than the
person who physically created the issue.
- Type: Constrained (Link to Issues)
Used to link issues that are related in some way. E.G. an issue is
created because the printing subsystem, is backed up. The first line
support person can't clear the problem because he doesn't know how.
So he passes it to the second line person. The second line person
finds an issue that describes how to solve this problem and put the ID
of this issue into the See Also attribute, and reassigns it to the first
line support person.
It can also be used to link related issues for justifying purchase of
a new disk. Every problem that comes in that can be solved by
purchasing a new disk can be put into the seealso attribute so that a
report can be generated of all the additional work caused by the lack
of disk space. Also see #IssueRelationshipsSeeAlso for further
odetails.
Enter the day the task should be started. If you wish the issue to be
automatically opened on this date, see the Action Date attribute.
- Type: Constrained (Link to Status)
Set the status of the issue. The defined statuses and their meanings
are defined in #IssueStatus.
- Type: Constrained (Link to Issues)
This is only visible on the edit fields or default issue view if it is
not empty. It is left in place for compatibility with the classic
trackers, but should not be used in the sysadmin tracker. Use the
dependson, groups and seealso attributes/fields instead.
- Type: Constrained (Multilink to User)
People in this list receive forwarded email for both comment AND reply
messages.
- Type: Constrained (Multilink to Timelog)
Enter the amount of time worked on the issue here. This is actually
linked to both the issue and any message that is created with it. Thus
you can look at a message (that documents a particular phase of solving
the issue) and find out how much time it took to perform the phase.
This is useful for future planning.
This can not be access via the email interface at this time.
The title for the issue. It should be descriptive and easily
distinguishable from others. For example use: "Build computer system
for Joan Jetty" rather then just "Build computer system". This line
will be shown in issue lists under the Title field.
- Type: Constrained (Multilink to Keywords)
This is used to categorize the issue. E.G. keywords like hardware,
software user_error can be assigned to the issue. This allows
statistics gathering in the future.
- Type: Constrained (Multilink to User)
People in this list receive forwarded email for ONLY reply messages.
Used to assign a working order to items. Useful when you have lots of
things at the same priority.
This section assumes that you have read the roundup documention on
installing a tracker.
These tasks need to be done by somebody with access to a user or
administrtor interface on the computer hosting the tracker. They can't
be done through the web interface.
If you are using the email interface, you will need to set up (at
least) two mail aliases for each tracker. The first alias is used for
issue creation and replies to the issues. If you are not using queus,
or you don't want a separate email address per queue, the sendmail
alias file looks like
tracker: |/tools/roundup/bin/roundup-mailgw -C msg
-S "messagetype=reply - to all" /var/roundup/sysadmin
(the lines are split for readability. In the alias file they will be
on the same line). Replace /tools/roundup/bin/roundup-mailgw by your
path to the roundup-mailgw. This creates the alias tracker. All
messages sent to it have their messagetype attribute set to "reply -
to all". The roundup tracker instance is located at
/var/roundup/sysadmin.
Then the comment alias is created and looks like:
tracker_comment: |/tools/roundup/bin/roundup-mailgw -C msg
-S "messagetype=comment - to technical" /var/roundup/sysadmin
(the lines are split for readability. In the alias file they will be
on the same line). Replace /tools/roundup/bin/roundup-mailgw by your
path to the roundup-mailgw. This creates the alias
tracker_comment. All messages sent to it have their messagetype
attribute set to "comment - to technical". The roundup tracker
instance is still located at /var/roundup/sysadmin.
If you are not using queues, or do not wish to have queue specific
addresses, then you are done with the special email setup for the
sysadmin tracker. You still have to handle the email setup specified
in the roundup documentation.
If you would like to have queue specific email addresses, say one for
each department: sales_tracker, development_tracker... per problem
queue: networking_tracker, email_tracker, web_tracker... etc. Then we
look at the following aliases:
sales_tracker: |/tools/roundup/bin/roundup-mailgw
-C msg -S "messagetype=reply - to all"
-C issue -S queue=sales
/var/roundup/sysadmin
sales_tracker_comment: |/tools/roundup/bin/roundup-mailgw
-C msg -S "messagetype=comment - to technical"
-C issue -S queue=sales /var/roundup/sysadmin
The major difference between these aliases and the ones above is the
setting of the queue attribute to "sales" for the issue class. You
would set up one email address pair for every queue that you use.
There are some settings in config.py that are unique to the sysadmin
tracker.
Set the NEW_ISSUE_ANNOUNCE_DEFAULT variable to an email address where
you want all new issues without an assigned queue or assignedto person
to be announced. If it is set to None (the default) no email will be
sent if queue is unassigned. If queue is assigned the email
address(es) associated with the queue will be used.
Multiple email addresses can be specified using a , between them. No
space is allowed in the string. A couple of examples are:
NEW_ISSUE_ANNOUNCE_DEFAULT = "sysadmin@example.com,sysadmin2@example.com"
NEW_ISSUE_ANNOUNCE_DEFAULT = "sysadmins"
Set the DEFAULT_PRIORITY variable to assign the priority to issues
arriving via email that don't have a priority. This is the way to
force a priority on email'ed issues. For the web, setting a priority
is enforced in the cgi. You can create a "Needs priority" priority
and use that as the default as an indicator that somebody need to look
at the issue and assign it a real priority. This is used in the
default_priority.py detector/auditor. The default priority is routine.
DEFAULT_PRIORITY = 'routine'
Set COMMENT_TRACKER_EMAIL to the alias used for handling comment
emails. This is usually the same as TRACKER_EMAIL except for comment
messages rather then reply messages. If you choose the default with
the _comment suffix, then there is no need to set this value, it is
calculated automatically.
COMMENT_TRACKER_EMAIL = 'tracker_c@%s'%MAIL_DOMAIN
There are some functions that are carried out on a scheduled basis. On
Unix, you can use cron, or self submitting at jobs to do this. On windows
you may be able to use the at command or other scheduler. The two jobs
done on a scheduled basis are to send daily (weekly) reminders to all
assigned people about the issues they have open. Also the automatic
action feature is carried out by a daily cron job.
Edit the cronjobs/roundup-reminder script to set the path to the roundup
install directory.
Add the script cronjobs/roundup-reminder to the crontab of the user
your cgi and mail gateways run as. Run the script daily (or weekly or
any other schedule you want) in the early morning. It is called with
the path to the roundup tracker home directory just like the
roundup-admin command.
Edit the cronjobs/roundup-action script to set the path to the roundup
install directory.
Add the script cronjobs/roundup-action to the crontab of the user your
cgi and mail gateways run as. Run the script daily in the early
morning. It is called with the path to the roundup tracker home
directory just like the roundup-admin command.
You can customize the tracker classes as well. However some detectors
may need to be modified since they will often embed the names of
priorities and statuses in them. So you can change it in the web
interface, but you may also need to get access to the system command
line to fully implment the change.
There are a number of supplimentary classes in the hyperdb.
queue.create(name="Integration", email="donotsend", order="1")
Status items have 6 attributes:
- name - the name of the status (e.g. new, open etc.)
- order - number indicating the sorting and display order for the
status.
- help - currently unused, but meant to be a brief description of
the purpose of the status to be used in on-line help.
- abbreviation - a one character abbreviation for the status. Used
when displaying linked issues.
- transitions - list of valid statuses that this status can follow.
- requiredpermissions - list of permissions required by the user to
set an issue to this state.
The name, order and help attributes are self explanatory.
The abbreviation attribute is used to indicate the issue status. See
Issue Status Indicators for more
information.
The transitions attribute specifies what the current state of an issue
must be in order for the new state to be selected. E.G. if the testing
state had its transitions attribute set to: "open,hold,stalled" then
an issue that was in the new state couldn't be transitioned to the
testing state. The issue would have to be moved from new to one of the
open, hold or stalled states before it could be moved to the testing
state. The value for this is the comma separated list of states. If
you are changing this in the CSV interface, you must enclose the
string in double quotes if you specify more than one state. If this
field is empty, the state can be selected from any prior state.
The requiredpermissions attribute lists the permissions the user must
have to select this status. E.G. you may only want managers to be able
to resolve an issue, or you may want to stop regular users
(i.e. people who generate the issues rather then the people who solve
the issues.) from selecting any state except new and resolved. This
attribute takes a comma separated list of required permissions. You
can include spaces as well as comma's to increase readability. If
changing this in the CSV view, you must include the string of
permissions inside of double quote (") marks if you specify more than
one permission. If this attribute is empty, anybody is able to select
this state.
Changing the names of the status will require detector changes.
If you are starting with a fresh tracker, you can skip this
section. If you want to import data from a classic tracker into a
sysadmin tracker, you should read this section.
Many items (topics, nosy etc) will translate without a problem. The
superseder relation will be displayed as needed.
- create a new initialized sysadmin tracker with the same database
type as your classic tracker.
(**FIXME fix what?? Fix the page file as described above.)
- shutdown classic tracker.
- backup classic tracker.
- copy the detectors and html directories from the newly
initialized sysadmin tracker to the classic tracker's directory.
- copy the database files for new objects into the db directory.
don't overwrite any of the class .db files that already exist.
I don't know how to do this with anything other then the dbm or db
databases. (e.g. mysql, or sqllite)
- merge settings in classic config.py into sysadmin tracker config.py
and use the sysadmin config.py.
- Copy the dbinit.py and interfaces.py file from the sysadmin
tracker into the classic tracker.
- Bring up the classic tracker.
- Add the 3 searches (Note: they are wrapped for readability,
leading spaces on following lines should be removed.):
klass="issue" name="WatcherTechnical"
url=":columns=title,id,status,queue,topic,duedate,
creator,assignedto,activity,nosy,verynosy&
:pagesize=50&:startwith=0"
klass="issue" name="Relationships"
url=":columns=title,id,status,queue,duedate,assignedto,
activity,dependson,group,seealso&:filter=status&
status=-1,1,2,3,4,5&:pagesize=50&:startwith=0"
klass="issue" name="Schedule"
url=":columns=title,id,status,queue,duedate,leadtime,startdate,
creator,assignedto,activity&:sort=-duedate&:pagesize=50&
:startwith=0&filter=status&status=-1,1,2,3,4,5&
@sort=-leadtime&@group=duedate"
using the CSV interface.
- remove the leading ?'s from the url fields in the tracker
queries using the CSV interface.
- set status class abbreviation property otherwise you don't get
abbrevs on issue links. Change description/names of states so that
resolved, new (unread) and open (chatting) exist.
- set default announce email for new issues. Change from sysadmin.
- set email addresses for per queue announcements if needed.
- run scripts to link files associated with issues to the issue so
they are displayed in the gui interface. A Bourne shell script
like:
#! /bin/sh
PATH=/tools/roundup:$PATH
roundup_home=/data/roundup/admin
for i in "$@"
do
case $i in
[0-9]*) issues="$issues $i"
;;
/*) roundup_home=$i
esac
done
for issue in ${issues:-`roundup-admin -s -i ${roundup_home} list issue`}
do
echo "Running over issue $issue"
files=""
for msg in `roundup-admin -s -i ${roundup_home} get messages issue$issue`
do
echo "Scanning message $msg"
files="$files,`roundup-admin -c -i ${roundup_home} get files msg$msg`"
done
if echo "$files" | grep "[0-9]" > /dev/null; then
files=`echo $files | sed -e 's/[,],*/,/g' -e 's/^,//' -e 's/,$//'`
echo "Files are $files"
roundup-admin -s -i ${roundup_home} set issue$issue files=$files
fi
done
This will take a while, but it runs over all issues making sure to set
the files attribute of the issue to the union of the files
attributes for all the issues messages.
- You will be able to see your superseder field unless it is empty.
At which point you can forget it exists.
See the roundup customization document for technical issues.
One idea that may be useful is to have an auditor that puts items in
the dependson list on the blockers list if the item is not resolved.
The auditor would also remove issues from the blocked list when they
are resolved. This would allow you to suppress display of issues that
are blocked because they have unresolved issues. While the blockedby
field exists, and is displayed at this time (7/2003) the detector is
not written since the plan is not to change the blocker field
directly, but to change it in sync with the dependson field.
In the sysadmin tracker, currently the preferred way to handle this is
to stall the depender issue until all the depended on issues are
resolved. Then the detector automatically opens the depending issue.
Enhance the tracker to include asset tracking by creating a new
hyperdb issue like object called asset. This asset can be linked to
messages to record repairs, changes of ownership, etc. Also these
assets can be linked into a hardware field of an issue to record the
issues caused by this hardware.
(Note: I use a Bourne like shell, so where you see SENDMAILDEBUG=...
before a command invocation, you should set the environment variable
SENDMAILDEBUG before running the command, and remove the
SENDMAILDEBUG=...[space] stuff from the command line if you you a csh
like shell.)
Create new tracker:
/tools/roundup/bin/roundup-admin -i /var/roundup/testing \
install sysadmin bsddb admin
edit the config.py to set url to point to testing rather than
sysadmin.
/tools/roundup/bin/roundup-admin -i /var/roundup/testing \
initialise admin
run
roundup-server -p 8080 -n 127.0.0.1 testing=/var/roundup/testing
test the following:
- log into the tracker as admin pw admin
- create issue with title issue1 and priority high
- create issue with title issue2 and priority low
- create issue with title issue3 and priority routine
- create issue via email by sending:
From: "rouilj"
Content-Type: text/plain
Subject: test 4a
To: issue_tracker@example.org
MIME-Version: 1.0
Message-Id: <1034901317.14.0.292086518234.issue@example.org>
Content-Transfer-Encoding: quoted-printable
New issue via email.
to stdin of:
SENDMAILDEBUG=/tmp/smd.email roundup-mailgw -C msg \
-S "messagetype=reply - to all" /var/roundup/testing
msg should be created with an email to rouilj@exampleSTOPSPAM.org. The created
issue should have:
nosy: rouilj@example.org
priority: routine
status: new
title: test 4a
An email should be sent out to rouilj@exampleSTOPSPAM.org with a reply address
of: issue_tracker@exampleSTOPSPAM.org. The subject line of the email should
include the proper issue tag. An identical message should be sent to
sysadmins.
Also the created message should have type reply.
- Add user admin to technical list and send the following email:
From: "d1"
Content-Type: text/plain
Subject: [issue4] test 4a
To: issue_tracker@example.org
MIME-Version: 1.0
Message-Id: <1034901317.14.0.292086518234.issue@example.org>
Content-Transfer-Encoding: quoted-printable
New issue via email.
where issue4 is REPLACED by the issue just created in the last
step. Send this email to:
SENDMAILDEBUG=/tmp/smd.email roundup-mailgw -C msg \
-S "messagetype=comment - to technical" /var/roundup/testing
An email should be sent out to roundup-admin@exampleSTOPSPAM.org with a
reply address of: issue_tracker_comment@exampleSTOPSPAM.org. The subject
line of the email should include the proper issue tag.
This finishes basic test of mailgw setting message type (or any
prop) verynosy and nosy message processing as well as default_priority.py
- make issue4 depend on issue1. Change status to resolved issue4.
Should result in an error that issue1 must be resolved. Change
status of issue4 to stalled.
- goto issue1 resolve it. Then go to issue4.
- issue 4 should be open. Change status to resolved. should work.
- on issue 4, remove issue1 from depends on list. Add issue 1 and 2 to
group relation.
- stall issue4. Goto issue1 and issue 2, they should also be stalled.
- add message to issue1. It should open issue1, issue2 and issue4.
- goto issue4, it should be open and have last message at the top of
its message list. Goto message 2 it should not have the latest message.
- add message to issue4. It should be in issue1 and issue2.
- edit the queue class. Empty the email address field for support.
- Create a new issue with integration as the queue and a message.
no email should be sent out.
- Create a new issue with support as the queue and a message.
email should be sent out to sysadmin.
From: "d1"
Content-Type: text/plain
Subject: test 4a [queue=Support]
To: issue_tracker@example.org
MIME-Version: 1.0
Message-Id: <1034901317.14.0.292086518234.issue@example.org>
Content-Transfer-Encoding: quoted-printable
New issue via email.
to
SENDMAILDEBUG=/tmp/smd.email roundup-mailgw -C msg \
-S "messagetype=reply - to all" /var/roundup/testing
testing automatic actions:
- Create new issue on the web interface.
- edit the issue and add today's date to the actiondate field, set a
status of hold.
- from the tracker directory, run the roundup-action script with the
path to the tracker like:
SENDMAILDEBUG=/tmp/mail crontabs/roundup-action $PWD
- the issue should have its status changed to hold, and the action
fields (actiondate, actionstatus, actioncomment) should be empty.
- edit the issue and add today's date to the actiondate field, set an
actioncomment.
- run the roundup-action script as above.
- the issue should have its status unchanged, (even if a nosy reactor
or something triggers) and should have a new message and the action
fields should be empty.
- edit the issue and add today's date to the actiondate field. Don't
set any other action fields.
- run the roundup-action script as above.
- the issue should have its status unchanged, but there should be a
history entry showing the unchanged status. Also the last changed
time for the issue will be updated.
As with all new software there are some gotchas or bugs that can't be
worked around.
You set resolved on an issue, and enter a message. You submit the
change and see that the message has been entered, but the ticket is
not resolved.
This occurs when the issue is groupedby another issue. What happens is
that the message you enter is propigated to the parent issue (the
grouper). Then the parent issue has been changed and it tries to
propagate its status to its child issues. This overrides the status
set in the web interface.
This could be considered a bug. I am not really sure how it should
work. To solve the problem, enter a message, then set the status
without a message. This should stop the upward propagation that occurs
for messages and clobbers the set status.
Now is the fact that you can set the status of a grouped issue
independently of its grouper a bug??
It is possible to create a loop of issues such that a depends on
issue is also a group issue of some parent issue. In this case, you
will not be able to resolve the issue because:
- Resolving the group issue will change change it resulting in its
being reopened, which reopens any issues the have it on the
dependson list.
The detectors do detect using the same issue on an issues dependson
and groups attribute, or assigning the issue to its own dependson or
groups attributes. They just don't walk the entire tree looking for
loops.
The solution is to get rid of the group or depends link that is
causing the loop.
Microsoft Outlook does not follow the standard for creating
continuation header lines in email. Outlook will fold the subject line
in the middle of a word rather than folding only at whitespace as
specified by RFC822 and later RFC2822. When the line is rejoined,
whitespace is inserted at the point of the fold as specified by the
RFC's. This can cause unintended white space to be added to the
subject line which prevents the subject line parser from recognizing
the [] enclosed attribute settings. E.G. it can turn "[status=resolved]"
into "[statu s=resolved]". Because of this, it can be difficult
to set attributes using []'d commands at the end of the subject
line. Until Microsoft manages to fix their software, this problem will
continue to exist, but by judicious padding of the subject line with
spaces the issue can be worked around although its a major pain in the
a**.
There are many areas for enhancement. A few open ideas include:
- provide a link in the timelog listing to the message that
was submitted with that timelog entry.
- implement a very nosy keyword field for the user object to add
the user object to the verynosy list if the listed keywords are
added to the issue's topic. See the implementation of the
nosy_keyword in the user object described at #WorkingWithUsers.
- implement blocking by adding functionality to the
dependson_semantics.py detector to keep the blocking field up to
date.
- add a button/link called
create dependson
for a message (or
issue) that will:
- create a new issue entry form with the change note filled with
the current message, or empty if invoked at the issue level.
- when the issue is created, add the newly created issue to the
dependson list of the original issue.
This is great for splitting tickets into multiple chunks.
- currently a help desk person can't create a new caller easily.
They need to get to the registration page and involve the caller
in the creation process. This isn't good. There needs to be a way
for a help desk worker using roundup to create a new user similar
to the way the admin can do it. Maybe a finer grain permission
for the user (say helpdesk) that includes the ability to create a
new user. This isn't an issue for me since our "help desk" people
are also admins, and most of our people submit tickets by email
thus autocreating the user. As a workaround the Cc field in a
message will create the user, but no info like phone number,
company etc can be filled in.
- there is a filestatus that is meant to label files with obsolete,
current etc so older version of files can be labeled as obsolete.
This is not currently in the templates.
- support for setting timelog via the email mechanism. Something
like [msg.timelog=2:10] at the end of an email subject line
should set the timelog entry for the newly created message.
- in the web interface, all statuses are listed for all users.
However all users may not have the rights to assign a given
status, or a given status may be invalid given the current
status (see Status). The status transitions
are enforced in the detectors, but only valid statuses should be
listed in the web interface. This requires an additional function
in the utils class to filter the displayed statuses that I
haven't written yet.
- the link to turn off AutoRefresh should not list the time
in seconds. It should list it as the select box does, sec,
min or hours.
- comment messages should not be visible to people that are not on
the Technical list. This needs to be fixed in the web
interface. Also it should be possible to enable people to see the
comments even if they are not on the technical list. Think about
a viewcomments permission and a per issue viewcomments multilink
to the users. The viewcomments field will need to be protected by
an auditor and limit changes to those who can already see the
comments, or to admins.
- Limit user access to issues. E.G. mark an issue as
private so unauthenticated users are not able to access it.
Or mark it queue admin or admin only. People on the nosy lists
should be able to see the issue. The searches should respect this
and not show restricted issues.
- An announcement email should be sent when a ticket is opened
because a previously resolved depended issue is unresolved.
- users should be able to be assigned to monitor issues (or limited
to seeing) issues in particular queues. Maybe add a multiselect
called queuewatcher to the user object.
- Emulate the following from RT.
"Goto ticket" has been replaced with a smart "Search" feature which
does a pretty good job of guessing whether you're trying to go to a
specific ticket, search for all tickets from a given email address,
find all new/open tickets in a given queue or search for tickets whose
subjects match a string. Thanks to Chris Reinhardt
- Implement other searches on the user detail page including
including issues where the user is nosy etc. to get more info
about the user.
- Implement reports via command line (in CSV and table output) and
web interface (with CSV download). This should be a standard
spreadsheet type display with the verical column vs the horizonal
row. So assignedto vs ticket status will provide the assignedto
people down the left hand side of the table and status across the
top row. Also if selectable is requested the user can select
which statuses they want. Also if groupable is there, the
selected items can be grouped into a single column, e.g. working
group may be everything except resolved, dead, delete and this
will be a valid column in the table. I have a command line
program that will do some of this. The report types I have come
up with:
- count of tickets for assignedto vs (selectable, groupable)
ticket status.
- count of non-resolved tickets per assignedto person.
- count of tickets assignedto vs (selectable, groupable) ticket
priority.
- count of tickets requestedby vs ticket status.
- count of tickets requestedby vs ticket priority.
- count of tickets non-resolved assignedto vs timeperiod
- average time spent to resolve ticket per priority
- average time to open ticket per priority
Here are some roundup core enhancements that this tracker would
benefit from.
** Support multiple sorts - eg. first by due date and the subsort by
lead time.
** Email gateway arguments to -S (set) should do lookup by key field or
id number, so messagetype=2 works.
MULTIPLE DATE FORMATS:
** Create dictionary of date formats. Select with us, uk etc country
code. E.G.
local_date_re={
'us': ( re.compile(r'''
((?P<m>\d\d?)/(?P<d>\d\d?)(/(?P<y>\d\d\d\d))?)? # mm/dd/yyyy
(?P<n>[. ])? # . space
(((?P<H>\d?\d):(?P<M>\d\d))?(:(?P<S>\d\d))?)? # hh:mm:ss
(?P<o>.+)? # offset
''', re.VERBOSE), _("format mm/dd/yyyy not found") ),
'uk': (re.compile(r'''
((?P<m>\d\d?)\.(?P<d>\d\d?)(\.(?P<y>\d\d))?)? # mm.dd.yyyy
(?P<n>[. ])? # . space
(((?P<H>\d?\d):(?P<M>\d\d))?(:(?P<S>\d\d))?)? # hh:mm:ss
(?P<o>.+)? # offset
''', re.VERBOSE), _("format mm/dd/yy not found") )
}
then loop using something like:
if config != None :
date_match_error = ''
for country in config.COUNTRY_DATE_FORMATS:
m=local_date_re[country][0].match(spec)
if m is not None:
break
date_match_error = date_match_error + local_date_re[country][1]
where COUNTRY_DATE_FORMATS is in config.py and looks like:
COUNTRY_DATE_FORMATS = ['us', 'uk' ...]
The first tried format is always serial format and the last format
is roundup standard format.
sourceforge feature tracker 2/22/2003
**Show who last did the activity on the issue. To go along with the
last activity date field. It should be a request in the sourceforge
feature tracker. This can be implemented in the tracker, but really
should be in the core.
**Need bulk update functionality.
- attribute
- a property of a roundup HyperDB item such as title,
priority, email address etc.
- blocker
- An depended issue that is not resolved and is preventing a
depending issue from being worked on. A manual implementation of
this can be found in the roundup customization document.
- groups
- A relationship between issues. If issue A groups issue B,
then issue B appears in issue A's groups attribute. Issue a is
the grouping issue and issue B is the grouped issue.
- grouped
- The target of the groups relationship. I.E. a grouped
issue is one that is listed in another issues groups attribute.
- grouping
- an issue that has a non empty groups attribute.
- change notification email
- email that is sent out in
response to a new message being received by an issue. Depending
on the type of email (comment, or reply) it is sent to different
lists of people.
comment messages:these messages are used to interact with
other technical people, and are forwarded only to the Technical
list.
- depended
- The target of the dependson relationship. I.E. a depended
issue is one that is listed in another issues dependson
attribute.
- depending
- an issue that has a non empty dependson attribute.
- dependson
- A relationship between issues. If issue A depends on
issue B then issue A can not be resolved until issue B is
resolved. Issue A is the depending issue and issue B is the
depended issues (target of the depends on relationship) issue.
- field
- the entry mechanism for an attribute in the web
interface. Also has the same meaning as attribute or value of
the attribute.
- requestor
- A user who is requesting an issue to be solved. Usually
the same as the issue creator if the requestor has access to the
tracker via email or web.
- reply messages
- these messages are used to interact with the
requestor via the Watcher list and are forwarded to both the the
Watcher and Technical lists.
- roundup administrator
- the person who sets up the sysadmin
tracker, and establishes the web interface, email addresses and
automatic tasks (cron jobs) required for the tracker to work.
- seealso
- a relationship between issues with no defined
requirements.
- staff
- A person with the Repair user role. This person is expected
to resolve jobs in the tracker.
- tracker
- An instance of a roundup database, rules for handling
issues and associated web and email interfaces.
- tracker administrator
- the person who is responsible for
adding user to the tracker, establishing the priorities,
statuses, edits keywords and handles day to day operation of the
tracker. Most of these tasks can be done via the web interface
with no other system access.
- user
- Anybody who uses the system. This includes:
- requestor
- person asking that something be done
- staff
- person solving the requesters problem
- manager
- person managing the staff
This tracker is released under GPL version 2
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
675 Mass Ave, Cambridge, MA 02139, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
Appendix: How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
Copyright (C) 19yy
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) 19yy name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, the commands you use may
be called something other than `show w' and `show c'; they could even be
mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the program, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.