Thanks Jacques for logging Jira for this. I have completed this effort and attached a patch on the Jira. Please have a look.
-- Thanks and Regards, *Pawan Verma* | Sr. Enterprise Software Engineer HotWax Commerce <http://www.hotwax.co/> by HotWax Systems <http://www.hotwaxsystems.com/> Plot no. 80, Scheme no. 78 Part ||, Near Brilliant Convention Center, Indore, M.P, India - 452010 Cell phone: +91 9977705687 On Tue, Sep 12, 2017 at 2:59 PM, Jacques Le Roux < [email protected]> wrote: > Yes! thanks Rishi > > Jacques > > > > Le 12/09/2017 à 10:16, Rishi Solanki a écrit : > >> +1 Jacques, Scott, we should keep the mentioned services and enable them >> by >> adding the service definition. Similar services already in system for >> party, facility, order, with contact mech (postal address/telecom number) >> creation. The code is simply created the work effort with postal >> address/telecom number, which seems to be genetic use case for >> intersection >> relations. >> >> Rishi Solanki >> Sr Manager, Enterprise Software Development >> HotWax Systems Pvt. Ltd. >> Direct: +91-9893287847 >> http://www.hotwaxsystems.com >> www.hotwax.co >> >> On Tue, Sep 12, 2017 at 3:02 AM, Scott Gray <[email protected] >> > >> wrote: >> >> I'm in favor of keeping them and adding the service definitions. As Taher >>> mentions, these are CRUD services and IMO if we have the table, we should >>> have the set of services allowing management of the data. >>> >>> These implementations are quite synonymous with the FacilityContactMech >>> services, they're only gathering dust because we don't have very advanced >>> work effort management screens and in cases where we do, the work effort >>> is >>> usually bound to a facility where the work will take place so the contact >>> mechs from the facility are used. >>> >>> The moment somebody wants to start doing some event management with >>> OFBiz, >>> these services would become useful. What we have here is a gap in the >>> work >>> effort management screens, not a code bloat problem. >>> >>> Regards >>> Scott >>> >>> On 11 September 2017 at 00:15, Jacques Le Roux < >>> [email protected] >>> >>>> wrote: >>>> Here, it's not about Minilang but only service definitions >>>> >>>> Jacques >>>> >>>> >>>> >>>> Le 10/09/2017 à 13:23, Michael Brohl a écrit : >>>> >>>> I think if we have code which is not used or planned to be used, it >>>>> should be removed. >>>>> >>>>> Since we agreed on deprecating minilang, no code is allowed to be >>>>> commited using minilang with the exception of a bug fix. We shoul be >>>>> >>>> very >>> >>>> restrictive in this case. >>>>> >>>>> I agree that we should first provide a test or convert a mini lang test >>>>> and provide it along with the converted code. This will be an >>>>> >>>> imporvement >>> >>>> on the test coverage and also prove that the converted code works the >>>>> >>>> same >>> >>>> as the minilang version. >>>>> >>>>> Thanks, >>>>> >>>>> Michael >>>>> >>>>> >>>>> Am 01.09.17 um 11:34 schrieb Jacques Le Roux: >>>>> >>>>> There will be years before we rewrite all the Minilang services. It's >>>>>> just an hour to revive these services, I can do it >>>>>> >>>>>> It will then be easy to rewrite them with all the others. >>>>>> >>>>>> BTW I fear this moment of massive regressions if we don't put ALL the >>>>>> required tests before doing the rewriting. >>>>>> >>>>>> Jacques >>>>>> >>>>>> >>>>>> Le 01/09/2017 à 11:23, Taher Alkhateeb a écrit : >>>>>> >>>>>> Well .. according to you, the thoughts were put in these services >>>>>>> >>>>>> before >>> >>>> the apache era! I'm not sure if we want such _very_ old code revived. >>>>>>> >>>>>> I >>> >>>> also think the community is capable enough of rewriting basic CRUD >>>>>>> services. There is no magic or incredibly sophisticated algorithms in >>>>>>> this >>>>>>> code. Juat another CRUD. >>>>>>> >>>>>>> On Sep 1, 2017 12:16 PM, "Jacques Le Roux" < >>>>>>> [email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> I disagree, some thoughts were put in these services. They are in >>>>>>> Minilang >>>>>>> admittedly, but we can still keep them and transform them later and >>>>>>> anway >>>>>>> we have tons of Minilang services. >>>>>>> >>>>>>> I'm not sure if I found them all but they seem to start from >>>>>>> updateWorkEffortContactMech and end at updateWorkEffortEmailAddress. >>>>>>> They >>>>>>> all use updateWorkEffortContactMech which is only used by them and >>>>>>> has >>>>>>> also >>>>>>> no definition. >>>>>>> >>>>>>> It's 168 lines of Minilang >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>>> >>>>>>> >>>>>>> Le 01/09/2017 à 10:47, Taher Alkhateeb a écrit : >>>>>>> >>>>>>> I agree, we need to remove from the pile not add to it. Deleting is >>>>>>> >>>>>> the >>> >>>> best course of action IMHO. Heck even some of the defined services >>>>>>>> should >>>>>>>> be deleted or heavily refactored for that matter. >>>>>>>> >>>>>>>> On Sep 1, 2017 11:33 AM, "Pierre Smits" <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> If the services are not used, we should ask ourselves whether it >>>>>>>> >>>>>>> would >>> >>>> not >>>>>>>> be best to remove these to keep the code base clean. If need be >>>>>>>> these >>>>>>>> can >>>>>>>> always be brought back from the repo. >>>>>>>> >>>>>>>> Pierre Smits >>>>>>>> >>>>>>>> ORRTIZ.COM <http://www.orrtiz.com> >>>>>>>> OFBiz based solutions & services >>>>>>>> >>>>>>>> OEM: the unaffiliated OFBiz Extensions Marketplace >>>>>>>> http://oem.ofbizci.net/oci-2/ >>>>>>>> >>>>>>>> On Thu, Aug 31, 2017 at 9:52 PM, Jacques Le Roux < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>> Hi Pawan, >>>>>>>> >>>>>>>> These services implementations were created before the Apache era. >>>>>>>>> >>>>>>>>> I suggest we simply create the corresponding definitions and test >>>>>>>>> they are >>>>>>>>> OK >>>>>>>>> >>>>>>>>> Jacques >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Le 31/08/2017 à 19:38, Pawan Verma a écrit : >>>>>>>>> >>>>>>>>> Hello Devs, >>>>>>>>> >>>>>>>>> I just walked through from *WorkEffortSimpleServices.xml* and >>>>>>>>>> >>>>>>>>> noticed >>> >>>> that >>>>>>>>>> >>>>>>>>> some of the simple methods neither have any service definition nor >>>>>>>>> used >>>>>>>>> >>>>>>>>> anywhere. Some of the examples are createWorkEffortPostalAddress, >>>>>>>>>> createWorkEffortTelecomNumber >>>>>>>>>> etc. I was expecting that it must be there. >>>>>>>>>> >>>>>>>>>> So I was just curious to know why it was not there, was it >>>>>>>>>> intentional? >>>>>>>>>> >>>>>>>>>> Or >>>>>>>>>> >>>>>>>>> it will be done under the Minilang deprecation task going on? >>>>>>>>> Please >>>>>>>>> let >>>>>>>>> >>>>>>>>> me >>>>>>>>>> know if anyone has any information on it else I would be more than >>>>>>>>>> happy >>>>>>>>>> to >>>>>>>>>> provide a patch to get it fixed now. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Thanks and Regards, >>>>>>>>>> >>>>>>>>>> *Pawan Verma* | Sr. Enterprise Software Engineer >>>>>>>>>> HotWax Commerce <http://www.hotwax.co/> by HotWax Systems >>>>>>>>>> <http://www.hotwaxsystems.com/> >>>>>>>>>> Plot no. 80, Scheme no. 78 Part ||, Near Brilliant Convention >>>>>>>>>> >>>>>>>>> Center, >>> >>>> Indore, >>>>>>>>>> M.P, India - 452010 >>>>>>>>>> Cell phone: +91 9977705687 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>> >
