Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0033940Openbravo ERPA. Platformpublic2016-09-09 13:002022-02-01 08:09
Reporternaiaramartinez 
Assigned ToTriage Platform Base 
PriorityurgentSeveritymajorReproducibilityalways
StatusnewResolutionopen 
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
Summary0033940: [SERQA 1558 ]When Postgres database is configured in French the unique message is not found in Openbravo's ad_message
DescriptionWhen creating a record in Openbravo that raises a unique constraint, instead of showing the ad_message it is showing the message raised by the database.

The message that I can see, for example, when creating a user that already exist, is the following:
 Saving failed. ERREUR: la valeur d'une clé dupliquée rompt la contrainte unique « ad_user_un_username » Détail : La clé « (username)=(Anthony) » existe déjà.

Please, check the 'ErrorTextParserPOSTGRE' java class to fix this. Stefan has asked to also include some test cases. For more information talk to Stefan.
Steps To Reproduceit is reproducible in French postgres database.
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
related to defect 00115723.0MP2 closed shuehner Constraint error text parser on Postgres doesn't work with Spanish translated PostgreSQL 
related to defect 0038907 closed caristu DB errors which several OB messages are not correctly parsed in PG 
related to design defect 0041866 acknowledged Triage Platform Base Error messages for check constrains are not generated if PosgreSQL is in Spanish 
Attached Fileslog openbravo.log (6,575) 2016-09-12 13:24
https://issues.openbravo.com/file_download.php?file_id=9802&type=bug
log postgres.log (545) 2016-09-12 15:45
https://issues.openbravo.com/file_download.php?file_id=9803&type=bug
diff 33940.diff (1,969) 2016-09-12 17:32
https://issues.openbravo.com/file_download.php?file_id=9804&type=bug
Issue History
Date ModifiedUsernameFieldChange
2016-09-09 13:00naiaramartinezNew Issue
2016-09-09 13:00naiaramartinezAssigned To => AugustoMauch
2016-09-09 13:00naiaramartinezModules => Core
2016-09-09 13:00naiaramartinezTriggers an Emergency Pack => No
2016-09-09 14:53paul_guiotResolution time => 1475186400
2016-09-09 14:53paul_guiotSummaryWhen Postgres database is configured in French the unique message is not found in Openbravo's ad_message => [SERQA 1558 ]When Postgres database is configured in French the unique message is not found in Openbravo's ad_message
2016-09-12 12:47VictorVillarAssigned ToAugustoMauch => platform
2016-09-12 13:04naiaramartinezPrioritynormal => urgent
2016-09-12 13:04naiaramartinezSeveritytrivial => major
2016-09-12 13:04naiaramartinezReproducibilityhave not tried => always
2016-09-12 13:24naiaramartinezFile Added: openbravo.log
2016-09-12 15:45naiaramartinezFile Added: postgres.log
2016-09-12 15:50shuehnerRelationship addedrelated to 0011572
2016-09-12 17:32shuehnerFile Added: 33940.diff
2016-09-12 17:33shuehnerNote Added: 0089903
2016-09-12 17:35shuehnerNote Edited: 0089903bug_revision_view_page.php?bugnote_id=0089903#r13093
2016-09-23 09:07alostaleResolution time1475186400 =>
2016-09-23 09:07alostaleNote Added: 0090184
2016-09-23 09:07alostaleTypedefect => design defect
2018-08-02 08:56alostaleRelationship addedrelated to 0038907
2019-09-27 11:20alostaleRelationship addedrelated to 0041866
2022-02-01 08:09alostaleAssigned Toplatform => Triage Platform Base

Notes
(0089903)
shuehner   
2016-09-12 17:33   
(edited on: 2016-09-12 17:35)
Note: Attached patch will NOT fix the issue just adds half fix + a simple junit test which can be used to show the issue.
Testcase also not final as 'expected message would need to be adjusted (after issue is fixed)'
(0090184)
alostale   
2016-09-23 09:07   
Moved to design defect.

Proper fix for this issue should add the capability to implement custom db error parsers instead of trying to handle all posible cases in any different language from a central one.