On Fri, Aug 12, 2011 at 6:48 PM, Ola Hodne Titlestad <[email protected]>wrote:
> Hi, > > Had a chat with Lars about this issue and we agreed that an OK solution > that will meet most requirements here and also not require much development > time will be to accept that orgunit groups can be used for both in group > sets (exclusive only) AND for a more free tagging/categorisation purpose > without group sets. > Thats great and wounderful news...it seems, you are agreed that we should treet this issue as new enhancement for upcomming DHIS2 sprint relise rather than treating it as a architectual design bug anyway. This is a very good example for the modification/upgradation of a very spacial and rare use case design issue in DHIS2 which changes with respect to time with more fine grained refinment according to its new upgraded/modified usecase. > > However, every group set must be exclusive, this way we know that we can > aggregate data by each group in a group set which will be important when > introduce group sets in report tables later this year, and this is also > important for the group set resource table for pivots. This is the > intended behavior today, but we need more strict control of group set > exclusivity every time a group membership is added/edited. > > For the "free" non-groupset groups it will be good if we can improve how we > present orgunits in reports and on maps and make use of these group > memberships (attributes) when listing information about an orgunit. E.g. > when clicking on a point in the GIS all group memberships should be listed, > and also improve orgunits distribution reports (reports module) > to include filtered lists based on one or multiple groups, e.g. list all > orgunits under a selected parent that is member of the group "CS", or member > of "PEPFAR" + "ART services" + "rural". The result could then be a simple > list of the orgunits meeting the criteria or aggregated numbers for each > region etc. > > I think this solution will provide the flexibility needed to cover all the > mentioned use cases. The only drawback I can see for the "services provided" > use case is that it will be impossible for DHIS to know which groups that > actually represent a service, but that can be dealt with using naming > conventions and custom report queries and views I think. > > What do you guys think? > > Ola > ------- > > > > ---------------------------------- > Ola Hodne Titlestad (Mr) > HISP > Department of Informatics > University of Oslo > > Mobile: +47 48069736 > Home address: Vetlandsvn. 95B, 0685 Oslo, Norway. Googlemaps > link<http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=Vetlandsvn.+95B,+0685+Oslo,+Norway> > > > > On 12 August 2011 14:02, Jason Pickering <[email protected]>wrote: > >> Hi Bob, >> I agree with your next point, to some extent. >> >> > But we also want to be able to categorize orgunits in non-binary terms >> > - the ownership example being a good one. We have successfully >> > mobilized the groupset idea to implement this - perhaps this could in >> > fact be implemented independently of the group idea ie. having a 1st >> > class coded dimension along the lines of a category. >> >> However, thus my suggestion that the _orgunitgroupsetstructure should >> ONLY contain exclusive group sets as columns. This is the only way it >> makes any sense. >> >> > >> > I wonder if Chet's problem is actually solved by NOT putting these >> > groups into a services groupset. >> >> How would this be done? An orgunit group for each possible combination >> of services, thereby ensuring exclusivity? >> Sounds very painful and repitious when this should be able to be >> accomplished through assignment to multiple orgunit groups. >> >> >This is probably >> > relatively simple sql - but would result in a very wide resource >> > table, >> >> In fact, it would be require procedural code to produce the crosstab >> (at least with Postgres) as is done with the resource tables. We have >> no idea how many columns there would be prima facie. I am not sure >> what "wide" actually means, and not sure it would be any "wider" than >> creating a PMTCT orgunit group and a PMTCT orgunit group set and a ART >> orgunit group and an ART orgunit groupset etc etc. Just seems >> pointless when we know that in the case of services, implementing >> partners, projects, programmes, etc we know there may be multiple >> attributes associated with a particular orgunit. >> >> The alternative workaround, for which gui already exists so >> > its a current workaround, is possibly my earlier suggestion of placing >> > such groups on their own into their own groupset for the purpose of >> > making an appearance in the resource table.. >> >> Yes, but this seems to be exactly the same as the proposed >> _orgunitgroupstructure table which would require a separate exclusive >> groupset for each possible group that the orgunit could belong to. >> >> In a way, it sounds like we are debating the old issue with DHIS 1.4, >> and exclusive and non-exclusive groupsets. I obviously do not know the >> full history of why it was removed in both 1.4 and 2, but I am still >> not convinced it was the right move. >> >> Regards, >> Jason >> > > > _______________________________________________ > Mailing list: https://launchpad.net/~dhis2-devs > Post to : [email protected] > Unsubscribe : https://launchpad.net/~dhis2-devs > More help : https://help.launchpad.net/ListHelp > > -- Regards, Brajesh
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
