| | 264 | '''100130''' |
| | 265 | re: WFP's FoodRequest |
| | 266 | {{{ |
| | 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 wrong...you 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 |
| | 322 | }}} |
