dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

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
>