This is an old revision of the document!


Background

During the SSF and Crisis Mapping response to the Haiti Earthquake in 2010, many requests for help and assistance were sent via email and other means. It was hard for multiple people to know who had taken responsibility for collecting this information, and assigning task(s) that may result from this incoming information. For example, numerous emails and links to documents containing information to be imported were provided, but not system was able to capture and track the assignment of the entry of this information.

Broadly, this is a two-stage process:

  1. Recording of incoming messages in a message log
  2. Management of actions/tasks generated by human review of a message

In this brief spec, these have been broken out into two different modules as the message log may be utilised to produce information in other modules - such as situation reporting. There is also a third module that may come into play - a document library for recording incoming attachments, e.g. Situation Reports from other organistions. I'll put all of them here initially, and later split them out into individual modules. There is also a close linkage with the Situation Awareness module in that incoming messages may have 1 or more map points associated with them based on the information that the message contains.

Current priority in terms of development would be:

  1. Incoming Message Log - need to first be able to capture the information
  2. Action Tracking - need to be able to coordinate our response to incoming information
  3. Documents - a nice to have ;)

Incoming Message Log module

The concept of the message log module is just to capture incoming information and messages that will later be reviewed and may result in the creation of further actions or derivative information. This is a common tool in emergency management with a simple paper log to track incoming messages. The message log is very much like a blog with messages listed in reverse chronological order with the newest at the top.

Key information to capture:

  • DateTime - if blank, time of submission to database, otherwise allow user to enter time (e.g. may want to manually enter time original email or phone call was received)
  • Creator - who created the message in the system
  • To - who the message was originally to, at a minimum one person or organisation, but may need to support multiple recipients
  • From - the person or organisation the email was from
  • Status - Normal or Urgent (may want more, but initially a means to flag certain messages as urgent will be useful)
  • Message - textblog or whatever, may need to quite large bodies of text, e.g. cut-and-paste email
  • Source - would be useful to have a source field, particularly for information obtained from URLs
  • Tagging - be able to tag each logged message with keywords for searching/filtering, ideally freetext tagging

Options:

  • AJAX update to show new messages without reloading page
  • AJAX update to highlight message marked as urgent (e.g. highlight background light red or similar)
  • When creating a message it would be useful to allow uploading a document to a document library module (not yet developed) and then linking that back to the original message it was sourced from. This would allow two-way linking e.g. from message to document, or document to message

Action Tracking module

Incoming messages need to be reviewed by a subset of users to identify if actions are required to be undertaken. A given message may result in 1 or more actions being identified, and these need to be recorded, and allow the assignment of actions to users, as well as expected completion times. The users should be able to mark actions assigned to them as underway, completed etc. We also need to be able to track what sort of Sahana system rights may be required, e.g. admin, data entry etc is required to undertake the task. Again, Actions and Incoming Messages should have a two-way linkage, so that actions associated with an incoming messages are shown, and likewise it is possible to view the source message that generated an action.

Document Library module

As part of receiving incoming emails and documents downloaded off the net, there is a need to have a document library to manage all the documents received. To make them easier to find however, it would be better to have them in a more structured document library for easy browsing, as well as making them available by keyword tagging from metadata. If the documents are sourced from an incoming message, then creating a two-way relationship between the incoming message and the document library is essential for tracing.

Key information to capture:

  • Uploaded file
  • DateTime
  • Creator
  • Link to source message in Incoming Message Log
  • Source
  • Incoming Message
  • Tagging

Options:

  • Included fulltext searching of uploaded documents

Additional Notes

  • Comments - it would be good to allow users to comment, a la blog style, against an Incoming Message, Document or Action
  • Situation Awareness - an Incoming Message may also generate 1 or more situation awareness points, and these should also be linked in a two-way manner as per actions and documents, so that Situation Awareness points can link back to original source message and vv.
  • Personnel Management - any assignment of actions needs to link to the Personnel Management system
  • Organisation Registry - some actions may be assigned to orgs from the OR, and then the manager of the Organisation that has an assigned action may decide which user within their org will be responsible for the action

QR Code
QR Code req:ticketing2010 (generated for current page)