dhis2-devs team mailing list archive

[Jim Grace <jim@xxxxxxxxx>]

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 needs
protection* (like DATIM, which uses tracker for site surveys), this is just
confusing. User interface design is all about predictability, and words
like "all" and "superuser" have unquestioned meanings in many of our heads.
I know this wasted a bit of Tim's time, and it would have done the same for
me. It would never occur to me that we would intentionally design software
to use words like these and not have them mean the obvious things. For
users who are just getting to know the product, either they don't know
about these exceptions in which case they misunderstand the software and
could be in for a surprise of unpredictable behavior, or they know about
them in which case they will have the feeling that this is
strangely-designed software that doesn't always live up to expectations.
The more unpredictable or inconsistent our software is, the lower will be
our users' opinion of it.

*For installations that use tracker for personal data that needs protection*,
they need to be serious about protecting the data. If they hand out too
many superuser roles with the "ALL" authority, they will have a problem in
any event, as Tim points out, since these users could assign themselves the
tracker authority. A much better solution, and one we should recommend, is
to not assign either the "ALL" authority or the tracker authorities except
to users who really need them. It's better to have a well-planned security
system than to have the illusion that they are protected when they are not
really. This feature could actually reduce security by giving the illusion
that it is there.

In short, I think the benefits of having Superuser and ALL not include the
tracker are at best questionable and at worst misleading into a false sense
of security, while the costs are real and negative.

My humble opinion.

Cheers,
Jim


On Fri, Apr 8, 2016 at 11:44 AM, Timothy Harding <tharding@xxxxxxxxxxxxxx>
wrote:

> 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 be this way, my
> follow up questions are still out there: *Will datasets eventually act
> this way as well*? If not, why the discrepancy?
>
>
>
> *I admit though I am a bit bias having spent more time that I care to
> admit to yesterday trying to figure out why my program would not appear in
> a vanilla instance.*
>
>
>
>
> *Timothy Harding*
> Sr. Systems Analyst, BAO Systems
> +1 202-536-1541 | tharding@xxxxxxxxxxxxxx | http://www.baosystems.com | Skype:
> hardingt@xxxxxxxxx | 2900 K Street, Suite 404, Washington D.C. 20007
>
> On Fri, Apr 8, 2016 at 7:53 AM, Abyot Asalefew Gizaw <abyot@xxxxxxxxx>
> wrote:
>
>> 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?
>>
>> By forcing users to explicitly go and assign a program, they know the
>> consequence of doing that...
>>
>> We am open for suggestions and discussions.
>>
>> --
>> Abyot A. Gizaw.
>> Senior Engineer, DHIS2
>> University of Oslo
>> http://www.dhis2.org
>>
>> On Fri, Apr 8, 2016 at 4:34 PM, Jim Grace <jim@xxxxxxxxx> wrote:
>>
>>> 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, 2016 at 11:19 PM, Morten Olav Hansen <morten@xxxxxxxxx>
>>> wrote:
>>>
>>>> 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 <
>>>> tharding@xxxxxxxxxxxxxx> 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 to also add that program to their superuser role. Is this intended? *Will
>>>>> datasets eventually act this way as well*? If not, why the
>>>>> discrepancy?
>>>>>
>>>>> Steps to reproduce
>>>>> 1. Create blank database in 2.21 or 2.22 (or use the SL demo)
>>>>> 2. Add root ou/set level
>>>>> 3. Add single tracker data element and single aggregate data element
>>>>> 4. Create a program (SENR) and a dataset to use the above respectively
>>>>>     - In the program's single stage, specify the tracker element above
>>>>> 5. Assign both the program and the dataset to the root ou
>>>>> 6. Notice that the dataset will show up in the "Data Entry App" and
>>>>> the program will NOT show up in the event viewer.
>>>>>
>>>>>
>>>>> *Timothy Harding*
>>>>> Sr. Systems Analyst, BAO Systems
>>>>> +1 202-536-1541 | tharding@xxxxxxxxxxxxxx | http://www.baosystems.com
>>>>> | Skype: hardingt@xxxxxxxxx | 2900 K Street, Suite 404, Washington
>>>>> D.C. 20007
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> Jim Grace
>>> Core developer, DHIS 2
>>> HISP US Inc.
>>> http://www.dhis2.org <https://www.dhis2.org/>
>>>
>>
>>
>


-- 
Jim Grace
Core developer, DHIS 2
HISP US Inc.
http://www.dhis2.org <https://www.dhis2.org/>