Project:
View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
ID | ||||||||
0047823 | ||||||||
Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
defect | [Openbravo ERP] A. Platform | major | have not tried | 2021-10-06 12:37 | 2021-10-25 10:06 | |||
Reporter | shuehner | View Status | public | |||||
Assigned To | platform | |||||||
Priority | normal | Resolution | no change required | Fixed in Version | ||||
Status | closed | Fix in branch | Fixed in SCM revision | |||||
Projection | none | ETA | none | Target Version | ||||
OS | Any | Database | Any | Java version | ||||
OS Version | Database version | Ant version | ||||||
Product Version | SCM revision | |||||||
Review Assigned To | ||||||||
Web browser | ||||||||
Modules | Core | |||||||
Regression level | ||||||||
Regression date | ||||||||
Regression introduced in release | ||||||||
Regression introduced by commit | ||||||||
Triggers an Emergency Pack | No | |||||||
Summary | 0047823: Synchronize terminology doing wrong changes with module in different language, pointing to core element not having translation | |||||||
Description | Special 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 Reproduce | Preparation: - 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 Solution | If 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. | |||||||
Tags | No 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 |