Disaster Specific Resource Page

Introduction
An infrastructure to allow instances of resource pages to be customizable for specific disasters, in association with multiple languages Currently in the Vesuvius system resource pages are not associated with events. This project aims at creating an approach through which disaster specific resource pages can be created.

Stakeholders
1.People with permission to Create/Modify Resource and System Page(Editors)
Editors can create new pages with focus on a single event itself, since each Page will be specific to a single event. They would also be able to edit pre-existing pages and using them to create another page. Thus increasing user ease.
2.End Users
Since the Event-based resource pages will only be loaded when the user is within that particular disaster event , the users would be presented specific and precise information only.Rather than showing all resource pages, it is always better to show only relevant pages.

User Stories
1. As an Editor I would like to be able to create event specific Resource/System pages.
    These pages should be mapped to that event.
    These should be able to be modified easily whenever required.
    These pages can be used as a template for creating a new one.
2. As an End-User I would like to be able to view Resource Pages of an event when I am within that particular disaster event.
    These pages should be able to be translated into another language.

Requirements
    The module should map events with the resource page.
    The module should retrieve all pages corresponding to same type events or parent event as suggestions
    The module should make all pages editable by the Administrator.
    The module should not hinder the translatable property of every page.

Technologies
    PHP, MySQL and xajax

Current Implementation
In the current Vesuvius system resource pages are not associated with events. Administrators can create Resource pages which can be viewed by users. But these pages, not being event-specific, are not arranged according to relevancy.Thus not serving their purpose completely.

Planned Implementation
The overall implementation can be broken down into two phases :
In the First phase of implementation : an index , incident_id will be inserted in the database table of rez_pages which would be a foreign key, referencing incident_id in the incident table.Thus mapping each resource page with an event. Since the incident table handles the hierarchal nature of events (there is an index parent which denotes the parent of that particular event), this implementation will handle Hierarchical nature of events as well.

There is another way of implementing this idea. Please look at this document for a better understanding of this phase implementation:
https://docs.google.com/document/d/1Pv9O-xT79EDZdmmQXZ_322YTMEz8rgH08qWgK4uZmUs/edit?usp=sharing

In the Second phase of implementation events will be categorized into different categories. Currently the events table handles categorization of events (a field event_type exists). If the page is a Parent event then the system will suggest all the same event type resource pages else will display pages of it’s parent event as suggestion. The admin can edit these suggestions accordingly.
The categories are currently undecided and will be worked upon during the course of the project. Some specific places where this categorization is being looked at are EDXL-SITREP , EDXL-CAP , Humanitarian eXchange language (HXL) etc.

Future Extensions
Currently the storage mechanism of resource pages only allows two kinds of pages namely the System and Resource pages. This needs to be restructured to allow option of adding another type of pages.

Work items:
Parent-Child Hierachrchial Mapping with Pages : INPROGRESS
Categories for events : TODO
Mapping of Categories with events and pages : TODO
Restructuring rez module data storage : TODO