= !BluePrint : Resource Tagging for Ticketing System =
[[TOC]]

== Introduction ==
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.
== Stakeholders ==
The users of the solution would be local government, emergency management officials, and first responders.  It will help them streamline their work queuing and prevent issues from falling through the cracks through the use of a proactive alert system that re-queues unassigned work.   This solution would impact the end users, because it automates re-queuing of unassigned issues.  It makes it very difficult for things to fall through the cracks.
Given that the stakeholders are typically the same individuals and organizations listed in the resource pool, it would assist them with an automated mechanism for queuing their work based on priority.  It would also provide a method of handling the data in such a fashion that it could be easily ported into a mapping system similar to Google Earth.  When an issue passes the threshold for reassignment, it would then dump the item back into the queue and alert other authoritative resources.
== Requirements ==
This project would require a web server (Apache), a PHP handler (phpMyAdmin), and a functional SQL database similar to those used in MySQL Community Server.

[[Image(Sahana Eden Ticketing System.jpg)]]
Resource Tagging Graphical Representation

=== System Constraints ===
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.

----
BluePrint