(Security) Access Control / sharing for objects

Registered by Lars Helge Øverland on 2012-02-23

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.

---

String publicAccess;

Set<UserGroupAccess> groupAccess;

User user;

We need a new entity to capture the relationship between UserGroup and access:

UserGroupAccess
  int id;
  String access;
  UserGroup group;

--

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.

Blueprint information

Status:
Complete
Approver:
Lars Helge Øverland
Priority:
High
Drafter:
None
Direction:
Approved
Assignee:
Morten Olav Hansen
Definition:
New
Series goal:
Accepted for trunk
Implementation:
Implemented
Milestone target:
milestone icon 2.11
Started by
Morten Olav Hansen on 2013-02-12
Completed by
Lars Helge Øverland on 2014-01-07

Related branches

Sprints

Whiteboard

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

datasetid
sourceid/organisationunitid
startdate
enddate
orgunitgroupid

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.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.