Agree on all points shared by Scott, Paul and Nicolas. Also valid concern raised in this thread by Jacques. Thanks!
As described by Nicolas, that work_effort is complex entity and we should consider the functional context for it, if we wnat to delete a work_effort. Still I think, until business or dba not force we should maintain the historical data. I mean to say, we have date fileds and status fields in the work_effort the maintain/filter them. Also on closing/cancelling the workeffort case by case basis system clear them out from the system. So we need a delete service for work_effort which requires extra handling for date fields, status field with some better algorithm so that once business decided to remove it, system should always remove instead of sending exception on dependencies. Thanks! Kind Regards, -- Rishi Solanki Sr. Manager, Enterprise Software Development HotWax Systems Pvt. Ltd. Direct: +91-9893287847 http://www.hotwaxsystems.com On Mon, Jan 23, 2017 at 4:25 PM, Nicolas Malin <[email protected]> wrote: > WorkEffort is a complexe entity as much technical aspect as functional > cover :) > > On the Jacques's case, the workEffort is used to follow jobSandox activity > after user command and in logical delete all older workEffort to minimize > the history (like jenkins with his scheduler). > > After your remarks, I think call deleteWorkEffort isn't logical without > functional context. If we want delete a WorkEffort, we need to understand > the this context and in this case prepare the deletion by a dedicate > service (remove all potential FK and so one) before call the standard > service. > > Nicolas > > > Le 23/01/2017 à 11:10, Paul Foxworthy a écrit : > >> Hi Jacques and Scott, >> >> On 23 January 2017 at 09:08, Scott Gray <[email protected]> >> wrote: >> >> >> I can't think of any *good* reasons to remove a WorkEffort record. >>> >> >> Hear, hear. In general, OFBiz expires an entity by setting the thruDate. >> What's so special about WorkEffort? >> >> Cheers >> >> Paul >> >> >
