dhis2-users team mailing list archive

[Rodolfo Melia <rmelia@xxxxxxxxxxxx>]

An alternative approach will be to use start/end dates for the Options,
similar to the way that Category Options and Org Units do. That way the
Option wouldn't show for data entry, but is preserved for the historical
data.

Rodolfo

On Monday, 30 May 2016, David Siang Fong Oh <doh@xxxxxxxxxxxxxxxx> wrote:

> Slight correction - the deleted option is removed completely from the
> database when removing it using the web application. It still remains in
> our database because we used the web API to remove it from the option set.
>
> So I guess our question is - can we soft-delete the options and then
> modify the reports application to still display the correct name?
>
> Cheers,
>
> -doh
>
> On Mon, May 30, 2016 at 9:55 AM, David Siang Fong Oh <doh@xxxxxxxxxxxxxxxx
> <javascript:_e(%7B%7D,'cvml','doh@xxxxxxxxxxxxxxxx');>> wrote:
>
>> Hi Lars,
>>
>> It makes sense that deleting all data/events linked to that option is too
>> drastic, however would it still be possible to show the option name in
>> event reports? It appears that the deleted option still remains in the
>> database with the correct *uid* so we are still able to retrieve the
>> option name.
>>
>> The use case we have is that options within an option set may evolve over
>> time. Existing options will be retired and new options will be added. We
>> don't want the retired options to show up in the drop-down during data
>> entry, however we still want the existing options to be displayed correctly
>> in reports.
>>
>> Cheers,
>>
>> David
>>
>> On Mon, May 16, 2016 at 3:53 PM, Lars Helge Øverland <lars@xxxxxxxxx
>> <javascript:_e(%7B%7D,'cvml','lars@xxxxxxxxx');>> wrote:
>>
>>> Hi Jhansi,
>>>
>>> this should be considered expected behavior. The link between options
>>> (in option sets) and data / events in "soft" in the sense that it is based
>>> on text (not relational constraints in the database). This means that there
>>> is nothing stopping you from editing existing option codes if you do it
>>> directly in the database. Deleting all data / events which are linked to an
>>> option when the option is deleted is too drastic in my mind - better to
>>> leave this up to the implementor.
>>>
>>> best regards,
>>>
>>> Lars
>>>
>>>
>>>
>>>
>>> On Mon, May 16, 2016 at 11:24 AM, jhansi <jhansirk@xxxxxxxxxxxxxxxx
>>> <javascript:_e(%7B%7D,'cvml','jhansirk@xxxxxxxxxxxxxxxx');>> wrote:
>>>
>>>> Hello,
>>>>
>>>> We have configured event reports to display the number of occurrences
>>>> of a particular option for a given period and orgunit in the event data. In
>>>> a couple of these reports, we are noticing option code instead of option
>>>> name.
>>>>
>>>> We further investigated into this and found that this issue is
>>>> happening because of deleting an existing option which has already been
>>>> used in the event data entry. All the events which had previously used this
>>>> option now display the option code.
>>>>
>>>> When an option is deleted (which has been used in the event data
>>>> entry), DHIS is not completely removing its trace from the events data and
>>>> reports. Has someone faced this issue before or has any suggestions/fix for
>>>> this?
>>>>
>>>> Thanks,
>>>> Hari/Jhansi
>>>>
>>>
>>>
>>>
>>> --
>>> Lars Helge Øverland
>>> Lead developer, DHIS 2
>>> University of Oslo
>>> Skype: larshelgeoverland
>>> lars@xxxxxxxxx <javascript:_e(%7B%7D,'cvml','lars@xxxxxxxxx');>
>>> http://www.dhis2.org <https://www.dhis2.org/>
>>>
>>>
>>
>

-- 
*Rodolfo Meliá*
*Principal  |  *rmelia@xxxxxxxxxxxx
Skype: rod.melia  |  +44 777 576 4090  |  +1 708 872 7636
www.knowming.com