Hi,
I have made the change ... authority "ALL" grants access to programs.
--
Abyot A. Gizaw.
Senior Engineer, DHIS2
University of Oslo
http://www.dhis2.org
On Fri, Apr 15, 2016 at 3:47 PM, Jim Grace wrote:
> Looping Tim back in, who started this thread but seems to have been
> dropped from it.
Looping Tim back in, who started this thread but seems to have been dropped
from it.
On Fri, Apr 15, 2016 at 9:38 AM, Bob Jolliffe wrote:
> Its an interesting problem. In general Role Based Access Control (RBAC)
> is known to be an insufficient security mechanism/framework for handling
> issues
Its an interesting problem. In general Role Based Access Control (RBAC) is
known to be an insufficient security mechanism/framework for handling
issues of patient confidentiality without some additional parameterization
to model things like legitimate relationships, patient consent management
etc.
I support making ALL provide full rights. We need to highlight this in the
docs.
Lars
On Thu, Apr 14, 2016 at 10:52 AM, Abyot Asalefew Gizaw
wrote:
> Thank you all !
>
> Seems I should give up and put back "All" authority on programs.
>
> It would have been nice if we get the view of those wor
Thank you all !
Seems I should give up and put back "All" authority on programs.
It would have been nice if we get the view of those working in "patient" or
clinical settings.
One thing we need to keep in mind is the way we deal with programs is
totally different from that of data sets. There is
Hi - I learned to live with this odd situation since at least 2.20, which I
have in multiple boxes. It doesn't make sense that you have access to all
data sets, but not to the programs. I really would like to see the 'All'
authority having access to all programs, for consistency sake.
*R*
On 13
Thank you all. I'm with Tim. I don't know if this is still up for
reconsideration or reversal, but it seems to me a bad idea to ship with a
"Superuser" role, and an "ALL" authority, neither of which gives access to
all authorities.
*For installations that do not use tracker for personal data that
Thanks Morten, Jim, Abyot,
Abyot:
Is the point of restricting a super user moot though since the super user
has the *ability* to assign themselves to whatever they like? It feels like
an extra step that shouldn't be needed for a superuser.
But, if there is indeed a need for the functionality to b
Hi,
It was like that before I think I changed it because at some point
there was a discussion saying we have to be careful on granting blanket
access in tracker.
One could be a superuser, but does this really mean this user will have
access to clinical data, names and everything implicitly?
Perhaps it was just an oversight in the code, forgetting to check for the
"ALL" authority in addition to the particular authority?
I would certainly expect "ALL" to grant the same access as all authorities.
It would surprise me if there is any good rationale to make it otherwise.
On Thu, Apr 7,
Yes, that is correct. I'm not sure when it was decided so, but you need to
give the userrole access to that program.
Maybe Abyot remember exactly why?
--
Morten Olav Hansen
Senior Engineer, DHIS 2
University of Oslo
http://www.dhis2.org
On Fri, Apr 8, 2016 at 9:51 AM, Timothy Harding
wrote:
>
Hey devs,
Just wanting to make sure of this: It looks like in version 2.21 and
beyond, the "ALL" authority no longer gives the super user access to
*everything* (about the same time programs were given their own entry in
the roles). This means when that user makes a new (public) program, they
need
12 matches
Mail list logo
