wiki:BluePrintOrganisationRegistry

Version 29 (modified by Fran Boon, 14 years ago) ( diff )

--

Organisation Registry

Who's doing What Where and When (4W)

This documentation needs to be moved between:

Introduction

"Who, What, Where"
The Organization Registry keeps track of all the relief organizations working in the disaster region. It captures not only the places where they are active, but also captures information on the range of services they are providing in each area.

Haiti Requirements: http://wiki.sahanafoundation.org/doku.php/haiti:requirements#organization_registry

Old PHP User Guide: http://wiki.sahanafoundation.org/doku.php?id=doc:or:english

We 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 BluePrint3W More work should be done to ensure that the schema is compatible with the BluePrint3W schema.

Tables

This means having the following tables:

Organisation

  • Name
  • Acronym
  • Type IS_IN_SET([Government,International Governmental Organization,International NGO,Misc,National Institution,National NGO,United Nations])
  • Website
  • National Staff
  • International Staff
  • Number of Vehicles
  • Vehicle Types
  • Donation Phone (gives the org an incentive to be listed)
  • Logo (could be displayed on the map)

Sectors

  • Name
  • Abbreviation

Office

Instance of the Site super entity

  • Name
  • Type IS_IN_SET([Headquarters,Regional,Country,Satellite Office]) (Would "Field" be a better term than "Satellite")
  • Phone 1
  • Phone 2
  • Email
  • Fax
  • Address 1
  • Address 2 (used for Postcode)
  • Needs validation (checkbox) [NEW] or Validate

Staff

To Do

  • 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)

Contact

Handled by the Person Registry?

  • First Name
  • Last Name
  • Title

Projects (previously Activities)

The Project Management module will be the main repository for Projects information.

These fields are take from a WASH (Water Health and Sanitation) Cluster form

  • Organization (link to Org Table)
  • Location
  • Sector
  • Sub-Sector (opt)
  • Description
  • Beneficiaries (number)
  • Start Date
  • End Date
  • Funded (Y/N)

4x Many-to-Many tables to link them

  • structured like t2_membership

Sector-to-Organisation

Many-to-Many table to link Sector to Organisations.

Office-to-Organisation

Many-to-Many table to link Offices to Organisations.
Optional validator to limit Offices as being affiliated to just a single Organisation

Contact-to-Office

Many-to-Many table to link Contacts to Offices.
Optional validator to limit Contacts as being affiliated to just a single Office

Contact-to-Organisation

Many-to-Many table to link Contacts to Organisations.
Optional validator to limit Contacts as being affiliated to just a single Organisation

Q: Is it useful to be able to have a Contact be affiliated to an Organisation but not to an Office?

  • would the default 'HQ' be appropriate?

Would be nice to add these functionalities:

  • Organigram creator from the Contacts
  • ID cards from the Contacts

Q: Wouldn't "Staff" be a better description than contact? Q: Contact implies just a single person for each organization.

Screens

This describes the screens laid out in a way matching with the workflow.

Dashboard

  • Organization Dashboard (will go to the organization of the current user)
  • Organizations Registry
  • Projects
  • Map

Organization Dashboard

  • Org. Details
  • Edit Org. (Restricted)
  • Offices
    • Add Office
  • Projects (for displayed Org.)
    • New Project

Organization Registry

  • List of Organizations
  • Add New Organization

Projects

  • List of all Projects
  • Display on Map (redirects to Map, with Project filter selected)

Map

Filterable options to display:

  • Offices
  • Projects
  • We want to be able to add Proejcts by Jurisdiction (e.g. Neighborhood for PaP)...without knowing the GIS data.
  • If we do have polygons for neighborhoods, these will be displayed automatically on map.
  • KML/GeoRSS feeds will just be GIS Centroids.

Reports

  • Tabular
  • Map
  • Key is to be able to identify Gaps

Site Super Entity

The following are instances of the site super entity:

  • org_office
  • cr_shelter
  • hms_hospital

The Site Super Entity allows the following components to be shared between these resources through the use of a single foreign key (site_id):

  • org_staff
  • inv_inv_item
  • inv_recv
  • inv_send
  • req_req
  • req_commit

Staff Permissions

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:

  • Only staff of an organisation have permissions (READ, CREATE, UPDATE and/or DELETE) for their organisation resource.
  • Only staff stationed at a certain site have permissions (READ, CREATE, UPDATE and/or DELETE) for their site resource.

For further flexibility, there are 2 boolean fields for staff:

  • no_access - If this is true, this staff member has no additional privileges (labelled as 'Read-only')
  • supervisor - This gives the options for more permissive permissions for some staff.

If a user creates a resource (Site or Organisation) then they are automatically given a staff record with Supervisor access to that resource.

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:

# Create roles for each organisation / site instance
s3xrc.model.configure(table, 
                       create_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. 4 & 5 will also work
    deployment_settings.aaa.has_staff_permissions = True
    deployment_settings.aaa.staff_acl = Permissions for staff role: Create, Read, Update & or Delete
    deployment_settings.aaa.supervisor_acl = Permissions for supervisor role: Create, Read, Update & or Delete
    
  2. When a new organisation or site instance is created:
    1. The current user is added as a Staff (with supervisor set) to the record [Being removed]
    2. New roles (staff & supervisor) are automatically created for that record (<tablename>_staff_id & <tablename>_supervisor_id).
    3. The current user is added as a member of both of those roles.
  1. Add staff to organisations and sites to grant them the appropriate permissions

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. This onaccept should be added to the onaccept for the component resource.

# Update owned_by_role to the site's owned_by_role    
s3xrc.model.configure(
    table, 
    onaccept = shn_component_copy_role_func(component_name = tablename, 
                                            resource_name = "org_site", 
                                            fk = "site_id",
                                            pk = "site_id")
)    

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:
    1. Sites having their own permissions according to the staff of that site
    2. 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.

Inventory Management

Inventories can be added to any site instance, by adding shn_show_inv_tabs(r) to the rheader tabs for that site instance.


BluePrints

Note: See TracWiki for help on using the wiki.