date:20190427

Devs,
I would like to propose the user selection ability for promotion. That
means user can select her own choice of promotion from the list of
promotion applicable to current cart. Right now promotion engine based on
algorithm implemented decide which promotion will be apply to cart from the
list of promotion. For example, if promotion engine find 3 promotion
applicable for the current cart then based on algorithm implemented it
apply the maximum amount value promotion to the cart.

Coming back to proposal with some use cases;

Use Case 1: Promotion engine find three promotions applicable to cart or
item as P1, P2 and P3. And as per algorithm promo engine decide to apply
P1. Now if user want to go with P2 or P3 then she can do that.

Use Case 2: In #1 user can also choose to not take any promotion, remove
the P1 and submit the order without promotion.

Use Case 3: Item1 and item2 will have two promotions common as P1 and P2.
Now user can opt which promotion should applicable to which item. That
means user can apply P1 or P2 on item1 or item2 based on her preference.

Use Case 4: In #3 if user wants then she can opt to select promotion for
one item and can remove promo from other.


Looking forward for valuable feedback on proposal and suggestion on design
from community. Also please feel free to ask for more details on each use
case or on proposal itself.


Thanks!

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P 452010
Linkedin: *Rishi Solanki*

Direct: +91-9893287847

Re: buildbot failure in on ofbizTrunkFrameworkPlugins

I see below JUNIT failure as;
- shipment-tests.testPackingServices : Error trying to begin transaction,
could not process method: The current transaction is marked for rollback,
not beginning a new transaction and aborting current operation; the
rollbackOnly was caused by: Error in Service
[completeAllocationPlanItemByOrderItem]: ERROR : Allocation plan is not
available.: [DEMO10090:1]
- production-run-tests.testCreateProductionRunForOrder : Assertion failed:
( NOT empty[originalOrderItemShipGrpInvRes=null]
-
auto-accounting-transaction-tests-sales.testAcctgTransForSalesOrderShipments
: Error trying to begin transaction, could not process method: The current
transaction is marked for rollback, not beginning a new transaction and
aborting current operation; the rollbackOnly was caused by: Error in
Service [completeAllocationPlanItemByOrderItem]: ERROR : Allocation plan is
not available.: [DEMO10090:1]
- productRentalOrder-test : Warning: no shipments created; could not find
anything ready and needing to be shipped.

These are not related to my commit, will check more and see if can fix
them. Thanks!

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P 452010
Linkedin: *Rishi Solanki*

Direct: +91-9893287847


On Sun, Apr 28, 2019 at 1:49 AM Rishi Solanki 
wrote:

> Jacques,
> I'm looking into this, thanks!
>
> Best Regards,
> --
> *Rishi Solanki* | Sr Manager, Enterprise Software Development
> HotWax Systems 
> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> Indore, M.P 452010
> Linkedin: *Rishi Solanki*
> 
> Direct: +91-9893287847
>
>
> On Sun, Apr 28, 2019 at 12:38 AM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
>> Hi Rishi,
>>
>> I reproduce locally but I don't understand why we have this problem (the
>> concerned data have no relation with the changed component)
>>
>> https://ci.apache.org/projects/ofbiz/logs/trunk/plugins/html/
>>
>> Also I still get the issue when I remove the plugin
>>
>> Thanks
>>
>> Jacques
>>
>> Le 27/04/2019 à 16:26, build...@apache.org a écrit :
>> > The Buildbot has detected a new failure on builder
>> ofbizTrunkFrameworkPlugins while building . Full details are available at:
>> >
>> https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/769
>> >
>> > Buildbot URL: https://ci.apache.org/
>> >
>> > Buildslave for this Build: silvanus_ubuntu
>> >
>> > Build Reason: The AnyBranchScheduler scheduler named
>> 'onTrunkPluginsCommit' triggered this build
>> > Build Source Stamp: [branch ofbiz/ofbiz-plugins/trunk] 1858279
>> > Blamelist: rishi
>> >
>> > BUILD FAILED: failed shell_4
>> >
>> > Sincerely,
>> >   -The Buildbot
>> >
>> >
>> >
>> >
>>
>

Entity data import and export utility in JSON

2019-04-27 Thread Jayansh Shinde

Hi Devs,

Currently, the OFBiz support import/export entity data in XML format.
Nowadays JSON is widely used in industry, we can have support for JSON
format to import and export the data.

Here is the Jira ticket [1] with high level design details.
It will be really helpful for me, if you can share your kind feedback on
this.


[1] https://issues.apache.org/jira/browse/OFBIZ-10966


- Thanks & Regards,
*Jayansh Shinde*  |  Sr. Technical Consultant
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P 452010
Linkedin: *Jayansh Shinde*

Re: buildbot failure in on ofbizTrunkFrameworkPlugins

Jacques,
I'm looking into this, thanks!

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P 452010
Linkedin: *Rishi Solanki*

Direct: +91-9893287847


On Sun, Apr 28, 2019 at 12:38 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Rishi,
>
> I reproduce locally but I don't understand why we have this problem (the
> concerned data have no relation with the changed component)
>
> https://ci.apache.org/projects/ofbiz/logs/trunk/plugins/html/
>
> Also I still get the issue when I remove the plugin
>
> Thanks
>
> Jacques
>
> Le 27/04/2019 à 16:26, build...@apache.org a écrit :
> > The Buildbot has detected a new failure on builder
> ofbizTrunkFrameworkPlugins while building . Full details are available at:
> >
> https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/769
> >
> > Buildbot URL: https://ci.apache.org/
> >
> > Buildslave for this Build: silvanus_ubuntu
> >
> > Build Reason: The AnyBranchScheduler scheduler named
> 'onTrunkPluginsCommit' triggered this build
> > Build Source Stamp: [branch ofbiz/ofbiz-plugins/trunk] 1858279
> > Blamelist: rishi
> >
> > BUILD FAILED: failed shell_4
> >
> > Sincerely,
> >   -The Buildbot
> >
> >
> >
> >
>

Re: buildbot failure in on ofbizTrunkFrameworkPlugins


Hi Rishi,

I reproduce locally but I don't understand why we have this problem (the 
concerned data have no relation with the changed component)

https://ci.apache.org/projects/ofbiz/logs/trunk/plugins/html/

Also I still get the issue when I remove the plugin

Thanks

Jacques

Le 27/04/2019 à 16:26, build...@apache.org a écrit :

The Buildbot has detected a new failure on builder ofbizTrunkFrameworkPlugins 
while building . Full details are available at:
 https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/769

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'onTrunkPluginsCommit' 
triggered this build
Build Source Stamp: [branch ofbiz/ofbiz-plugins/trunk] 1858279
Blamelist: rishi

BUILD FAILED: failed shell_4

Sincerely,
  -The Buildbot

Re: Manufacturer Support In Promotion Engine

2019-04-27 Thread Swapnil M Mane

Hi Rishi,
This seems good addition to me in promotion engine, +1.



- Best Regards,
Swapnil M Mane,
ofbiz.apache.org



On Sat, Apr 27, 2019 at 6:32 PM Rishi Solanki 
wrote:

> Devs,
> Currently promotion engine support all the discount based on party,
> category, party role, party classification, shipping etc.. And promotion
> engine based on the condition decide that the promotion will apply for
> customer purchase over the cart or cart item depending upon the action.
>
> I would like to propose to add support in promotion engine, so that , we
> can add promotion against manufacturing party and should apply to all the
> products manufactured by that party.
>
> For example;
> M1, M2 are two manufacturers.
> M1P1 and M1P2 are products manufactured by M1.
> M2P1 and M2P2 are products manufactured by M2.
>
> Now M1 gives 10% discount on all products M1, and if customer purchase all
> products with quantity ONE.
>
> Assuming all items price is $100. Then CartTotal will be $400 and discount
> amount will be $20. As discount is on M1 products only.
>
> Best Regards,
> --
> *Rishi Solanki* | Sr Manager, Enterprise Software Development
> HotWax Systems 
> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> Indore,
> M.P 452010
> Linkedin: *Rishi Solanki*
> 
> Direct: +91-9893287847
>

Re: Manufacturer Support In Promotion Engine

2019-04-27 Thread Arun Patidar

+1 for adding support for product manufacturer party in promotion.


Kind Regards
---





Arun Patidar



On Sat, Apr 27, 2019 at 6:32 PM Rishi Solanki 
wrote:

> Devs,
> Currently promotion engine support all the discount based on party,
> category, party role, party classification, shipping etc.. And promotion
> engine based on the condition decide that the promotion will apply for
> customer purchase over the cart or cart item depending upon the action.
>
> I would like to propose to add support in promotion engine, so that , we
> can add promotion against manufacturing party and should apply to all the
> products manufactured by that party.
>
> For example;
> M1, M2 are two manufacturers.
> M1P1 and M1P2 are products manufactured by M1.
> M2P1 and M2P2 are products manufactured by M2.
>
> Now M1 gives 10% discount on all products M1, and if customer purchase all
> products with quantity ONE.
>
> Assuming all items price is $100. Then CartTotal will be $400 and discount
> amount will be $20. As discount is on M1 products only.
>
> Best Regards,
> --
> *Rishi Solanki* | Sr Manager, Enterprise Software Development
> HotWax Systems 
> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> Indore,
> M.P 452010
> Linkedin: *Rishi Solanki*
> 
> Direct: +91-9893287847
>

