[[TOC]]
= Ticketing =

This is the core requirement of a first-responder Emergency Operations Center.

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).
 * [wiki:BluePrintMessagingModule Messaging module] therefore needs to be moved up in the list of models.

This can optionally be linked to a map:
 * http://wiki.sahanafoundation.org/doku.php/req:ticketing

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

== Resource Tagging ==

Resource tagging can be a method to assign 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. like:

{{{
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 shn_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.

----
BluePrints