Project:
View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||||||
ID | ||||||||||||
0024711 | ||||||||||||
Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||||||
feature request | [Openbravo ERP] C. Security | minor | have not tried | 2013-09-06 10:27 | 2013-09-06 11:41 | |||||||
Reporter | jonalegriaesarte | View Status | public | |||||||||
Assigned To | AugustoMauch | |||||||||||
Priority | normal | Resolution | open | Fixed in Version | ||||||||
Status | new | Fix in branch | Fixed in SCM revision | |||||||||
Projection | none | ETA | none | Target Version | ||||||||
OS | Any | Database | Any | Java version | ||||||||
OS Version | Database version | Ant version | ||||||||||
Product Version | 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 | 0024711: Add the ability to configure a window in order to have a delete on cascade or not | |||||||||||
Description | Actually, 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 | |||||||||||
Tags | No tags attached. | |||||||||||
Attached Files | ||||||||||||
Relationships [ Relation Graph ] [ Dependency Graph ] | |
Notes | |
(0060960) shuehner (administrator) 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. |
Issue History | |||
Date Modified | Username | Field | Change |
2013-09-06 10:27 | jonalegriaesarte | New Issue | |
2013-09-06 10:27 | jonalegriaesarte | Assigned To | => AugustoMauch |
2013-09-06 10:27 | jonalegriaesarte | Modules | => Core |
2013-09-06 10:27 | jonalegriaesarte | Triggers an Emergency Pack | => No |
2013-09-06 11:38 | shuehner | Issue Monitored: shuehner | |
2013-09-06 11:41 | shuehner | Note Added: 0060960 |
Copyright © 2000 - 2009 MantisBT Group |