Changes between Version 1 and Version 2 of BluePrint/Requests/2.0


Ignore:
Timestamp:
09/19/21 20:16:46 (4 years ago)
Author:
Fran Boon
Comment:

Proposal 2

Legend:

Unmodified
Added
Removed
Modified

  • BluePrint/Requests/2.0

    v1 v2  
    11= Requests module for Sahana Eden 2.0 =
    22
     3== Background ==
    34Currently there are 2 parallel Requests systems in the REQ module:
    45* req_req
    … …  
    1415Whilst the Logistics usecase worked pretty well, the other usecases never really worked properly due to the fact that req_req required Requests to originate from a Site....this is why req_need was developed...to provide a simpler Requests system than req_req's simple mode, which could be flexibly extended to originate from Sites, Orgs or People. Could also be flexibly extended to support requests for Items, Skills, etc
    1516
    16 Proposal:
     17== Requirements ==
     18* REQ & INV should both be able to operate without the other
     19 * This is currently the case & shouldn't get broken by this restructure
     20* Enable support for future implementation of [https://docs.oasis-open.org/emergency/edxl-rm/v1.0/EDXL-RM-SPEC-V1.0.html EDXL-RM]
     21
     22== Proposal 1 ==
    1723* REQ should only have a single Requests system, for which the req_need model is more suitable.
    1824* req_req should be stripped down to it's logistics core usecase & moved to inv_req
    … …  
    2329 * req_job moved to req_need_job
    2430
     31== Proposal 2 ==
     32{{{
     33=> req_availability (inc commit_status)
     34  <= inv_commit
     35  <= hrm_commit (orgs) / vol_commit (individuals)
     36  <= fin_commit (or budget_commit)
     37=> req_acquisition (inc transport_status)
     38  <= inv_send
     39  <= hrm_deploy / vol_deploy
     40  <= fin_payment (or budget_allocation)
     41}}}
     42Any of these could come from external sources (e.g. via EDXL-RM).
     43* These would not create a record for the external source, but just the response to it
     44 * e.g. an external availability request is to be processed into either a commit, or a simple "not available" response
     45 * e.g. an external acquisition request would be referenced as document in the inv_send, but not establish an internal req_acquisition record.
     46 * The internal req_aquisition entity would be to store outgoing requests only (if requesting to another entity in the same system then it would only be seen like this to the requesting entity).
     47
     48== SHARE ==
    2549There are also some models which are just used by SHARE & should be moved to that template (as share_*):
    2650* req_need_line