| | 49 | * '''Security''' - enable role management - this is an urgent requirement assigned to sysadmin team: Praneeth (lead), Tim & Dan. Need written recommendation sent to mark by e-mail by 1600Z on 28 January 2010; meeting in #sahana-py at 1700Z on 28 January. Background: security for personnel on ground makes it inadvisable to publish publicly the needs and fulfillment information that might be embedded in the HMS - i.e. publishing that medical supplies are to be delivered to this place at this time might put the shipment and relief workers lives at risk. We need a plan to implement role-based access to different Sahana libraries. I need the sysadmin team to advise which of the following requirements is possible to do through front-end configuration of SahanaPy security settings (preferred) and which will require coding changes (not preferred). Alternatives are welcome. The team should also evaluate and advise on the impact shutting down read-only public access to parts of sahana will have on our feeds of data on hospital locations and hospital management data. Requirements: |
| | 50 | * Public/anonymous access: Read only access to OR, RMS Twitter and 4636 Messages. |
| | 51 | * Option to make HMS hospitals feed with location and general information - but not the shortages table - publicly available |
| | 52 | * Can we hide individual fields (like beds available, security status, facility status) from public view without code changes? |
| | 53 | * Registered users: Read only access to entire system (adding PR and HMS / HMS shortages) |
| | 54 | * Entry users: Registered users who are given add/edit/update/delete access to OR, PR, HMS |
| | 55 | * Options to create additional groups that have add/edit/update/delete access to each individual registry - and bundle people that way. e.g. Tim has write privileges to OR and PR but not HMS or RMS; Praneeth has write privileges to RMS but nothing else; Dan has write privileges to RMS, OR, and PR but not HMS. [[BR]] |
| | 56 | |
| | 57 | * Add Link to Bed Capacity, Services, Shortages, Contacts to main ADD Hospital form @ /hms/hospital/create |
| | 58 | |
| | 59 | '''Notes from dzubey''' |
| | 60 | |
| | 61 | - Need to establish who are our user groups? Then based on that what rights should they NOT have. |
| | 62 | - 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. |
| | 63 | |
| | 64 | - 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: opposed? individual user-based ACL too complex for disaster response, role-based ACL is a proven good solution, and you can always add one "role" per user and thus establish an individual ACL) |
| | 65 | |
| | 66 | - 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. |
| | 67 | ---- |
| | 68 | ==== Accepted ==== |
| | 69 | |
| | 70 | * Add Register for new account and Login Links prominent on home/splash page |
| | 71 | * Add '''Operating Room Status''' to list of services on Hospital entry/edit form - similar to Emergency Room, Clinical, Facility, Security fields now. |
| | 72 | * '''Provenance of data''' - without adding any fields (at this time), we need to display the last time data records were updated and by whom - we should be able to pull from the last modified column and the registered user who made the modification. This is especially important to allow for evaluation of how old data is and how often it is being updated. Maybe a big bold splash on upper right when viewing a hospital record would say "Last modified on DDMMYY at HH:MM UTC by <Registered User>". Or just show the data as additional field in form view or column in table view. |
| | 73 | * For HMS - additional fields needed for hospital data: |
| | 74 | * Road Status (comment field to describe road access to the facility). |
| | 75 | * Ability to attach multiple meta-data tagged files (e.g. photos of the facility, scanned maps of the area and surrounding roads). |
| | 76 | * For HMS - Locations: |
| | 77 | * We need to manage additional "medical facilities" beyond hospitals. I think we can do this now without further modification as one is not prohibited from entering something that is not a hospital after you select "add hospital". |
| | 78 | * Other feature classes that we can expect will be added to the HMS are: "field hospitals", "clinics", "pharmacies", and "helipads". While it is easy to add these are locations and give them a different feature class and marker, there is no category within the HMS record itself, unless we pull it from the location feature class... Can we do that? |
| | 79 | * Of course, this may mean that we may need to be prepared change labeling from "hospital" to "medical facility" or "medical" (and HMS becomes relabeled as MMS). Be prepared. |
| 77 | | == Additional Requirements based on 280110T0400Z review of notes from the day: == |
| 78 | | |
| 79 | | |
| 80 | | * '''Security''' - enable role management - this is an urgent requirement assigned to sysadmin team: Praneeth (lead), Tim & Dan. Need written recommendation sent to mark by e-mail by 1600Z on 28 January 2010; meeting in #sahana-py at 1700Z on 28 January. Background: security for personnel on ground makes it inadvisable to publish publicly the needs and fulfillment information that might be embedded in the HMS - i.e. publishing that medical supplies are to be delivered to this place at this time might put the shipment and relief workers lives at risk. We need a plan to implement role-based access to different Sahana libraries. I need the sysadmin team to advise which of the following requirements is possible to do through front-end configuration of SahanaPy security settings (preferred) and which will require coding changes (not preferred). Alternatives are welcome. The team should also evaluate and advise on the impact shutting down read-only public access to parts of sahana will have on our feeds of data on hospital locations and hospital management data. Requirements: |
| 81 | | * Public/anonymous access: Read only access to OR, RMS Twitter and 4636 Messages. |
| 82 | | * Option to make HMS hospitals feed with location and general information - but not the shortages table - publicly available |
| 83 | | * Can we hide individual fields (like beds available, security status, facility status) from public view without code changes? |
| 84 | | * Registered users: Read only access to entire system (adding PR and HMS / HMS shortages) |
| 85 | | * Entry users: Registered users who are given add/edit/update/delete access to OR, PR, HMS |
| 86 | | * Options to create additional groups that have add/edit/update/delete access to each individual registry - and bundle people that way. e.g. Tim has write privileges to OR and PR but not HMS or RMS; Praneeth has write privileges to RMS but nothing else; Dan has write privileges to RMS, OR, and PR but not HMS. [[BR]] |
| 87 | | |
| 88 | | ---- |
| 89 | | '''Notes from dzubey''' |
| 90 | | |
| 91 | | |
| 92 | | Need to establish who are our user groups? Then based on that what rights should they NOT have. |
| 93 | | |
| 94 | | 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. |
| 95 | | |
| 96 | | There is an more optimal method of assigning flags to users, which indicate what capabilities they are allowed, as opposed to role-based. |
| 97 | | |
| 98 | | 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. |
| 99 | | [[BR]] |
| 100 | | * '''Provenance of data''' - without adding any fields (at this time), we need to display the last time data records were updated and by whom - we should be able to pull from the last modified column and the registered user who made the modification. This is especially important to allow for evaluation of how old data is and how often it is being updated. Maybe a big bold splash on upper right when viewing a hospital record would say "Last modified on DDMMYY at HH:MM UTC by <Registered User>". Or just show the data as additional field in form view or column in table view. [[BR]] |
| 101 | | [[BR]] |
| 102 | | * '''Operating Room Status''' - add to list of services on Hospital entry/edit form - similar to Emergency Room, Clinical, Facility, Security fields now.[[BR]] |
| 103 | | [[BR]] |
| 104 | | * Add Link to Bed Capacity, Services, Shortages, Contacts to main ADD Hospital form @ /hms/hospital/create[[BR]] |
| 105 | | [[BR]] |
| 106 | | * Add Register for new account and Login Links prominent on home/splash page |
| 107 | | |
| 108 | | |
