dhis2-devs team mailing list archive

[Lars Helge Øverland <lars@xxxxxxxxx>]

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 <abyot@xxxxxxxxx>
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 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 a lot more workflow and
> confidentially with programs, their attribute values and events.
>
> --
> Abyot A. Gizaw.
> Senior Engineer, DHIS2
> University of Oslo
> http://www.dhis2.org
>
> On Thu, Apr 14, 2016 at 12:55 AM, Rodolfo Melia <rmelia@xxxxxxxxxxxx>
> wrote:
>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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
>
>


-- 
Lars Helge Øverland
Lead developer, DHIS 2
University of Oslo
Skype: larshelgeoverland
http://www.dhis2.org <https://www.dhis2.org/>