Anonymous | Login
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
TypeCategorySeverityReproducibilityDate SubmittedLast Update
feature request[Openbravo ERP] A. Platformmajorhave not tried2008-11-13 10:092009-05-22 19:33
ReporternetworkbView Statuspublic 
Assigned Toiciordia 
PrioritynormalResolutionopenFixed in Version
StatusacknowledgedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned To
Web browser
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo

0005946: When an update.database fails you shouldn't be able to acess to the application.

Description-When you do an update.database after solve conflicts depending on how did you solve conflicts the process can fails becausesome constraints can not be enabled.
-In this case the update.database process is stopped but you can access to the application. Accessing to the application in this situation can
be dangerous because you are able to delete rows of tables were the constraints are not enabled and you shouldn't be able to do this.
-I think that you shouldn't access to application until you have solve problems and have done a successfully update.database.
-When the process of updating.database fails, a new column in a table of the application could be filled saying that the application is not enabled. Then
the login process should check this column to permit or avoid access to the application.
This verification could be extended to the export.database process. For example, avoid to do an export.database until you have done a successfully update.database.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
jpabloae (reporter)
2008-11-14 11:15

A suggestion:

Sometimes a "BUILD SUCCESSFUL" doesn't guarantee that all the update.database operations have been successful. Because of this, it could be good to add a "sanity check" after every update.database command, so it could verify that all the constraints are correctly enabled, for instance. If this sanity check fails, we could add a warning or prevent the access.

- Issue History
Date Modified Username Field Change
2008-11-13 10:09 networkb New Issue
2008-11-14 11:15 jpabloae Note Added: 0010277
2008-11-26 17:17 pjuvara Project @4@ => Openbravo ERP
2008-11-26 17:17 pjuvara Tag Attached: ReleaseCandidate
2008-11-26 17:17 pjuvara Assigned To => pjuvara
2008-11-26 17:17 pjuvara Status new => acknowledged
2008-11-26 17:18 pjuvara Category => A. Platform
2008-12-02 13:02 jaimetorre sf_bug_id 0 => 2377111
2009-05-22 19:33 pjuvara Assigned To pjuvara => iciordia

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker