|Version 15 (modified by 12 years ago) ( diff ),|
Table of Contents
This is the core requirement of a first-responder Emergency Operations Center.
e.g. See this OpenSource CAD (Computer-Aided Dispatch) tool: http://openises.sourceforge.net/tickets01.html
A basic workflow app so that tasks can be logged for individuals or groups (pr_pentity without the dead bodies!).
Users can subscribe to their tasks via Email/SMS/Twitter/RSS - ideally based on category (such as location/project/priority/urgency).
- Messaging module therefore needs to be moved up in the list of models.
This can optionally be linked to a map:
What we have implemented so far is a Master Message Log where all inbound communications come (the Inbox for non-XForms SMS, Emails, Tweets & Ushahidi Incidents).
These can be marked as Verified/Actionable/Actioned, Prioritised, Classified & Routed to other modules:
- Alerting (CAP, SMS, Email)
- Request Management System
- Situation Reporting (once available)
- Volunteer Management (to be Project Management): Tasks
Resource tagging can be a method to link tickets to resources, e.g. to hospitals, organisations or projects.
A resource tag is basically a table with:
- tag ID
- ticket ID
- resource name (=tablename)
- resource UID
which links tickets to any resource (many-to-many, a ticket can be linked to multiple resources).
A RESTful controller for resource tags can CRUD all tickets that are assigned to a specific resource, or to a type of resources, e.g.:
def tag(): tablename = request.vars.get("tag.resource", None) uid = request.vars.get("tag.uid", None) filter = None if tablename: filter = (db.ticket_tag.resource_name == tablename) if uid: filter = (db.ticket_tag.resource_uid == uid) & filter response.s3.filter = filter return s3_rest_controller("ticket", "tag", ...)
This controller can be linked-in in any relevant resource view (e.g. as a popup) in a generic way. The tags can also be used to link module-specific request/response information to the tickets.