| | 1 | = NEW! = |
| | 2 | This relates to functionality implemented in https://code.launchpad.net/~michael-howden/sahana-eden/eden. It is being documented in the Blue Prints so that the functionality can be reviewed. Once it is approved this documentation will be shifted between: |
| | 3 | * UserGuidelinesAdmin |
| | 4 | * UserGuidelinesOrganisationRegistry |
| | 5 | * UserGuidelinesInventory |
| | 6 | * S3XRC/ModelExtensions/SuperEntities |
| | 7 | |
| | 8 | == Site Super Entity == |
| | 9 | The following are instances of the site super entity: |
| | 10 | * org_office |
| | 11 | * cr_shelter |
| | 12 | * hms_hospital |
| | 13 | The Site Super Entity allows the following components to be shared between these resources through the use of a single foreign key ({{{site_id}}}): |
| | 14 | * org_staff |
| | 15 | * inv_inv_item |
| | 16 | * inv_recv |
| | 17 | * inv_send |
| | 18 | * req_req |
| | 19 | * req_commit |
| | 20 | |
| | 21 | == Staff Permissions == |
| | 22 | Staff ({{{org_staff}}) can be added as components of site instances (offices, hospitals and shelters) and organisations. There are a number of Use Cases where you may want to apply permissions based on the staff of a resource: |
| | 23 | * Only staff of an organisation have permissions (READ, CREATE, UPDATE and/or DELETE) for their organisation resource. |
| | 24 | * Only staff stationed at a certain site have permissions (READ, CREATE, UPDATE and/or DELETE) for their organisation resource. |
| | 25 | For further flexibility, there are 2 boolean fields for staff: |
| | 26 | * {{{no_access}} - If this is true, this staff member has no additional priviledges |
| | 27 | * {{{supervisor}}} - This gives the options for more permissive permissions for some staff. |
| | 28 | |
| | 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: |
| | 30 | {{{ |
| | 31 | # Create roles for each organisation |
| | 32 | s3xrc.model.configure(table, |
| | 33 | onaccept = shn_staff_join_onaccept_func(tablename)) |
| | 34 | }}} |
| | 35 | |
| | 36 | === Enabling Staff Permissions === |
| | 37 | 1. Set: |
| | 38 | {{{ |
| | 39 | deployment_settings.security.policy = 3 # Controller-ACLs |
| | 40 | deployment_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" |
| | 43 | }}} |
| | 44 | 2. Add staff to organisations and sites |
| | 45 | |
| | 46 | === 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 |
| | 48 | {{{ |
| | 49 | # Update owned_by_role to the site's owned_by_role |
| | 50 | s3xrc.model.configure( |
| | 51 | table, |
| | 52 | onaccept = shn_component_copy_role_func(component_name = tablename, |
| | 53 | resource_name = "org_site", |
| | 54 | fk = "site_id", |
| | 55 | pk = "site_id") |
| | 56 | ) |
| | 57 | }}} |
| | 58 | |
| | 59 | |
| | 60 | === To Do === |
| | 61 | * How to handle permissions for site resources - should they inherit permissions from an organisation resource? |
| | 62 | * 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. |
| | 63 | |
| | 64 | == Inventory Management == |
| | 65 | Inventories can be added to any site instance, by adding {{{shn_show_inv_tabs(r)}}} to the rheader tabs for that site instance. |
| | 66 | |
