@judy, I interstage from your post at CIEL: Duplicate names in 1.11.x for Eparinn & Gratel in 'ht' locale that there are some specific examples where the concept looks good to you in CIEL but James reported it as an error.
Can you highlight just one example of a concept, and highlight the specific name in 1.6 that you think is fine, but is failing?
Here are new errors latest drop. There are 2 of them.
As for validation, it seems that exporting the concept packages from metadatasharing module, validates the concepts, so if @judy, @akanter have access to the reference application, this method can be used to validate the concept dictionary. Just a suggestion.
We can’t use the ref app as the validation since we have multiple distributions
We can however get the rules to add to our own existing rules – should be simple statements maybe @rafal can help
@darius I think our changes mainly in the Spanish locale were causing problems are are fixed given this new round of tests
I will fix the other two and wait for @akanter decision on release
Judy is this now done? Can we put out an official build today/tonight?
James I had to remove 512
It caused new name problems with a new conflict between 512 and 119022
See
Concept [id:512 uuid:512AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA] failed validation ‘Maladi po’ is a duplicate name in locale ‘ht’
Both are fixed
Thanks @judy, the existing concept 119022 is a better match for “Maladi po”, so good job!. Creole just doesn’t have enough words to be precise.
New version added to dropbox
There was one error with new CIEL version. The error does indicate the error in validation. @judy, I have included some high level descriptions of the validation rules in openmrs. I hope this is helpful.
James you can go ahead and do the following as it will be the change i make in the dictionary
select * from openmrs.concept_name where concept_name_id='134644'
Set voided to 1 , voided by to 54 and date voided - 2016-28-04
It should appear as below
and thank you for the rules , thats what i needed
This is a summary of my findings in case you want to go through them
I think we should just void all of these and add them back one by one when we can develop a proper default spanish translation for the concepts with multiple synonyms.
That’s what we did . Posted here for @darius if they want to tweet the code for validation
Thanks @judy, for the summary of findings! Can you please explain it to me like I’m dumb, and I need detailed explanation?
I see that one problem is that the UI is displaying things incorrectly when there is no preferred/fully-specified name.
But besides that, what is the thing that is going wrong in code and we need to fix?
I think what needs to be confirmed is that the update process is actually taking what is seen in the UI in 1.6.6 (one synonym elevated to preferred/default) and converting it to real data in later versions which fail validation. By removing the data causing the problem we clean up what appears in the later versions… but we don’t solve the underlying problem (which is that they shouldn’t be elevated to default/preferred automatically).
@jdegraft, we discussed this on today’s PM call. It looks like the step described by @judy is the last step needed. Is that clear to you? Were you able to do this?
I have a pull request with step included, ie. the final CIEL release for ref app 2.4 release. I can wait for this to be merged before releasing to UAT.