Re: Confusing implementation of the quickAdd feature of e-commerce

Dear Pawan,
In general template should be change. So that we can reuse the data
preparation logic. In case quick add is not working due to some
parameters/context missing then we can think of separate groovy for
ecommerce.
But first we try to reuse the base component logics in plugin component.

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P 452010
Linkedin: *Rishi Solanki*

Direct: +91-9893287847


On Sat, Apr 27, 2019 at 8:44 PM Pawan Verma 
wrote:

> Hello Devs,
>
> While looking into OFBIZ-10978, I found the implementation of the quickAdd
> feature of e-commerce confusing.
>
> What I found under the quickadd screen of ecommerce/CatalogScreens.xml is
> that the UI and data preparation layers are in no sync to each other.
> The QuickAdd.groovy file has the correct implementation of the QuickAdd
> feature (as per the ordermgr component) and the FTL has been designed as
> per e-commerce.
>
> I think we need to take a decision here about the quickadd screen.
>
> Should we make this feature same as quickadd feature of ordermgr?
> OR
> Should we write separate data preparation logic for quickadd feature of
> e-commerce?
>
> Suggestions are most welcome. Thanks!
>
> --
> Kind Regards,
> *Pawan Verma* | Technical Consultant
> HotWax Systems 
> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> Indore,
> M.P. 452010
> Linkedin: *Pawan Verma *
>

Re: Adding fromDate and thruDate in GoodIdentification Entity

Thanks so much, everyone for the valuable feedback.

This indeed increases my understanding.  Based on inputs I will have more
look into this.
For now, I have discarded the ticket OFBIZ-10963 [1], we can reopen it in
the future if required.


[1] https://issues.apache.org/jira/browse/OFBIZ-10963

Kind Regards,
*Aishwary Shrivastava* | Senior Enterprise Software Engineer
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P 452010
Cell phone: +91-8962244998
Linkedin: *Aishwary Shrivastava*



On Sat, Apr 27, 2019 at 8:08 PM Devanshu Vyas 
wrote:

> Agree with Rishi here, and a -1 for the proposal.
>
> The GoodIdentification or the PartyIdentification entity should only
> contain the information to uniquely identify a product(which said by
> everyone, is rarely), so adding fromDate/thruDate will not be much
> beneficial.
> On the other hand, the GoodIdentificationHistory could be a good
> alternative approach to what you are suggesting here.
>
> Thanks & Regards,
> Devanshu Vyas.
>
>
> On Sat, Apr 27, 2019 at 7:22 PM Rishi Solanki 
> wrote:
>
> > -1 for the proposal.
> > For a product identification code will be one of one type. The universal
> > data model book by Len Silverston suggested the same.
> >
> > Best Regards,
> > --
> > *Rishi Solanki* | Sr Manager, Enterprise Software Development
> > HotWax Systems 
> > Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> > Indore,
> > M.P 452010
> > Linkedin: *Rishi Solanki*
> > 
> > Direct: +91-9893287847
> >
> >
> > On Sat, Apr 27, 2019 at 4:03 PM Michael Brohl 
> > wrote:
> >
> > > Hi Aishwary,
> > >
> > > can you elaborate a bit more why a history of GoodIdentification is
> > needed?
> > >
> > > It is used for identification numbers as ISBN, EAN etc.. Those numbers
> > > are rarely subject to change for the same product.
> > >
> > > I don't see any use case for history tracking so I would appreciate
> some
> > > examples.
> > >
> > > Thanks,
> > >
> > > Michael Brohl
> > >
> > > ecomify GmbH - www.ecomify.de
> > >
> > >
> > > Am 27.04.19 um 09:11 schrieb Aishwary Shrivastava:
> > > > Hello, Devs
> > > >
> > > > We should add support of fromDate and thruDate in the
> > GoodIdentification
> > > > entity for tracking and history purpose.
> > > >
> > > > As of now, if we need to update any Good Identification record for a
> > > > product, then we have to replace its value and this history isn't
> > > > maintained.
> > > > It will also enable the user to maintain multiple goodIdentifications
> > of
> > > a
> > > > product.
> > > >
> > > > Best,
> > > > *Aishwary Shrivastava* | HotWax Systems <
> http://www.hotwaxsystems.com/
> > >
> > > >
> > >
> > >
> >
>

Confusing implementation of the quickAdd feature of e-commerce

2019-04-27 Thread Pawan Verma

Hello Devs,

While looking into OFBIZ-10978, I found the implementation of the quickAdd
feature of e-commerce confusing.

What I found under the quickadd screen of ecommerce/CatalogScreens.xml is
that the UI and data preparation layers are in no sync to each other.
The QuickAdd.groovy file has the correct implementation of the QuickAdd
feature (as per the ordermgr component) and the FTL has been designed as
per e-commerce.

I think we need to take a decision here about the quickadd screen.

Should we make this feature same as quickadd feature of ordermgr?
OR
Should we write separate data preparation logic for quickadd feature of
e-commerce?

Suggestions are most welcome. Thanks!

-- 
Kind Regards,
*Pawan Verma* | Technical Consultant
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P. 452010
Linkedin: *Pawan Verma *

Re: Adding fromDate and thruDate in GoodIdentification Entity

Thanks so much, everyone for the valuable feedback.

This indeed increases my understanding.  Based on inputs I will have more
look into this.
For now, I have discarded the ticket OFBIZ-10963 [1], we can reopen it in
the future if required.


[1] https://issues.apache.org/jira/browse/OFBIZ-10963


Kind Regards,
*Aishwary Shrivastava* | Senior Enterprise Software Engineer
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P 452010
Cell phone: +91-8962244998
Linkedin: *Aishwary Shrivastava*



On Sat, Apr 27, 2019 at 7:22 PM Rishi Solanki 
wrote:

> -1 for the proposal.
> For a product identification code will be one of one type. The universal
> data model book by Len Silverston suggested the same.
>
> Best Regards,
> --
> *Rishi Solanki* | Sr Manager, Enterprise Software Development
> HotWax Systems 
> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> Indore,
> M.P 452010
> Linkedin: *Rishi Solanki*
> 
> Direct: +91-9893287847
>
>
> On Sat, Apr 27, 2019 at 4:03 PM Michael Brohl 
> wrote:
>
> > Hi Aishwary,
> >
> > can you elaborate a bit more why a history of GoodIdentification is
> needed?
> >
> > It is used for identification numbers as ISBN, EAN etc.. Those numbers
> > are rarely subject to change for the same product.
> >
> > I don't see any use case for history tracking so I would appreciate some
> > examples.
> >
> > Thanks,
> >
> > Michael Brohl
> >
> > ecomify GmbH - www.ecomify.de
> >
> >
> > Am 27.04.19 um 09:11 schrieb Aishwary Shrivastava:
> > > Hello, Devs
> > >
> > > We should add support of fromDate and thruDate in the
> GoodIdentification
> > > entity for tracking and history purpose.
> > >
> > > As of now, if we need to update any Good Identification record for a
> > > product, then we have to replace its value and this history isn't
> > > maintained.
> > > It will also enable the user to maintain multiple goodIdentifications
> of
> > a
> > > product.
> > >
> > > Best,
> > > *Aishwary Shrivastava* | HotWax Systems  >
> > >
> >
> >
>

Re: Adding fromDate and thruDate in GoodIdentification Entity

Thanks so much, everyone for the valuable feedback.

This indeed increases my understanding.  Based on inputs I will have more
look into this.
For now, I have discarded the ticket OFBIZ-10963 [1], we can reopen it in
the future if required.


[1] https://issues.apache.org/jira/browse/OFBIZ-10963

Best,
*Aishwary Shrivastava*



On Sat, Apr 27, 2019 at 8:08 PM Devanshu Vyas 
wrote:

