attributes

Hi Morten

Hi Bob,

I have just talked to Lars about this issue, and there are several
concerns, with dropping the AttributeOption, and with keeping it.

Why drop?
- Reuse group / groupset code already there
- Aggregation

Why keep?
- Reuse of attributes (options can be used for DE/I/OU/U, etc)
- Some types which supports options (such as User) do not have groupset
- Some UI issues (although this could probably be resolved)
- The solution is already there and working
- We might need to extend groupsets with extra attributes (mandatory, etc)
- Keep global sorting of attributes

So what we decided was this:
We keep the attribute solution as it is today, but we expose
group/groupset functionality in add/edit data element / indicator. I
will code this sometime next week.

Would that work for you?

I've thought about what you say above, but I really feel quite
strongly that it is a bad, bad route to follow, What it implies is a
completely new set of (unnecessary) codelists which will need to be
exchanged in order to synch orgunits which, as you know, is a major
use case here in Rwanda. Randy is already baulking a bit as the
realisation has dawned that synching orgunits is not just a matter of
synching flat tables, but there are a range of additional codelists
(what he calls lookup tables) which need to be considered.

If as you say, you can implement adding orgunits to a groupset from
the orgunit edit screen in addition to the bulk assignement of
orgunits to groupsets, then there really seems to be no reason at all
to proceed with having the additional means to assign coded attribute
options which have exactly the same functionality as assigning coded
groups to groupsets.

When you say the solution is already there and working then I think
you have to apply the same logic to groupsets - they are already there
and wiorking and there is a great deal of supporting code around them,
including in the GIS and resource tables for pivoting.

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.

Whereas I think canning the coded attributes for now is the only
sensible thing to do, I don't think the thought and code you have put
into it need necessarily be wasted. The nomenclature of groups and
groupsets has always seemed a bit weak to me, and if these were called
attributes and attribute options, then in many ways they might make
more sense. But, names aside, there is clearly a need down the line,
to generalize this groupset idea, and I think what you have figured
out in terms of generalized attribute options could and should be
applied here.

But for the moment lets not duplicate functionality, tables, services,
xml formats etc.

Bob

···

2011/9/29 Morten Olav Hansen <mortenoh@gmail.com>:

--
Morten

2011/9/29 Morten Olav Hansen <mortenoh@gmail.com>:

How close are we on the attributes implementation?

It should be done, what is missing is the dictionary reporting
functionality, but that is being worked on.

And have youresolved how you might implement coded attributes in terms of
groupsets? I didn't hear anything back from you on that. Reason I'm
asking is that I have to implement the xml serialization of same
pretty soon in order to implement synching of different databases.

I'm sorry, but I must have totally missed that.. what should I do
here? are you talking about grouping of attribute options? last time I
talked to Lars about this, he did not want any grouping of these
(unless I'm misunderstanding something here)

Rwanda is pretty chaotic .. I've spent very little time on the
integration and mostly on trying to sort out their network. Trying to
implement stable static IP addresses for servers is pretty tricky when
I discovered at least 5 dhcp servers on the network yesterday, all
happily distributing IP addresses from the same pool!

Yes, I also ended up doing lots of stuff not really on the agenda..
its just the way it works :wink:

--
Morten

Anyway had a good session with Randy yesterday and have a good grasp
of what we need to do to synch the orgunits. Synching data is next
challenge ...

Regards
Bob

I think I agree with most of what you are saying Bob, but it will take
some time for me to grok it. :wink:

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

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

I think I agree with most of what you are saying Bob, but it will take
some time for me to grok it. :wink:

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

···

On 30 September 2011 05:00, Jason Pickering <jason.p.pickering@gmail.com> wrote:

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

Bob,

Ok, we give up :wink: 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@gmail.com> wrote:

On 30 September 2011 05:00, Jason Pickering <jason.p.pickering@gmail.com> wrote:

I think I agree with most of what you are saying Bob, but it will take
some time for me to grok it. :wink:

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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp