[
https://issues.apache.org/jira/browse/OFBIZ-9185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16082188#comment-16082188
]
Jacques Le Roux commented on OFBIZ-9185:
----------------------------------------
I tend to agree Deepak. I always found weird to have both deleting and
deprecating patterns in OFBiz.
For me the deprecating pattern is better for at least 2 reasons:
# Data can still be audited, even in cases that could be surprising helpful (ie
not foreseen when deciding to initially deleting)
# If the reason is because people would need place (less and less a problem
nowadays), then it's better to carefully review what really needs to deleted,
and then deletion be done with a custom SQL script.
> The deleteWorkEffort service is incomplete and even wrong
> ---------------------------------------------------------
>
> Key: OFBIZ-9185
> URL: https://issues.apache.org/jira/browse/OFBIZ-9185
> Project: OFBiz
> Issue Type: Bug
> Components: workeffort
> Affects Versions: Trunk
> Reporter: Jacques Le Roux
> Priority: Minor
>
> This issue is very old (pre Apache) so all versions are affected (I just
> tested with R09.04)
> When you try to delete a Workeffort which has an established relationship
> with a RuntimeData or any of the entities Workeffort has a relation with (eg
> NoteData, RecurrenceInfo) using the the deleteWorkEffort service this one
> fails
> Also from my experience CustRequestWorkEffort is missing in deleteWorkEffort,
> would be to add
> {code}
> <remove-related value-field="lookedUpValue"
> relation-name="CustRequestWorkEffort"/>
> {code}
> Besides (minor) ApplicationSandbox is maybe missing in the implementation of
> deleteWorkEffort.
> There is indeed a workeffortId in ApplicationSandbox.
> So ApplicationSandbox is indirectly linked to Workeffort by RuntimeData.
> But it can anyway be deleted by a simple delete-by-and (or alike), so not a
> problem for deleteWorkEffort, though this case could be handled there also.
> Summary: the deleteWorkEffort service needs more work. The only solution I
> see is to remove the FK from the Workeffort (ie put null in the related field
> if it's not) and then deleted the related entity instead of directly calling
> remove-related
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)