Project:
View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||||||
ID | ||||||||||||
0007580 | ||||||||||||
Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||||||
design defect | [Openbravo ERP] 01. General setup | minor | have not tried | 2009-02-16 17:05 | 2012-05-10 12:13 | |||||||
Reporter | plujan | View Status | public | |||||||||
Assigned To | mirurita | |||||||||||
Priority | normal | Resolution | open | Fixed in Version | ||||||||
Status | scheduled | Fix in branch | Fixed in SCM revision | |||||||||
Projection | none | ETA | none | Target Version | ||||||||
OS | Linux 64 bit | Database | PostgreSQL | Java version | ||||||||
OS Version | Database version | Ant version | ||||||||||
Product Version | pi | SCM revision | ||||||||||
Review Assigned To | ||||||||||||
Web browser | ||||||||||||
Modules | Core | |||||||||||
Regression level | ||||||||||||
Regression date | ||||||||||||
Regression introduced in release | ||||||||||||
Regression introduced by commit | ||||||||||||
Triggers an Emergency Pack | No | |||||||||||
Summary | 0007580: If Organization Type contents change, an update.database will not update local copy | |||||||||||
Description | If I have an Openbravo release with old values on Organization Type window and a new revision update that content (by adding or updating rows) the update.database task will not update that table and old contents will remain. | |||||||||||
Proposed Solution | It has no sense to keep this records untouched. For other tables, like User, may be it is logic to keep records as user had them, but is not the same for Organization Type. | |||||||||||
Tags | OB3-Reviewed | |||||||||||
Attached Files | ||||||||||||
Relationships [ Relation Graph ] [ Dependency Graph ] | ||||||||
|
Notes | |
(0014611) marvintm (developer) 2009-03-12 15:37 |
This table currently belongs to dataset ADRD, and therefore will not be updated during the update.database process. It should be decided whether this is correct or not. If it's not, then it should be moved to dataset AD. However, modularity will then need to be taken into account (an AD_MODULE_ID column will have to be added, or at least the whereclause will need to be modified to specify the module each row of this table belongs to). |
Issue History | |||
Date Modified | Username | Field | Change |
2009-02-16 17:05 | plujan | New Issue | |
2009-02-16 17:05 | plujan | Assigned To | => rafaroda |
2009-02-16 17:05 | plujan | Regression testing | => No |
2009-02-18 04:30 | pjuvara | version | => trunk |
2009-02-24 12:55 | psarobe | Status | new => scheduled |
2009-02-24 12:55 | psarobe | Assigned To | rafaroda => marvintm |
2009-02-24 12:55 | psarobe | fix_in_branch | => trunk |
2009-03-12 15:37 | marvintm | Note Added: 0014611 | |
2009-03-12 15:37 | marvintm | Assigned To | marvintm => vmromanos |
2011-10-28 10:31 | psarobe | Type | defect => design defect |
2011-10-28 10:31 | psarobe | fix_in_branch | pi => |
2011-10-28 10:31 | psarobe | Tag Attached: OB3-Reviewed | |
2011-11-24 15:30 | vmromanos | Relationship added | related to 0008916 |
2012-05-10 12:13 | gorka_gil | Assigned To | vmromanos => mirurita |
Copyright © 2000 - 2009 MantisBT Group |