Differences

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

--- hd:requirements [2005/09/24 21:06] – (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 21: / Line 36: @@
   * 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 =====
@@ Line 60: / Line 74: @@
     * Set the ticket prefix and numbering base
-==== UML class diagram for the helpdesk entities ====
-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 88: / 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.