← Back to team overview

dhis2-devs team mailing list archive

Re: Weakness in the assignment of organisational units to users

 

Hi Samuel,


Currently, the orgunit selection is really geared towards data entry.
What it is not geared towards is reporting. Here in Zambia, we would
like to authorize users to have data entry access to their districts
facilities, but have reporting access to aggregate data from other
districts. So, there needs to be a distinction between what the user
is allowed to enter data for, and what they are allowed to see. Bob
and I have discussed this a bit in the context of MyDatamart as well,
as the current workflow here (or the desired one) would be to provide
facility level data to particular district users, but then also allow
them to have other districts data if needed (but without provding them
facility level data of other districts).

So, maybe this can be accomplished some how, but one must obviously be
very careful how one does it.

Regards,
JPP



On Thu, Nov 17, 2011 at 10:34 AM, Samuel Cheburet
<samuelcheburet@xxxxxxxxx> wrote:
> Thanks great people. assignment  of access right to enter data for any
> orgunit. The concept here will depend on orgnizational structure.
> there is two way to this.
>
> The right can be provided to district person to one or more orgunit like 2
> district if he/she is the only doing data entry for the two.
> The data entry user can a locate selected health facilities cutting across
> the ougunit and this depend on manning agency if they want to enter their
> data. in case of Kenya local authorizes could like to enter data for all
> health facilities under local authories from various district hence the ens
> user have to get access to selected health facilities.
>
> cheers
> On Thu, Nov 17, 2011 at 11:26 AM, Jason Pickering
> <jason.p.pickering@xxxxxxxxx> wrote:
>>
>> Yes, I agree it is not a typical use case, but it is not entirely
>> straightforward. If you have a situation where a user need to enter
>> data for fifty facilities for a district, do you select all fifty
>> facilities, or simply select the single district? The current setup is
>> such that if you select the district, you get automatic access to its
>> children, so there is no need to select all the individual facilities,
>> even though you could. I would even say that the UI encourages you to
>> do this, with the "Select children" function.
>>
>> No doubt it is a mistake in the code. Even if a user has had all 4000+
>> orgunits selected explicitly, as opposed to having only the root
>> orgunit selected, the result should be the same. However, the
>> difference is performance and appearance to the user in terms of what
>> the orgunit tree looks like, is pretty startling.
>>
>> Basically, think there needs to be some function so that if a parent
>> is chosen, then the children are NOT added to the usermembership
>> table, or the code needs to be tweaked to deal with this situation.
>>
>> Yes, Stephen's database seems to be working much much better after
>> this tweak, but it is something we need to look into.
>>
>> Regards,
>> Jason
>>
>>
>> On Thu, Nov 17, 2011 at 10:10 AM, Ola Hodne Titlestad <olati@xxxxxxxxxx>
>> wrote:
>> >
>> > On 17 November 2011 08:16, Jason Pickering <jason.p.pickering@xxxxxxxxx>
>> > wrote:
>> >>
>> >> Hi Devs,
>> >> I have been working with Stephen on his database, and have detected a
>> >> weakness in the code in 2.5 and trunk. I suspect this has to do with
>> >> the changes which we introduced related to the handling of multiple
>> >> orgunit roots, but am not 100% sure. Let me describe the problem.
>> >> Stephen has about 4000 orgunits, not a huge number say compared to
>> >> Nigeria for instance. We noticed the problem already at login, where
>> >> it took a very long time for the user to be authenticated. The CPU
>> >> usage of Tomcat shot up through the roof, and stayed there for almost
>> >> 2 minutes. The issue seems to be that ALL orgunits had been assigned
>> >> to the admin user, instead of just the highest level root orgunit. The
>> >> other strange thing was, that the orgunit tree was "flat" after
>> >> assigning all orgunits to the admin user. There was no hierarchy, and
>> >> all operations which involved ouwt were extremely slow. We deleted all
>> >> associations of the admin user in the usermembership table, and then
>> >> reassigned ONLY the root orgunit. Login took about 2 seconds, and
>> >> everything performed as expected.
>> >>
>> >> So, there seems to be a weakness somewhere in the code which we need
>> >> to take a look at, and I suspect it is related to the bug I filed the
>> >> other day [1] and the revisions which we did not test very well before
>> >> the release of 2.5 related to the handling of multiple roots. As a
>> >> variant of the procedure described in that bug report, just assign all
>> >> orgunits to a user and then login with that user. The login takes much
>> >> much longer.
>> >>
>> >> Thoughts?
>> >>
>> >
>> > Hi Jason,
>> > Have no idea of the code implications here, but why would anyone assign
>> > all
>> > orgunits to a user?
>> > I can think of use cases where you cover 2-3 districts, or a selection
>> > of
>> > health facilities at the lowest level, but can't really think of any use
>> > case where more than max 50 orgunits would be assigned to one user.
>> > I understand this was a mistake by Stephen and that he has no problems
>> > now
>> > that he has set it up correctly?
>> > I think the GUI is a bit confusing now as you have all these options to
>> > select multiple orguitunits at the same time.
>> > The users can easily think that they need to select all orgunits they
>> > want
>> > to see/use, and not just the root of the tree or a few roots of
>> > subtrees.
>> > Given that e.g. the dataset assignment screen (where you have to select
>> > every single orgunit) looks exactly the same as this one , I can
>> > understand
>> > if users get confused.
>> > That said, there is obviously something in the code that can be looked
>> > at as
>> > well, to better support multiple orguints per user, but the use case for
>> > 4000+ orgunits selected for a user like in this case, doesn't seem
>> > realistic. Then I would rather restrict that from happening in the user
>> > interface at the point of selecting orgunits for users.
>> > Ola
>> > --------
>> >>
>> >> Regards,
>> >> Jason
>> >>
>> >>
>> >>
>> >>
>> >> [1] https://bugs.launchpad.net/dhis2/+bug/891005
>> >>
>> >> _______________________________________________
>> >> 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
>
>
>
> --
> Samuel Cheburet
> Ministry Of Health
> P.O. Box 20781
> Nairobi, Kenya
> Mobile- 0721624338
>
> "When you cease to dream you cease to live, Neither you nor the world knows
> what you can do until you have tried".
>
> "Chance favours the prepared mind" -Louis Pasteur
>
>


Follow ups

References