Differences

This shows you the differences between two versions of the page.

--- hd:requirements [2005/09/24 17:46] – (old revision restored) 127.0.0.1
+++ hd:requirements [2020/11/23 17:23] (current) – external edit 127.0.0.1
@@ Line 6: / Line 6: @@
+===== 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
@@ Line 19: / Line 36: @@
   * a [[FOLLOWUP]] represents additional action on a [[TICKET]] after it has been created.
-=== UML class diagram for the helpdesk entities ====
+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/<user>/edit
+    * Set the ticket prefix and numbering base
-The following is a UML class diagram of these entities, prior to physical modeling:
-{{ hd:helpdesk8.png |UML class diagram for helpdesk}}
 ===== Links to existing drupal service =====
@@ Line 47: / Line 102: @@
 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.