> Agree with Rishi here, and a -1 for the proposal.
>
> The GoodIdentification or the PartyIdentification entity should only
> contain the information to uniquely identify a product(which said by
> everyone, is rarely), so adding fromDate/thruDate will not be much
> beneficial.
> On the other hand, the GoodIdentificationHistory could be a good
> alternative approach to what you are suggesting here.
>
> Thanks & Regards,
> Devanshu Vyas.
>
>
> On Sat, Apr 27, 2019 at 7:22 PM Rishi Solanki 
> wrote:
>
> > -1 for the proposal.
> > For a product identification code will be one of one type. The universal
> > data model book by Len Silverston suggested the same.
> >
> > Best Regards,
> > --
> > *Rishi Solanki* | Sr Manager, Enterprise Software Development
> > HotWax Systems 
> > Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> > Indore,
> > M.P 452010
> > Linkedin: *Rishi Solanki*
> > 
> > Direct: +91-9893287847
> >
> >
> > On Sat, Apr 27, 2019 at 4:03 PM Michael Brohl 
> > wrote:
> >
> > > Hi Aishwary,
> > >
> > > can you elaborate a bit more why a history of GoodIdentification is
> > needed?
> > >
> > > It is used for identification numbers as ISBN, EAN etc.. Those numbers
> > > are rarely subject to change for the same product.
> > >
> > > I don't see any use case for history tracking so I would appreciate
> some
> > > examples.
> > >
> > > Thanks,
> > >
> > > Michael Brohl
> > >
> > > ecomify GmbH - www.ecomify.de
> > >
> > >
> > > Am 27.04.19 um 09:11 schrieb Aishwary Shrivastava:
> > > > Hello, Devs
> > > >
> > > > We should add support of fromDate and thruDate in the
> > GoodIdentification
> > > > entity for tracking and history purpose.
> > > >
> > > > As of now, if we need to update any Good Identification record for a
> > > > product, then we have to replace its value and this history isn't
> > > > maintained.
> > > > It will also enable the user to maintain multiple goodIdentifications
> > of
> > > a
> > > > product.
> > > >
> > > > Best,
> > > > *Aishwary Shrivastava* | HotWax Systems <
> http://www.hotwaxsystems.com/
> > >
> > > >
> > >
> > >
> >
>

Re: Adding fromDate and thruDate in GoodIdentification Entity

2019-04-27 Thread Devanshu Vyas

Agree with Rishi here, and a -1 for the proposal.

The GoodIdentification or the PartyIdentification entity should only
contain the information to uniquely identify a product(which said by
everyone, is rarely), so adding fromDate/thruDate will not be much
beneficial.
On the other hand, the GoodIdentificationHistory could be a good
alternative approach to what you are suggesting here.

Thanks & Regards,
Devanshu Vyas.


On Sat, Apr 27, 2019 at 7:22 PM Rishi Solanki 
wrote:

> -1 for the proposal.
> For a product identification code will be one of one type. The universal
> data model book by Len Silverston suggested the same.
>
> Best Regards,
> --
> *Rishi Solanki* | Sr Manager, Enterprise Software Development
> HotWax Systems 
> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> Indore,
> M.P 452010
> Linkedin: *Rishi Solanki*
> 
> Direct: +91-9893287847
>
>
> On Sat, Apr 27, 2019 at 4:03 PM Michael Brohl 
> wrote:
>
> > Hi Aishwary,
> >
> > can you elaborate a bit more why a history of GoodIdentification is
> needed?
> >
> > It is used for identification numbers as ISBN, EAN etc.. Those numbers
> > are rarely subject to change for the same product.
> >
> > I don't see any use case for history tracking so I would appreciate some
> > examples.
> >
> > Thanks,
> >
> > Michael Brohl
> >
> > ecomify GmbH - www.ecomify.de
> >
> >
> > Am 27.04.19 um 09:11 schrieb Aishwary Shrivastava:
> > > Hello, Devs
> > >
> > > We should add support of fromDate and thruDate in the
> GoodIdentification
> > > entity for tracking and history purpose.
> > >
> > > As of now, if we need to update any Good Identification record for a
> > > product, then we have to replace its value and this history isn't
> > > maintained.
> > > It will also enable the user to maintain multiple goodIdentifications
> of
> > a
> > > product.
> > >
> > > Best,
> > > *Aishwary Shrivastava* | HotWax Systems  >
> > >
> >
> >
>

Re: Adding fromDate and thruDate in GoodIdentification Entity

-1 for the proposal.
For a product identification code will be one of one type. The universal
data model book by Len Silverston suggested the same.

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P 452010
Linkedin: *Rishi Solanki*

Direct: +91-9893287847


On Sat, Apr 27, 2019 at 4:03 PM Michael Brohl 
wrote:

> Hi Aishwary,
>
> can you elaborate a bit more why a history of GoodIdentification is needed?
>
> It is used for identification numbers as ISBN, EAN etc.. Those numbers
> are rarely subject to change for the same product.
>
> I don't see any use case for history tracking so I would appreciate some
> examples.
>
> Thanks,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 27.04.19 um 09:11 schrieb Aishwary Shrivastava:
> > Hello, Devs
> >
> > We should add support of fromDate and thruDate in the GoodIdentification
> > entity for tracking and history purpose.
> >
> > As of now, if we need to update any Good Identification record for a
> > product, then we have to replace its value and this history isn't
> > maintained.
> > It will also enable the user to maintain multiple goodIdentifications of
> a
> > product.
> >
> > Best,
> > *Aishwary Shrivastava* | HotWax Systems 
> >
>
>

Re: svn commit: r1856609 - in /ofbiz/ofbiz-framework/trunk/applications/order: groovyScripts/test/OrderTests.groovy testdef/data/OrderTestData.xml


Thanks Suraj,

Can't we avoid the duplicated data?

Jacques

Le 27/04/2019 à 15:17, Suraj Khurana a écrit :

Hello team,

I have checked and found that there is a data dependency of
workEffortId=9000 in the test case which is available in plugins/projectmgr
component.

This was the main reason testIntegration was failing without having plugins
component. I will take care of it and add respective dependent data on
order test data file.

I think its making sense now and we don't need to revert now.

--
Best Regards,
Suraj Khurana






On Sat, Apr 27, 2019 at 10:14 AM Suraj Khurana 
wrote:


Sure Jacques,

I am into it today and if got nothing I will remove OrderTests.groovy

--
Best Regards,
Suraj Khurana







On Fri, Apr 26, 2019 at 7:27 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Suraj,

I think that, as suggested by Mathieu, in the meantime it's better to
remove “OrderTests.groovy”

Because it could hide other issues else reported by Buildbot which is our
last safeguard

Thanks

Jacques

Le 25/04/2019 à 10:52, Pierre Smits a écrit :

Hi Mathieu,

Is there a way to move this forward?

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without

privileges)

since 2008*
Apache Steve , committer


On Sat, Apr 20, 2019 at 2:25 PM Pierre Smits 

wrote:

Maybe we should move the load aspects regarding tests out of the test
suite invocations altogether.
The gradlew tasks states:

task testIntegration(group: ofbizServer) {

dependsOn 'ofbiz --test'

description 'Run OFBiz integration tests; You must run loadAll before
running this task'

}


IMO, loading test data could be part of the loadAll task.


Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without

privileges)

since 2008*
Apache Steve , committer


On Sat, Apr 20, 2019 at 1:56 PM Mathieu Lirzin <

mathieu.lir...@nereide.fr>

wrote:


Pierre Smits  writes:


I believe there are a few more where testing individual test-suites

and/or

test-cases are dependent on data loaded in other test-suites and/or

other

test-cases.

I have the same experience.  Moreover another source of fragility is
that tests depend on other tests within a single OFBiz “test-case”,
meaning one test can depend on the data produced by another test.

This

is acceptable for a “simple-method-test” because the order of

execution

is sequential and managed by OFBiz, but this is problematic for JUnit
tests (Groovy, Java) because the order while being deterministic

depends

on the arbitrary order imposed by the JVM.

For example I know for a fact that “QuoteTests.groovy” is suffering

from

that issue.


While I don't hear/read about failing testIntegration (except where

code in

the base is faulty, not when test-suites/cases are faulty), I see

following

failures in test executions in OFBiz against jdk11:


 1. Execution failed for task ':ofbiz --test component=webapp

--test

 suitename=webapptests'.
 2. Execution failed for task ':ofbiz --test component=accounting

--test

 suitename=invoicetest'.
 3. Execution failed for task ':ofbiz --test component=order

--test

 suitename=ordertests'.
 4. Execution failed for task ':ofbiz --test component=product

--test

 suitename=producttests'.

Do we have these test failing also when doing the test execution

against

jdk8?
*Caveat: I recently set this up, so there may still be some

configuration

issues in the jdk11-test setup.. *

I have just tested the “ordertests” test-suite with Icedtea 3.7

(jdk-8)

and it is still failing, so it seems unrelated in that case.

Thanks.

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: svn commit: r1856609 - in /ofbiz/ofbiz-framework/trunk/applications/order: groovyScripts/test/OrderTests.groovy testdef/data/OrderTestData.xml

Hello team,

I have checked and found that there is a data dependency of
workEffortId=9000 in the test case which is available in plugins/projectmgr
component.

This was the main reason testIntegration was failing without having plugins
component. I will take care of it and add respective dependent data on
order test data file.

I think its making sense now and we don't need to revert now.

--
Best Regards,
Suraj Khurana






On Sat, Apr 27, 2019 at 10:14 AM Suraj Khurana 
wrote:

