+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 <scott.g...@hotwaxsystems.com> 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 < > jacques.le.r...@les7arts.com > > 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" < > >>>> jacques.le.r...@les7arts.com> > >>>> 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" <pierre.sm...@gmail.com> > >>>>> 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 < > >>>>> jacques.le.r...@les7arts.com> 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 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>> > >> > >> > > >
