What comments are you looking for? It either works or it doesn't. A couple of things to consider: - Is there really a good reason to delete a WorkEffort record when changing its status should be sufficient? - Maybe it doesn't work now because the data model has changed since it was introduced? - Maybe it only ever worked for the contributor's use case which didn't make use of the foreign keys that concern you?
Regardless there are only two paths of action: fix it or remove it. My preference is for the latter because I can't think of any *good* reasons to remove a WorkEffort record. Regards Scott On 23 January 2017 at 01:58, Jacques Le Roux <[email protected]> wrote: > I created https://issues.apache.org/jira/browse/OFBIZ-9185 please comment > > Thanks > > Jacques > > > > Le 19/01/2017 à 21:35, Jacques Le Roux a écrit : > >> Hi, >> >> I looked closely and I do not understand how the deleteWorkEffort service >> can work. Especially when a Workeffort has an established relationship with >> a RuntimeData. If someone has some clues I'm interested! >> >> Also CustRequestWorkEffort is missing in deleteWorkEffort, please confirm >> if you can. >> >> 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. >> >> Jacques >> >> >> >
