Services with no definition and usage

[Pawan Verma]

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: [phone]

[Jacques Le Roux]

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: [phone]
>

[Pierre Smits]

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 <
[hidden email]> 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: [phone]
>>
>>
>

[taher]

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" <[hidden email]> 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 <
[hidden email]> 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: [phone]
>>
>>
>

[Jacques Le Roux]

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" <[hidden email]> 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 <
> [hidden email]> 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: [phone]
>>>
>>>

[taher]

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" <[hidden email]>
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" <[hidden email]> 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 <
> [hidden email]> 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: [phone]
>>>
>>>
>>>

[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" <[hidden email]>
> 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" <[hidden email]> 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 <
>> [hidden email]> 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: [phone]
>>>>
>>>>
>>>>

[Michael Brohl-3]

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"
>> <[hidden email]>
>> 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" <[hidden email]> 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 <
>>> [hidden email]> 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: [phone]
>>>>>
>>>>>
>>>>>
>

[Jacques Le Roux]

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" <[hidden email]>
>>> 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" <[hidden email]> 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 <
>>>> [hidden email]> 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: [phone]
>>>>>>
>>>>>>
>>>>>>
>>
>
>

[Scott Gray-3]

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 <[hidden email]
> 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" <
>>>> [hidden email]>
>>>> 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" <[hidden email]>
>>>>> 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 <
>>>>> [hidden email]> 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: [phone]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>
>>
>

[Rishi Solanki]

+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: [phone]
http://www.hotwaxsystems.com
www.hotwax.co

On Tue, Sep 12, 2017 at 3:02 AM, Scott Gray <[hidden email]>
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 <
> [hidden email]
> > 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" <
> >>>> [hidden email]>
> >>>> 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" <[hidden email]>
> >>>>> 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 <
> >>>>> [hidden email]> 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: [phone]
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>
> >>
> >>
> >
>

[Jacques Le Roux]

Thanks to Pawan Verma for reporting, everyone for the discussion and Scott for the detailed argumentation which makes totally sense,

I created https://issues.apache.org/jira/browse/OFBIZ-9708 for that, and will create the definitions

Jacques


Le 11/09/2017 à 23:32, Scott Gray a écrit :

> 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 <[hidden email]
>> 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" <
>>>>> [hidden email]>
>>>>> 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" <[hidden email]>
>>>>>> 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 <
>>>>>> [hidden email]> 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: [phone]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>

[Jacques Le Roux]

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: [phone]
> http://www.hotwaxsystems.com
> www.hotwax.co
>
> On Tue, Sep 12, 2017 at 3:02 AM, Scott Gray <[hidden email]>
> 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 <
>> [hidden email]
>>> 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" <
>>>>>> [hidden email]>
>>>>>> 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" <[hidden email]>
>>>>>>> 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 <
>>>>>>> [hidden email]> 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: [phone]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>

[Pawan Verma]

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: [phone]

On Tue, Sep 12, 2017 at 2:59 PM, Jacques Le Roux <
[hidden email]> 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: [phone]
>> http://www.hotwaxsystems.com
>> www.hotwax.co
>>
>> On Tue, Sep 12, 2017 at 3:02 AM, Scott Gray <[hidden email]
>> >
>> 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 <
>>> [hidden email]
>>>
>>>> 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" <
>>>>>>> [hidden email]>
>>>>>>> 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" <[hidden email]>
>>>>>>>> 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 <
>>>>>>>> [hidden email]> 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: [phone]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>
>