Pardon.! there are some typographical mistakes in these following words in my recent reply on this mailing thread,, *Thats, wounderful, treet, upcomming, relise, architectual, upgradation, refinment, usecase,*
these should be like this, *That's, wonderful, treat, upcoming, relies, architectural, up gradation, refinement, use case.* :)* * 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. Thats wounderful treet upcomming relise architectual upgradation refinment usecase. On Wed, Aug 17, 2011 at 11:49 AM, Brajesh Murari <[email protected]>wrote: > > 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 > > > -- 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