> Sure Jacques,
>
> I am into it today and if got nothing I will remove OrderTests.groovy
>
> --
> Best Regards,
> Suraj Khurana
>
>
>
>
>
>
>
> On Fri, Apr 26, 2019 at 7:27 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
>> Hi Suraj,
>>
>> I think that, as suggested by Mathieu, in the meantime it's better to
>> remove “OrderTests.groovy”
>>
>> Because it could hide other issues else reported by Buildbot which is our
>> last safeguard
>>
>> Thanks
>>
>> Jacques
>>
>> Le 25/04/2019 à 10:52, Pierre Smits a écrit :
>> > Hi Mathieu,
>> >
>> > Is there a way to move this forward?
>> >
>> > Best regards,
>> >
>> > Pierre Smits
>> >
>> > *Apache Trafodion , Vice President*
>> > *Apache Directory , PMC Member*
>> > Apache Incubator , committer
>> > *Apache OFBiz , contributor (without
>> privileges)
>> > since 2008*
>> > Apache Steve , committer
>> >
>> >
>> > On Sat, Apr 20, 2019 at 2:25 PM Pierre Smits 
>> wrote:
>> >
>> >> Maybe we should move the load aspects regarding tests out of the test
>> >> suite invocations altogether.
>> >> The gradlew tasks states:
>> >>
>> >> task testIntegration(group: ofbizServer) {
>> >>
>> >> dependsOn 'ofbiz --test'
>> >>
>> >> description 'Run OFBiz integration tests; You must run loadAll before
>> >> running this task'
>> >>
>> >> }
>> >>
>> >>
>> >> IMO, loading test data could be part of the loadAll task.
>> >>
>> >>
>> >> Best regards,
>> >>
>> >> Pierre Smits
>> >>
>> >> *Apache Trafodion , Vice President*
>> >> *Apache Directory , PMC Member*
>> >> Apache Incubator , committer
>> >> *Apache OFBiz , contributor (without
>> privileges)
>> >> since 2008*
>> >> Apache Steve , committer
>> >>
>> >>
>> >> On Sat, Apr 20, 2019 at 1:56 PM Mathieu Lirzin <
>> mathieu.lir...@nereide.fr>
>> >> wrote:
>> >>
>> >>> Pierre Smits  writes:
>> >>>
>>  I believe there are a few more where testing individual test-suites
>> >>> and/or
>>  test-cases are dependent on data loaded in other test-suites and/or
>> >>> other
>>  test-cases.
>> >>> I have the same experience.  Moreover another source of fragility is
>> >>> that tests depend on other tests within a single OFBiz “test-case”,
>> >>> meaning one test can depend on the data produced by another test.
>> This
>> >>> is acceptable for a “simple-method-test” because the order of
>> execution
>> >>> is sequential and managed by OFBiz, but this is problematic for JUnit
>> >>> tests (Groovy, Java) because the order while being deterministic
>> depends
>> >>> on the arbitrary order imposed by the JVM.
>> >>>
>> >>> For example I know for a fact that “QuoteTests.groovy” is suffering
>> from
>> >>> that issue.
>> >>>
>>  While I don't hear/read about failing testIntegration (except where
>> >>> code in
>>  the base is faulty, not when test-suites/cases are faulty), I see
>> >>> following
>>  failures in test executions in OFBiz against jdk11:
>> 
>> 
>>  1. Execution failed for task ':ofbiz --test component=webapp
>> --test
>>  suitename=webapptests'.
>>  2. Execution failed for task ':ofbiz --test component=accounting
>> >>> --test
>>  suitename=invoicetest'.
>>  3. Execution failed for task ':ofbiz --test component=order
>> --test
>>  suitename=ordertests'.
>>  4. Execution failed for task ':ofbiz --test component=product
>> --test
>>  suitename=producttests'.
>> 
>>  Do we have these test failing also when doing the test execution
>> against
>>  jdk8?
>>  *Caveat: I recently set this up, so there may still be some
>> >>> configuration
>>  issues in the jdk11-test setup.. *
>> >>> I have just tested the “ordertests” test-suite with Icedtea 3.7
>> (jdk-8)
>> >>> and it is still failing, so it seems unrelated in that case.
>> >>>
>> >>> Thanks.
>> >>>
>> >>> --
>> >>> Mathieu Lirzin
>> >>> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>> >>>
>>
>

Manufacturer Support In Promotion Engine

Devs,
Currently promotion engine support all the discount based on party,
category, party role, party classification, shipping etc.. And promotion
engine based on the condition decide that the promotion will apply for
customer purchase over the cart or cart item depending upon the action.

I would like to propose to add support in promotion engine, so that , we
can add promotion against manufacturing party and should apply to all the
products manufactured by that party.

For example;
M1, M2 are two manufacturers.
M1P1 and M1P2 are products manufactured by M1.
M2P1 and M2P2 are products manufactured by M2.

Now M1 gives 10% discount on all products M1, and if customer purchase all
products with quantity ONE.

Assuming all items price is $100. Then CartTotal will be $400 and discount
amount will be $20. As discount is on M1 products only.

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P 452010
Linkedin: *Rishi Solanki*

Direct: +91-9893287847

Re: Unusual logging pattern in Visit Handler


I agree, I see no reason for a too long stack trace (ever)

There are 2 other such instances

Jacques

Le 27/04/2019 à 10:54, Aditya Sharma a écrit :

Here is the link of the image:

https://drive.google.com/file/d/0B27ZznUMte3BbWkxZVdsMU54NVNBTVBuSU9wczVwWVdaOVpn/view?usp=sharing

Thanks and Regards,
*Aditya Sharma* | Enterprise Software Engineer
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore, 
M.P 452010
Linkedin:*Aditya Sharma* 



On Sat, Apr 27, 2019 at 2:15 PM Aditya Sharma mailto:aditya.sha...@hotwaxsystems.com>> wrote:

Hello everyone,

While exploring VisitHander.java, I observed that for logging the pattern 
followed is:

Debug.logInfo(new Exception(), Error Message, module);

due to which we get a long stack trace like this:

image.png



Is there a specific reason for using such a pattern?

I think we should follow the standard pattern only as this may populate log 
files with hefty logs. Though I can only find 3 such traces. I
propose to replace this with the standard pattern:

Debug.logInfo( Error Message, module);

WDYT?

--
Thanks and Regards,
*Aditya Sharma* | Enterprise Software Engineer
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, 
Indore, M.P 452010
Linkedin:*Aditya Sharma*

Re: auto-stamp fields in "entity-engine in webtools". was [[Re: [PROPOSAL] DataModel - Improve Internal Fields injection]]

This is handled by OFBIZ-10959, so we can close this convo and use rather "[PROPOSAL] Enable entity timestamp fields" at
https://markmail.org/message/x7paa3ulljns6awh if ever needed (OK there and in Jira for me)

Jacques

Le 27/04/2019 à 10:29, Jacques Le Roux a écrit :

Thanks Deepak, Suraj,

Yes, that's why I changed the title for this "sub-thread".

Now the question is to agree about having those fields always visible while
searching or it they should show only based on a properties.

Are those of interest also in a production environment?

Maybe they are not present simply because their presence depends on
no-auto-stamp="false". I see no other reasons, notably not a performance reason.

In order to avoid confusion we should create a new thread to discuss those 2
points:

1. Adding them to search fields
2. Having them always visible, not only in dev environment

And if OK create a Jira :)

Jacques

Le 27/04/2019 à 07:40, Suraj Khurana a écrit :

+1, Deepak Dixit.

--
Best Regards,
Suraj Khurana

On Sat, Apr 27, 2019 at 11:05 AM Deepak Dixit
wrote:

I think here we are mixing two different thread.

auto-stamp fields in "entity-engine in webtools"

As I understand in this thread we are talking about only view part of find
generic entity page.
Here we are not talking about adding or removing fields in the entity. If
an entity has stamp filed it should display on webtools find generic page,
as it helps while debugging issues.

Please correct me if I misunderstood anything.

Kind Regards,
Deepak Dixit

On Fri, Apr 26, 2019 at 6:38 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi Pritam, All,

To clarify, in case there is a confusion here. If I'm not wrong Suraj
suggested to add the auto-stamp fields in "entity-engine in webtools".

Like for instance at

https://demo-trunk.ofbiz.apache.org/webtools/control/FindGeneric?entityName=OrderHeader

He did not speak about the 'createdByUserLogin' and
'lastModifiedByUserLogin' fields, please Suraj confirm.

Then I agreed but suggested that it was not a default but implemented

with

a properties to be used during development mostly

Thanks

Jacques

Le 26/04/2019 à 09:00, Pritam Kute a écrit :

IMO, adding 'createdByUserLogin' and 'lastModifiedByUserLogin' fields

every entity is not that useful. Like for example, if we consider the
"Visit" entity, I am not able to find any advantage of having these

fields

in this entity. But, it should be added to some crucial entities like
OrderHeader, OrderItem, ProductPrice(which is already there) to track

the

things like who dod the last price updates or order updates.

Kind Regards,
--
Pritam Kute

On Thu, Apr 25, 2019 at 6:10 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Le 25/04/2019 à 14:17, Suraj Khurana a écrit :

IMO, this is configurable as Jacques pointed, so need to take any

action.

In fact, I would suggest showing these fields while searching for any

data

from entity-engine in webtools, because they are really helpful while
working in a dev environment for debugging.

