[wiki:Haiti Haiti] ---- == Haiti RMS (Request Management System) == * Requirements/Blueprint: http://wiki.sahana.lk/doku.php/haiti:requirements#request_management_system University of Wisonsin Python club are leading on this: #sahanarms Suggest following the New Module Development tutorial as this is new functionality for Py: * DeveloperGuidelinesNewModule Keep it real simple to start with - get something usable quickly, which we can then refine later if we gets needs to do so. UPDATE - 100117 02:36am * Added draft of rms to launchpad branch (~uwthw/sahana/rms) * Draft script for Cron job of GeoRSS feed from Ushahidi is in applications/sahana/cron/entry2record.py ** TODO write check for duplicates in GUID ** TODO get access to older Ushahidi logs ** TODO scrape additional data from Ushahidi link in each record (e.g. category) ** Need Cron job timing decision and command to be written STATUS - experimental * form for request (sahana/rms/request_aid) & pledge (sahana/rms/pledge_aid) ** no data validation ** limited formatting NEXT STEPS * build logic for matching pledge and request {{{ Basically there will be loads of requests for aid coming from the field by sms, through calls and otherwise and people will have to enter these (millions) of requests quickly into the system for tracking there is no time for complex workflows and approvals, so the system has to be extremely quick if we can enter everything for a request in one html form that would be ideal similarly there will be loads of people offering donations of aid of various things often they cannot be used immediately but they need to be tracked so that when a need arises the donation and the person who offered it can be found This is the main objective of the request management system, to connect people who need aid and people who are offering it however to do the matching you need to agree to some measures I need 100 Kg of Rice bit the person that pledges can only offer 40Kg so you match it but note that there is 60Kg remaining to be delivered but you need to track the remainder that was not fulfilled so we now have an added part of getting unstructured data from various sources basicially someone is recording some information about aid, without reviewing the content and send it to us first step is someone needs to convert that to a request for aid or pledge so on click of the queue that is coming in (as a GeoRSS feed from Ushidhi right now of their SMS messages) you convert it to the first step of a request or a pledge once you click that item is no longer in the pending queue (it has been read and processed) So let's think through what a typical situation would be someone would make a call with a request or sms a request fist step would be to enter what is needed and it will be a list of items chamindra> sometimes they will just say "food" or "water" without a quantity but then you need to ask for how many people which is why that field is there for units are not compulsory How specific does, say the food field need to be? For instance, is Rice good enough, or do we need to be very specific like Brown Rice IMO not very possibly you can have a highlevel drop down category AJAX dropdown Right that is what I was thinking no ones going to care with the rice is brown or white right now me thinks :-) because the alternative would be a foods string that then gets parsed but you are right in some instances like if it is pork or for religious reasons so possible as you said one high level category OK so we'll come up with a representative list for a drop down menu food, water, aid, medical, etc Great, that makes life easier for the matching and a free text box for the sub category on the free text thing, there reason is that strcuture can create a bottle neck unless that process can be made easier.. like using an AJAX lookup so that you avoid spelling mistakes We have an AJAX autocomplete widget in SahanaPy I can help with that For use where dropdowns become unwieldy scopatz> Maybe we'll add that later, I think the goal now is to get the basic RMS up and running scopatz: Yes, that's icing...getting *something* quickly is key also you will have many types of items per request one request will consist of multiple items (like a shopping list) so each one needs type, description, units, quantity but you can consider the whole request being from one contact, phone, and for a number of people good to have a backup phone and contact as well, in case the primary disappears but that is optional one last bit and that is the matching part once you get a request.. you can do a lookup and see if there is a potential match for it in the pledges and vice versa so even immidiately as they are on the call, they can respond saying there might be some options at the end of the request, show a list of potential full and partial matches to the request remember think simple intuitive interface no complex workflows and approvals }}} ---- [wiki:Haiti Haiti]