Top-level Files of tip
Not logged in

Files in the top-level directory from the latest check-in


This is a tracker with functions for a sysadmin or helpdesk use.

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:

    Defined relationships between issues including:
            dependson - shows dependencies and prevents sits from
                     being resolved if they have any unresolved
		     tickets that they depend on.
	    grouping (merging) - used to update multiple
		     similar tickets as a group.
            seealso - used to link issues that are related in some
		    way.

    Two types of messages: replies and comments.
            reply messages - are used to interact with the requestor
            comment messages - are used to interact with other
                        technical people.

       Note that right now both types of messages are visible to all
       users. This will change in the future with the comment messages
       available to a more restricted group of people.

    Two notification (nosy) lists:
            nosy (aka watcher list) - people on this list receive
                   only messages of type reply.
            verynosy (aka technical) - people on this list receive
                   messages of type reply or comment.

    The agent role has been defined and is used to restrict which
            users are visible in the assignedto listbox, or which
            users can be assigned to an issue via email. Also there
            is an auditor that will assign the first person to respond
            to an issue to that issue. See unused/autotake.py.

    Issues can be assigned to queues. Each queue can have its own
	   email list for unassigned issues.

    Issues support tracking the amount of time spent solving the issue.

    Issue has the extra fields 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 field 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.

        These are useful for automatically closing an issue, or
        generating a reminder on a given date. Currently only one
        pending action is supported. You can run the included script
        as a cron job to perform the action.
	
      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 field will have the same value
		      as the creator property, but this field 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 tickets 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 textarea
        filled with a quoted attributed version of the message you are
        replying to.

    In the web interface each message that is sent can be cc'ed to
        arbitrary email addresses.

    Wherever issue numbers how up, they also display an indication of
        the state of the issue. This is settable in the status class.

    The user 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.

   You can require that the person setting a particular state on
        an issue has a given permission.

   It comes preloaded with searches for displaying (in a limited way)
        relations between tickets, scheduling showing due dates,
        showing watcher and technical lists.

   Also 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
        every minute. 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 (thanks to a patch from
        Patrick Ohly)

   Date spec modified to support yyyy/mm/dd (and more importantly
        mm/dd) from patch by Luke Opperman.

   The user web page has a list of issues that this user has as well
       as a link to an index page of all issues created by the user for
       interactive sort and group 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.


MORE DOCS:

See README in the detectors directory.

GOTCHAS and BUGS:
It is possible to create a loop of tickets such that a depends on
ticket is also a group ticket of some parent ticket. In this case, you
will not be able to resolve the ticket because:

     Resolving the group ticket will change change it resulting in its
     being reopened, which reopens any tickets the have it on the
     dependson list.

The detectors do detect using the same ticket on an issues dependson
and groups field, or assigning the issue to its own dependson or
groups fields.

TESTING:

(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 cash
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" <rouilj@example.org>
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@example.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@example.org with a reply address
    of: issue_tracker@example.org. The suject 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" <d1@example.org>
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@example.org with a
    reply address of: issue_tracker_comment@example.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.

* Send the following email

=========
From: "d1" <d1@example.org>
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 ticket on the web interface.

* edit the ticket 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 ticket 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 ticket 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.

OVERLAYS ON CLASSIC TRACKER:
  create a new initialized sysadmin tracker with the same database
     type as your classic tracker. Fix the page file as described above.

  backup classic tracker.

  shutdown classic tracker.

  copy the detectors and html directories to the classic tracker.

  copy the database files for new objects into the db directory.
  don't overwrite any of the class .db files. 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 into the classic tracker.

  You will be able to see your superseeds field unless it is empty.
     At which point it will be ignored.

  Add the searches:

    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.

  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 annoucements if needed.

  run scripts to link files associated with issues to the issue so
  they are displayed in the gui interface. A shell script like:


  for issue in `roundup-admin -s -i /var/roundup/admin list issue`
  do
   echo 'Running over issue $issue'
   files=""
   for msg in `roundup-admin -s -i /var/roundup/admin get messages issue$issue`
   do
    echo "Scanning message $msg"
    files="$files,`roundup-admin -c -i /var/roundup/admin get files msg$msg`"
   done
   [ -z "$files" ] && \
     roundup-admin -s -i /var/roundup/admin set issue$issue \
            messages=`echo $files | sed -e 's/,,//g'`
  done

  This will take a while, but it runs over all issues making sure to set
  the files field of the issue to the union of the files fields for all
  the issues messages.