| 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 | | |
| 32 | | == Phase 1 == |
| 33 | | There are also some models which are just used by SHARE & should be moved to that template (as need_*): |
| 34 | | * req_need_activity |
| 35 | | * req_need_demographic |
| 36 | | * req_need_line |
| 37 | | * req_need_response |
| 38 | | * req_need_response_line |
| 39 | | * req_need_response_organisation |
| 40 | | * req_need_sector (can be simply removed, as unused) |
| 41 | | * event_event_need |
| 42 | | * event_event_need_response |
| 43 | | |
| 44 | | Whilst doing these, also copy the other req_need models in so that it is self-contained. |
| 45 | | * req_need |
| 46 | | * req_need_contact |
| 47 | | * req_need_item |
| 48 | | * req_need_organisation |
| 49 | | |
| 50 | | === Status === |
| 51 | | * Complete |
| 52 | | |
| 53 | | == Phase 2 == |
| 54 | | * req_req should be stripped down to it's logistics core usecase |
| 55 | | * Remove types (so remove support for Simple, Skills, etc) |
| 56 | | * Remove current req_skill/req_commit_person/req_commit_skill models |
| 57 | | |
| 58 | | === Status === |
| 59 | | * Complete |
| 60 | | |
| 61 | | == Phase 3 == |
| 62 | | * Move req_req to inv_req |
| 63 | | * 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 |
| 64 | | * Also move associated !Controllers/Classes/Functions/View |
| 65 | | |
| 66 | | === Pros === |
| 67 | | * Req becomes cleaner & ready for Phase 2 |
| 68 | | * Logistics templates, like RMS, don't need to enable the Req module & have a simpler requests system to maintain |
| 69 | | |
| 70 | | === Issues === |
| 71 | | * Still have 2 separate Requests systems |
| 72 | | |
| 73 | | === Status === |
| 74 | | * Complete |
| | 17 | [wiki:BluePrint/Requests/2.0/Completed Precursor Steps Completed] |
