| Version 33 (modified by , 14 years ago) ( diff ) |
|---|
Haiti RMS (Request Management System)
- Requirements/Blueprint: http://wiki.sahana.lk/doku.php/haiti:requirements#request_management_system
University of Wisconsin Python club are leading on this: #sahanarms
Keep it real simple to start with - get something usable quickly, which we can then refine later if we gets needs to do so.
Other parallel efforts for which interop would be nice:
Comments We pushed a simple pledge system to dev. We'll be changing it soon to accommodate new feeds and improve database design.
STATUS
production (100120@02:45CT)
- view with sms feeds from Ushahidi
- disabled personal information fields (fname, lname, phone_num)
- with with twitter feeds from TtT
- SMS alerts on map viewer
- pledge system with simple flat-table extending sms feeds table
- ServerSidePagination
development (100118@4:34CT)
- in production
experimental (100118@4:34CT)
- launchpad branch (~uwthw/sahana/rms)
- 3 tables request_aid, pledge_aid, match - building controllers/views
TODO
- build logic for matching pledge and request (PRIORITY)
- match table that links request_item_id with pledge_item_id
- percent completion (as pie graph) of pledge
- pledge dashboard showing multiple pledge items by pledge organization (joined resource commented out in branch)
- icon showing status of pledge (red = unpledged, green = pledged)
- standardize this wiki page with the other project pages (FB: No big need. This is Temp status...move longer-term goodness to UserGuidelinesRMS)
- feed from Tweak the Tweet split feed into 2 tables: #offer & #help
- report generating functionality assings id (alpha, beta,...) to pledges every ~6 hours to facilitate tracking by relief organizations
LOGS
100116
[11:29am] nicopresto: would screenshots be helpful?
[11:32am] flavour: screenshots 4 what?
[11:32am] flavour: For the User Manual?
[11:32am] flavour: http://trac.sahanapy.org/wiki/UserGuidelinesRMS
[11:32am] flavour: We have paolo volunteerting to help with user manuals once code has stablised a bit
[11:33am] nicopresto: screenshots of the rms as we build it .. will check guidelines
[11:33am] flavour: You can ping him directly:
[11:51am] nicopresto: mprutsalis: we briefly outlined were we made it to on the wiki (http://www.sahana.lk/wiki/doku.php/doc:rms:english). We have request and post forms, then wrote a cron job for getting the GeoRSS. We'll update the cron to the new feed link you sent. We're currently checking over the forms to get them ready for dev
[11:52am] nicopresto: the launchpad branch is at (~uwthw/sahana/rms)
[11:54am] mprutsalis: need to keep it simple for haiti-- you've seen the quality of data...
[11:55am] mprutsalis: so we post it all - make it searchable/listable by category....
[11:55am] mprutsalis: if you are on skype - I can add you to the chat room there working on this project
[11:59am] mprutsalis: oh whoa - that haiti.ushahidi.com/feed feed is really a mess
[12:00pm] nicopresto: yea
[12:04pm] flavour: feed is the main incident feed isn't it
[12:04pm] flavour: Not the 200 RMS line
[12:04pm] nicopresto: ok we'll separate the sms messages from our request table and offer another tab that shows simple/searchable SMS messages. Shouldn't take long and we could get to dev in ~2 hrs.
[12:08pm] nicopresto: ok so we have 2 feeds http://75.101.195.137/rss.php?key=yqNm7FHSwfdRb8nC2653 (let's call it "4636") and haiti.ushahidi.com/feed (let's call it 'haiti"). We've been using "haiti" and will switch to "4636". We'll display that info in a separate tab. So we'll have 3 tabs at the RMS: "request aid", "pledge aid", and "view SMS requests" ... cool?
[12:09pm] nicopresto: similar to the php side bar (75.101.195.137/add_record.php)
[12:09pm] flavour: sounds good
[12:10pm] flavour: I see I need to work on the Map-based Lat/Lon entry urgently
[12:11pm] flavour: 4636 isn't XML?
[12:11pm] flavour: Just the way it displays in Chrome
[12:11pm] flavour: FF tries to open in Google Reader
[12:12pm] mprutsalis: 4636 replaced 200
[12:13pm] flavour: 200 was suppoosed to be vols accordint o chamindra but the data there seems an MPR
[12:15pm] mprutsalis: hunh... I think 200 is abandoned effort - that was going to be the shortcode in haiti for sms but they couldn't get control of it so migrated to 4636... is new data going into 200?
[12:19pm] flavour: Looks like 3 sample entries to me
[12:31pm] mprutsalis: update from ushahidi... they are making more features to the rss feed "in a bit"
[12:31pm] mprutsalis: [1:29:31 PM] Brian Herbert: but for now, you can do paging
[12:31pm] mprutsalis: [1:29:38 PM] Brian Herbert: just add &limit=0,50
[12:31pm] mprutsalis: [1:29:44 PM] Brian Herbert: that number works just like mysql
[12:31pm] mprutsalis: default is 50 items so you aren't going to surface all reports without using the limit
[12:32pm] mprutsalis: also - Katie Stanton from US State Department - latest project is connecting organizations who can donate things like laptops, generators, phones, etc. with those working on the ground.
[12:32pm] mprutsalis: I have offered up standard RMS functionality - you are working off those specs - for this....
[12:32pm] flavour: Great - we want uers
[12:32pm] flavour: Users
[12:33pm] mprutsalis: so much going on everywhere... hard to keep up.
[12:34pm] flavour: I think good if nico is the PoC for RMS
[12:35pm] mprutsalis: ok - nico I will introduce you to the 4636 room....
[12:35pm] nicopresto: great thanks
[1:36pm] nicopresto: mprutsalis: typo above (11:51am) I listed a link to an older php rms doc. Our status is on http://trac.sahanapy.org/wiki/HaitiRMSToDo
[2:04pm] mprutsalis: thanks nicopresto... the older doc is good overview for less technical like katie... that's why I used it.
[2:05pm] nicopresto: yes, that document was also very helpful for us
[2:15pm] }flavour{ joined the chat room.
[2:29pm] }flavour{: <mprutsalis> request management is priority focus...
[2:29pm] }flavour{: <mprutsalis> US State Department wants a registry of pledged in-kind donations from US organizations/companies - that can be matched with needs of organizations on the ground in haiti....
[2:31pm] nicopresto: we've got the georss going ... working on an interface
[2:32pm] nicopresto: we used the built in organization table, correct?
[2:32pm] mprutsalis: sure... if that works.
[2:32pm] mprutsalis: let me know when there is something to look at (in dev)
[2:34pm] nicopresto: ok we'll post our rough draft to branch in a few ... our database
[2:34pm] nicopresto: ... our database structure is flat and not very pretty yet ... working on it
[3:10pm] nicopresto: ok new georss cron just worked ... adding validation for duplicate guid fields then moving over to branch
[3:22pm] scopatz: Ok we are testing our cron job right now....this is the last step (for the moment!)
[3:27pm] nicopresto: starting to upload
[3:27pm] nicopresto: editing wiki
[3:31pm] scopatz: Pushed to lp
[3:32pm] scopatz: ...so you should be able to grab our changes any time.
[3:33pm] scopatz: Note that we added a cron job for rms (rms_entry2record.py) but commented it out
[3:33pm] scopatz: you should uncomment for it to work
[3:34pm] flavour: ok, I'll get back to you for help if reqd
100116
<chamindra> Basically there will be loads of requests for aid coming from the field <chamindra> by sms, through calls and otherwise <chamindra> and people will have to enter these (millions) of requests quickly into the system for tracking <chamindra> there is no time for complex workflows and approvals, so the system has to be extremely quick <chamindra> if we can enter everything for a request in one html form that would be ideal <chamindra> similarly there will be loads of people offering donations of aid of various things <chamindra> often they cannot be used immediately <chamindra> but they need to be tracked so that when a need arises the donation and the person who offered it can be found <chamindra> This is the main objective of the request management system, to connect people who need aid and people who are offering it <chamindra> however to do the matching you need to agree to some measures <chamindra> I need 100 Kg of Rice <chamindra> bit the person that pledges can only offer 40Kg <chamindra> so you match it but note that there is 60Kg remaining to be delivered <chamindra> but you need to track the remainder that was not fulfilled <chamindra> so we now have an added part of getting unstructured data from various sources <chamindra> basicially someone is recording some information about aid, without reviewing the content and send it to us <chamindra> first step is someone needs to convert that to a request for aid or pledge <chamindra> 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 <chamindra> once you click that item is no longer in the pending queue (it has been read and processed) <chamindra> So let's think through what a typical situation would be <chamindra> someone would make a call with a request or sms a request <chamindra> fist step would be to enter what is needed <chamindra> and it will be a list of items chamindra> sometimes they will just say "food" or "water" without a quantity <chamindra> but then you need to ask for how many people <chamindra> which is why that field is there for <chamindra> units are not compulsory <scopatz> How specific does, say the food field need to be? <scopatz> For instance, is Rice good enough, or do we need to be very specific like Brown Rice <chamindra> IMO not very <chamindra> possibly you can have a highlevel drop down category <nicopresto> AJAX dropdown <scopatz> Right that is what I was thinking <chamindra> no ones going to care with the rice is brown or white right now me thinks :-) <scopatz> because the alternative would be a foods string that then gets parsed <chamindra> but you are right in some instances <chamindra> like if it is pork or for religious reasons <chamindra> so possible as you said one high level category <scopatz> OK so we'll come up with a representative list for a drop down menu <chamindra> food, water, aid, medical, etc <scopatz> Great, that makes life easier for the matching <chamindra> and a free text box for the sub category <chamindra> on the free text thing, there reason is that strcuture can create a bottle neck <chamindra> unless that process can be made easier.. like using an AJAX lookup so that you avoid spelling mistakes <flavour> We have an AJAX autocomplete widget in SahanaPy <flavour> I can help with that <flavour> 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 <flavour> scopatz: Yes, that's icing...getting *something* quickly is key <chamindra> also you will have many types of items per request <chamindra> one request will consist of multiple items (like a shopping list) <chamindra> so each one needs type, description, units, quantity <chamindra> but you can consider the whole request being from one contact, phone, and for a number of people <chamindra> good to have a backup phone and contact as well, in case the primary disappears <chamindra> but that is optional <chamindra> one last bit <chamindra> and that is the matching part <chamindra> once you get a request.. you can do a lookup and see if there is a potential match for it in the pledges <chamindra> and vice versa <chamindra> so even immidiately as they are on the call, they can respond saying there might be some options <chamindra> at the end of the request, show a list of potential full and partial matches to the request <chamindra> remember think simple intuitive interface <chamindra> no complex workflows and approvals
Note:
See TracWiki
for help on using the wiki.
