Changes between Version 16 and Version 17 of UserGuidelines/Admin/Permissions


Ignore:
Timestamp:
04/08/20 13:33:14 (13 months ago)
Author:
Fran Boon
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • UserGuidelines/Admin/Permissions

    v16 v17  
    4646
    4747== Control access to Records ==
    48 Records can be owned by individuals or Organisations (including Branches, Teams & Facilities).
     48Records can have a Realm - the Realm Entity can be an individual Person, a Group, an Organisation (including Branches, Teams & Facilities), or other Person Entity (PE).
     49
     50You can see the Person Entity Model here:
     51* [wiki:DeveloperGuidelines/PersonEntityModel Person Entity Model]
    4952
    5053This allows control of access by Realm - so staff of 1 Organisation can see their records of a certain type yet not those for another Organisation in the same database.
     
    5760NB This also requires an ACL to a role other than Anonymous, Authenticated or Admin. Resources are never realm-restricted for these 3 roles.
    5861
    59 This functionality can be extended to support Hierarchy so that data restrcited to a single organisation can be amde avaialble to all branches of that Organisation (however data owned by the Branch is by default only visible to members of the Branch):
     62This functionality can be extended to support Hierarchy so that data restricted to a single organisation can be made available to all branches of that Organisation (however data owned by the Branch is by default only visible to members of the Branch):
    6063{{{
    6164settings.security.policy = 7: Apply Controller, Function, Table ACLs and Entity Realm + Hierarchy
    6265}}}
     66Note that if an entity is specified on the ACL, then that is NOT hierarchical...only the Entity on the auth_membership record is.
    6367
    6468This functionality can be extended yet further by allowing organisations to share their private data with selected individuals, teams, facilities and organisations that they wish to (this is done by delegating the access role to that other entity, as they can now decide which of their people get the access):