dhis2-devs team mailing list archive

[Morten Olav Hansen <mortenoh@xxxxxxxxx>]

Bob,

Ok, we give up ;) We buy your arguments. I will extend all the
groupsets with a mandatory field (since this would be needed), and
expose groupset functionality in DE/I.

I still think the solution will suffer a bit from it, since we loose
all reuse of options across the different types in our system, and in
reality we loose multiple choices for attributes (since the idea from
the start was that they could be shared among all types).

Anyways, just need you to OK it with Randy (since it was for the
requirements in Rwanda I added multiple choice), and then I will
implement these changes next week.

--
Morten



On Fri, Sep 30, 2011 at 6:59 AM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
> On 30 September 2011 05:00, Jason Pickering <jason.p.pickering@xxxxxxxxx> wrote:
>> I think I agree with most of what you are saying Bob, but it will take
>> some time for me to grok it. ;)
>>
>>> The issue of attributes for users is I think not compelling.  There
>>> isn't really an immediate strong demand, other than a half hearted
>>> wish from Jason.  Of course I think we all agree having attributes for
>>> users is a good idea, but I also think, if I am reading Jason's
>>> request properly, the immediate requirement is simply for attributes,
>>> not coded attributes.
>>
>> It is not really half hearted but a real request based on a
>> demonstrated use case in Zambia,
>
> Sorry poor choice of words late at night.
>
>> which we cannot accomplish currently
>> with DHIS2. You are right, we have no immediate need for user group
>> sets.
>>Of course once we realize there is not a whole lot of difference
>> between our dimensions orgunit(where),
>> period(when),dataelement/catocombooption(what),user(who), the simpler
>> one would think it would be to create a common code base which is
>> common across all the dimensions would be. Seems we are headed in that
>> that direction, but I digress.
>
> I completely agree that it would be very useful.  And if we need them
> in the short term then we should implement them as user groupsets .
> that that I am in love with the groupset notion, but it follows the
> flow of the rest of what we have.
>
> What is driving this use case is the synchronising of our database
> with other databases which may maintain different metadata for
> orgunits.  So as the dust settles on this design I need to come up
> with some sensible format for representing these in xml, which
> currently looks like I will have an orgunit element, below which I
> will have (amongst other things) both its groupsets and its
> coded-attributes, both of which refer to coded lists.  There is no way
> to sensibly explain to any third party what the difference between
> these two are.  It is unneeded complexity and there would seem to be
> no rational basis to pick between attributes or groupsets.
> Particularly given that interoperability lies at the heart of this,
> creating such dhis-idiosyncracies is not a good idea.
>
> This required functionality for the user through the GUI  is easily
> achieved on top of our existing constructs.
>
> Bob
>
>> The real requirement for us is simply to be able to have dynamic
>> attributes (namely an alternative phone number which is managed
>> through an Excel sheet currently). Not really sure of the full list,
>> but I could get my hands on that sheet to see exactly what it is they
>> want in Zambia, but it is certainly not anything akin to a user group
>> set.
>>
>> 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
>