Support Ticket System
The support ticket works closest to the project / timesheet concepts of Tryton. The models are
Ticket
historised
_inherits = {'timesheet.work': 'work'}
name field will be filled with the sequence of ticket
- work = Many2One - timesheet.work
- title = Char
- owner = Many2One - party.party
- comment = fields.Function(getter-set empty, setter-set the field)
- assigned_to: Many2One company.employee
- follow_ups: One2Many History (refer History Fields tree below)
- state = Many2One ticket.states
- last_updated_by = Invisible Char field to be filled at Create Write from the context. If GTK client, then fill the User, if by email the context should be appropriately set in the context.
History Fields (Tree)
- datetime
- author (Char - Employee/Party/User/email - depending on write mechanism)
- comment
- state
History Fields (Form)
- datetime
- author
- title
- owner
- comment
- assigned_to
- state
States
_name = "ticket.states" _order = sequence ASC
- name: Char
- sequence: Integer
Configuration
_name = "ticket.configuration"
sequence = property(Many2one(ir.sequence)) (by default sequence with prefix 'ticket' Note:define in XML for the sequence prefix)
Presentation
Menus
- Support Management
- Configuration
- Tickets
- Tickets by State
- New Ticket
Future Improvements
- Integration with email system
- Generate ticket from email
- Update followups by email
> Ticket inherits = {'timesheet.work': 'work'}
I can not see a reason why here is inherits used. May you explain, please?
Like that employee could enter timesheet lines on ticket. It is the same concept that makes project.work inherit timesheet.work.
I think the term "author" might convey meaning better than "writer".
Also, what about the ability to reference a parent ticket? For example, when a Telecom has a fiber cut that affects many customers.... often one ticket is opened up on each customer until the common component is identified; when the ticket on the common component is opened, the other tickets are "closed into" the main ticket.
How about multiple queues? This is useful when tickets might be opened or triaged by a call center, then placed in the proper queue. Support representatives with expertise for the specific queue might have a search which limits only to their queue....
Another concept often used is a "pop-up date". The concept here is that a goal of touching tickets every hour or two is often not possible, because one of the tickets might have an external dependency which won't complete for several hours. Thus, one might set a "pop-up date" on the ticket, which is used to suppress the ticket from rotating to the top of the search, when sorted by last_updated_time descending. This could basically be an ir.cron task, which, at the time of the pop up, just removes the "pop-up date" value.
I'm not completely clear on the reason for having owner and assigned_to on both ticket and history... At first, I suspected that the purpose was to have a "history" entry when a ticket is reassigned from one employee to another. However, the "owner" field confuses me.... it would be rare to reassign the ticket from one company to another, no?
Also, the overall ticket and history fields should have both a "public" and "private" comments field. In all cases, the public comments fields should each have a "publish" boolean, which notifies the recipients.
Speaking of recipients, there should also be both a main ticket recipient list, as well as the ability to add a recipient to an individual history entry. This list should permit both linked contact records as well as a simple char entry for an occasional email address.
Just my thoughts, from years of working with Clarify, Remedy, RT, Footprints, and numerous homegrown systems.
--phil
Agree on "author". All others comments have been discussed on irc. We try to make a minimal (essential) ticket system, all other features will come by other modules.
I agree on the suggestion of author as well.
You can see the IRC logs here: http://www.tryton.org/~irclog/2010-08-14.log.html