dhis2-devs-core team mailing list archive

[Jim Grace <jimgrace@xxxxxxxxx>]

Hi All,

Lars suggested I keep you up to date on the code I've been adding for 2.16.
Here's some of what I've been up to -- besides minor bug fixes and the like
;)

*User groups and invitations*

o Allow distributed management of users through the use of user groups.
This is enabled through a new system setting "Users must belong to a group
controlled by the user manager". When enabled, a user with the authority
"Add/Update user" may only create or edit users who belong to a user group
to which the managing user has R/W ("Can edit and view") access.

This allows independent groups of users to be managed within the system, in
the same parts of the organisation unit hierarchy. For example, a user
group may have access to resources such as an attribute category
(representing, for example, an implementation partner). If a user
administrator has R/W access to this group, then they may manage other
users within that group who are thus granted access to the same category.

Other user management restrictions still apply. For example, a user cannot
create another user with wider access to organization units. So with this
setting, you can have distributed management of users within a subset of
available attribute categories and also within a subset of the organisation
unit hierarchy.

More details at:
https://blueprints.launchpad.net/dhis2/+spec/distributed-user-management-by-user-groups

o User account invitations can now be made by a POST to /users/invite. With
both user account invitations and regular user creation (POST to /users),
you can specify user group membership at the same time as creating a user
or user invitation. (This is necessary for when "Users must belong to a
group controlled by the user manager" is in effect.) Just use the same
format for specifying user groups as when you do a GET of a user -- but
only the user group UID is required.

*User analysis dimension restrictions:*

o Added the ability to restrict analysis for a user account by attribute
category. (Specify an attribute category, and then any time the user
fetches data, the data is automatically filtered by the category options
from that category to which the user has read access.) This is in addition
to the previous feature to restrict analysis by category option group set
(specify a C.O.G.S. and any user data access will be restricted to the
category option groups that the user can see within the C.O.G.S.)

o Enhanced the validation logic to take into account dimension restrictions
(both C.O.G.S. and category.) So the user running the validation will be
see results only from data that they are authorized to see.

*Start and end dates for category options:*

o You may optionally assign a start date and/or end date to a category
option, for use in attribute categories. When a start date is assigned,
that option may be selected as an attribute category option only for
periods that span the start date, or later. When an end date is assigned,
data for that option may be selected as an attribute category option only
for periods that span the end date, or earlier.

For this reason, the period is now specified on the data entry screen
before any attribute category options, since the options available may
depend on the period. While doing this, I also made it more flexible to
switch contexts as you add data. For example, if you switch data sets, and
the new data set has the same period type, the period selection is retained
instead of discarded. And if the same attribute categories apply to the new
data set, the category option settings are retained instead of discarded.

I also added the category option selection(s) when present to the
non-scrolling selection status division, so the user can be reminded which
category option(s) they are entering data for. (I reduced the font size to
normal because the div can grow wider.)

Cheers,
Jim