Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015423Openbravo ERP00. Application dictionarypublic2010-12-14 14:172012-09-24 23:24
Reportertgarcia 
Assigned Tomarvintm 
PrioritylowSeverityminorReproducibilityalways
StatusscheduledResolutionopen 
PlatformOS20OS VersionCommunity Appliance
Product Version2.50MP24 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customerNo
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0015423: Naming Exception's "active" field is not taken into account during ant export.database
DescriptionIf a naming exception is created and set as not active, ant export.database still takes it into account.
Steps To ReproduceI am using two templates, A and B. Both of them have the same naming exception, as both implement their own version of C_INVOICE_POST DB function.

I want B to overwrite A's function, so B changes A's naming exception to "not active", using configScript.xml.
If I run update.database, B's implementation of C_INVOICE_POST is pushed to the database, as it should be.

However, if I export.database right after this, A keeps it's xml version, and B's xml file get deleted.
Proposed SolutionEnforcing only one active naming exception per object/entity would be a good ideia, as I can have multiples modules activly implementing the same object, and that would generate conflicts.

Also, and more important, ant export.database should not display the mentioned behavior.
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-12-14 14:17tgarciaNew Issue
2010-12-14 14:17tgarciaAssigned To => alostale
2010-12-14 14:17tgarciaModules => Core
2010-12-20 08:46alostaleStatusnew => scheduled
2010-12-20 08:46alostaleAssigned Toalostale => marvintm
2010-12-20 08:46alostalefix_in_branch => pi
2012-01-30 18:02marvintmOBNetwork customer => No
2012-01-30 18:02marvintmNote Added: 0044712
2012-01-30 18:02marvintmTypedefect => design defect
2012-01-30 18:02marvintmfix_in_branchpi =>
2012-09-24 23:24AugustoMauchNote Added: 0052462
2012-09-24 23:24AugustoMauchPrioritynormal => low

Notes
(0044712)
marvintm   
2012-01-30 18:02   
The original specification for Naming Exceptions didn't consider whether it should be possible to deactivate them or not.

It may make sense to do it, but in any case it would be a considerable effort for a feature which is not very used anymore (it was designed primarily to facilitate the migration of some complex OB instances from 2.35 and 2.40 to 2.50).

So, in any case, this issue is going to be changed to a design defect.
(0052462)
AugustoMauch   
2012-09-24 23:24   
Effort: 1
Impact: low
Plan: long