Openbravo Issue Tracking System - Openbravo ERP |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0001638 | Openbravo ERP | 00. Application dictionary | public | 2007-07-26 17:22 | 2008-06-12 09:43 |
|
| Reporter | villind | |
| Assigned To | alostale | |
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | |
| Platform | | OS | 5 | OS Version | |
| Product Version | | |
| Target Version | | Fixed in Version | pi | |
| 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 | No |
|
| Summary | 0001638: WAD generated code allows dirty writes |
| Description | WAD generated code does not notice a dirty write where two or more users are making conflicting changes.
Scenario:
User A is starting to edit the sales order.
User B is starting to edit the sales order.
User A saves the sales order.
User B saves the sales order.
Changes made by the user A are lost
Things to do:
1. At least prevent the write to the dirty data (User B saves).
2. Try not to lcose changes mady by the user B -> browser back and display some indication that the user should manually open new window and do the merge or start all ower again.
3. Provide merge aid, by getting the updated data from the DB and side by side data that user inputed. By clicking the imputed data it will be overwrite the version coming from the database.
|
| Steps To Reproduce | |
| Proposed Solution | |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | |
| Attached Files | |
|
| Issue History |
| Date Modified | Username | Field | Change |
|
Notes |
|
|
(0005227)
|
|
user71
|
2005-06-01 00:00
(edited on: 2008-06-12 09:43) |
|
|
|
|
(0001589)
|
|
villind
|
2007-07-26 17:25
(edited on: 2008-06-12 09:20) |
|
Logged In: YES
user_id=61737
Originator: YES
The detection of a dirty write can be done by adding a "AD_version" column in the tables and that is incremented by each write. While writing the code must use the existing version in the WHERE clause and check that the affected rows was more than 0.
|
|
|
|
(0001590)
|
|
villind
|
2007-07-26 18:21
(edited on: 2008-06-12 09:20) |
|
Logged In: YES
user_id=61737
Originator: YES
Actually the version number can also enable automatic audit trail for these tables.
* Add a table which is a copy of the original, except the name an primary key also includes the version number.
* Add an update trigger that copies data to this table whenever the original is updated.
|
|
|
|
(0001591)
|
|
psarobe
|
2007-09-03 19:13
(edited on: 2008-06-12 09:20) |
|
Logged In: YES
user_id=1500703
Originator: NO
This is not a bug, this should be a feature request.
Thank you very much |
|
|
|
(0001592)
|
|
villind
|
2007-09-04 08:44
(edited on: 2008-06-12 09:20) |
|
Logged In: YES
user_id=61737
Originator: YES
This is a bug to anyone who is using Openbravo for serious business. Currently I would not advise anyone to use it if there are more than one person taking care of one function in a company.
Even if this is not a implementation bug this is serious design flaw. There have been similar design issues that result implementations that implementation that _destroys_data_, and in most cases those have been accepted as bug reports. I can pull the feature request side apart from this ticket and add it as a feature request, but let's keep the _data_destruction_ side as a bug report.
In my opinion, this should be listed somewhere where it is visible to possible users. It may be in open bugs list or known issues list, but definitely not just a feature request.
Ville
|
|
|
|
(0001593)
|
|
plujan
|
2007-09-04 10:38
(edited on: 2008-06-12 09:20) |
|
Logged In: YES
user_id=1759992
Originator: NO
Hi Ville,
You are right, there are not write locking policies in the current OpenbravoERP version. The design for next version provides native support for write lockings, so no dirty writes will be produced. You may check the roadmap we are working out at the wiki.
I understand your concern about data destruction, and I agree it is important, but in our ERP implementations (with real end-users making real use of functionallity) there were not data overwriting.
Regards,
Pablo. |
|
|
|
(0001594)
|
|
plujan
|
2007-09-04 10:39
(edited on: 2008-06-12 09:20) |
|
Logged In: YES
user_id=1759992
Originator: NO
Hi Ville,
You are right, there are not write locking policies in the current OpenbravoERP version. The design for next version provides native support for write lockings, so no dirty writes will be produced. You may check the roadmap we are working out at the wiki.
I understand your concern about data destruction, and I agree it is important, but in our ERP implementations (with real end-users making real use of functionallity) there were not data overwriting.
Regards,
Pablo. |
|
|
|
(0001595)
|
|
villind
|
2007-09-04 11:09
(edited on: 2008-06-12 09:20) |
|
Logged In: YES
user_id=61737
Originator: YES
Hi,
the problem is that with the current implementation the Openbravo does not detect that there is any data overwriting. As the normal users believe that computer systems sometimes loose some data and do other "weird" things it is not easy to detect this kind of issues in real life before they do serious damage.
I agree that the native and the fancy implementation with conflict resolution should go to the "Green version" but Openbravo 2.x should at least detect and prevent this from happening.
The easiest way to implement this would be just by adding modified(or was it update) time in where clause for WAD generated code and check that the save result affects exactly the number of rows that are expected.
But if the decision is no for Openbravo 2.x then we need to do this.
Ville |
|
|
|
(0001596)
|
|
pjuvara
|
2007-10-30 15:58
(edited on: 2008-06-12 09:20) |
|
Logged In: YES
user_id=1871571
Originator: NO
Reopening this bug.
Regardless on when it gets implemented, we cannot argue that this is not a bug. |
|
|
|
(0001597)
|
|
alostale
|
2008-05-21 11:34
(edited on: 2008-06-12 09:20) |
|
Logged In: YES
user_id=1500722
Originator: NO
This bug is rejected and will be taken into account for the new data access layer definition |
|
|
|
(0001598)
|
|
alostale
|
2008-05-26 09:28
(edited on: 2008-06-12 09:20) |
|
|