dhis2-users team mailing list archive

[wanjala pepela <wanjala2p@xxxxxxxxx>]

It is important to decentralise user management as we promote data use at point of collection as well as increase people's participation from the district level.. this will also enhance the data ownership and encourage use.

PEPELA WANJALAMINISTRY OF HEALTH HEADQUARTERSHEALTH INFORMATION SYSTEMAFYA HOUSE, HIS LG 37P.O BOX 30016, NAIROBI, KENYATEL: +254 (020) 2717077 EXT 45097CELL: +254 (0) 722375633 or 0202033363EMAIL: wanjala2p@xxxxxxxxx            hmis@xxxxxxxxxxxx 

--- On Sat, 6/11/11, jason.p.pickering@xxxxxxxxx <jason.p.pickering@xxxxxxxxx> wrote:

From: jason.p.pickering@xxxxxxxxx <jason.p.pickering@xxxxxxxxx>
Subject: Re: [Dhis2-devs] Decentralization of user management
To: "Lars Helge Øverland" <larshelge@xxxxxxxxx>, dhis2-users@xxxxxxxxxxxxxxxxxxx, "DHIS 2 developers" <dhis2-devs@xxxxxxxxxxxxxxxxxxx>
Date: Saturday, June 11, 2011, 5:39 AM

Is this a default behaviour or something which can be controlled.through a setting? I guess my question is more about whether there is a separate "GRANT" setting which can be assigned to users to give them this privilege?

Sent from my HTC

----- Reply message -----
From: "Lars Helge Øverland" <larshelge@xxxxxxxxx>
Date: Sat, Jun 11, 2011 10:24
Subject: [Dhis2-devs] Decentralization of user management
To: <dhis2-users@xxxxxxxxxxxxxxxxxxx>, "DHIS 2 developers" <dhis2-devs@xxxxxxxxxxxxxxxxxxx>

Hi,

one learning from Kenya is that "local concerns" such as assignment of
services (datasets) and classification (group assignment) of facilities
should be decentralized to district managers as they can perform this task
more efficiently and with a better understanding of their local area.

We now increasingly see that facility users start entering data online
themselves and decentralizing management of facility user accounts would be
a good idea. This comes with a few challenges however as we want to provide
them the ability only to create users with "less" authority than what they
have themselves. We have now implemented a solution for this in trunk which
implies that a user can issue a user role to a new user if:

- The current user has the ALL authority OR the issued user role authority
group is a subset of the aggregated authorities of the current user (i.e.
the current user has all of the authorities he wants to issue to another
user.)

- The issued user role is NOT among the current user's user roles (i.e. the
current user can not issue his own user roles to another user.)

The latter rule is there e.g. because we don't want districts users to
create new district users, rather to create facility users only.

This solution means that it is now sensible to allow district and province
users access to the user module. Just to keep you informed...


Lars



-----Inline Attachment Follows-----

_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp