Requests module for Sahana Eden 2.0

Requirements

• 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
  • Requisitions can be sent without an earlier Availability Request
  • Commits can happen to either Availability Requests or Requisitions
  • Unsolicited Offers can be sent

Precursor Steps Completed

Phase 4

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

Motivation

req_need is highly flexible, however is too simple

Phase 5

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_requisition (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 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)
  • 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
  • doesn't need a transport_status (just fulfil_status & commit_status)

• req_requisition
  • has a timeframe (consumable goods would have no end)
  • 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
  • needs all 3 statuses (fulfil_status, commit_status and transport_status)
  • has a location_id FROM as well as TO
    • The Requester may have to do the delivery
      • This may have costs
      • The delivery methods used may have limited routes available
    • Bridges may be down so resources to each side of the bridge may need to be sourced from that side of the river
    • Volunteers may need to be able to return home after a day's work as they cannot be accommodated
    • There may be Restrictions for e.g. to prevent COVID infections between areas

• Using pe_id for requester
  • means that we are directly accessing a SuperEntity, which is bad for permissions (can't differentiate by instance_type)
  • so 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
      • explicit accessible_query on the instance_type in the widget instantiation
    • have separate UI paths for the different options (Like Asset's 'Assign to Person'/'Assign to Org')
      • differently-filtered pe_id
        • server-side page refreshes
        • AJAX-load the different options
        • use a custom widget to display the separate options
          • e.g. have all 3 dropdowns in the form, but hide the ones not currently selected
      • proxy fields in the form
        • Simple to develop, although lower performance needing to load all the models each time even when not all needed
  • AddResourceLink needs adjusting to support pe_id instead of id (& mixed-instance_type needs this adjustable with the options)

• 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)