dhis2-users team mailing list archive

[GROUT, Lise <groutl@xxxxxxx>]

Dear all, 
 
I am sorry I missed all this exchange about the sharing settings problem. Thank you for your interest in this!
 
You are right, I will already try to review the list of users having the “add/update public objects”.
 
Actually, I see the solution proposed by Lars as a minimum : to be able, at the moment of creating the object, to decide on the public vs private status of the object. Ideally, this should be also available through csv import of metadata then. 
 
It would also be great if this could be one of the column of research, so that you can easily identify which are public and which are not. 
 
But the option proposed by Jason would even be better in my understanding. Maybe I miss something. Here is my use case. We are 2 superusers of the NTD instance. We have metadata for 6 diseases currently in the system. User working on 1 disease may not be working on the other ones. And I don’t want the users to see neither all the category combinations in pivot tables, nor all the favorites in pivot table, gis or visualizer.  For the moment, the superusers are the one creating 90% of the metadata and favorites, and making them available to the different diseases. I would see it more convenient to create by default private objects and then to decide with which user group I want to share it. Moreover, new department (non-NTD) are joining our instance. They will have their own superuser for their part of the system. I understand I should then not give them the “add/update public objects” authority if I don’t want my NTD users to see their objects?
 
Best
Lise.
 
From: Dhis2-users [mailto:dhis2-users-bounces+groutl=who.int@xxxxxxxxxxxxxxxxxxx] On Behalf Of Victor Garcia
Sent: 07 September 2017 18:18
To: Pamod Amarakoon
Cc: dhis1-users; Wilfred Senyoni; RAMON JOSE JIMENEZ POMARETA
Subject: Re: [Dhis2-users] Sharing settings
 
Hi,
 

I also share the issue raised by Lisa. For us the problem appears when superusers are also regular users in the system: they can do typical superuser tasks like creation of public data elements and data sets, and in other moment they can do some analysis just like other standard user and they assume their tables are private. And then they have to remember to remove the public sharing.

 

Regards,

 

Víctor

 
On 7 September 2017 at 18:14, Pamod Amarakoon <pamodm@xxxxxxxxx> wrote:
I also vote for enabling sharing UI per object base. Just wonder whether there should be a provision to update the sharing status at a later stage and not only to restrict this at point of creating the object.

 
On Thu, Sep 7, 2017 at 9:32 PM, Jason Pickering <jason.p.pickering@xxxxxxxxx> wrote:
I was seeing this more as a per-user-choice actually, to account for the experience of the user. 
 

Suppose I  do not want to share anything (and supposedly know what I am doing), I could enable in my profile "Do not share publicly by default". 

 

Maybe that is the same thing however Lars?

 

Regards,

Jason

 

 

 

 
On Thu, Sep 7, 2017 at 5:30 PM, Prosper BT <ptb3000@xxxxxxxxx> wrote:
I vote for also adding sharing in the "Add New" at min Public Vs Private



Prosper Behumbiize, MPH
DHIS2 Implementation| HISP Uganda

prosper@xxxxxxxxxxxxxx | prosper@xxxxxxxxx | Skype: prospertb

 
On Thu, Sep 7, 2017 at 6:21 PM, Lars Helge Øverland <lars@xxxxxxxxx> wrote:
Right. I think this has two sides to it - for basic metadata like data elements it makes sense to at least allow it to become public when creating an object. Otherwise, inexperienced users might have a hard time understanding that you need to share it before anyone else can see it. A solution to this would be to have a basic sharing UI inside the "add new" object screens, so that for users with "create public" authorities, you can choose whether to make it public or private before creating an object.
 

 

 
On Thu, Sep 7, 2017 at 3:31 PM, Jason Pickering <jason.p.pickering@xxxxxxxxx> wrote:
Hi Lars,
I think this is the problem however. In certain instances, it would be better if this permission was granted explicitly. Right now, if you are a super user, anytime you create a favorite, it is shared publically. 

 

I think what Lisa is asking for is something we have seen a need for as well, and that is basically that analytical objects and metadata should NOT be public by default, but rather granted on a case by case basis as desired by the user. 

 

Regards,

Jason

 

 
On Thu, Sep 7, 2017 at 3:25 PM, Lars Helge Øverland <lars@xxxxxxxxx> wrote:
Hi Lise,
 

you can achieve this by simply not granting "Add/Update Public Chart" (and report table, map) to users through user roles. Creating private charts/maps is implicitly allowed for anyone.

 

regards,

 

Lars

 
On Thu, Sep 7, 2017 at 2:45 PM, GROUT, Lise <groutl@xxxxxxx> wrote:

Dear all, 
 
Is there a way of configuring the instance so that by default all favorites are not public (public acces=none), i.e. by default only the creator of the favorites can see it and then he can chose to share it with user groups?
 
Thanks 
Lise.
 
Dr. Lise Grout
Epidemiologist
 
World Health Organization
Department of Neglected Tropical Diseases (HTM/NTD/IDM)
Innovative and Intensified Disease Management Unit
20, Avenue Appia; CH-1211 Geneva 27
Tel. +41 22 791 2341
Mobile +41 79 290 68 61
Skype: tigrouveto
http://www.who.int/neglected_diseases
 

 

_______________________________________________
Mailing list: https://launchpad.net/~dhis2-users
Post to     : dhis2-users@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~dhis2-users
More help   : https://help.launchpad.net/ListHelp




 

-- 
Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

lars@xxxxxxxxx

http://www.dhis2.org

 


_______________________________________________
Mailing list: https://launchpad.net/~dhis2-users
Post to     : dhis2-users@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~dhis2-users
More help   : https://help.launchpad.net/ListHelp




 

-- 

Jason P. Pickering
email: jason.p.pickering@xxxxxxxxx
tel:+46764147049




 

-- 
Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

lars@xxxxxxxxx

http://www.dhis2.org

 


_______________________________________________
Mailing list: https://launchpad.net/~dhis2-users
Post to     : dhis2-users@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~dhis2-users
More help   : https://help.launchpad.net/ListHelp

 




 

-- 
Jason P. Pickering
email: jason.p.pickering@xxxxxxxxx
tel:+46764147049


_______________________________________________
Mailing list: https://launchpad.net/~dhis2-users
Post to     : dhis2-users@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~dhis2-users
More help   : https://help.launchpad.net/ListHelp




-- 

Regards,
Dr. Pamod Amarakoon

MBBS (SL)

MSc (Biomedical Informatics), EMSc (Health Admin), CEH

Medical Officer in Health Informatics

Nutrition Coordination Division

Ministry of Health, Nutrition and Indigenous Medicine,

Sri Lanka


Confidentiality Notice: the information contained in this email and any attachments may be legally privileged and confidential. If you are not an intended recipient, you are hereby notified that any dissemination, distribution, or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender and permanently delete the e-mail and any attachments immediately. You should not retain, copy or use this e-mail or any attachments for any purpose, nor disclose all or any part of the contents to any other person.
 
 


_______________________________________________
Mailing list: https://launchpad.net/~dhis2-users
Post to     : dhis2-users@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~dhis2-users
More help   : https://help.launchpad.net/ListHelp