Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0047823
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] A. Platformmajorhave not tried2021-10-06 12:372021-10-25 10:06
ReportershuehnerView Statuspublic 
Assigned Toplatform 
PrioritynormalResolutionno change requiredFixed in Version
StatusclosedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned To
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0047823: 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.
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
(0132390)
alostale (manager)
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 (administrator)
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 (manager)
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 [^]

- Issue History
Date Modified Username Field Change
2021-10-06 12:37 shuehner New Issue
2021-10-06 12:37 shuehner Assigned To => platform
2021-10-06 12:37 shuehner Modules => Core
2021-10-06 12:37 shuehner Triggers an Emergency Pack => No
2021-10-18 09:53 alostale Note Added: 0132390
2021-10-19 10:18 shuehner Note Added: 0132437
2021-10-25 10:06 alostale Note Added: 0132601
2021-10-25 10:06 alostale Status new => closed
2021-10-25 10:06 alostale Resolution open => no change required


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker