====== Requirements ====== The helpdesk module will be noted "HD" for ease of writing. ===== Nagging questions ===== * Should [[FOLLOWUP]]s be implemented as comments instead of nodes ? * On the one hand, in many regards, they are to [[TICKET]]s 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 [[TICKET]]s, [[FOLLOWUP]]s and, for [[CUSTOMER]]s, [[CONTRACT]]s. 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 ===== Entities defined for the module ===== * 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 [[USER]]s' problems * an [[ATTENDANT]] is a person taking calls over the phone or receiving them by fax or mail, and allocating [[TICKET]]s to [[USER]]s * 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. ===== Services available ===== ==== To users ==== * 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 [[CONTRACT]]s, typically a drupal user identifier and the attached public information ==== To customers ==== * Access the list of [[USER]] accounts attached to self * Access the list of [[CONTRACT]]s owned by self * Access the list of [[TICKET]]s owned by [[USER]]s 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. ==== To support techs ==== Mostly anything HD-related. This includes notably: * setting up [[CONTRACT]]s and changing their parameters for all [[CUSTOMER]]s * setting up [[USER]]-[[CUSTOMER]] relationships * submitting tickets and followups on behalf of [[USER]]s * 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//edit * Set the ticket prefix and numbering base ===== Links to existing drupal service ===== ==== taxonomy ==== 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. ==== e-commerce ==== 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. ==== access control ==== 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.