Occurs in the 2 most recent Play demo instances (2.40.1 and 2.39.2.1)
When updating a category combination, the action fails. The GUI presents an “OK” message but the console shows this error:
{httpStatus: ‘Conflict’, httpStatusCode: 409, status: ‘ERROR’, message: ‘Update cannot be applied as it would make existing data values inaccessible’, errorCode: ‘E1120’}
saveFail
@
EditModelForm.component.js:214
t.__tryOrUnsub
@
Subscriber.js:242
t.error
@
Subscriber.js:201
t._error
@
Subscriber.js:132
t.error
@
Subscriber.js:106
(anonymous)
@
PromiseObservable.js:71
Promise.then (async)
t._subscribe
@
PromiseObservable.js:62
e._trySubscribe
@
Observable.js:172
e.subscribe
@
Observable.js:160
_saveAction
@
EditModelForm.component.js:231
o.handleClick
@
EnhancedButton.js:146
o
@
ReactErrorUtils.js:26
a
@
EventPluginUtils.js:85
u
@
EventPluginUtils.js:108
p
@
EventPluginHub.js:43
m
@
EventPluginHub.js:54
o
@
forEachAccumulated.js:24
processEventQueue
@
EventPluginHub.js:257
o
@
ReactEventEmitterMixin.js:17
handleTopLevel
@
ReactEventEmitterMixin.js:28
i
@
ReactEventListener.js:72
perform
@
Transaction.js:140
batchedUpdates
@
ReactDefaultBatchingStrategy.js:62
i
@
ReactUpdates.js:97
dispatchEvent
@
ReactEventListener.js
The action fails in our own 2.40 and 2.39 instances installed on our own servers where data/metadata stems from older DHIS instances that were upgraded to the more recent DHIS versions.
However, it functioned properly on our own 2.39-Snapshot server when creating category options/categories/category combos from scratch.
The action functions properly in Play 2.38.4.3.
Note the update test I attempted (which triggered the error above) was to make a minor modification to the category combo Name.
UPDATE: I see the Jira entry for a related issue here.
However, the lack of informative message persists, despite the Jira issue being marked as done. Furthermore, the changes I was making to the category Combo did not affect any dependent metadata but just the name of the catCombo. A change like that should be permitted, no?
And even when modifying a catCombo that is not associated with a dataElement, the Save hangs… upon refreshing the screen the saved record is available.
Thanks for your post @LauraLincks and the link to the jira issue. In one of the related issues, @Lars explains:
When adding or removing a category from a category combination, then DHIS 2 will drop and recreate category option combinations (this because the existing category option combinations can no longer be valid). So when trying to delete a category option combination which have data values associated, the delete will fail with a foreign key constraint.
We could tackle this from a deletion handler perspective, and block the update of the category combination if it results in deleting category option combinations which have data values associated.
(@lars)
Additionally, if it’s marked as done and working in previous versions then it might be that the fix wasn’t part of the latest branch so I will make a comment in the jira issue.
So the intent here is to place boundaries on how existing category combinations can be altered. Lets say you have a category combination called “Age” with options “<15,15+”. This category combination is assigned to a data element, and data is entered with these category option combinations “<15” and “15+”. Later you determine you need an additional category called “Sex” consisting of “Male” and “Female”. You then alter the existing category combination to include two categories: “Age” and “Sex”.
The problem here is that the existing data which has been assigned to the <15/15+ category option combinations become disassociated from the now altered category combination. While the <15 and 15+ options will continue to exist, they will be disassociated from the new category combination.
Thus, you should not add or delete categories from category combinations which have data. You should also not delete category options from existing categories which also creates the same problem. Adding additional category options to a category should not be a problem.
We have added several additional integrity checks to recent versions of DHIS2 which should identify these situations if they have occurred in previous versions of DHIS2. However this error message (which should be handled better in the front end) is an attempt to prevent the alteration of existing category combinations which affect the availability of existing data. While this may have worked in previous versions, alterations of existing category combinations with new or deleted categories creates data integrity issues.
Hello @jason and @Gassim ,
I understand the explanation you gave and in my opinion it makes sense that these rules exist.
However, for what I intend to do, updating the category combination to ignore the totals in the creation of analytics, I believe there should not be an error in doing so. I understand that this is done when creating analytical tables and not in the data itself.
Thank you for sharing a workaround. Would you like to share it in the jira ticket [DHIS2-13707] - Jira? It’s still not assigned but I’m following up on this issue. You can ‘watch’ the ticket to receive notifications.
Thanks @asacur! Please know the developers are having a look at the issue. I think you weren’t able to post there because it’s a duplicate of ([DHIS2-13678] - Jira) where I posted your comment. Thanks again!
Hi there. Just an update on this issue. There was a backend bug (now fixed) which prevented users from changing category combinations in valid circumstances. You should always be able to change the name, short name and totals. You should also be able to change the combination of categories IF there is no data. If there is data, you should receive that conflict message from the server, but that is still an outstanding issue on the front-end as far as I know. This has however been fixed on 2.39 and 2.40 (development versions). So, this fix should make its way into the next patch release.
