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 should only have a single Requests system, for which the req_need model is currently more suitable.
• REQ & INV should both be able to operate without the other
  • This is currently the case & shouldn't get broken by this restructure
  • e.g. Should be able to operate very simple Requests easily (like req_need can be used currently)
• REQ & INV should be able to operate together
  • This is currently the case & shouldn't get broken by this restructure
• Should be able to support use-cases, like RMS, where there is no Commit stage
  • This is currently the case & shouldn't get broken by this restructure
• Enable future support in SAFIRE for Requesting Consumables, Assets (by Item Type, possibly Named as well) and People (by Job Title, possibly Named as well)
• Enable future support for implementation of ​EDXL-RM

Phase 1

There are also some models which are just used by SHARE & should be moved to that template (as need_*):

• req_need_activity
• req_need_demographic
• req_need_line
• req_need_response
• req_need_response_line
• req_need_response_organisation
• req_need_sector (can be simply removed, as unused)
• event_event_need
• event_event_need_response

Whilst doing these, also copy the other req_need models in so that it is self-contained.

• req_need
• req_need_contact
• req_need_item
• req_need_organisation

Status

• Complete

Phase 2

• req_req should be stripped down to it's logistics core usecase
  • Remove types (so remove support for Simple, Skills, etc)
  • Remove current req_skill/req_commit_person/req_commit_skill models

Phase 3

• Move req_req to inv_requisition
  • Similarly req_req_item/req_commit/req_commit_item/req_approver/req_req_tag/req_order_item/req_project_req/req_job 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/inv_req_job
  • Also move associated Controllers/Classes/Functions/View

Pros

• Fairly easy to implement
• Req becomes cleaner & ready for Phase 2
• Logistics templates, like RMS, don't need to enable the Req module & have a simpler requests system to maintain

Issues

• Still have 2 separate Requests systems

Phase 4

Move req_need (& associated tables) to CCC template (SHARE is already isolated now).

Replace with a new Requests model:

=> 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, 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_req (like inv_recv is to an inv_send in the same system)).
• 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

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