an issue where input is needed from the community:
Currently, one rule for user management says that users cannot see nor edit users which have granted the same user roles as themselves.
The rationale for this restriction is e.g. that district officers should not be able to create other district officer user accounts.
Is this restriction still necessary?
Reason for asking is that some organisations have started designing user roles in a way where you a have a larger number of user roles focused on topics, and user roles are mixed and matched when creating new users. This restriction does not work well in this scenario.
A second rule is that users can only see other users for which they have all of their authorities. This restriction will remain.
On Friday, 14 March 2014, 11:34, Lars Helge Øverland larshelge@gmail.com wrote:
Hi all,
an issue where input is needed from the community:
Currently, one rule for user management says that users cannot see nor edit users which have granted the same user roles as themselves.
The rationale for this restriction is e.g. that district officers should not be able to create other district officer user accounts.
Is this restriction still necessary?
Reason for asking is that some organisations have started designing user roles in a way where you a have a larger number of user roles focused on topics, and user roles are mixed and matched when creating new users. This restriction does not work well in this scenario.
A second rule is that users can only see other users for which they have all of their authorities. This restriction will remain.
Hello Bayo
With the restriction lifted a user would be able to edit or create users within the org unit (and children) assigned, with the same or lower rights assigned to the account. Would that work for you?
On Friday, 14 March 2014, 11:34, Lars Helge Øverland larshelge@gmail.com wrote:
Hi all,
an issue where input is needed from the community:
Currently, one rule for user management says that users cannot see nor edit users which have granted the same user roles as themselves.
The rationale for this restriction is e.g. that district officers should not be able to create other district officer user accounts.
Is this restriction still necessary?
Reason for asking is that some organisations have started designing user roles in a way where you a have a larger number of user roles focused on topics, and user roles are mixed and matched when creating new users. This restriction does not work well in this scenario.
A second rule is that users can only see other users for which they have all of their authorities. This restriction will remain.
since there were conflicting views on this issue, and since both "modes"
makes sense depending on how you define your user roles, it seems a system
setting will be the best option. In trunk a system access setting called
"allow users to grant own user roles" has been added now.
since there were conflicting views on this issue, and since both “modes” makes sense depending on how you define your user roles, it seems a system setting will be the best option. In trunk a system access setting called “allow users to grant own user roles” has been added now.
Vous servir est mon désire (Serving you is my desire)
Hi,
since there were conflicting views on this issue, and since both “modes” makes sense depending on how you define your user roles, it seems a system setting will be the best option. In trunk a system access setting called “allow users to grant own user roles” has been added now.
–
Vous servir est mon désire (Serving you is my desire)
Hi,
since there were conflicting views on this issue, and since both “modes” makes sense depending on how you define your user roles, it seems a system setting will be the best option. In trunk a system access setting called “allow users to grant own user roles” has been added now.
The thinking was that there are two "styles" of defining user roles - one
hierarchical approach where you define user roles according to people's
position/role in the ministry/organisation, e.g. "district officer". The
other where you define roles based on dhis functionality, e.g. "data
quality operations". So in these two approaches you would likely want all
roles to be either / or.
But these are just ideas and we will learn when it hits real users.
···
On Mon, Mar 24, 2014 at 7:05 AM, Jason Pickering < jason.p.pickering@gmail.com> wrote:
I personally would think this would make more sense as a permission for a
user role. That way, it is very clear who is allowed to do what.