Changes between Version 33 and Version 34 of BluePrint/Requests/2.0


Ignore:
Timestamp:
09/22/21 21:13:07 (3 years ago)
Author:
Fran Boon
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrint/Requests/2.0

    v33 v34  
    105105 * 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
    106106 * needs all 3 statuses (fulfil_status, commit_status and transport_status)
     107 * has a location_id FROM as well as TO
     108  * The Requester may have to do the delivery
     109   * This may have costs
     110   * The delivery methods used may have limited routes available
     111  * Bridges may be down so resources to each side of the bridge may need to be sourced from that side of the river
     112  * Volunteers may need to be able to return home after a day's work as they cannot be accommodated
     113  * There may be Restrictions for e.g. to prevent COVID infections between areas
    107114
    108 * Using pe_id for requester means that we are directly accessing a !SuperEntity, which is bad for permissions (can't differentiate by instance_type)
    109  * 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)
     115* Using pe_id for requester
     116 * means that we are directly accessing a !SuperEntity, which is bad for permissions (can't differentiate by instance_type)
     117 * 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)
    110118  * the usecase only needs 1 per context
    111   * have separate UI paths for the different options (Like Asset's 'Assign to Person'/'Assign to Org').
    112   * use a custom widget to display the separate options (most costly to build)
     119  * have separate UI paths for the different options (Like Asset's 'Assign to Person'/'Assign to Org')
     120   * differently-filtered pe_id
     121    * server-side page refreshes
     122    * AJAX-load the different options
     123    * use a custom widget to display the separate options
     124     * e.g. have all 3 dropdowns in the form, but hide the ones not currently selected
     125   * proxy fields in the form
     126    * Simple to develop, although lower performance needing to load all the models each time even when not all needed
     127 * AddResourceLink needs adjusting to support pe_id instead of id (& mixed-instance_type needs this adjustable with the options)
    113128
    114129* HRM (~mandatory model) should ideally not have a link to Req (optional module)