dhis2-devs team mailing list archive

[Brajesh Murari <brajesh2murari@xxxxxxxxx>]

On Fri, Aug 12, 2011 at 6:48 PM, Ola Hodne Titlestad <olati@xxxxxxxxxx>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 <jason.p.pickering@xxxxxxxxx>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     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Regards,
Brajesh