dhis2-devs team mailing list archive

[Rodolfo Melia <rmelia@xxxxxxxxxxxx>]

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 April 2016 at 21:32, Jim Grace <jim@xxxxxxxxx> wrote:

> 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/>
>
> _______________________________________________
> 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
>
>