This could be configurable indeed (less need in production for

instance

default would be false)

Jacques

Just my two cents !!!

--
Best Regards,
Suraj Khurana
TECHNICAL CONSULTANT
mobile: +91 9669750002
email: suraj.khur...@hotwax.co
www.hotwax.co

On Wed, Apr 24, 2019 at 7:14 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

A bit out of subject, just to complete the discussion because nobody

spoke

about.

The entities are defined with no-auto-stamp="false" by default so

it's

possible to change this default.

Of course 'createdByUserLogin' and 'lastModifiedByUserLogin' fields

are

not concerned, it was just to complete

Jacques

Le 24/04/2019 à 13:36, Rishi Solanki a écrit :

Michael,
Thank you for details, all makes sense.

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention

Center,

Indore,

M.P 452010
Linkedin: *Rishi Solanki*

Direct: +91-9893287847

On Wed, Apr 24, 2019 at 4:37 PM Michael Brohl <

michael.br...@ecomify.de>

wrote:

I have not time to elaborate in-depth right now, but just a quick

food

for thought:

Having these fields in every entity *by default* allows detailed
tracking of users which might be unwanted. I know that this is a
sensible topic in companies and affects privacy protection.

I am not sure how the selection of entities with these fields was

done,

maybe others can add insights.

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 24.04.19 um 12:40 schrieb Pierre Smits:

Thanks Michael,

So we should keep those *TxStamp fields.

But what about the second suggestion about having the

'createdByUserLogin'

and 'lastModifiedByUserLogin' fields added to the internal

fields

set?

Best regards,

Pierre Smits

*Apache Trafodion

[DISCUSSION] bi/birt component integration

2019-04-27 Thread Pierre Smits

Hi All,
Currently the various business intelligence (BI) functionalities are
scattered in various components (consider all the overviews regarding
inventory positions, orders/deliveries per customer/supplier) in the
applications folder.

And on the other hand we have the BI component and the Birt component in
the plugins repo. Both of those components have minimal functionality
regarding the business intelligence aspect. But both components are
complimentary:

   1. the bi (short for: Business Intelligence) component initialised the
   OFBiz DWH and has secas and services for copying data from the ofbiz
   database to the ofbizolap database, and
   2. the birt (short for Business Intelligence Report Tool) component is
   intended to deliver on  functionalities to display data overviews in
   various forms (tables, charts, in PDFs, UI widgets, etc)...

Unfortunately, both components lack of love from our community. But a bit
more love would significantly enhances the appeal of OFBiz for (potential)
adopters!

As a result from a customer project, I recently have been working a bit
more on the business intelligence aspect (see recent tickets in [1] and
[2]).

I believe it would be in the best interest of the project to integrate the
functionalities in the Birt component into the BI component. It will send a
clear message to both (potential) adopters and OFBiz developers (both our
contributors, and those not participating here but working on
implementations of adopters), being:

*everything related with business intelligence happens in and comes from
the bi component*.


What do you think?

When we have this, the community can start working on enhancing the single
component to increase its (and inherently OFBiz) appeal:


   1. more entitiy definitions for dimension and fact tables (per [3], from
   the OFBiz related books),
   2. more scheduled services that move data from various ofbiz tables into
   ofbizolap tables,
   3. more UI widgets for displaying data aggregations (tables, charts) in
   the form of portal pages widgets. These portal page widgets can then be
   integrated by our adopters dynamically anywhere in the components of the
   applications folder, e.g through starting/main pages.

[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AND%20component%20%3D%20bi%20AND%20status%20not%20in%20(Closed)
[2]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AND%20component%20%3D%20birt%20AND%20status%20not%20in%20(Closed)
[3] https://www.amazon.com/gp/product/0471200247

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer

Re: Fwd: [PROPOSAL] Enable entity timestamp fields

2019-04-27 Thread Pawan Verma

Hello All,

I have attached a patch for this improvement on the task.

Added include-internal attribute in auto-fields-entity with default value
false. And in FindGeneric.groovy, for list records set it to true.

Please let me know in case of any concern.
-- 
Kind Regards,
*Pawan Verma* | Technical Consultant
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P. 452010
Linkedin: *Pawan Verma *


On Fri, Apr 26, 2019 at 12:31 PM Pawan Verma 
wrote:

> Thank You, everyone, for the inputs. I have logged Jira for this
> https://issues.apache.org/jira/browse/OFBIZ-10959.
> --
> Kind Regards,
> *Pawan Verma* | Technical Consultant
> HotWax Systems 
> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> Indore, M.P. 452010
> Linkedin: *Pawan Verma *
>
>
> On Wed, Apr 24, 2019 at 7:06 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
>> Thanks Guys,
>>
>> Makes sense to me
>>
>> Jacques
>>
>> Le 24/04/2019 à 08:36, Deepak Dixit a écrit :
>> > On Wed, Apr 24, 2019 at 11:58 AM Nicolas Malin <
>> nicolas.ma...@nereide.fr>
>> > wrote:
>> >
>> >> Hello,
>> >>
>> >> On 24/04/2019 08:01, Deepak Dixit wrote:
>> >>> I think it's removed while converting find generic ftl to form widget
>> >>> at OFBIZ-9217
>> >> Yes it's me :)
>> > Was it intentional? If yes what was the reason?
>> >> Yes and not, when I converted it to widget screen I did a choice slim
>> >> code, increase functionality but lose timestamp field on result list.
>> >>> I think it's not intentional, form widget auto-fields-entity exclude
>> the
>> >>> stamp filed, that's why it's not rendering on webtools find generic
>> page.
>> >> If you want to enable it, I suggest to improve auto-fields-entity
>> system
>> >> to support internal fields by parameters
>> >>
>> >
>> > Agree, we can extend auto-fields-entity and add an option to include
>> > internal default value will be false.
>> >
>> > @Pawan, Could you please open a Jira ticket for the same?
>> >
>> > Thanks & Regads
>> > --
>> > Deepak Dixit
>> >
>> >
>> >> Nicolas
>> >>
>> >>> Kind Regards,
>> >>> Deepak Dixit
>> >>>
>> >>>
>> >>> On Fri, Apr 19, 2019 at 10:57 PM Jacques Le Roux <
>> >>> jacques.le.r...@les7arts.com> wrote:
>> >>>
>>  Hi Pawan,
>> 
>>  Seems to make sense, do you know when (by which commit) it has been
>>  removed. Was it intentional? If yes what was the reason?
>> 
>>  Thanks
>> 
>>  Jacques
>> 
>>  Le 19/04/2019 à 18:03, Pawan Verma a écrit :
>> > Hello  Devs,
>> >
>> > While working on a Production environment, I have found that for
>> some
>> > reason entity timestamp fields are disabled at Search Results
>> screen in
>> > Trunk and the previous release branch. It is available at View Value
>> > screen. It was enabled in Release 16.11.
>> >
>> > These fields are helpful for developers to get the idea about when
>> the
>>  row
>> > in the entity is created/updated. Extremely helpful while working on
>> >> the
>> > Production environment.
>> >
>> > I propose to reenable these fields. Views/suggestions are most
>> welcome.
>> >
>>
>

Re: svn commit: r1858243 - in /ofbiz/ofbiz-plugins/trunk: ecommerce/minilang/customer/CustomerEvents.xml example/template/reports/BarCode.fo.ftl

Hello Gil,

Nice catch, I also just noticed that something to commit that I have
already added in code is not available to commit now :)
Anyways, I have also committed related work and both are part of trunk
repository now.

This part is for plugins directory, I think we are good with this.
Still, if you insist, I can revert and split this commit into two different
commits (Three new commits :) )

--
Best Regards,
Suraj Khurana






On Sat, Apr 27, 2019 at 3:25 PM Gil Portenseigne <
gil.portensei...@nereide.fr> wrote:

