Changes between Version 31 and Version 32 of NextforHMS


Ignore:
Timestamp:
01/29/10 06:05:06 (15 years ago)
Author:
Mark Prutsalis
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • NextforHMS

    v31 v32  
    2828  ||KABAP||Pre-Production||http://haiti-hms.sahanafoundation.org/live/hms||lp:sahana/haiti-hms||Branch to abandon||
    2929  ||VITA||Demo||http://vita.sahanapy.org/sahana/hms||lp:~nursix.org/sahana/vita||Main Development Line for HMS||
    30   ||PROD||Production||http://haiti.sahanafoundation.org/prod/hms||lp:sahana/haiti-release||Final target branch for HMS||
     30  ||PROD||Production||http://haiti.sahanafoundation.org/prod/hms||lp:sahana/haiti-release||Final target branch for HMS||[[BR]]
     31>>> globaliist says: I thought KAPAB was based on lp:sahana/haiti-release code?  Check with TimClicks.  This should function as a test/UAT environment for integrating with the other systems that are a part of this project.  Once KAPAB is ready to go live, will need to flush and set up sync with production.[[BR]]
     32
    3133
    3234----
     
    7476   ||HMSAdmin||access to everything in HMS||
    7577
     78>>> globaliist says: I like role-based systems.  Thanks.  Is this too complex?  How does it address above requirements which include OR, PR, RMS (not H-RMS) but this seems to create a level of complexity that will be hard to administer or is that more straightforward to implement based on the above requirements[[BR]]
     79
    7680>> If the main concern is keeping certain data away from the general public, and we are time crunched, then a generic anonymous / read-only / read-write structure is fine...but this makes it very hard to change in the future.
    77 
    7881>> There is an more optimal method of assigning flags to users, which indicate what capabilities they are allowed, as opposed to role-based (nursix thinks: role-based ACL is a proven good solution, implemented by the web2py framework, so nothing we have to develop, and you can always add one "role" per user and thus establish an individual ACL)
    7982
    8083>> we've already leaked a good quantity of data to various search engines and blogs and whatnot. I imagine this current push is to secure future data we capture.
     84
     85>>> globallist says: dzubey.... the requirements come from what I already explained - it has to do with the safety and security of relief workers... not because the data is otherwise sensitive. 
    8186----
    8287==== Accepted ====