Changes between Version 23 and Version 24 of BluePrintOrganisationRegistry


Ignore:
Timestamp:
03/11/11 10:50:24 (11 years ago)
Author:
Michael Howden
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrintOrganisationRegistry

    v23 v24  
    2727 * {{{supervisor}}} - This gives the options for more permissive permissions for some staff.
    2828
    29 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:
     29This 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:
    3030{{{
    31 # Create roles for each organisation
     31# Create roles for each organisation / site instance
    3232s3xrc.model.configure(table,
    3333                      onaccept = shn_staff_join_onaccept_func(tablename)) 
    3434}}}
     35(This code should be called after the resource table is defined in the model)
    3536
    3637=== Enabling Staff Permissions ===
    3738 1. Set:
    3839 {{{
    39 deployment_settings.security.policy = 3 # Controller-ACLs
     40deployment_settings.security.policy = 3 # Controller-ACLs. 4 & 5 will also work
    4041deployment_settings.aaa.has_staff_permissions = True
    41 deployment_settings.aaa.staff_acl = Permissions for staff
    42 deployment_settings.aaa.supervisor_acl = Permissions for staff flagged as "supervisor"
     42deployment_settings.aaa.staff_acl = Permissions for staff role
     43deployment_settings.aaa.supervisor_acl = Permissions for supervisor role
    4344}}}
    44  2. Add staff to organisations and sites
     45 2. When a new organisation or site instance is created:
     46  i. The current user is added as a Staff (with supervisor set) to the record
     47  i. New roles (staff & supervisor) are automatically created for that record (<tablename>_staff_id & <tablename>_supervisor_id). 
     48  i. The current user is added as a member of both of those roles.
     49
     50 3. Add staff to organisations and sites to grant them permission
    4551
    4652=== Inheriting Permissions ===
    47 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
     53To 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.
    4854{{{
    4955# Update owned_by_role to the site's owned_by_role   
     
    5763}}}
    5864
     65The staff component resource itself currently inherit permissions from sites not organisations, because this is LESS permissive. This may need to become a deployment setting.
    5966
    6067=== To Do ===
    6168 * How to handle permissions for site resources - should they inherit permissions from an organisation resource?
     69  * No, they have their own permissions which are more specific than the organisation permissions, but...
     70 * Have an deployment_setting to switch between:
     71  a. Sites having their own permissions according to the staff of that site
     72  a. All sites inheriting their permissions from the organisation's staff (site's owned_by_role = org_organisation_staff role)
     73 * Allow staff for Organisation to be marked as "admin" (or something) and have them ALWAYS have permissions for any site belonging to the organisation
    6274 * 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.
    6375