Openbravo Issue Tracking System - Openbravo ERP |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0010921 | Openbravo ERP | 00. Application dictionary | public | 2009-10-09 12:03 | 2009-12-02 09:21 |
|
| Reporter | networkb | |
| Assigned To | alostale | |
| Priority | high | Severity | major | Reproducibility | always |
| Status | closed | Resolution | no change required | |
| Platform | | OS | 5 | OS Version | |
| Product Version | 2.50MP6 | |
| Target Version | 2.50MP9 | Fixed in Version | | |
| Merge Request Status | |
| Review Assigned To | |
| OBNetwork customer | OBPS |
| Web browser | |
| Modules | Core |
| Support ticket | |
| Regression level | |
| Regression date | |
| Regression introduced in release | |
| Regression introduced by commit | |
| Triggers an Emergency Pack | No |
|
| Summary | 0010921: If the java package of a module is modify after do some developments, the ad_model_object is not updated |
| Description | If the java package of a module is modify after do some developments, the ad_model_object is not updated with the new packages
so the developments don't work |
| Steps To Reproduce | -Create a module with a package name
-Add a development, for example a new report with his mapping
-Change the javapackage of the module
-See that the the mapping is not change according the new javapackage |
| Proposed Solution | |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | | related to | feature request | 0011431 | | closed | alostale | Complete modularity checks |
|
| Attached Files | |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 2009-10-09 12:03 | networkb | New Issue | |
| 2009-10-09 12:03 | networkb | Assigned To | => rafaroda |
| 2009-10-09 12:03 | networkb | OBNetwork customer | => Yes |
| 2009-10-09 14:03 | psarobe | Priority | immediate => high |
| 2009-10-09 14:03 | psarobe | Status | new => scheduled |
| 2009-10-09 14:03 | psarobe | Assigned To | rafaroda => alostale |
| 2009-10-09 14:03 | psarobe | fix_in_branch | => pi |
| 2009-10-22 10:04 | networkb | Target Version | 2.50MP8 => 2.50MP9 |
| 2009-10-22 10:04 | networkb | fix_in_branch | pi => |
| 2009-11-17 07:54 | alostale | Note Added: 0021897 | |
| 2009-11-17 07:54 | alostale | Status | scheduled => closed |
| 2009-11-17 07:54 | alostale | Resolution | open => no change required |
| 2009-11-18 00:00 | anonymous | sf_bug_id | 0 => 2899458 |
| 2009-11-20 09:55 | alostale | Note Added: 0022047 | |
| 2009-11-20 09:55 | alostale | Relationship added | related to 0011431 |
| 2009-11-23 15:47 | networkb | Note Added: 0022115 | |
| 2009-12-02 09:21 | alostale | Note Added: 0022348 | |
|
Notes |
|
|
|
|
This change shouldn't be automatically done. It would require not only changing the application dictionary mapping, but also the actual packaging in java files this would make the automatic process quite dangerous. |
|
|
|
|
|
A verification is going to be implemented when exporting obx to ensure that at that time everything has been fixed (0011431) |
|
|
|
|
@alostale: If an automatic process is quite dangerous, changing the mappings manually won't be also dangerous? Won't be better to control this process from Openbravo side?
A way to solve it could be to not allow modifying the javapackage if there are elements with a mapping defined |
|
|
|
|
Yes, it is dangerous but it is allowed because it is possible at some point you decide to change the module's java package.
It cannot be automatically done because it requires anyway to repackage the java classes in the new package and this is always better done manually (you can use you IDE to facilitate the work).
After the commit of issue 0011431 if you modify your java package but not the packages for the rest of elements you will get a warning when you compile and you will not be able to package the module as obx file till you don't fix it. |
|