Changes between Version 32 and Version 33 of BluePrintOrganisationRegistry


Ignore:
Timestamp:
03/21/11 04:24:30 (11 years ago)
Author:
Michael Howden
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrintOrganisationRegistry

    v32 v33  
    22= Organisation Registry  =
    33'''Who's doing What Where and When (4W)'''
    4 
    5 This documentation needs to be moved between:
    6 * UserGuidelinesAdmin
    7 * UserGuidelinesOrganisationRegistry
    8 * UserGuidelinesInventory
    9 * [wiki:S3XRC/ModelExtensions/SuperEntities]
    104
    115== Introduction ==
     
    1913We should aim to be able to exchange data with UN OCHA's 3W. Information about the 3W database schema, possible import methods to OCHA, and 3W controlled vocabulary lists can be found at [wiki:BluePrint3W]
    2014More work should be done to ensure that the schema is compatible with the [wiki:BluePrint3W] schema.
     15
     16Most 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
    2129
    2230== Tables ==
     
    5260
    5361=== Staff ===
    54 ==== To Do ====
    55  * 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)
    56 
    57 === Contact ===
    5862Handled by the [wiki:BluePrintPersonRegistry Person Registry]?
    5963 * First Name
     
    8589Optional validator to limit Offices as being affiliated to just a single Organisation
    8690
    87 === Contact-to-Office ===
    88 Many-to-Many table to link Contacts to Offices.[[BR]]
    89 Optional validator to limit Contacts as being affiliated to just a single Office
     91=== Staff-to-Office ===
     92Many-to-Many table to link Staff to Offices.[[BR]]
     93Optional validator to limit Staff as being affiliated to just a single Office
    9094
    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 ===
     96Many-to-Many table to link Staff to Organisations.[[BR]]
     97Optional validator to limit Staff as being affiliated to just a single Organisation
    10498
    10599== Screens ==
     
    132126Filterable options to display:
    133127 * Offices
    134  * Projects
    135 
    136128 * We want to be able to add Proejcts by Jurisdiction (e.g. Neighborhood for PaP)...without knowing the GIS data.
    137129 * If we do have polygons for neighborhoods, these will be displayed automatically on map.
     
    143135  * Key is to be able to identify Gaps
    144136
    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 
    221137----
    222138BluePrints