Changes between Version 31 and Version 32 of BluePrint/Requests/2.0

Timestamp:

09/22/21 20:32:35 (4 years ago)

Author:

Fran Boon

Comment:

--

BluePrint/Requests/2.0

@@ -93 +93 @@
  * e.g. an external requisition request would be referenced as document in the inv_send, but not establish an internal req_requisition record.
  * The internal req_requisition entity would be to store outgoing requisitions only (if requesting to another entity in the same system then it would only be seen like this to the requesting entity, which solves the issue of both sides needing permissions to see the Request...outgoing see it as a resource, incoming see it as a document (e.g. XML or PDF)....or they see it as e.g. inv_requisition (like inv_recv is to an inv_send in the same system)).
+
 * req_availability
  * has a timeframe (consumable goods would have no end)
@@ -99 +100 @@
 org=>office address, site=>site location) if not explicitly provided
  * doesn't need a transport_status (just fulfil_status & commit_status)
+
 * req_requisition
  * has a timeframe (consumable goods would have no end)
@@ -106 +108 @@
  * needs all 3 statuses (fulfil_status, commit_status and transport_status)
 
-=== Issues ===
 * Using pe_id for requester means that we are directly accessing a !SuperEntity, which is bad for permissions (can't differentiate by instance_type)
-* HRM (~mandatory model) has a link to Req (optional module) which should be avoided
+ * use this for just 1 instance_type at a time: variable single type NOT mixed type (mixed type can be seen as poor UX by users, as well as the permission issues)
+  * the usecase only needs 1 per context
+  * have separate UI paths for the different options (Like Asset's 'Assign to Person'/'Assign to Org'). 
+  * use a custom widget to display the separate options (most costly to build)
+
+* HRM (~mandatory model) should ideally not have a link to Req (optional module)
+ * hrm_deploy could be req_deploy_hrm (& req_deploy_vol, if this needs to be differentiated)
+
+