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] |