dhis2-devs team mailing list archive

[Brajesh Murari <brajesh2murari@xxxxxxxxx>]

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
<brajesh2murari@xxxxxxxxx>wrote:

>
> 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
>
>
>


-- 
Regards,
Brajesh