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).

• 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.:

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 BluePrints