dhis2-devs team mailing list archive

[Ola Hodne Titlestad <olatitle@xxxxxxxxx>]

2009/12/4 Abyot Gizaw <abyota@xxxxxxxxx>

> Have been discussing this with Lars, and "not allowing to edit" is what we
> could come up at least for the time being.
>
> We can think of allowing users to edit the members in the
> categorycombination - like adding/removing options or categories. But the
> question is what will be the consequence of doing this when data is already
> registered?
>
> We can keep existing optioncombos, deal with all the internal complexities
> of extending/shrinking optioncombos by adding/removing options. Still the
> real challenge is what will happen to values previously registered? For
> example - assume the following
>
> Malaria ( <5 ) = 50
> Malaria ( >5 ) = 40
>
> We have only one category Age with options <5 and >5. Next time you want to
> further break and come up with <5, 6-15, >15 or something like that - then
> what are we going to do with the values 50 and 40? Remove the values and
> record (rather collect) them again? Do we need to keep 50 and 40 for some
> reason (history?). If so how are we going to display them? because if we
> want to keep the old values and at the same time reflect the new changes -
> then we need to have a new set of optioncombos lined to the dataelement (in
> our case Malaria) so there is no way to refer to the old data because the
> dataelement is linked to the new optioncombo/categorycombo.
>
> The way I see it by allowing adding/removing categories/options from
> categorycomobs/categories we will be inviting lots of complexities - so I
> think the best way is not to allow addition or removal.
>
>
> Thank you
> Abyot.
>
>
>
Hi,

I agree that it becomes very messy if the user can modify the categorycombo
and thereby modifying the categoryoptioncombos directly linked to new values
coming in.

Changes will happen over time, and often an annual revision of forms process
is normal and there the dimensions to the data is likely to change.
CategoryCombos is a way of navigating to the dimensional data we have in the
system and changing these when there are data in the system will as you say
make it difficult to both pull out data that has been stored with old
version of a catcombo and do comparisons over time for data captured with
new and old versions of a catcombo.

I suggest we make it possible to keep old versions of catcombos in the
system as inactive in order to be able to look up historical data using
catcombos, even though they are no longer actively used in data entry. The
query to compare old and new will be complex, but still easier than not
having a catcombo for your historical data at all. So I agree that we should
lock catcombos for editing and deletion as soon as any of their
catoptioncombos are used in a datavalue. As soon as there are no values
attached to a catcombo it should be open for both edit and deletion.

There are however some use cases where it is very cumbersome not to be able
to edit or delete catcombos and their categories and options. So when there
are no values we should not lock this down I think. This will make the
startup process easier, when you do a lot of trial and error on the metadata
side before starting to collect data, and it will enable pruning of old
stuff that you no longer need if you're cleaning up an existing system.

Ola
-----------