Requirements

The helpdesk module will be noted “HD” for ease of writing.

• Should FOLLOWUPs be implemented as comments instead of nodes ?
  • On the one hand, in many regards, they are to TICKETs 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.

• User deletion in drupal involved removing the user's nodes, in our case TICKETs, FOLLOWUPs and, for CUSTOMERs, CONTRACTs. Is this acceptable behaviour ?

• 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

• a USER is a person experiencing issues and requesting help from the helpdesk
• a CUSTOMER is a person or entity owning a CONTRACT to access the helpdesk
• a TECH is a person working on the helpdesk to solve USERs' problems
• an ATTENDANT is a person taking calls over the phone or receiving them by fax or mail, and allocating TICKETs to USERs
• a CONTRACT is the set of terms under which a CUSTOMER has access to the helpdesk, and its current state vector
• a TICKET is the initial entry point for an issue opened by a USER
• a FOLLOWUP represents additional action on a TICKET after it has been created.

A UML class diagram 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
• Obtain a contact point for the CUSTOMER managing one's HD CONTRACTs, typically a drupal user identifier and the attached public information

• Access the list of USER accounts attached to self
• Access the list of CONTRACTs owned by self
• Access the list of TICKETs owned by USERs attached to self
• Suspend/Resume access to any CONTRACT by an attached USER
• Suspend/Resume the validity of any CONTRACT 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.

Mostly anything HD-related. This includes notably:

• setting up CONTRACTs and changing their parameters for all CUSTOMERs
• setting up USER-CUSTOMER relationships
• submitting tickets and followups on behalf of USERs
• changing the owner of any CONTRACT, TICKET or FOLLOWUP, including mass reassigning when USER or CUSTOMER accounts disappear.
• Change various generic HD-implemented settings:
  • Toggle the display of user roles in user/<user>/edit
  • Set the ticket prefix and numbering base

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 CUSTOMER: 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
• Helpdesk > Tech : this represents the most extensive set of rights, typical of TECH: can do all a CUSTOMER can, but also create/revoke contracts, modifiy their values, create tickets, and followups, etc.

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.