Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005585Openbravo ERPC. Securitypublic2008-10-20 11:292008-12-31 12:16
Reporternataliaperu 
Assigned Toiciordia 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOS5OS Version
Product Version 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0005585: Foreign keys must be included in CREATEDBY and UPDATEDBY fields
DescriptionCREATEDBY and UPDATEDBY columns within all Openbravo ERP tables are used for auditing purposes. These columns are filled with the ID of the logged user that creates or updates the record. This user has to be recorded in AD_USER table. The problem is that in many (IF NOT ALL) tables do not have as foreign key the AD_USER_ID column of the AD_USER table for CREATEDBY and UPDATEDBY columns. As a result of this, one can delete one record from AD_USER table even if this user has created or updated records. It is known that this has caused problems with the upgrader from Openbravo ERP MP4 to MP5 where some users were deleted (those who had AD_CLIENT_ID = 0). Since no foreign key exists in CREATEDBY and UPDATEDBY fields, for example in C_INVOICE table, there are records in C_INVOICE table within users that do not exist in the database.
Steps To Reproduce1) Logged as Client Admin, create a new User and assign him a Role.
2) Log out and log in with this user and create a new transaction, for instance, an invoice.
3) Log out and log in again as Client Admin and deleted the previously created User.

You are able to do it since CREATEDBY and UPDATEDBY columns have not AD_USER_ID as a foreign key.
Proposed SolutionThe solution for this issue would be add the following lines in all the XML tables withing /src-db/database/model/tables (changing _CINVOICE by the corresponging table name):
<foreign-key foreignTable="AD_USER" name="ADUSER_CBY_CINVOICE">
  <reference local="CREATEDBY" foreign="AD_USER_ID"/>
</foreign-key>
<foreign-key foreignTable="AD_USER" name="ADUSER_UBY_CINVOICE">
  <reference local="UPDATEDBY" foreign="AD_USER_ID"/>
</foreign-key>

Nevertheless, a decision has to be taken since this could give a lot of errors during upgrades if any current Openbravo live implementation has inserted records in any table with an user that does not exist anymore in AD_USER table.
Additional Information
TagsNo tags attached.
Relationships
has duplicate defect 0055867 closed SABARINATH P POS2 Missing properties related to Product Characterisctics in the Product Import Swagger API 
blocks defect 0005542 closed iciordia Openbravo ERP Foreign keys must be included in CREATEDBY and UPDATEDBY fields 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2008-10-20 11:29psarobeNew Issue
2008-10-20 11:29psarobeAssigned To => cromero
2008-10-20 11:29psarobeStatusnew => scheduled
2008-11-10 13:04cromeroAssigned Tocromero => rafaroda
2008-11-13 22:07rafarodaAssigned Torafaroda => Dowid
2008-11-26 16:42rafarodaAssigned ToDowid => rafaroda
2008-11-26 17:08rafarodaNote Added: 0010724
2008-11-26 17:08rafarodaDescription Updated
2008-11-26 17:08rafarodaProposed Solution updated
2008-11-26 17:08rafarodaSteps to Reproduce Updated
2008-12-31 12:15iciordiaRegression testing => No
2008-12-31 12:15iciordiaStatusscheduled => closed
2008-12-31 12:15iciordiaNote Added: 0011786
2008-12-31 12:15iciordiaResolutionopen => no change required
2008-12-31 12:15iciordiaAssigned Torafaroda => iciordia
2008-12-31 12:15iciordiaStatusclosed => new
2008-12-31 12:15iciordiaResolutionno change required => open
2008-12-31 12:16iciordiaStatusnew => closed
2008-12-31 12:16iciordiaNote Added: 0011787
2008-12-31 12:16iciordiaResolutionopen => no change required
2024-07-01 09:28guilleaerRelationship addedhas duplicate 0055867

Notes
(0010724)
rafaroda   
2008-11-26 17:08   
The following SELECT in Oracle shows the tables that miss from this foreign key.

select *
  from user_tables u
  where not exists (select 1 from user_constraints t, user_cons_columns cl
          where t.table_name = u.table_name
          and r_constraint_name = 'AD_USER_KEY'
          and cl.constraint_name = t.constraint_name
          and cl.column_name ='UPDATEDBY')
    or not exists (select 1 from user_constraints t, user_cons_columns cl
          where t.table_name = u.table_name
          and r_constraint_name = 'AD_USER_KEY'
          and cl.constraint_name = t.constraint_name
          and cl.column_name ='CREATEDBY');
(0011786)
iciordia   
2008-12-31 12:15   
Foreign keys in audit info result in a heavy overload and bad performance. Since the user is not allowed to edit this information (the system is in charge of that) these foreign keys are not needed. If the upgrader performs an action that creates any data inconsitency then the fix needs to be applied to the upgrader, but these constraints MUST NOT be created.
(0011787)
iciordia   
2008-12-31 12:16   
Foreign keys in audit info result in a heavy overload and bad performance. Since the user is not allowed to edit this information (the system is in charge of that) these foreign keys are not needed. If the upgrader performs an action that creates any data inconsitency then the fix needs to be applied to the upgrader, but these constraints MUST NOT be created.