dhis2-devs team mailing list archive

[Ola Hodne Titlestad <olati@xxxxxxxxxx>]

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.

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
>