wiki:BluePrintIncidentReporting

Version 21 (modified by Fran Boon, 11 years ago) ( diff )

--

Incident Reporting

Allow the public to report Incidents, with associated locations on the map.

Optionally, provide the ability for admin to approve the Reports.

Usability Suggestions

Usability Suggestion for IRS.doc

  • All points for this document have been actioned, except:
  • "Put a “search” button after the search column" for irs/report. This might not be required as the search will happen automatically on key-press and this will involve going into DataTables API.

http://hsiaojan.pbworks.com/f/searchbutton.jpg

Replace irs_incident

  • With a 'parent' field so that ireports can be linked together but without needing an extra table.
  • a 'Lead Incident' flag can be used to indicate the master record which is where most updates happen

(This is how Service Now manages Incidents)

Simplified Categories

Status

We need a simplified version of these to be presented to users whilst keeping the full sets available for EM professionals ('Editors' in a simple use case). A mapping needs to be maintained between the different lists. We should have a (personalisable) configuration option to show which list to use (& hence which symbology set to display on the map).

The back-end should NOT be easily customised as otherwise it is hard to share data between instances.

Proposals

Fran

Change to something more like this (doesn't yet handle the mapping - needs work!):

irs_incident_type_opts = Storage (
    INTERNAL_FORMAT_1 ={
        simple: T("Broken Road"),
        canada: "roadway.roadwayClosure"
    },
    INTERNAL_FORMAT_2 = {
        simple: T("Broken Bridge"),
        canada: "roadway.bridgeClosure"
    },
)

A subclass of IS_IN_SET() is created to handle this data structure, providing access to full list to a role (default to 'Editor'), but the sub-set to normal users' dropdowns.

  • Q: Should .represent also be modified for Display of records?

nursix

a) keep the original dict, but change the values of the dict into tuples like:

irs_incident_type_opts = {
        101: ("roadway.bridgeClosure", T("Broken Road")),
}

b) make the .represent towards normal users show the second item in the tuple rather than the first (easy tweak), while admin users may see both (the controller can switch between those two)

c) have a admin-only-accessible DB table irs_incident_type_opts with the options available for the "normal" user like:

define_table("irs_incident_type_opts",
             Field("code", "integer", requires=IS_IN_SET(irs_incident_type_opts)))

d) In the model, make .requires the normal IS_IN_SET (To allow Sync of records with any of the options):

.requires = IS_IN_SET(irs_incident_type_opts)

f) In the controller, if "normal" user, override this requires by:

allowed_opts = [opt.code for opt in db().select(db.irs_incident_type_opts.code)]
.requires = IS_IN_SET(allowed_opts)

keith, marr

A config screen for admin/editor to map "simple category" to "canadian category". Assume that total number for simple category options is small and limited, say 6 for Taiwan's case. In IRS report adding screen, default menu using simple category, user can switch via radio-button to canadian category.

Note that if the category code options differ from instance to instance then you cannot exchange the incident reports anymore - therefore I suggested to keep the original options dictionary keys, and just add a second "user-friendly" category title (nursix)

keith

To define "Incident Category" isn't an easy work. The Candian ems.incident seems too detail for a large disaster management system. e.g. It should be "Transport/Railway" instead of "Railway/Hijacking" We might start from small to define our own incident categories to increasing user experience without missing the flexibility and accuracy.

The way to category is using primitive way "number range":

    irs_incident_type_opts = {
        1:T("Natural Disaster"),
        2:T("Transport"),
        3:T("Collapse, Illness, Injury, Trapped"),
        4:T("Industrial"),
    }

    irs_incident_subtype_opts = {
        100:(1, T("Flood")),
        101:(1, T("Landslide")),
        200:(2, T("Roads Brodken")),
        201:(2, T("Bridges Broken ")),
        300:(3, T("Buildings Collapsed")),
        301:(3, T("People Trapped")),
        400:(4, T("Power Failures")),
    }

So ID 1~99 are major categories. ID 100~199 are under 1st Category "Nature Disaster". 200~299 are under "Transport".

If someone gonna create a new category, he *should* have a look at "THE NATIONAL STANDARD FOR INCIDENT RECORDING" http://rds.homeoffice.gov.uk/rds/pdfs08/countnsir08.pdf

TODO: There should be "Please refer to the link of 'Make a request' for the need of helps" in the page before creating a incident report.

It is what I can think of now to get most benefit for current usage and fine for future development.

For now the code will only show the sub categories.

Look of sub categories

If it's ok, the diff code is on http://bazaar.launchpad.net/~keitheis/sahana-eden/edentrunk/revision/1073

If we had much more time and the amount of categories went out of control, we can try the top-down way of selecting gis location. (I've tried and find it needs much more effort to make it work.)

Where there are hierarchies (such as roadway.roadwayClosure) provide a JS widget to split this into a hierarchical selector.


BluePrints

Attachments (3)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.