| | 1 | = Completed Elements = |
| | 2 | |
| | 3 | == Background == |
| | 4 | Currently there are 2 parallel Requests systems in the REQ module: |
| | 5 | * req_req |
| | 6 | * req_need |
| | 7 | |
| | 8 | 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 |
| | 9 | |
| | 10 | Subsequently this was extended to support: |
| | 11 | * Requests for Skills, via req_req_skill & req_commit_skill & req_commit_person |
| | 12 | * 'Simple' Requests (just a textbox of details) |
| | 13 | * Planned to be extended to support Requests for Assets & Shelter, although that was never developed. |
| | 14 | |
| | 15 | 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 |
| | 16 | |
| | 17 | == Phase 1 == |
| | 18 | There are also some models which are just used by SHARE & should be moved to that template (as need_*): |
| | 19 | * req_need_activity |
| | 20 | * req_need_demographic |
| | 21 | * req_need_line |
| | 22 | * req_need_response |
| | 23 | * req_need_response_line |
| | 24 | * req_need_response_organisation |
| | 25 | * req_need_sector (can be simply removed, as unused) |
| | 26 | * event_event_need |
| | 27 | * event_event_need_response |
| | 28 | |
| | 29 | Whilst doing these, also copy the other req_need models in so that it is self-contained. |
| | 30 | * req_need |
| | 31 | * req_need_contact |
| | 32 | * req_need_item |
| | 33 | * req_need_organisation |
| | 34 | |
| | 35 | === Status === |
| | 36 | * Complete |
| | 37 | |
| | 38 | == Phase 2 == |
| | 39 | * req_req should be stripped down to it's logistics core usecase |
| | 40 | * Remove types (so remove support for Simple, Skills, etc) |
| | 41 | * Remove current req_skill/req_commit_person/req_commit_skill models |
| | 42 | |
| | 43 | === Status === |
| | 44 | * Complete |
| | 45 | |
| | 46 | == Phase 3 == |
| | 47 | * Move req_req to inv_req |
| | 48 | * 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_approver/inv_req_tag/inv_order_item/inv_req_project/inv_req_job |
| | 49 | * Also move associated !Controllers/Classes/Functions/View |
| | 50 | |
| | 51 | === Pros === |
| | 52 | * Req becomes cleaner & ready for Phase 2 |
| | 53 | * Logistics templates, like RMS, don't need to enable the Req module & have a simpler requests system to maintain |
| | 54 | |
| | 55 | === Issues === |
| | 56 | * Still have 2 separate Requests systems |
| | 57 | |
| | 58 | === Status === |
| | 59 | * Complete |
