Changes between Version 23 and Version 24 of BluePrintOrganisationRegistry

Timestamp:

03/11/11 10:50:24 (14 years ago)

Author:

Michael Howden

Comment:

--

BluePrintOrganisationRegistry

@@ -27 +27 @@
  * {{{supervisor}}} - This gives the options for more permissive permissions for some staff.
 
-This is done by the {{{shn_create_record_roles}}} function in {{{models/05_org.py}}}, which can be called from a org or site onaccept by using:
+This is done by the {{{shn_create_record_roles}}} function in {{{models/05_org.py}}}, which can be called from a org or site onaccept by configuring the onaccept for that resource as following:
 {{{
-# Create roles for each organisation 
+# Create roles for each organisation / site instance
 s3xrc.model.configure(table, 
                       onaccept = shn_staff_join_onaccept_func(tablename))  
 }}}
+(This code should be called after the resource table is defined in the model)
 
 === Enabling Staff Permissions ===
  1. Set:
  {{{
-deployment_settings.security.policy = 3 # Controller-ACLs
+deployment_settings.security.policy = 3 # Controller-ACLs. 4 & 5 will also work
 deployment_settings.aaa.has_staff_permissions = True
-deployment_settings.aaa.staff_acl = Permissions for staff
-deployment_settings.aaa.supervisor_acl = Permissions for staff flagged as "supervisor"
+deployment_settings.aaa.staff_acl = Permissions for staff role
+deployment_settings.aaa.supervisor_acl = Permissions for supervisor role 
 }}}
- 2. Add staff to organisations and sites
+ 2. When a new organisation or site instance is created: 
+  i. The current user is added as a Staff (with supervisor set) to the record
+  i. New roles (staff & supervisor) are automatically created for that record (<tablename>_staff_id & <tablename>_supervisor_id).  
+  i. The current user is added as a member of both of those roles.
+
+ 3. Add staff to organisations and sites to grant them permission
 
 === Inheriting Permissions ===
-To allow other components inherit the same permissions as the primary resource, the following function can be called, to add a onaccept function which will copy the "owned_by_role" from the primary resource
+To allow other components inherit the same permissions as the primary resource, the following function can be called, to add a onaccept function which will copy the "owned_by_role" from the primary resource. This onaccept should be added to the onaccept for the component resource. 
 {{{
 # Update owned_by_role to the site's owned_by_role    
@@ -57 +63 @@
 }}}
 
+The staff component resource itself currently inherit permissions from sites not organisations, because this is LESS permissive. This may need to become a deployment setting.
 
 === To Do ===
  * How to handle permissions for site resources - should they inherit permissions from an organisation resource?
+  * No, they have their own permissions which are more specific than the organisation permissions, but...
+ * Have an deployment_setting to switch between:
+  a. Sites having their own permissions according to the staff of that site
+  a. All sites inheriting their permissions from the organisation's staff (site's owned_by_role = org_organisation_staff role)
+ * Allow staff for Organisation to be marked as "admin" (or something) and have them ALWAYS have permissions for any site belonging to the organisation
  * if a single person is assigned as staff to multiple sites or organisations, there will be multiple site records for this person. This may cause confusion when creating staff lists. Perhaps the data structure should be revised to accommodate this.