part of the ArsDigita Community System
by Tracy Adams
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.
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
- 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
- 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
STEPS TO REPRODUCE:
FOUND IN VERSIONS:
- 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
- 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.
- 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).