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

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0011590
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Modules] Mass Invoicingminorhave not tried2009-12-02 09:362014-04-01 21:48
ReportermtaalView Statuspublic 
Assigned Todalsasua 
PrioritynormalResolutionfixedFixed in Version2.50
StatusclosedFix in branchpiFixed in SCM revision
ProjectionnoneETAnoneTarget Version2.50
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product Version2.50SCM revision 
Regression date
Regression introduced by commit
Regression level
Review Assigned To
Regression introduced in release
Summary

0011590: Check/correct module for new modularity naming rules

DescriptionSee the email from Asier Lostale on 2nd of December 2009.

A summary of the rules to check:

    * Mapping for WAD code
          o Rule: Mapping for WAD windows contains now the module's mapping for tabs not in core. As this is automatically generated and shouldn't be manually edited class and mapping tabs in Windows and Tabs window has been set as non editable.
          o Consequence: When updating to the new core version mappings in modules will be automatically updated to the new rule.
          o Action: Export the module with the new automatically generated mapping.
    * Mapping for manual code.
          o Rule: HTML mapping for all manual objects (forms, searchs, reports and processes) must start now with the module's package. For example, the mapping for a report in a module with package (org.myCompany.moduleTest) could be /org.myCompany.moduleTesr.reports/MyReport.html.
          o Consequence: Old modules not following this rule will still work, but a warning will be displayed whenever the code is compiled. These modules will not be allowed to be packaged in obx files till they are not fixed.
          o Action: The action to be taken to fix modules is to detect the incorrect mappings (it will be shown as a warning when compiling) and adapt them to the new rule.
    * Column.name value
          o Rule: Name attribute in column must follow now the same rules as Database name (columnname) had. This is, when the column is in the same module as its table, no special rule required; if it is in another module, it must start by EM_ + the module's db_prefix.
          o Consequence: This rule has been enforced in through database triggers, making not possible to create or modify existent objects if the mapping is not correct. Anyway, old modules not following this rule will still work, but a warning will be displayed whenever the code is compiled. These modules will not be allowed to be packaged in obx files till they are not fixed.
          o Action: Locate columns not following the naming and change it. Note that this will cause a change in the module's API, because this value is used by DAL to generate the property in Java. Therefore it will be necessary also to change the Java processes accessing the column with DAL.
    * Database indexes and constraints
          o Rule: Indexes and constraints now must start with the module's db_prefix if they are in the same module as their table. If they are in a different one, the rule is the same as it was (start by EM_ + db_prefix).
          o Consequence. Now when exporting database (if validate.model property is set to true) a warning will be raised if there are indexes or constraints not following the rule. It will not be allowed to package modules in obx files if they do not follow the rule.
          o Action: Rename indexes and constraints to adapt them to the new rule. Note that it is possible to define messages for constraints, in this way it is possible to display a customized message when the constraint is not satisfied. These message have as Search key value the constraint name, therefore it will be necessary to change them if exist.
    * Reference name
          o Rule: In this case a restriction has been removed. Prior to this change, reference name was unique in the whole database, thus it was possible two different module adding two reference with same name and it was not possible to install both in the same instance. Now, reference name is unique per module, so there is no problem with several modules defining the same name for different references.
          o Consequence: Now name cannot be used to identify references. Therefore constructor for TableComboData shouldn't be used passing as parameter the reference name, but its ID. This constructor has been changed and when passing name the reference is always looked within core but not in other modules.
          o Action: Review module's manual code to ensure all TableComboData constructors are called using ID when the reference is not in core.

As addition, all default messages used to be displayed when a constraint is not satisfied have been removed from database as they are automatically managed. This means that hundreds of messages have disappear and it is recommended for those of you maintaining a translation to repackage it again without all of these messages.
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
(0022603)
mtaal (manager)
2009-12-09 23:09

Scheduled
(0022604)
mtaal (manager)
2009-12-09 23:10

Solved in changeset:
https://code.openbravo.com/erp/mods/org.openbravo.document.massinvoicing/rev/34830bb7b980 [^]
(0065775)
plujan (manager)
2014-04-01 21:48

Marked as Closed since it was in Resolved for too long

- Issue History
Date Modified Username Field Change
2009-12-02 09:36 mtaal New Issue
2009-12-02 09:36 mtaal Assigned To => mtaal
2009-12-09 23:09 mtaal Status new => scheduled
2009-12-09 23:09 mtaal Note Added: 0022603
2009-12-09 23:09 mtaal fix_in_branch => pi
2009-12-09 23:10 mtaal Note Added: 0022604
2009-12-09 23:10 mtaal Status scheduled => resolved
2009-12-09 23:10 mtaal Fixed in Version => 2.50
2009-12-09 23:10 mtaal Resolution open => fixed
2011-06-03 11:11 dalsasua Assigned To mtaal => dalsasua
2014-04-01 21:48 plujan Note Added: 0065775
2014-04-01 21:48 plujan Status resolved => closed


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker