ArsDigita Archives

/ticket system

part of the ArsDigita Community System by Tracy Adams, Henry Minsky, Jeff Davis

The big picture

Software occasionally has bugs. The ticket system is designed to to record and track tasks, bugs, and feature requests. The intent is to have clearly defined responsibilities for tickets in every state and to have auto-notification capabilities which ensure that no ticket slips through the cracks.

The medium picture

The new version is much more configurable and intended to support centralized tracking of multiple projects. Also, there are a number of new features to facilitate recording higher quality data on web development projects in particular. There is an interface into the ticket tracker which allows creating a link on each page for submitting a ticket which will record the user-agent, originating URL, and originating query.

Additionally, there are two ticket entry modes: "feedback," which hides all the complexity of the ticket tracker, and "full," which allows all fields to be set. Feedback mode is suitable for a feedback link in the footer of user oriented pages (and will also record user-agent and other data).

To see the feedback entry mode and the enhanced information tracking visit the "Feedback" link in the top right of the Administration screen.

User Model

Project and Feature areas are owned by groups. Tickets can only be assigned to users who are members of the owning group of the Feature Area. Tickets can be private to projects or to Feature Areas (depending on whether the "Public" flag is set) and will only be visible if the user is a member of either the owning group of the project or feature area. This restriction may also be applied on a per ticket basis.

Ticket Administration is carried out by members of the group Ticket Admin Staff, whose responsibilities include creating new projects and feature areas, project permissioning, and default ticket assignments per project/feature area. Adding a user to the Ticket Admin Staff group (group type Administration) gives the user full access to all tickets and ticket system administration capabilities.

Creating a Project

  • Create the necessary feature areas for the project via "create new feature area" in the admin screen.
    note that feature areas can be assigned to multiple projects so that it is not necessary to create multiple "System Administration" feature areas unless the staffing for System Administration was different between projects.
  • Create the project and assign an owning group.
    • Chose short and long titles. Short titles are typically used in tables while long titles are in reports and select boxes. These can be changed later without impacting pre-existing tickets.
    • The current "version" string is stored with each ticket when it is created.
    • Choose the "code set" that defines the all the ticket state codes (severity, cause, status, etc.) In a base install there will only be one "code set" and currently there is no admin interface for defining new code sets and the "ad" code set defines the standard set used within ArsDigita.
    • Decide whether the tickets should be public (visible to any registered user) or only to project members.
    • You may enter a long textual description of the project which will be displayed with the project on the new ticket creation screen.
    • You then can assign feature areas explicitly or just use the same set as another project.
    • Finally you may enter a new ticket template to guide user's data entry. For example, for a development project this might be something like:
  • Assign users to the owning group of the project and to the owning groups of the assigned feature areas (note that for small teams these can actually be the same group).
  • Set default ticket assignments via "view feature areas" for the newly created project.

Note that you can also create a project as a "copy" of another project. This is useful since you can create a "template project" with a set of feature areas such as System Administration, Admin, Automated testing reports, documentation, etc. preassigned.

You can also create a feature area and assign it to all the same projects as a pre-existing feature area.

New features in 3.1

User visible:
  • Per user persistent customizations ("Settings" at top right in /ticket)
  • Customizable table display and sorting.
  • Much "flatter" organization. Most functions now directly accessible from top level /ticket/ screen.
  • Meaningful sorting on all "coded" columns (severity, Status, Type, etc). Sorts are now "stable."
  • Scored "quick search"
  • Tickets comments now displayed on "/shared/community-member" page.
  • Tickets now "Alertable" with alert management via standard screens.
  • You can cancel/approve your own tickets.
  • Email notifications are much more informative.
  • index state is perserved in the context bar.
  • Per project named "milestones" supported for deadlines.
  • Tickets can be copied (not necessarily a good thing!)
  • Projects and feature areas can be copied.
  • Standard group management tools will work.
  • Comments and new tickets now show up in New Stuff with links for administration.
Non user-visible:
  • Much more "standard ACS" since it uses general-comments, normal auditing, and groups.
  • Cleaner data model with most things "data-driven."

Missing features of the old version

Some features of the original ticket tracker are currently broken or missing:
  • Email support -- in progress (with enhanced ticket dispatching via an adressee -> project/feature area mapping table).
  • No Past-due notification emails.
  • Cross referencing now simple ID# entry rather than the "search" driven interface from the old version.

Things to come

  • Integration with the intranet module.
  • Better tools to facilitate project management.
  • Tools for rolling tickets to new projects (Sharenet 5.6 -> Sharenet 5.7 for example).,