> Hello Suraj,
>
> You commited something about maritalStatus id this commit. I guess its
> part of another JIRA.
>
> Regards
>
> Le 06:18 - samedi 27 avril, sur...@apache.org a écrit :
> > Author: surajk
> > Date: Sat Apr 27 06:18:17 2019
> > New Revision: 1858243
> >
> > URL: http://svn.apache.org/viewvc?rev=1858243=rev
> > Log:
> > Improved: Use code128 instead of code39 for barcode generation.
> > (OFBIZ-10896)
> > Currently, we are using code39 to generate barcodes but there are some
> limitations of code39 as it only able to encrypt letters from A to Z,
> digits from 0 to 9 and an additional set of special characters – “. $ % + –
> / *”.
> > Thanks Pawan Verma for reporting, analysis and providing the patch.
> Thanks everyone else for providing their inputs during discussion on Dev ML.
> >
> > Modified:
> >
>  ofbiz/ofbiz-plugins/trunk/ecommerce/minilang/customer/CustomerEvents.xml
> > ofbiz/ofbiz-plugins/trunk/example/template/reports/BarCode.fo.ftl
> >
> > Modified:
> ofbiz/ofbiz-plugins/trunk/ecommerce/minilang/customer/CustomerEvents.xml
> > URL:
> http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/ecommerce/minilang/customer/CustomerEvents.xml?rev=1858243=1858242=1858243=diff
> >
> ==
> > ---
> ofbiz/ofbiz-plugins/trunk/ecommerce/minilang/customer/CustomerEvents.xml
> (original)
> > +++
> ofbiz/ofbiz-plugins/trunk/ecommerce/minilang/customer/CustomerEvents.xml
> Sat Apr 27 06:18:17 2019
> > @@ -550,7 +550,7 @@ under the License.
> >  
> >
> >  
> > -
> > +
> >   field="employmentStatusEnumId">
> >  
> >   type="Long"> property="EcommerceYearsWithEmployeeNotValid"/>
> >
> > Modified:
> ofbiz/ofbiz-plugins/trunk/example/template/reports/BarCode.fo.ftl
> > URL:
> http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/example/template/reports/BarCode.fo.ftl?rev=1858243=1858242=1858243=diff
> >
> ==
> > --- ofbiz/ofbiz-plugins/trunk/example/template/reports/BarCode.fo.ftl
> (original)
> > +++ ofbiz/ofbiz-plugins/trunk/example/template/reports/BarCode.fo.ftl
> Sat Apr 27 06:18:17 2019
> > @@ -38,10 +38,10 @@ under the License.
> >  
> >http://barcode4j.krysalis.org/ns;
> >message="${exampleId}">
> > -
> > +
> >0.75in
> >.375mm
> > -
> > +
> >  
> >bottom
> >Helvetica
> >
> >
>

Re: Adding fromDate and thruDate in GoodIdentification Entity

2019-04-27 Thread Michael Brohl


Hi Aishwary,

can you elaborate a bit more why a history of GoodIdentification is needed?

It is used for identification numbers as ISBN, EAN etc.. Those numbers 
are rarely subject to change for the same product.


I don't see any use case for history tracking so I would appreciate some 
examples.


Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 27.04.19 um 09:11 schrieb Aishwary Shrivastava:

Hello, Devs

We should add support of fromDate and thruDate in the GoodIdentification
entity for tracking and history purpose.

As of now, if we need to update any Good Identification record for a
product, then we have to replace its value and this history isn't
maintained.
It will also enable the user to maintain multiple goodIdentifications of a
product.

Best,
*Aishwary Shrivastava* | HotWax Systems 





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Adding fromDate and thruDate in GoodIdentification Entity

2019-04-27 Thread Pritam Kute

+1 Nicolas for maintaining history(if we are going to maintain it) in
separate entity rather than adding fromDate, thruDate to GoodIdentification
table. The purpose of this entity is to store the identification codes for
the product. I don't find any use case where product identifications codes
are frequently changed and need to maintain the history of it.

Kind Regards,
--
Pritam Kute


On Sat, Apr 27, 2019 at 1:17 PM Nicolas Malin 
wrote:

> I'm mixed about that idea.
>
> GoodIdentification like PartyIdentification are useful to search on
> multiple identification shared by other system.  Add life-stamp will add
> complexity the resolve quickly a element. Like a name 99% case it's more
> important to have the current identification list. Maybe a history
> entity (as GoodIdentificationHistory) would be more simple to implement
> and sufficient to your problematic ?
>
> Nicolas
>
> On 27/04/2019 09:22, Arun Patidar wrote:
> > +1, looks good to me.
> >
> > This will require changes in existing CRUD operations related to
> > GoodIdentifications. Also may need migration service or SQL scripts.
> >
> >
> > --
> > Best Regards,
> > Arun Patidar
> > www.hotwax.co
> >
> >
> >
> > On Sat, Apr 27, 2019 at 12:42 PM Aishwary Shrivastava <
> > aishwary.shrivast...@hotwaxsystems.com> wrote:
> >
> >> Hello, Devs
> >>
> >> We should add support of fromDate and thruDate in the GoodIdentification
> >> entity for tracking and history purpose.
> >>
> >> As of now, if we need to update any Good Identification record for a
> >> product, then we have to replace its value and this history isn't
> >> maintained.
> >> It will also enable the user to maintain multiple goodIdentifications
> of a
> >> product.
> >>
> >> Best,
> >> *Aishwary Shrivastava* | HotWax Systems 
> >>
>

Re: Adding fromDate and thruDate in GoodIdentification Entity

Hello Deepak,

We might need to change good identification value anytime due to change in
the third-party system or due to other reason. So to track the previous/old
value we may need to maintain it by date constraint. At a time only one
identification will be active for a product of the same type.

Best,
*Aishwary Shrivastava*


On Sat, Apr 27, 2019 at 1:17 PM Nicolas Malin 
wrote:

> I'm mixed about that idea.
>
> GoodIdentification like PartyIdentification are useful to search on
> multiple identification shared by other system.  Add life-stamp will add
> complexity the resolve quickly a element. Like a name 99% case it's more
> important to have the current identification list. Maybe a history
> entity (as GoodIdentificationHistory) would be more simple to implement
> and sufficient to your problematic ?
>
> Nicolas
>
> On 27/04/2019 09:22, Arun Patidar wrote:
> > +1, looks good to me.
> >
> > This will require changes in existing CRUD operations related to
> > GoodIdentifications. Also may need migration service or SQL scripts.
> >
> >
> > --
> > Best Regards,
> > Arun Patidar
> > www.hotwax.co
> >
> >
> >
> > On Sat, Apr 27, 2019 at 12:42 PM Aishwary Shrivastava <
> > aishwary.shrivast...@hotwaxsystems.com> wrote:
> >
> >> Hello, Devs
> >>
> >> We should add support of fromDate and thruDate in the GoodIdentification
> >> entity for tracking and history purpose.
> >>
> >> As of now, if we need to update any Good Identification record for a
> >> product, then we have to replace its value and this history isn't
> >> maintained.
> >> It will also enable the user to maintain multiple goodIdentifications
> of a
> >> product.
> >>
> >> Best,
> >> *Aishwary Shrivastava* | HotWax Systems 
> >>
>

Re: ReturnContactMech is not used

2019-04-27 Thread Ratnesh Upadhyay

+1 Good catch, Vaibhav!

Thanks!

Regards,
Ratnesh Upadhyay

On Sat, Apr 27, 2019 at 12:33 PM Vaibhav Jain <
vaibhav.j...@hotwaxsystems.com> wrote:

> *Bottom line:*
> ReturnContactMech entity is not used in OFBiz
>
> *Story:*
> ContactMech of parties involved in an order is captured in OrderContactMech
> entity.
> ContactMech of parties involved in the return is not captured in
> ReturnContactMech entity.
>
> Kind Regards,
> *Vaibhav Jain* | Senior Enterprise Software Engineer
> HotWax Systems 
> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> Indore,
> M.P 452010
> Linkedin: *Vaibhav Jain*  >
>
> [image: Mailtrack]
> <
> https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;
> >
> Sender
> notified by
> Mailtrack
> <
> https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;
> >
> 04/27/19,
> 12:23:48 PM

Re: ReturnContactMech is not used

2019-04-27 Thread Vaibhav Jain

Thanks for the quick response.

A JIRA is created to add a workflow to capture the contactMech of
associated parties in the ReturnContactMech entity.

Here is the reference for the same
https://issues.apache.org/jira/browse/OFBIZ-10971

Kind Regards,
*Vaibhav Jain* | Senior Enterprise Software Engineer
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P 452010
Linkedin: *Vaibhav Jain* 


On Sat, Apr 27, 2019 at 2:37 PM Swapnil M Mane 
wrote:

> +1
>
> - Best Regards,
> Swapnil M Mane,
> ofbiz.apache.org
>
>
>
> On Sat, Apr 27, 2019 at 12:33 PM Vaibhav Jain <
> vaibhav.j...@hotwaxsystems.com> wrote:
>
> > *Bottom line:*
> > ReturnContactMech entity is not used in OFBiz
> >
> > *Story:*
> > ContactMech of parties involved in an order is captured in
> OrderContactMech
> > entity.
> > ContactMech of parties involved in the return is not captured in
> > ReturnContactMech entity.
> >
> > Kind Regards,
> > *Vaibhav Jain* | Senior Enterprise Software Engineer
> > HotWax Systems 
> > Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> > Indore,
> > M.P 452010
> > Linkedin: *Vaibhav Jain* <
> https://www.linkedin.com/in/vaibhav-jain-170793/
> > >
> >
> > [image: Mailtrack]
> > <
> >
> https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;
> > >
> > Sender
> > notified by
> > Mailtrack
> > <
> >
> https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;
> > >
> > 04/27/19,
> > 12:23:48 PM
> >
>

Re: svn commit: r1858243 - in /ofbiz/ofbiz-plugins/trunk: ecommerce/minilang/customer/CustomerEvents.xml example/template/reports/BarCode.fo.ftl

2019-04-27 Thread Gil Portenseigne

Hello Suraj,

You commited something about maritalStatus id this commit. I guess its
part of another JIRA.

Regards

