(Security) Access Control / sharing for objects
The system needs to provide a more fine-grained level of access control. In many implementations there are several stakeholders including the government, implementing partners, programs, NGOs and so on. Some of these stakeholders have needs for confining access to data artefacts within their own organisation. For instance, an implementing partner might want to create a report which should only be accessible to users within that organisation.
All identifiable objects must have three levels of access.
We need a new entity to capture the relationship between UserGroup and access:
We need a user interface widget for setting access control (sharing). It should be available in add, update and list screens.
"Add new object" authorities must be split into "add new private object" and "add new public object".
Icons for updating and removing objects in the user interface must be visually disabled if the current user does not have the authority to perform those actions.
- Lars Helge Øverland
- Morten Olav Hansen
- Series goal:
- Accepted for trunk
- Milestone target:
- Started by
- Morten Olav Hansen on 2013-02-12
- Completed by
- Lars Helge Øverland on 2014-01-07
Added by JPP. Putting this here..from our email conversation Lars.
--Restrict user access controls
In one scenario, the specific requirement is to only provide access to the orgunits
which have been assigned to the user through usermemberships. Of
course, the admin user is a completely different case, and should have
access to all, and thus no need to store these explicitly in
usermembership.This would imply several new classes of users
1) Access to all orgunit regardless of dataset assignment. Data would be available through MyDatamart and other parts of the application regardless of the assignments in usermembership.
2) Automatically inherit all sibilings of orgunits which have been assigned to the user. For instance, a privileged user at the state level is assigned a single state. They inherit all orgunits beneath the state which they have been assigned. The user would be confined to their branch of the orgunit hierarchy, including downloads through MyDatamart, reports, etc.
3) Do not inherit any orgunits automatically unless explicitly assigned to the user. The usermembership table would then act as a sort of global filter in all areas, and confine the user to specific orgunits which have been explicitly assigned to them.
--Temporal nature of the partner hierarchy
More info from the use case in Nigeria, while I am thinking about it.
In addition to the access controls mentioned above, we need to be able to deal with the dynamic nature of the partner/projects parallel hierarchy. A suggested object to store this may look like this
This would establish a linkage between a dataset, an orgunit, some time interval, and then a link to an orgunit groupid, which should be part of an orgunitgroupset such as "Implementing partners". The scenario as I understand it here is that there are situations where multiple partners work in the same facility, but typically (but not always) report on different datasets. So, PartnerA may report PMTCT and Partner B may work on Counselling and Testing in 2011. In 2012, maybe PMTCT is taken over by Partner C while Partner B continues to work on Counselling and Testing.