Changes between Version 5 and Version 6 of BluePrintRegionsAndIncidents

Timestamp:

02/16/11 14:47:14 (14 years ago)

Author:

Pat Tressel

Comment:

--

BluePrintRegionsAndIncidents

@@ -55 +55 @@
    * The user's personal gis_config.
    * The generic gis_config.
+ * Filter entities that have locations by region.
+  * Filter drop-down menus and other selectors.
+  * Filter search results.
+  * Filter lists.
+  * Perhaps provide an option to view all entities?
+    (This isn't necessary as one can deselect the region but might be convenient
+    if one wants to find nearby entities.)
 
 The "region location" associates specific locations to the region.
@@ -90 +97 @@
  * Information (e.g. work logs, instructions)
 
-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.
+==== Use an org ====
+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.
 
-Many types of things are associated with an incident.  The "relational" way to do this, without adding fields to entities, is to add relationship tables that associate an incident with each of the types.  That is, there would be an "incident assessments" table that says which assessments go with which incident, and so-on for the other associated types.  This allows overlap.  When an entity is no longer needed for an incident, it's relationship can be deleted or "expired" by setting an end date.  (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.)
+==== Use relationship tables ====
+Many types of things are associated with an incident.  The "relational" way to do this, without adding fields to entities, is to add relationship tables that associate an incident with each of the types.  That is, there would be an "incident assessments" table that says which assessments go with which incident, and so-on for the other associated types.  This allows overlap.  When an entity is no longer needed for an incident, it's relationship can be deleted or "expired" by setting an end date.
+
+(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.)