A system for managing support tickets

Common tasks

Creating a new ticket

1. User must register an account before asking for help
   • Maybe show a login / create an account on the same form, or create a two step process - the first form leads to the second.
2. User creates a new ticket using a form
   • The form is only a convenience to get a proper page using the correct template and with the required data.
   • What do we do if a visitor create a ticket page manually? I seems safer if there is only one way to create a ticket, from the form.
     • Please describe the security problems arising by hand-crafted requests.
3. Tickets use special names? location? both?
4. The user get a confirmation mail with the ticket (number)?

5. Support team notified by subscribing to the the ticket pages pattern, e.g. ^Support/Ticket.+

6. Or the ticket system notify all the users in PaidSupportGroup?

   • Just the people who subscribed manually. In order to simplify administration.

Assign Ticket to support person

1. Support person assign the page with a WikiBadge

2. The user will get notification when support add the badge? see bellow
3. It will be convenient if by assigning you also get subscribe to the page
4. One click to assign using a macro/action is better then editing

Changing the assignment

1. Support person replace the WikiBadge

2. The user should be notified
3. The previous support person may also be notified
4. Other support team may be notified only if they like too
   • Use subscribe to all ticket pages

Getting tickets status

1. How do we see the status of all tickets in the system? for example, get a list of tickets, sorted by status/support person/user requesting/ etc?

   • One option is using FullSearch macros, like current bug system. Hard to setup, slow, fragile - and we don't have any way to get nice sorted tables with all the data.

2. Tickets have common meta data that we can use for sorting/listing:

   • Saved as WikiBadge, can be edited or deleted like any text

   • What meta data we have for a ticket?
     • See the ticket page.
   • how we retrieve it?
     • Like always
       • With fragile regular expressions?
       • Or cached meta data, like page links. Each time you save, the page is parsed, meta data saved in a global ticket system cache.

Ticket protection

1. A user can read and write its own ticket pages
2. Support team can read, write, revert and delete all tickets
3. Other should not have any access by default.
4. Admin must have full control over the acl used, maybe add other groups

Here is a solution using templates:

1. Have the acl in a TicketTemplate page:

   • #acl SupportGroup:read,write,revert,delete
     #acl %(username)s:read,write
     #acl All:

   • The template page can go in the NewTicket macro, so one can have few types of ticket sub systems, each with different acl.

2. When creating a page, make sure page acl is equal to the template acl, or fail - the user creating the page can not change the acl of the template.
3. Then replace username with the username
4. Write the file.

Same system will work for any page created from a template, expect the username thing. It can be a general replacement like template = template % dict, either some variables are replaced in the template or nothing happens.

• It works exactly like you described

Notifications

It make sense that the user and the support group will be subscribed to ticket pages.

• How to subscribe groups?

User want to get notification when:

• They create a ticket
• Support assign to their ticket
• Support leave a message on the page

Support person want to get notification when:

• Other edit the ticket page

Other support team want to get notification when:

• Ticket created
• Ticket assigned
• Ticket closed?
• Other ticket editing may not be interesting

On other cases, for example, the user and the support person discussing the problem on the wiki, its may be not interesting for the rest of the support team.

Notification options:

• The user may subscribe the page if he like to be notified

• Or the system subscribe the user automatically, or add an easy option on the ticket creation page: [ ] Subscribe to page to be notified on changes

• Or opening, assigning, closing and other interesting actions are NOT done by an edit, but with an action that handle the notifications.
• In the last case, subscribing to ticket pages is an option for the user or support team.

Questions

1. Do we have more special tasks or use cases related to tickets?

Reference

Links to other ticket systems?

It will be a good idea to try Gallery support.

• Not really. Talking to people is enough. I did that.

Implementation

So far it seems that ticket pages are different from other pages by:

• Should be created by a form, using a template
• Have special dynamic acl set on creation
• May have different notification behavior, depending on how notification is implemented.

Notification issue

Hi Nir. Your last notify_editor thingie patch broke the NewTicket system completly because I cannot save save pages anymore while notifying the editor and ignoring ACL changes. This is because savePage is not meant to be used internally (at least if you look at the code flow). Please repair it or I will have to revert to the old state. -- AlexanderSchremmer 2005-06-20 16:30:47

Its not clear why saveText is not meant to be used and the previous solution - adding an instance variable - was wrong. What do you mean by "I cannot save save pages anymore while notifying the editor and ignoring ACL changes"? why you need to ignore acl changes? If the problem is ignoring acl, why not add a "ignore_acl" option?

• Because the code obviously handles the user interface, it needs e.g. a rev and handles conflicts. So please add that option. Otherwise you have broken the code
  • What option? ignore_acl? how rev and conflict handling are related?

20 hours left till revert.

• I don't like to code before thinking and discussing.
  • I do not like destructive ideas before constructive ones.

Create a TicketPage class?

If a ticket page can be identified by name or location (actually name), we can create a TicketPage instead of Page. The custom code used by a ticket page can be in that class, then we don't need to add complexity to Page. For example, if the notification behavior is different in ticket pages, override the notification code. If we have special meta data in a ticket page, the code to parse that data or to set it can be in that class.

• I don't really like this idea. What exactly lets those pages qualify as a ticket page?
  • The special name of ticket pages - we already use special names to identify groups, dicts and editor backup pages, and talked about xxxSidebar, xxxBookmarks etc. Isn't this the wiki way?
  Any kind of code can need this feature.
  • this?
    • Yeah, see above. Special ACL settings, notification of the editor etc.

We can have code like this:

   1 import sys
   2 
   3 class Page:
   4     pass
   5 
   6 class TicketPage(Page):
   7     pass
   8 
   9 class GroupPage(Page):
  10     pass
  11 
  12 def page(name, *args, **kw):
  13     className = name.split(None)[-1] + 'Page' # extended name for now
  14     pageClass = globals().get(className, Page)
  15     return pageClass(*args, **kw)

This will make it very easy for 3rd party developers to add special type of pages using plugins. For example, slide show can use a XXXShow pattern, gallery page a XXXGallery.