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

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0015423
TypeCategorySeverityReproducibilityDate SubmittedLast Update
design defect[Openbravo ERP] 00. Application dictionaryminoralways2010-12-14 14:172012-09-24 23:24
ReportertgarciaView Statuspublic 
Assigned Tomarvintm 
PrioritylowResolutionopenFixed in Version
StatusscheduledFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSLinux 32 bitDatabasePostgreSQLJava version1.6.0_18
OS VersionCommunity ApplianceDatabase version8.3.9Ant version1.7.1
Product Version2.50MP24SCM revision 
Review Assigned To
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

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

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
(0044712)
marvintm (developer)
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 (manager)
2012-09-24 23:24

Effort: 1
Impact: low
Plan: long

- Issue History
Date Modified Username Field Change
2010-12-14 14:17 tgarcia New Issue
2010-12-14 14:17 tgarcia Assigned To => alostale
2010-12-14 14:17 tgarcia Modules => Core
2010-12-20 08:46 alostale Status new => scheduled
2010-12-20 08:46 alostale Assigned To alostale => marvintm
2010-12-20 08:46 alostale fix_in_branch => pi
2012-01-30 18:02 marvintm Note Added: 0044712
2012-01-30 18:02 marvintm Type defect => design defect
2012-01-30 18:02 marvintm fix_in_branch pi =>
2012-09-24 23:24 AugustoMauch Note Added: 0052462
2012-09-24 23:24 AugustoMauch Priority normal => low


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker