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 <ol...@ifi.uio.no> wrote: > > On 17 November 2011 08:16, Jason Pickering <jason.p.picker...@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