Le 06:18 - samedi 27 avril, sur...@apache.org a écrit :
> Author: surajk
> Date: Sat Apr 27 06:18:17 2019
> New Revision: 1858243
> 
> URL: http://svn.apache.org/viewvc?rev=1858243=rev
> Log:
> Improved: Use code128 instead of code39 for barcode generation.
> (OFBIZ-10896)
> Currently, we are using code39 to generate barcodes but there are some 
> limitations of code39 as it only able to encrypt letters from A to Z, digits 
> from 0 to 9 and an additional set of special characters – “. $ % + – / *”.
> Thanks Pawan Verma for reporting, analysis and providing the patch. Thanks 
> everyone else for providing their inputs during discussion on Dev ML.
> 
> Modified:
> ofbiz/ofbiz-plugins/trunk/ecommerce/minilang/customer/CustomerEvents.xml
> ofbiz/ofbiz-plugins/trunk/example/template/reports/BarCode.fo.ftl
> 
> Modified: 
> ofbiz/ofbiz-plugins/trunk/ecommerce/minilang/customer/CustomerEvents.xml
> URL: 
> http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/ecommerce/minilang/customer/CustomerEvents.xml?rev=1858243=1858242=1858243=diff
> ==
> --- ofbiz/ofbiz-plugins/trunk/ecommerce/minilang/customer/CustomerEvents.xml 
> (original)
> +++ ofbiz/ofbiz-plugins/trunk/ecommerce/minilang/customer/CustomerEvents.xml 
> Sat Apr 27 06:18:17 2019
> @@ -550,7 +550,7 @@ under the License.
>  
>  
>  
> -
> +
>  
>  
>   type="Long"> property="EcommerceYearsWithEmployeeNotValid"/>
> 
> Modified: ofbiz/ofbiz-plugins/trunk/example/template/reports/BarCode.fo.ftl
> URL: 
> http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/example/template/reports/BarCode.fo.ftl?rev=1858243=1858242=1858243=diff
> ==
> --- ofbiz/ofbiz-plugins/trunk/example/template/reports/BarCode.fo.ftl 
> (original)
> +++ ofbiz/ofbiz-plugins/trunk/example/template/reports/BarCode.fo.ftl Sat Apr 
> 27 06:18:17 2019
> @@ -38,10 +38,10 @@ under the License.
>  
>http://barcode4j.krysalis.org/ns;
>message="${exampleId}">
> -
> +
>0.75in
>.375mm
> -
> +
>  
>bottom
>Helvetica
> 
>

Re: ReturnContactMech is not used

2019-04-27 Thread Swapnil M Mane

+1

- Best Regards,
Swapnil M Mane,
ofbiz.apache.org



On Sat, Apr 27, 2019 at 12:33 PM Vaibhav Jain <
vaibhav.j...@hotwaxsystems.com> wrote:

> *Bottom line:*
> ReturnContactMech entity is not used in OFBiz
>
> *Story:*
> ContactMech of parties involved in an order is captured in OrderContactMech
> entity.
> ContactMech of parties involved in the return is not captured in
> ReturnContactMech entity.
>
> Kind Regards,
> *Vaibhav Jain* | Senior Enterprise Software Engineer
> HotWax Systems 
> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> Indore,
> M.P 452010
> Linkedin: *Vaibhav Jain*  >
>
> [image: Mailtrack]
> <
> https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;
> >
> Sender
> notified by
> Mailtrack
> <
> https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;
> >
> 04/27/19,
> 12:23:48 PM
>

Re: Unusual logging pattern in Visit Handler

2019-04-27 Thread Aditya Sharma

Here is the link of the image:

https://drive.google.com/file/d/0B27ZznUMte3BbWkxZVdsMU54NVNBTVBuSU9wczVwWVdaOVpn/view?usp=sharing

Thanks and Regards,
*Aditya Sharma* | Enterprise Software Engineer
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P 452010
Linkedin: *Aditya Sharma* 



On Sat, Apr 27, 2019 at 2:15 PM Aditya Sharma <
aditya.sha...@hotwaxsystems.com> wrote:

> Hello everyone,
>
> While exploring VisitHander.java, I observed that for logging the pattern
> followed is:
>
> Debug.logInfo(new Exception(), Error Message, module);
>
> due to which we get a long stack trace like this:
>
> [image: image.png]
>
>
>
> Is there a specific reason for using such a pattern?
>
> I think we should follow the standard pattern only as this may populate
> log files with hefty logs. Though I can only find 3 such traces. I propose
> to replace this with the standard pattern:
>
> Debug.logInfo( Error Message, module);
>
> WDYT?
>
> --
> Thanks and Regards,
> *Aditya Sharma* | Enterprise Software Engineer
> HotWax Systems 
> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> Indore, M.P 452010
> Linkedin: *Aditya Sharma* 
>
>

Unusual logging pattern in Visit Handler

2019-04-27 Thread Aditya Sharma

Hello everyone,

While exploring VisitHander.java, I observed that for logging the pattern
followed is:

Debug.logInfo(new Exception(), Error Message, module);

due to which we get a long stack trace like this:

[image: image.png]



Is there a specific reason for using such a pattern?

I think we should follow the standard pattern only as this may populate log
files with hefty logs. Though I can only find 3 such traces. I propose to
replace this with the standard pattern:

Debug.logInfo( Error Message, module);

WDYT?

--
Thanks and Regards,
*Aditya Sharma* | Enterprise Software Engineer
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P 452010
Linkedin: *Aditya Sharma*

Re: ReturnContactMech is not used


Le 27/04/2019 à 09:41, Pawan Verma a écrit :

Yes, We should add a workflow to add associated parties of return in
ReturnContactMech entity.

+1

Jacques

Re: auto-stamp fields in "entity-engine in webtools". was [[Re: [PROPOSAL] DataModel - Improve Internal Fields injection]]


Thanks Deepak, Suraj,

Yes, that's why I changed the title for this "sub-thread".

Now the question is to agree about having those fields always visible while 
searching or it they should show only based on a properties.

Are those of interest also in a production environment?

Maybe they are not present simply because their presence depends on 
no-auto-stamp="false". I see no other reasons, notably not a performance reason.

In order to avoid confusion we should create a new thread to discuss those 2 
points:

1. Adding them to search fields
2. Having them always visible, not only in dev environment

And if OK create a Jira :)

Jacques

Le 27/04/2019 à 07:40, Suraj Khurana a écrit :

+1, Deepak Dixit.

--
Best Regards,
Suraj Khurana







On Sat, Apr 27, 2019 at 11:05 AM Deepak Dixit 
wrote:


I think here we are mixing two different thread.


auto-stamp fields in "entity-engine in webtools"

As I understand in this thread we are talking about only view part of find
generic entity page.
Here we are not talking about adding or removing fields in the entity. If
an entity has stamp filed it should display on webtools find generic page,
as it helps while debugging issues.

Please correct me if I misunderstood anything.

Kind Regards,
Deepak Dixit


On Fri, Apr 26, 2019 at 6:38 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Pritam, All,

To clarify, in case there is a confusion here. If I'm not wrong Suraj
suggested to add the auto-stamp fields in "entity-engine in webtools".

Like for instance at


https://demo-trunk.ofbiz.apache.org/webtools/control/FindGeneric?entityName=OrderHeader

He did not speak about the 'createdByUserLogin' and
'lastModifiedByUserLogin' fields, please Suraj confirm.

Then I agreed but suggested that it was not a default but implemented

with

a properties to be used during development mostly

Thanks

Jacques

Le 26/04/2019 à 09:00, Pritam Kute a écrit :

IMO, adding 'createdByUserLogin' and 'lastModifiedByUserLogin' fields

to

every entity is not that useful. Like for example, if we consider the
"Visit" entity, I am not able to find any advantage of having these

fields

in this entity. But, it should be added to some crucial entities like
OrderHeader, OrderItem, ProductPrice(which is already there) to track

the

things like who dod the last price updates or order updates.

Kind Regards,
--
Pritam Kute


On Thu, Apr 25, 2019 at 6:10 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Le 25/04/2019 à 14:17, Suraj Khurana a écrit :

IMO, this is configurable as Jacques pointed, so need to take any

action.

In fact, I would suggest showing these fields while searching for any

data

from entity-engine in webtools, because they are really helpful while
working in a dev environment for debugging.

This could be configurable indeed (less need in production for

instance

so

default would be false)

Jacques


Just my two cents !!!

--
Best Regards,
Suraj Khurana
TECHNICAL CONSULTANT
mobile: +91 9669750002
email: suraj.khur...@hotwax.co
www.hotwax.co






On Wed, Apr 24, 2019 at 7:14 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


A bit out of subject, just to complete the discussion because nobody

spoke

about.

The entities are defined with no-auto-stamp="false" by default so

it's

possible to change this default.

Of course 'createdByUserLogin' and 'lastModifiedByUserLogin' fields

are

not concerned, it was just to complete

Jacques


Le 24/04/2019 à 13:36, Rishi Solanki a écrit :

Michael,
Thank you for details, all makes sense.

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention

Center,

