0011431: Complete modularity checks - Openbravo Issue Tracking System

Openbravo Issue Tracking System - Openbravo ERP

View Issue Details

Project

Category

View Status

Date Submitted

Last Update

0011431

Openbravo ERP

A. Platform

public

2009-11-20 08:52

2010-01-22 00:00

Reporter

alostale

Assigned To

alostale

Priority

urgent

Severity

major

Reproducibility

N/A

Status

closed

Resolution

fixed

Platform

OS Version

Product Version

Target Version

Fixed in Version

Merge Request Status

Review Assigned To

OBNetwork customer

Web browser

Modules

Core

Support ticket

Regression level

Regression date

Regression introduced in release

Regression introduced by commit

Triggers an Emergency Pack

Summary

0011431: Complete modularity checks

Description

Currently there are some checks missing in modularity making possible different modules defining artifacts causing conflicts.

Steps To Reproduce

Proposed Solution

1. Manual code
-Implement properly by trigger automatic proposals of classes and html mapping.
-Add validation before compiling to raise warning (future error) when there're elements not following the rule.
-Notify all developers about this issue.
-Write these rules in documentation.

2. WAD windows
-All management should be done automatically by triggers. So make this tabs read only.
-Change for WAD windows the tab class name and mapping adding them the tab's UUID, in this way we could have different modules adding to the same window tabs with the same name.

3. Column.name
Currently ad_column.name is not checked to have the dbprefix for adding columns to a different module. This makes possible modules adding the different columns with the same name to a table. The solution would be:
-Add a trigger not to allow new columns in this way.
-Validate before compiling raising a waning (future error)
-Notify all developers about this issue.
-Document this.

4. Reference name
Currently ad_reference table has a unique constraint for name. Name in reference should not be part of the API, I mean references shouldn't be identified by name but by UUID. My proposal is to change this uniqueness to be module and name, allowing so different modules to define a reference with the same name.
The other solution would be to force references in modules to be named starting by the dbprefix, but this would require to change exitent references in modules.

5. Database objects (Indexes and constraints)
Indexes and constraints are properly managed with dbprefix just in case they are for a table that is not in the same module as the object. But there's no restriction for the name to insert them in the same module. As they are unique in DB this must be guaranteed by naming rule.
Proposed solution:
-Add to export.database a validation rasing a warning (future error) in case the rule is not followed. I think it's easier to do this one in export.database than when compiling.
-Change ALL core indexes and constraints to follow the naming rule.
-Notify all developers about this issue.
-Document this.

Additional Information