Weakness in the assignment of organisational units to users

Support - Assistance technique
1

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?

Regards,
Jason

[1] https://bugs.launchpad.net/dhis2/+bug/891005

2

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

···

On 17 November 2011 08:16, Jason Pickering jason.p.pickering@gmail.com 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?

Regards,

Jason

[1] https://bugs.launchpad.net/dhis2/+bug/891005

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

3

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@ifi.uio.no> wrote:

On 17 November 2011 08:16, Jason Pickering <jason.p.pickering@gmail.com> > 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: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

4

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.

  1. 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.
  2. 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@gmail.com 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@ifi.uio.no wrote:

On 17 November 2011 08:16, Jason Pickering jason.p.pickering@gmail.com > > > 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@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

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

5

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@gmail.com> 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@gmail.com> 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@ifi.uio.no> >> wrote:
>
> On 17 November 2011 08:16, Jason Pickering <jason.p.pickering@gmail.com> >> > 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: DHIS 2 developers in Launchpad
>> Post to : dhis2-devs@lists.launchpad.net
>> Unsubscribe : DHIS 2 developers in Launchpad
>> More help : ListHelp - Launchpad Help
>
>

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

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

6

I total agree Jason. In kenya we have define all the data etry role and data access role.

  1. In data entry role varies from programme area and who does what like district HIV coordinator could be be the one entering HIV related from all site offering the the service and even given right to assign the dataset. But if one is Reproductive health coordinator he/she should for noly what is related to.
  2. Data user person is able to see only aggregate data without any data entry. Even the data entry person can access data from other district for comparison either through mydata mart and even GIS.
    Cheers
···

On Thu, Nov 17, 2011 at 11:50 AM, Jason Pickering jason.p.pickering@gmail.com wrote:

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@gmail.com 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@gmail.com 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@ifi.uio.no > > >> wrote:

On 17 November 2011 08:16, Jason Pickering jason.p.pickering@gmail.com > > >> > 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@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

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

–
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