Changes between Version 25 and Version 26 of NextforHMS

Timestamp:

01/28/10 23:31:36 (15 years ago)

Author:

Dominic König

Comment:

--

NextforHMS

@@ -45 +45 @@
  * 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]]
 
- * Added the following roles (auth.group):
+ * Add Link to Bed Capacity, Services, Shortages, Contacts to main ADD Hospital form @ /hms/hospital/create
+
+'''Notes from dzubey'''
+
+>> Need to establish who are our user groups? Then based on that what rights should they NOT have.
+> * nursix says: I added the following roles (auth.group):
 
    ||'''Role'''||'''proposed for'''||
@@ -54 +59 @@
    ||HMSAdmin||access to everything in HMS||
 
- * Add Link to Bed Capacity, Services, Shortages, Contacts to main ADD Hospital form @ /hms/hospital/create
+>> 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. 
 
-'''Notes from dzubey'''
+>> 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)
 
- - Need to establish who are our user groups? Then based on that what rights should they NOT have.
- - 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. 
-
- - 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)
-
- - 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.
+>> 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.
 ----
 ==== Accepted ====