| | 15 | |
| | 16 | Most of this functionality has already been implemented. |
| | 17 | |
| | 18 | == To Do == |
| | 19 | * How to handle permissions for site resources - should they inherit permissions from an organisation resource? |
| | 20 | * No, they have their own permissions which are more specific than the organisation permissions, but... |
| | 21 | * Have an deployment_setting to switch between: |
| | 22 | a. Sites having their own permissions according to the staff of that site |
| | 23 | a. All sites inheriting their permissions from the organisation's staff (site's owned_by_role = org_organisation_staff role) |
| | 24 | * Allow staff for Organisation to be marked as "admin" (or something) and have them ALWAYS have permissions for any site belonging to the organisation |
| | 25 | * 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. |
| | 26 | * Make S3PersonAutocompleteWidget work with the filter criteria of the field.requires (this is required to ensure only unique staff can be added to each site) |
| | 27 | * Organigram creator from the Staff |
| | 28 | * ID cards from the Staff |
| 91 | | === Contact-to-Organisation === |
| 92 | | Many-to-Many table to link Contacts to Organisations.[[BR]] |
| 93 | | Optional validator to limit Contacts as being affiliated to just a single Organisation |
| 94 | | |
| 95 | | |
| 96 | | Q: Is it useful to be able to have a Contact be affiliated to an Organisation but not to an Office? |
| 97 | | * would the default 'HQ' be appropriate? |
| 98 | | |
| 99 | | Would be nice to add these functionalities: |
| 100 | | * Organigram creator from the Contacts |
| 101 | | * ID cards from the Contacts |
| 102 | | Q: Wouldn't "Staff" be a better description than contact? |
| 103 | | Q: Contact implies just a single person for each organization. |
| | 95 | === Staff-to-Organisation === |
| | 96 | Many-to-Many table to link Staff to Organisations.[[BR]] |
| | 97 | Optional validator to limit Staff as being affiliated to just a single Organisation |
| 145 | | == Site Super Entity == |
| 146 | | The following are instances of the site super entity: |
| 147 | | * org_office |
| 148 | | * cr_shelter |
| 149 | | * hms_hospital |
| 150 | | The Site Super Entity allows the following components to be shared between these resources through the use of a single foreign key ({{{site_id}}}): |
| 151 | | * org_staff |
| 152 | | * inv_inv_item |
| 153 | | * inv_recv |
| 154 | | * inv_send |
| 155 | | * req_req |
| 156 | | * req_commit |
| 157 | | |
| 158 | | == Staff Permissions == |
| 159 | | 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: |
| 160 | | * Only staff of an organisation have permissions (READ, CREATE, UPDATE and/or DELETE) for their organisation resource. |
| 161 | | * Only staff stationed at a certain site have permissions (READ, CREATE, UPDATE and/or DELETE) for their site resource. |
| 162 | | |
| 163 | | For further flexibility, there are 2 boolean fields for staff: |
| 164 | | * {{{no_access}}} - If this is true, this staff member has no additional privileges (labelled as 'Read-only') |
| 165 | | * {{{supervisor}}} - This gives the options for more permissive permissions for some staff. |
| 166 | | |
| 167 | | If a user creates a resource (Site or Organisation) then they are automatically given the Supervisor role for that resource. |
| 168 | | |
| 169 | | The roles are created by the {{{shn_create_record_roles}}} function in {{{models/05_org.py}}}, which can be called from an org or site create_onaccept by configuring the model as following: |
| 170 | | {{{ |
| 171 | | # Create roles for each organisation / site instance |
| 172 | | s3xrc.model.configure(table, |
| 173 | | create_onaccept = shn_staff_join_onaccept_func(tablename)) |
| 174 | | }}} |
| 175 | | (This code should be called after the resource table is defined in the model) |
| 176 | | |
| 177 | | === Enabling Staff Permissions === |
| 178 | | 1. Set: |
| 179 | | {{{ |
| 180 | | deployment_settings.security.policy = 3 # Controller-ACLs. 4 & 5 will also work |
| 181 | | deployment_settings.aaa.has_staff_permissions = True |
| 182 | | deployment_settings.aaa.staff_acl = Permissions for staff role: Create, Read, Update & or Delete |
| 183 | | deployment_settings.aaa.supervisor_acl = Permissions for supervisor role: Create, Read, Update & or Delete |
| 184 | | ("org", Storage( |
| 185 | | .... |
| 186 | | restricted = True, |
| 187 | | }}} |
| 188 | | 2. When a new organisation or site instance is created: |
| 189 | | i. New roles (staff & supervisor) are automatically created for that record (tablename_recordid Staff of recordname & tablename_recordid Supervisors of recordname). |
| 190 | | i. The current user is added as a member of both of those roles. |
| 191 | | |
| 192 | | 3. Add staff to organisations and sites to grant them the appropriate permissions |
| 193 | | |
| 194 | | === Inheriting Permissions === |
| 195 | | 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. |
| 196 | | {{{ |
| 197 | | # Update owned_by_role to the site's owned_by_role |
| 198 | | s3xrc.model.configure( |
| 199 | | table, |
| 200 | | onaccept = shn_component_copy_role_func(component_name = tablename, |
| 201 | | resource_name = "org_site", |
| 202 | | fk = "site_id", |
| 203 | | pk = "site_id") |
| 204 | | ) |
| 205 | | }}} |
| 206 | | |
| 207 | | 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. |
| 208 | | |
| 209 | | === To Do === |
| 210 | | * How to handle permissions for site resources - should they inherit permissions from an organisation resource? |
| 211 | | * No, they have their own permissions which are more specific than the organisation permissions, but... |
| 212 | | * Have an deployment_setting to switch between: |
| 213 | | a. Sites having their own permissions according to the staff of that site |
| 214 | | a. All sites inheriting their permissions from the organisation's staff (site's owned_by_role = org_organisation_staff role) |
| 215 | | * Allow staff for Organisation to be marked as "admin" (or something) and have them ALWAYS have permissions for any site belonging to the organisation |
| 216 | | * 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. |
| 217 | | |
| 218 | | == Inventory Management == |
| 219 | | Inventories can be added to any site instance, by adding {{{shn_show_inv_tabs(r)}}} to the rheader tabs for that site instance. |
| 220 | | |
