Changes between Version 46 and Version 47 of HaitiRMSToDo

01/31/10 04:01:47 (14 years ago)
Fran Boon

Links to WFP's FoodRequest & associated chatlogs


  • HaitiRMSToDo

    v46 v47  
    77   * Where we need more work really is in the ticketing UI, so that people can easily find the high priority tasks to action, mark them as actioned, etc
    88   * Possible code to look at [ YATSY] (a Web2Py !HelpDesk system)
     9  * Embedded RMS inside [HaitiHospitals HMS]
     10  * FoodRequests for WFP
    1012University of Wisconsin Python club are leading on this: #sahana-py
    258260<chamindra> remember think simple intuitive interface
    259261<chamindra> no complex workflows and approvals
     265re: WFP's FoodRequest
     267<flavour> I think I should merge RMS back into Trunk - just taking out the Haiti-specific URLs
     268<flavour> & the frontpage mention of Ushahidi/TtT
     269<flavour> So it's a manual based system
     270<nicopresto> that sounds like a great intiative, I'd be happy to help.
     271<flavour> With some generic feedparsing stuff which can be easily adapted as required
     272<flavour> Cool :)
     273<nicopresto> I just looked a the guts of Yatsy
     274<flavour> We don't have specific requirements yet, so nothing on that side
     275<nicopresto> could pull a couple of tweaks from there
     276<flavour> Do you fancy trying the merge back to Trunk of generic stuff?
     277<flavour> & then focus new deevl there?
     278<flavour> I guess the 'merge' is pretty easy - just the model, controller, views & cron scripts/crontab entries
     279<flavour> Then clean a little
     280<flavour> Really v.strightfwd
     281<nicopresto> sure do I just propose a merge with trunk once I've made generic?
     282<nicopresto> should this be a higher priority than polishing the haiti-specific RMS?
     283<flavour> I would say Yes
     284<flavour> As WFP is also Haiti
     285<flavour> & I think the time window when Generic RMS for Haiti was adding value has passed...I may be may be more in touch with it than me
     286<flavour> There has been a merge into HMS of that stuff for us specifically with hospitals
     287<flavour> WFP want to use for Food requests
     288<flavour> Those are the active Haiti threads
     289<flavour> For improved maintainability even in medium term, would be good to merge RMS back into Trunk
     290<flavour> This removes that anomaly
     291<flavour> Haiti-specific customisations of Ushahidi/TtT URLs & view index pages remain in Haiti
     292<flavour> That's how I see it anyway
     293<flavour> mprutsalis1: Care to comment?
     294<nicopresto> looks like they'll add specific fields, if we can make that easy for them
     295<nicopresto> also sounds like we should add back the quantity/unit level detail on requests/pledges that we started designing in the early going of the Haiti work
     296<flavour> ok, makes sense
     297<flavour> I like that anyway
     298<flavour> We know that those fields should be oprtional in some use cases
     299<flavour> e.g. the SMS/TtT feeds
     300<flavour> However for actionable requests post Search/Rescue phase then these numbers are key
     301<flavour> The one thing I think to ponder in WFP, which isn't yet clear, is security
     302<flavour> My guess is that they may want a view of 'their' requests separately from others
     303<flavour> THis /may/ need to be able to be excuded from public view
     304<flavour> It /may/ need to have a different role to enable Edits
     305<nicopresto> we need groups perhaps
     306<flavour> Right, We already have security roles
     307<flavour> We need to be able to implement them easily within RMS
     308<flavour> So once the core Haiti RMS is available in Trunk, I think that's a really good are to work on - it's similar to the Hospital mini-RMS in terms of being able to have a separate view
     309<flavour> However I think it's nice to be able to offer an aggegated view too
     310<flavour> Just some stuff to think about
     311<nicopresto> it does have the potential to diverge in terms of tasks from RMS
     312<flavour> You're thinking it's very hard to keep RMS generic?
     313<flavour> I too worry about this
     314<flavour> The Ticketing System is really critical for the 1st phase Search & Rescure part
     315<flavour> HMS have specific needs
     316<flavour> WFP have specific needs
     317<flavour> So what can be made core Trunk for RMS to allow easy deployment customisation to meet needsd
     318<flavour> Ideally being able to support customisation for multiple needs at the same time on the same instance
     319<flavour> This isn't easy but would be *so* valuable
     320<nicopresto> I think a core set of code could be generic. Maybe after we build a WFP. We could compare RMS, WFP and HMS and pick best practices for a generic
     321<nicopresto> might require some attention to generic dbase