|Version 14 (modified by 9 years ago) ( diff ),|
BluePrint : Resource Tagging for Ticketing System
During a natural disaster, notification and assignment of key resources is a key component of an effective response. As disaster data and needs are gathered, that information must be disseminated in a fashion that is effective, efficient, and contains protective measures that will prevent issues from being overlooked. The data must be conveyed in a "many to many" format, similar to joins and grouping within a relational database. The goal is to categorize, notify, allocate resources from a pool, and notify those resources whenever a new issue is presented. We believe that this will help expedite a cohesive response to issues which arise in a natural disaster.
The project that our team, the Fighting Mongooses, will be working on deals with the issue of resource tagging within the ticketing system that emergency management groups utilize to mount a mitigating response to the problems that arise during and after a natural disaster. This includes tagging the issue with a unique ID number, tagging the resource pool, and how the individual resources are tagged. The module should also allow for multiple teams or resources to be assigned individual tasks for a single incident when a response from more than one team or resource is required. The client application for this module must be able to create, update, and delete/resolve incidents within the database. Although resolved incidents would remain in the database for historical purposes, they would be tagged as inactive and no longer appear in resources' work queues. Once a resource or team is assigned an incident, the resource or team will be notified based on their individually configured notification preferences. Options will include RSS, Twitter, SMS, and e-mail.
The stakeholders for this project will be local government deploying the software, emergency management officials, first responders, and individuals reporting an issue. Ancillary stakeholders will be the individuals working with the Sahana Foundation, as it is their software that the module would be incorporated into. The module would assist emergency management officials and responders by effectively and efficiently disseminating information on incidents requiring interaction. It would also provide centralized control of the repository of information. Individuals reporting an issue would be assured that their problem would given to an appropriate response team.
This project is to be completed in Web2py. Web2py provides all of the functionality of an SQL database through a Database Abstraction Layer, so constructing a relational database within the existing system would present no problem. This provides the functionality for a "many to many" relationship between incidents and resources or resource pools.
There are modules that can be integrated to update RSS feeds for resource notification. This is due to the fixture structure of RSS feeds. These include title, link, description, items, etc.
Email notification is also possible within Web2py. It requires that settings, similar to those you would configure when setting up an email client, be configured within the code. This allows the client application to connect to an SMTP server to send email notifications to users.
SMS notification to resource cell phones is possible through Web2py. It does require the utilization of an SMSC proxy. The data is encrypted for secure transmission across the Internet with the use of an X.509 certificate.
Twitter notification is also possible for notification within Web2py. There is a constraint with Twitter notifications. Although the notifications can be sent across Twitter, the tweets will still be constrained to the 140 character limit. This would require that the subject and incident number only be included within the notification, and the user would have to use an alternative method to acquire the full incident description. As such, this aspect of the notification module could provide notification only. It would require further intervention from the resource receiving the message.
The primary issue created by handling data this way would that the data is initially put in by users. Although data checking can be done for correct format, it would be very difficult to verify that an address is correct. Also, the person reporting the issue may not be physically on site. This would also create problems with pulling GPS information from a cell phone. The constraint would be that location information would need to be accurate for the system to be effective with geo-tagging.
Sahana Eden Ticketing System.jpg
) - added by 9 years ago.
Resource Tagging System Blueprint
) - added by 9 years ago.
Work Flow Document
- questionaire.PNG (19.1 KB ) - added by 9 years ago.
- gantt.jpg (121.7 KB ) - added by 9 years ago.
- tasks.jpg (85.3 KB ) - added by 9 years ago.
Download all attachments as: .zip