Version 4 (modified by 2 years ago) ( diff ) | ,
---|
Requests module for Sahana Eden 2.0
Background
Currently there are 2 parallel Requests systems in the REQ module:
- req_req
- req_need
req_req was the first system built, initially to support the Logistics functionality in Inv, via req_req_item, req_commit and req_commit_item
Subsequently this was extended to support:
- Requests for Skills, via req_req_skill & req_commit_skill & req_commit_person
- 'Simple' Requests (just a textbox of details)
- Planned to be extended to support Requests for Assets & Shelter, although that was never developed.
Whilst 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
Requirements
- REQ & INV should both be able to operate without the other
- This is currently the case & shouldn't get broken by this restructure
- Enable support in SAFIRE for Requesting Consumables, Assets (by Item Type, possibly Named as well) and People (by Job Title, possibly Named as well)
- Enable support for future implementation of EDXL-RM
Proposal 1
- REQ should only have a single Requests system, for which the req_need model is more suitable.
- req_req should be stripped down to it's logistics core usecase & moved to inv_req
- Remove types (so remove support for Simple, Skills, etc)
- Similarly req_req_item/req_commit/req_commit_item/req_approver/req_req_tag/req_order_item/req_project_req should be moved to inv_req_item/inv_commit /inv_commit_item/inv_req_tag/inv_req_approver/inv_req_item_order/inv_req_project
- Also move associated Controllers/Classes/Functions/View
- Remove current req_skill/req_commit_person/req_commit_skill models
- req_job moved to req_need_job
Proposal 2
Replace both req_need & req_req (& associated tables) with:
=> req_availability (inc commit_status) <= inv_commit <= hrm_commit (orgs) / vol_commit (individuals) <= fin_commit (or budget_commit) => req_acquisition (inc transport_status) <= inv_send <= hrm_deploy / vol_deploy <= fin_payment (or budget_allocation)
Any of these could come from external sources (e.g. via EDXL-RM).
- These would not create a record for the external source, but just the response to it
- e.g. an external availability request is to be processed into either a commit, or a simple "not available" response
- e.g. an external acquisition request would be referenced as document in the inv_send, but not establish an internal req_acquisition record.
- 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).
- req_availability
- has a timeframe
- might be anonymous
- if not anonymous then the Location could be inferred from the PE (e.g. person=>home address,
org=>office address, site=>site location) if not explicitly provided
- req_acquisition
- has a timeframe
- might be anonymous if using a pick-up mode using an identity-proxy (i.e. ticket, or voucher)
- if not anonymous then the Location could be inferred from the PE (e.g. person=>home address,
org=>office address, site=>site location) if not explicitly provided
SHARE
There are also some models which are just used by SHARE & should be moved to that template (as share_*):
- req_need_line
- req_need_response
- req_need_response_line
- req_need_response_organisation