ofbiz-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacques Le Roux (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OFBIZ-9185) The deleteWorkEffort service is incomplete and even wrong
Date Mon, 23 Jan 2017 14:32:26 GMT

    [ https://issues.apache.org/jira/browse/OFBIZ-9185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15834659#comment-15834659

Jacques Le Roux commented on OFBIZ-9185:

BTW, I have to look closer in the RemoveRelated class, but it seems to me that the remove-foreign-key
is not even needed. You want to remove or not, that's all. So if you use remove-related it
means you want to get rid of the record/s in the related entity. I'll be back :)

Actually I though proposed the remove-foreign-key attribute because of the legacy behaviour
which could else cause issues in custom projects. 

So I finally think we should still use it as proposed above. Just that something which is
supposed to remove and don't is surprising, moreover after more than 10 years :-o

> 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
> 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

View raw message