On Mon, Mar 24, 2014 at 7:05 AM, Jason Pickering <
jason.p.picker...@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.
>
>
Interesting idea. Might be better for all I know.
The thinking
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.
Regards,
Jason
On Mon, Mar 24, 2014 at 3:45 PM, riddy ndoma wrote:
> I think as good. Because it's flexible @Lars!
>
>
> 2014-03-23 19:57 GMT+01:00 Deemoy
I think as good. Because it's flexible @Lars!
2014-03-23 19:57 GMT+01:00 Deemoyes :
> Yes, I think this makes sense.
>
> Sent from my BlackBerry 10 smartphone.
> *From: *Lars Helge Øverland
> *Sent: *Sunday, 23 March 2014 19:30
> *To: *JM Alcantara
> *Cc: *DHIS 2 Users list; DHIS 2 Developers
Yes, I think this makes sense. Sen
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.
Lars
_
Dears,
For me, i will YES. This
restriction is still very neccessary.
Since they have same or equal
level of previledge, the restriction should remain.
Thank you.
_ _ _ _ _ _ _ _
Bayo Mohammed, ONIMODE, mbcs |Database/IT Specialist
USAID/Nigeria Monitoring
and Evaluation Management Services (M
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?
Best regards,
JM
2014-03-14 11:44 GMT+01:00 Bayo Mohammed Onimode Jnr :
> Dears,
>
> Fo
7 matches
Mail list logo