Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
0015423Openbravo ERP00. Application dictionarypublic2010-12-14 14:172012-09-24 23:24
tgarcia 
marvintm 
lowminoralways
scheduledopen 
20Community Appliance
2.50MP24 
 
Core
No
0015423: Naming Exception's "active" field is not taken into account during ant export.database
If a naming exception is created and set as not active, ant export.database still takes it into account.
I 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.
Enforcing 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.
No tags attached.
Issue History
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: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