Indore,

M.P 452010
Linkedin: *Rishi Solanki*

Direct: +91-9893287847


On Wed, Apr 24, 2019 at 4:37 PM Michael Brohl <

michael.br...@ecomify.de>

wrote:


I have not time to elaborate in-depth right now, but just a quick

food

for thought:

Having these fields in every entity *by default* allows detailed
tracking of users which might be unwanted. I know that this is a
sensible topic in companies and affects privacy protection.

I am not sure how the selection of entities with these fields was

done,

maybe others can add insights.

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 24.04.19 um 12:40 schrieb Pierre Smits:

Thanks Michael,

So we should keep those *TxStamp fields.

But what about the second suggestion about having the

'createdByUserLogin'

and 'lastModifiedByUserLogin'  fields added to the internal

fields

set?

Best regards,

Pierre Smits

*Apache Trafodion , Vice

President*

*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without

privileges)

since 2008*
Apache Steve

Re: ReturnContactMech is not used

+1.

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P 452010
Linkedin: *Rishi Solanki*

Direct: +91-9893287847


On Sat, Apr 27, 2019 at 1:19 PM Pawan Verma 
wrote:

> Yes, We should add a workflow to add associated parties of return in
> ReturnContactMech entity.
>
> --
> Kind Regards,
> *Pawan Verma* | Technical Consultant
> HotWax Systems 
> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> Indore,
> M.P. 452010
> Linkedin: *Pawan Verma *
>
>
> On Sat, Apr 27, 2019 at 12:55 PM Suraj Khurana 
> wrote:
>
> > +1.
> > This could be a nice improvement to have.
> >
> > --
> > Best Regards,
> > Suraj Khurana
> >
> >
> >
> >
> >
> >
> >
> > On Sat, Apr 27, 2019 at 12:33 PM Vaibhav Jain <
> > vaibhav.j...@hotwaxsystems.com> wrote:
> >
> > > *Bottom line:*
> > > ReturnContactMech entity is not used in OFBiz
> > >
> > > *Story:*
> > > ContactMech of parties involved in an order is captured in
> > OrderContactMech
> > > entity.
> > > ContactMech of parties involved in the return is not captured in
> > > ReturnContactMech entity.
> > >
> > > Kind Regards,
> > > *Vaibhav Jain* | Senior Enterprise Software Engineer
> > > HotWax Systems 
> > > Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> > > Indore,
> > > M.P 452010
> > > Linkedin: *Vaibhav Jain* <
> > https://www.linkedin.com/in/vaibhav-jain-170793/
> > > >
> > >
> > > [image: Mailtrack]
> > > <
> > >
> >
> https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;
> > > >
> > > Sender
> > > notified by
> > > Mailtrack
> > > <
> > >
> >
> https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;
> > > >
> > > 04/27/19,
> > > 12:23:48 PM
> > >
> >
>

Re: ReturnContactMech is not used

2019-04-27 Thread Pawan Verma

Yes, We should add a workflow to add associated parties of return in
ReturnContactMech entity.

-- 
Kind Regards,
*Pawan Verma* | Technical Consultant
HotWax Systems 
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P. 452010
Linkedin: *Pawan Verma *


On Sat, Apr 27, 2019 at 12:55 PM Suraj Khurana 
wrote:

> +1.
> This could be a nice improvement to have.
>
> --
> Best Regards,
> Suraj Khurana
>
>
>
>
>
>
>
> On Sat, Apr 27, 2019 at 12:33 PM Vaibhav Jain <
> vaibhav.j...@hotwaxsystems.com> wrote:
>
> > *Bottom line:*
> > ReturnContactMech entity is not used in OFBiz
> >
> > *Story:*
> > ContactMech of parties involved in an order is captured in
> OrderContactMech
> > entity.
> > ContactMech of parties involved in the return is not captured in
> > ReturnContactMech entity.
> >
> > Kind Regards,
> > *Vaibhav Jain* | Senior Enterprise Software Engineer
> > HotWax Systems 
> > Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> > Indore,
> > M.P 452010
> > Linkedin: *Vaibhav Jain* <
> https://www.linkedin.com/in/vaibhav-jain-170793/
> > >
> >
> > [image: Mailtrack]
> > <
> >
> https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;
> > >
> > Sender
> > notified by
> > Mailtrack
> > <
> >
> https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;
> > >
> > 04/27/19,
> > 12:23:48 PM
> >
>

Re: Adding fromDate and thruDate in GoodIdentification Entity

2019-04-27 Thread Nicolas Malin


I'm mixed about that idea.

GoodIdentification like PartyIdentification are useful to search on 
multiple identification shared by other system.  Add life-stamp will add 
complexity the resolve quickly a element. Like a name 99% case it's more 
important to have the current identification list. Maybe a history 
entity (as GoodIdentificationHistory) would be more simple to implement 
and sufficient to your problematic ?


Nicolas

On 27/04/2019 09:22, Arun Patidar wrote:

+1, looks good to me.

This will require changes in existing CRUD operations related to
GoodIdentifications. Also may need migration service or SQL scripts.


--
Best Regards,
Arun Patidar
www.hotwax.co



On Sat, Apr 27, 2019 at 12:42 PM Aishwary Shrivastava <
aishwary.shrivast...@hotwaxsystems.com> wrote:


Hello, Devs

We should add support of fromDate and thruDate in the GoodIdentification
entity for tracking and history purpose.

As of now, if we need to update any Good Identification record for a
product, then we have to replace its value and this history isn't
maintained.
It will also enable the user to maintain multiple goodIdentifications of a
product.

Best,
*Aishwary Shrivastava* | HotWax Systems

Re: Adding fromDate and thruDate in GoodIdentification Entity

2019-04-27 Thread Arun Patidar

+1, looks good to me.

This will require changes in existing CRUD operations related to
GoodIdentifications. Also may need migration service or SQL scripts.


--
Best Regards,
Arun Patidar
www.hotwax.co



On Sat, Apr 27, 2019 at 12:42 PM Aishwary Shrivastava <
aishwary.shrivast...@hotwaxsystems.com> wrote:

> Hello, Devs
>
> We should add support of fromDate and thruDate in the GoodIdentification
> entity for tracking and history purpose.
>
> As of now, if we need to update any Good Identification record for a
> product, then we have to replace its value and this history isn't
> maintained.
> It will also enable the user to maintain multiple goodIdentifications of a
> product.
>
> Best,
> *Aishwary Shrivastava* | HotWax Systems 
>

Re: Adding fromDate and thruDate in GoodIdentification Entity

2019-04-27 Thread Deepak Dixit

Hi Aishwarys,

On Sat, Apr 27, 2019 at 12:42 PM Aishwary Shrivastava <
aishwary.shrivast...@hotwaxsystems.com> wrote:

> Hello, Devs
>
> We should add support of fromDate and thruDate in the GoodIdentification
> entity for tracking and history purpose.
>
>
Sounds good.




> As of now, if we need to update any Good Identification record for a
> product, then we have to replace its value and this history isn't
> maintained.
>

Could you please give us an example of this use case? Why and when we have
to update the Good Identification?


> It will also enable the user to maintain multiple goodIdentifications of a
> product.
>

I am not sure why we need to maintain multiple goodIdentifications of the
same type.


Kind Regards,
Deepak Dixit



> Best,
> *Aishwary Shrivastava* | HotWax Systems 
>

Re: ReturnContactMech is not used

+1.
This could be a nice improvement to have.

--
Best Regards,
Suraj Khurana







On Sat, Apr 27, 2019 at 12:33 PM Vaibhav Jain <
vaibhav.j...@hotwaxsystems.com> wrote:

> *Bottom line:*
> ReturnContactMech entity is not used in OFBiz
>
> *Story:*
> ContactMech of parties involved in an order is captured in OrderContactMech
> entity.
> ContactMech of parties involved in the return is not captured in
> ReturnContactMech entity.
>
> Kind Regards,
> *Vaibhav Jain* | Senior Enterprise Software Engineer
> HotWax Systems 
> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> Indore,
> M.P 452010
> Linkedin: *Vaibhav Jain*  >
>
> [image: Mailtrack]
> <
> https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;
> >
> Sender
> notified by
> Mailtrack
> <
> https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;
> >
> 04/27/19,
> 12:23:48 PM
>

Re: Adding fromDate and thruDate in GoodIdentification Entity

+1 with fromDate as part of primary key.

--
Best Regards,
Suraj Khurana







On Sat, Apr 27, 2019 at 12:42 PM Aishwary Shrivastava <
aishwary.shrivast...@hotwaxsystems.com> wrote:

> Hello, Devs
>
> We should add support of fromDate and thruDate in the GoodIdentification
> entity for tracking and history purpose.
>
> As of now, if we need to update any Good Identification record for a
> product, then we have to replace its value and this history isn't
> maintained.
> It will also enable the user to maintain multiple goodIdentifications of a
> product.
>
> Best,
> *Aishwary Shrivastava* | HotWax Systems 
>

Adding fromDate and thruDate in GoodIdentification Entity