dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Hi Morten

2011/9/29 Morten Olav Hansen <mortenoh@xxxxxxxxx>:
> 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

>
> --
> Morten
>
>
>
> 2011/9/29 Morten Olav Hansen <mortenoh@xxxxxxxxx>:
>>> 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 ;)
>>
>> --
>> 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
>>>
>>
>