/ticket system

• User-accessible directory: /ticket/
• Ticket system administration directory: /ticket/admin/
• Site administrator directory: /admin/ticket/ (empty)
• data model : /doc/sql/ticket.sql
• Remote project administration using this module

The big picture

The medium picture

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

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:

    PROBLEM STATEMENT:
    
    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

• 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).