Table of Contents
The helpdesk module will be noted “HD” for ease of writing.
- Should HD Ticket Followupss be implemented as comments instead of nodes ?
- On the one hand, in many regards, they are to HD Ticketss what comments are to usual nodes on drupal
- On the other hand, there seems to be a trend amongst drupal developers (except the first of them ) to move away from the current separate implementation of nodes and comments and towards a unified node implementation.
- How will this assist with customer billing and record keeping?
- How will customer credits and payments be stored?
- How will this address hours spent?
- How can invoices be generated?
Here is how I see it:
- credits and payments are created as tickets and followups with negative billed values, meaning their duration, when substracted from the running credit total, actually adds to it, extending the contract.
- tickets have a txnid linking back to a transaction in the ecommerce module, where all the financial part of billing is done. Of course, if using another ecommerce module, the txnid can be used to store a transaction id in this other module
- invoices are generated by the ecommerce module
- hours spent (or number of issues) are simply calculated per-contract by adding the duration entered for every followup bound to the contract
Entities defined for the module
- a USER is a person experiencing issues and requesting help from the helpdesk
A UML UML class diagram for the helpdesk entities is available representing the relations between these entities.
- Create a ticket for an issue or have one created by an ATTENDANT
- Review any and all of owned tickets
- Submit a followup on any of owned tickets
- Change the status of an owned ticket by adding a followup with a new status.
- Receive a notification when the status of any owned ticket changes, or when a followup is added:
- initial release: by RSS
- later: by email
- later: by SMS
- maybe someday: by fax
- Access the list of USER accounts attached to self
- Access the list of HD Contractss owned by self
- Suspend/Resume the validity of any HD Contracts owned by self, if allowed by system setup
- Submit a ticket on behalf of an attached USER.
- Add a followup to a ticket belonging to any attached USER.
- Change the status of a ticket owned by any attached USER by adding a followup with a new status.
To support techs
Mostly anything HD-related. This includes notably:
- submitting tickets and followups on behalf of USERs
- Change various generic HD-implemented settings:
- Toggle the display of user roles in user/<user>/edit
- Set the ticket prefix and numbering base
Links to existing drupal service
HD makes use of two vocabularies:
- HD Status : a list of the status values defined by the HD site admin. HD only requirement is that the first value defined in the taxonomy represents the state a ticket is in where the issue no longer needs anything done.
- HD Severity : a list of the severity levels defined by the HD site admin. HD makes no use of this.
HD tickets can link to an e-commerce transaction, allowing for faster resource allocation decisions on tickets submitted without a support contract, and for code-based generation of contract by the e-commerce module, which could be useful for the automatic setup of warranty HD access.
HD access relies on drupal permissions (admin/access). Three composite levels of permissions are defined:
- Helpdesk > User : this represents the rights of the typical USER: can create tickets, submit followups, view own tickets and followups
- Helpdesk > Customer : this represents the rights of the typical Customers: can check their contract status (billing), suspend/reactivate their contract if this feature has been enabled, check all support tickets and followups for the users bound to them
It is expected that admins of site using HD will define 3 roles and give each role the set of permissions matching these descriptions: role user gets “Helpdesk > User”, role customer get “Helpdesk > Customer” and usually “Helpdesk > User” to be able to function as a user too, and role tech gets all three permissions, for situations where there are techs besides the actual Drupal admin.