Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0047823Openbravo ERPA. Platformpublic2021-10-06 12:372021-10-25 10:06
Reportershuehner 
Assigned Toplatform 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOS5OS Version
Product Version 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0047823: Synchronize terminology doing wrong changes with module in different language, pointing to core element not having translation
DescriptionSpecial case found indirectly in Jenkins for a customer job.

- Having module with language es_ES (any non en_US)
- That module having an ad_column referencing an ad_element from backoffice repo
- Not having es_ES translation available for that core ad_element_id
  - I.e. by not having es_ES translation module installed for core.

In that situation running synchronize terminology is overwriting the text entries in the module with the 'en_US text' as it is missing the 'correct es_ES' translation for the ad_element.

Note that having es_ES translation available for the ad_element the logic seems to be fine and not breaking the module data.
Steps To ReproducePreparation:
- Pristine backoffice install without additional module
- org.openbravo.module.organization.representative.es
  Installed (with dependencies as required)
- NOT have es_ES translation modules installed (i.e. NOT the full SPLP pack)

To produce problem:
- Set modules in development
- Run synchronize terminology
- run export.database for above module
  See data changes replacing the es_ES text with the wrong english texts

To avoid the problem:
- Have also es_ES translation installed for backoffice repo
- Then problem does not occour.
Proposed SolutionIf translated value for the 'correct' language is missing it is probably better to not update the ad_column instead of overwriting it with the wrong language.
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2021-10-06 12:37shuehnerNew Issue
2021-10-06 12:37shuehnerAssigned To => platform
2021-10-06 12:37shuehnerModules => Core
2021-10-06 12:37shuehnerTriggers an Emergency Pack => No
2021-10-18 09:53alostaleNote Added: 0132390
2021-10-19 10:18shuehnerNote Added: 0132437
2021-10-25 10:06alostaleNote Added: 0132601
2021-10-25 10:06alostaleStatusnew => closed
2021-10-25 10:06alostaleResolutionopen => no change required

Notes
(0132390)
alostale   
2021-10-18 09:53   
Could this be caused by having es_ES language marked as system language?

The AD_Synchronize process does:

1. Populate ad_element_trl with the missing "translations" for system languages and elements in modules in development. In this step, if es_ES was marked as system but there was no translation for the element yet, it will be created as a copy of the base element.
2. Updates column of modules in development. For columns that link to an element which module has a different language than the column's module, the element_trl record is taken. In this case, it will take the record that was just created that as a copy of the original one, this is with values in English.

Note that, in this case, executing synchronize terminology having es_ES not flagged as system without ad_element_trl record for the given element, keeps unchanged the values in the ad_column record.
(0132437)
shuehner   
2021-10-19 10:18   
The instance/job showing this has 2 es_ES translations module still present (even while not having core translation).
- org.openbravo.module.sii.es_ES
- org.openbravo.module.taxreportlauncher.es

Probably installing any of those will trigger es_ES to be system-language.
Quick look at those module shows them apparently only containing translations.
So it might be possible for them not to be needed (in this specific case).

While that would not be a 'fix' it could avoid triggering the error.
(0132601)
alostale   
2021-10-25 10:06   
This confirms the case.

When a translation module is installed (both by install.source or update.database), its language is marked as system [1].

Therefore this issue is going to be closed.

---
[1] https://gitlab.com/openbravo/product/openbravo/-/blob/c835743e09883e0ed34313dd2e4145689b37c1f7/src/org/openbravo/erpCommon/modules/ApplyModule.java#L166 [^]