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