Changes between Version 10 and Version 11 of BluePrintRegionsAndIncidents
- Timestamp:
- 02/16/11 17:18:55 (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
BluePrintRegionsAndIncidents
v10 v11 24 24 The definition of a region or incident should be shared among (appropriate) users. That is, a site admin should be able to configure a region or incident. 25 25 26 An dincident will probably need a region as part of its specification.26 An incident will probably need a region as part of its specification. 27 27 28 28 === Region proposal === … … 104 104 * Vehicles assigned 105 105 * Inventory allocated 106 * Associated entities 106 * Associated entities (Are these simply tagged as being part of this Incident & we filter by default to the already-tagged ones, but can also remove this filter if we want to find a resource from the wider pool) 107 107 * Hospitals 108 108 * Shelters … … 112 112 113 113 ==== Use an org ==== 114 Fran considered creating an org for each incident, as it has fields and components that would be appropriate, but says that may not be sufficient. Probably need at least a region in addition.114 Fran considered creating an org for each incident, as it covers the command hierarchy for the staffing, but says that may not be sufficient. Probably need at least a region in addition. 115 115 116 116 ==== Use relationship tables ==== … … 118 118 119 119 (If a "paper trail" is needed, i.e. a record of what was used for each incident, there are several ways of providing that. One is to add start and end dates to the relationship. Since those could clutter the table, one could dump / pickle historical data, or move them to a parallel set of "expired" relationship tables. Keeping it online would be more convenient for preparing reports. Simplest is to leave them in the main incident relationship tables but set their end dates.) 120 121 ---- 122 BluePrints
