Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0024711Openbravo ERPC. Securitypublic2013-09-06 10:272013-09-06 11:41
Reporterjonalegriaesarte 
Assigned ToAugustoMauch 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusnewResolutionopen 
PlatformOS5OS Version
Product Version 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customerOBPS
Web browser
ModulesCore
Support ticket23179
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0024711: Add the ability to configure a window in order to have a delete on cascade or not
DescriptionActually, when the user deletes a record in the header, the records in the child tab are always deleted. This behaviour can not be changed. It would be great if the administrator could change this behaviour in the window (or tab) definition
Steps To Reproduce- Access to sales invoice
- Create a header and one line
- Remove the header, the lines are removed also
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2013-09-06 10:27jonalegriaesarteNew Issue
2013-09-06 10:27jonalegriaesarteAssigned To => AugustoMauch
2013-09-06 10:27jonalegriaesarteModules => Core
2013-09-06 10:27jonalegriaesarteOBNetwork customer => Yes
2013-09-06 10:27jonalegriaesarteSupport ticket => 23179
2013-09-06 10:27jonalegriaesarteTriggers an Emergency Pack => No
2013-09-06 11:38shuehnerIssue Monitored: shuehner
2013-09-06 11:41shuehnerNote Added: 0060960

Notes
(0060960)
shuehner   
2013-09-06 11:41   
That ability doesn't need to be invented it exists since around forever. For each foreign key you can define onDelete behavior to be either cascade or restrict which is exactly what is asked for here.

However some very old (and imo just bad/wrong) design decision when DAL layer was to just ignore all that and just delete everything all the time. There is at least one workaround to make that work at all for some tables.

So if that is now wanted people should revisit that old decision and fix DAL to behave sanely as defined in the db-model. However that may be an intrusive api-change as there can be code relying on the current behavior.

I would escalate that question to at least the platform mailing list for discussion.