Re: [PROPOSAL] DataModel - Improve entities using fromPartyId & toPartyId

2019-05-20 Thread Jacques Le Roux

Hi Pierre,

In the DMRB, Silverstein mentions from and to party fields for PARTY 
RELATIONSHIPS, SHIPMENTs, FIXED ASSET ASSIGNMENTs, and PAYMENT ACCTG TRANSs 
entities

In the "Logical Data Model Entities and Attributes Listing" section there is 
actually from and to party fields for the following entities:

AGREEMENT
CUSTOMER RELATIONSHIP
EMPLOYMENT
ORGANIZATION CONTACT RELATIONSHIP
PARTY RELATIONSHIP
PAY HISTORY

--

In OFBiz we have from and to party fields for the following entities:

Invoice
InvoiceItemAssoc
Payment
Employment
PartyBenefit
PayHistory
UnemploymentClaim
Agreement
AgreementEmploymentAppl
CommunicationEvent
PartyInvitation
PartyRelationship
Shipment
PartyRelationship
PartyInvitation

Each entity in OFBiz which has from and to party fields has also roleTypeIdFrom 
and roleTypeIdTo.

You lastly wrote:

   However there are a (quite a) few entities that defy these 1-on-1
   relationships (between internal party and the object, and the external
   party and the object), like:

   - OrderHeader: neither partyIdFrom nor partyIdTo
   - Quote: neither partyIdFrom nor partyIdTo but having a partyId field
   - CustRequest: only having fromPartyid (plus its role
   - Subscription: having originatedFromPartyId (plus the role) and partyId
   - ReorderGuideline: having partyId (plus the role)

   And I am confident I am missing a few.

   In order to simplify processes for capturing the main parties in various
   entity records I propose to realign these (master) entities to ensure that
   both the primary internal and external parties (and their primary roles)
   are captured.

In OFBiz we have also 29 '*role" entities (I let you check searching for '/
1?498: 
marketing-entitymodel.xml (3 matches)
125: 
3?007: Note that both models don't intersect (eg CASE ROLE, ORGANIZATION ROLE, PERSON ROLE - redundant with PARTY ROLE IMO-, REQUEST ROLE - did not find 
CustRequestRole mentioned by Rishi -, "misses" in OFBiz data model)


AGREEMENT ROLE
BILLING ACCOUNT ROLE
BUDGET ROLE
CASE ROLE
COMMUNICATION EVENT ROLE
FINANCIAL ACCOUNT ROLE
INVOICE ROLE
ITEM ISSUANCE ROLE
ORDER ITEM ROLE
ORDER ROLE
ORGANIZATION ROLE
PARTY ROLE
PERSON ROLE
QUOTE ROLE
REQUEST ROLE
REQUIREMENT ROLE
SHIPMENT RECEIPT ROLE
TIMESHEET ROLE
VALID CONTACT MECHANISM ROLE

I think we should consider Scott's proposition:

   I'd prefer to see us move in the other
   direction and remove top-level entitiy from/to fields if there is an
   existing *Role entity in order to simplify the datamodel while maintaining
   flexibility.

Even if I don't think it's a priority task as it also implies a lot of changes 
and work

My 2 cts

Jacques

Le 20/05/2019 à 10:27, Scott Gray a écrit :

In my experience very few things in the business world are immutable.
Dated *Role entities enhance flexibility and provide a decent audit trail
for the inevitable changes that businesses need to support (I placed this
order against the wrong customer, customer A has bought customer B so we
need to transfer over all existing orders).

Having *Role entities alongside from/to partyIds (or any time there's
multiple ways to link two objects) leads to confusion, behavioral
inconsistencies and a complicated code base.

For example why is there an originFacilityId on OrderHeader when there is a
facilityId field on OrderItemShipGroup as well?  That's just an example I
noticed recently, I've noticed a bunch over the years and they only serve
to complicate development.

I'm sure there are scenarios where from/to partyIds are suitable (like
PartyRelationship) but I disagree with a broad proposal such as this to
apply them to a range of entities.  I'd prefer to see us move in the other
direction and remove top-level entitiy from/to fields if there is an
existing *Role entity in order to simplify the datamodel while maintaining
flexibility.

Regards
Scott

On Sun, 19 May 2019 at 22:57, Pierre Smits  wrote:


I totally agree with

leave the entity designs well designed and solid


The Unified Data Model has been designed well and is still withstanding the
test of time. This design is the reason why our project opted to have this
at its core for all the business applications.
It is the digressions from (even more so the explanation regarding the
applicability of those digressions) that have us going through hoops to
ensure that what is used where, when, how and why remains consistent. From
persistence, through service/functions and UI to documentation.

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 Sun, May 19, 

Re: OFBiz Statistics in monthly blog entries

2019-05-20 Thread Jacques Le Roux

That's quite interesting thanks Pierre.

Should we not get rid of "Average Time in Status: OFBiz"? Seems useless, no 
data there.

Jacques

Le 20/05/2019 à 08:16, Aditya Sharma a écrit :

Indeed! Looks Great. Thanks Pierre for your efforts. We will see to it if
we can utilize some information from it.

Thanks and Regards,
*Aditya Sharma* | Enterprise Software Engineer
HotWax Systems <http://www.hotwaxsystems.com/>
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P 452010
Linkedin: *Aditya Sharma* <https://www.linkedin.com/in/aditya-p-sharma/>



On Mon, May 20, 2019 at 10:30 AM Pritam Kute 
wrote:


That's cool Pierre. Thanks for your efforts.

Kind Regards,
--
Pritam Kute


On Sat, May 18, 2019 at 12:37 PM Pierre Smits 
wrote:


Hi all,

I finally got an OFBiz dashboard working. See


https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12310603

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without

privileges)

since 2008*
Apache Steve <https://steve.apache.org>, committer


On Mon, May 6, 2019 at 9:22 AM Aditya Sharma 
wrote:


Thank you Suraj for your input!

Thank you Jacques for sharing the insights.

Thank you Pierre for your inputs. Initially, we will be adding basic
statistics (just like February 2018 blog) but definitely, we will look

into

the possibility of enriching it with more useful information.

Thank you Sharan for your inputs. We will definitely ensure that it

doesn't

get into that direction. Thank you for your efforts in Kibble. Indeed,

It's

an amazing tool.

--
Thanks and Regards,
Aditya Sharma

On Sun, May 5, 2019 at 4:57 PM Pierre Smits 
wrote:


I truly appreciate initiatives like kibble, the various reporter

functions

and other stuff that work towards showing the health of projects.
Unfortunately these initiatives still have miles to go towards

providing

more meaning. Showing number of tickets opened and closed is nice,

but

that

has been available since the availability of JIRA. Showing the number

of

mails threads started (and or continued) and number of people

involved

is

also nice.

But what I deem more important are the various engagement factors

when

talking about the health of the project, like

- when looking at the number of subscribers per mailing list, how

is

the

diversity (meaning how many PMC Members, Committers,

non-privileged

contributors and others have subscribed);
- when looking the threads per mailing list, how is the diversity

among

the participants - and who are in the top 5/10 of each segment

(again

PMC
Member, Committers, no-privileged contributors)
- When looking at tickets and commits, again showing insights per
diversity segments and interactions between ;


I would say all the data is there, yet very much still in silos.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without

privileges)

since 2008*
Apache Steve <https://steve.apache.org>, committer


On Sun, May 5, 2019 at 12:19 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Le 05/05/2019 à 11:58, Sharan Foga a écrit :

You can probably see that I'm a little Kibble focussed at the

moment:-)

Thanks
Sharan

Yes I know that Sharan, I also follow Kibble

Thanks for your efforts there and elsewhere :)

Jacques




Re: svn commit: r1536324

2019-05-17 Thread Jacques Le Roux

Hi,

If you want to test it's ready. I should commit in a week...

All feedback is appreciated

Jacques

Le 15/05/2019 à 18:43, Jacques Le Roux a écrit :

Hi Scott, Jacopo, All,

I have finally reopened OFBIZ-5254 as I propose a solution for this issue in a 
new patch.

checkStringForHtmlSafeOnly() is still a WIP and can be improved, fortunately by 
using extendible policies

Jacques

Le 03/09/2016 à 11:27, Jacopo Cappellato a écrit :

I am resurrecting this old thread, because I think that Scott's remarks and
concerns to Jacques' commit were valid and the response of Jacques was not
satisfactory: in fact the two tickets Jacques mentioned have been resolved
but the issues that Scott identified in Jacques' commit are still there.
We should consider reverting the commit but my post for now is as a
reminder and to restart the conversation.

Jacopo


On Sat, Dec 28, 2013 at 12:54 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


That's why https://issues.apache.org/jira/browse/OFBIZ-5254 is not
closed, just resolved as incomplete. In other word it's a temporary
unsatisfying solution.
The idea is to continue https://issues.apache.org/jira/browse/OFBIZ-5343
All good wills are welcome

Jacques

On Friday, December 27, 2013 11:20 PM scott.g...@hotwaxmedia.com wrote

"safe" should not have been deprecated.  The input should have just been

cleansed as an interim measure until a better solution

could be found.

Regards
Scott

On 27/12/2013, at 9:37 PM, Jacques Le Roux wrote:


I agree, it's in my long TODO list...

Jacques

On Friday, December 27, 2013 8:43 PM scott.g...@hotwaxmedia.com wrote

This is not a fix, the problem was that "safe" wasn't filtering unsafe

html or returning an error.  Taking all "safe" input

parameters and making them "any" because "safe" wasn't working as

intended is a bit silly to say the least.

Regards
Scott

On 28/10/2013, at 12:12 PM, jler...@apache.org wrote:


Author: jleroux
Date: Mon Oct 28 12:12:43 2013
New Revision: 1536324

URL: http://svn.apache.org/r1536324
Log:
Fixes <
set to "safe">>

https://issues.apache.org/jira/browse/OFBIZ-5254

After r751990, <> and <> are the

same: they do nothing! The only difference is the warning

message from the OWASP Antisamy IntrusionDetector, which is both, as

Christoph noted "giving you a false sense of security" or

as I wrote "disturbing, wrong and useless". So there are no longer

any reasons for differencing "safe" and "any".

This
* Deprecates "safe" (making it clear in the XSD documentation),

keeping only "none" and "any". This is for backward

compatibility, else we could completely remove the misleading "safe".

Note that "none" is the default.

* Replaces in services definition all allow-html="safe" by

allow-html="any"

* Remove from ModelService.java (near line 587) the code which throws

the OWASP Antisamy IntrusionDetector message in log

Modified:
   ofbiz/trunk/applications/accounting/servicedef/

services_agreement.xml

ofbiz/trunk/applications/accounting/servicedef/services_invoice.xml
ofbiz/trunk/applications/content/servicedef/services.xml
ofbiz/trunk/applications/content/servicedef/services_content.xml
ofbiz/trunk/applications/content/servicedef/services_data.xml
ofbiz/trunk/applications/marketing/servicedef/services_

opportunity.xml

ofbiz/trunk/applications/order/servicedef/services.xml
ofbiz/trunk/applications/order/servicedef/services_quote.xml
ofbiz/trunk/applications/order/servicedef/services_request.xml
ofbiz/trunk/applications/party/servicedef/services.xml
ofbiz/trunk/applications/product/servicedef/services.xml
ofbiz/trunk/applications/product/servicedef/services_pricepromo.xml
ofbiz/trunk/applications/workeffort/servicedef/services.xml
ofbiz/trunk/framework/common/servicedef/services.xml
ofbiz/trunk/framework/common/servicedef/services_email.xml
   ofbiz/trunk/framework/service/dtd/services.xsd
ofbiz/trunk/framework/service/src/org/ofbiz/service/

ModelService.java

ofbiz/trunk/specialpurpose/ebaystore/servicedef/services.xml

Modified: ofbiz/trunk/applications/accounting/servicedef/

services_agreement.xml

URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/

accounting/servicedef/services_agreement.xml?rev=
1536324=1536323=1536324=diff

==

---

ofbiz/trunk/applications/accounting/servicedef/services_agreement.xml

(original) +++

ofbiz/trunk/applications/accounting/servicedef/services_agreement.xml

Mon Oct 28 12:12:43 2013 @@ -30,7 +30,7 @@ under the

    License. 
main-action="CREATE"/>

    
    
-    
+    
    
    
engine="simple"

location="component://accounting/script/org/ofbiz/

accounting/agreement/AgreementServices.xml"

invoke="upda

Re: Code Improvement for Groovy

2019-05-16 Thread Jacques Le Roux

Thanks Scott,

Quite helpful!

Jacques

Le 16/05/2019 à 10:12, Scott Gray a écrit :

Hi Pawan

Sounds good, just one point to be careful of:
maxRetry = 0
if (!maxRetry) {
  // Not set, use a default
  maxRetry = -1
}

Because groovy evaluates zero to be false, it wouldn't be possible to set
maxRetry to zero.  So it's best not to use groovy truth for null-checks on
numbers in some cases.  I thought it was worth mentioning since there's a
higher risk of making this mistake when making changes in bulk.

Regards
Scott

On Thu, 16 May 2019 at 00:29, Pawan Verma 
wrote:


Hello Devs,

As we all know, Groovy is a powerful language with great built-in
functions. Groovy Truth[1] is one of them, which is not used properly in
our code base. We have used UtilValidate Class to validate arguments for
Empty or NotEmpty, which can easily be done in groovy with built-in
functionality.

Current Code: if (UtilValidate.isNotEmpty(locations)) { ... }

Groovy Built-in Code: if (locations) { ... }

IMO, We should use this Groovy Truth feature instead of UtilValidate Class.
Please let me know your thoughts on this. Thanks!
[1] - http://groovy-lang.org/semantics.html#Groovy-Truth

--
Kind Regards
Pawan Verma
Technical Consultant
*HotWax Systems*



Re: svn commit: r1536324

2019-05-15 Thread Jacques Le Roux

Hi Scott, Jacopo, All,

I have finally reopened OFBIZ-5254 as I propose a solution for this issue in a 
new patch.

checkStringForHtmlSafeOnly() is still a WIP and can be improved, fortunately by 
using extendible policies

Jacques

Le 03/09/2016 à 11:27, Jacopo Cappellato a écrit :

I am resurrecting this old thread, because I think that Scott's remarks and
concerns to Jacques' commit were valid and the response of Jacques was not
satisfactory: in fact the two tickets Jacques mentioned have been resolved
but the issues that Scott identified in Jacques' commit are still there.
We should consider reverting the commit but my post for now is as a
reminder and to restart the conversation.

Jacopo


On Sat, Dec 28, 2013 at 12:54 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


That's why https://issues.apache.org/jira/browse/OFBIZ-5254 is not
closed, just resolved as incomplete. In other word it's a temporary
unsatisfying solution.
The idea is to continue https://issues.apache.org/jira/browse/OFBIZ-5343
All good wills are welcome

Jacques

On Friday, December 27, 2013 11:20 PM scott.g...@hotwaxmedia.com wrote

"safe" should not have been deprecated.  The input should have just been

cleansed as an interim measure until a better solution

could be found.

Regards
Scott

On 27/12/2013, at 9:37 PM, Jacques Le Roux wrote:


I agree, it's in my long TODO list...

Jacques

On Friday, December 27, 2013 8:43 PM scott.g...@hotwaxmedia.com wrote

This is not a fix, the problem was that "safe" wasn't filtering unsafe

html or returning an error.  Taking all "safe" input

parameters and making them "any" because "safe" wasn't working as

intended is a bit silly to say the least.

Regards
Scott

On 28/10/2013, at 12:12 PM, jler...@apache.org wrote:


Author: jleroux
Date: Mon Oct 28 12:12:43 2013
New Revision: 1536324

URL: http://svn.apache.org/r1536324
Log:
Fixes <
set to "safe">>

https://issues.apache.org/jira/browse/OFBIZ-5254

After r751990, <> and <> are the

same: they do nothing! The only difference is the warning

message from the OWASP Antisamy IntrusionDetector, which is both, as

Christoph noted "giving you a false sense of security" or

as I wrote "disturbing, wrong and useless". So there are no longer

any reasons for differencing "safe" and "any".

This
* Deprecates "safe" (making it clear in the XSD documentation),

keeping only "none" and "any". This is for backward

compatibility, else we could completely remove the misleading "safe".

Note that "none" is the default.

* Replaces in services definition all allow-html="safe" by

allow-html="any"

* Remove from ModelService.java (near line 587) the code which throws

the OWASP Antisamy IntrusionDetector message in log

Modified:
   ofbiz/trunk/applications/accounting/servicedef/

services_agreement.xml

   ofbiz/trunk/applications/accounting/servicedef/services_invoice.xml
   ofbiz/trunk/applications/content/servicedef/services.xml
   ofbiz/trunk/applications/content/servicedef/services_content.xml
   ofbiz/trunk/applications/content/servicedef/services_data.xml
   ofbiz/trunk/applications/marketing/servicedef/services_

opportunity.xml

   ofbiz/trunk/applications/order/servicedef/services.xml
   ofbiz/trunk/applications/order/servicedef/services_quote.xml
   ofbiz/trunk/applications/order/servicedef/services_request.xml
   ofbiz/trunk/applications/party/servicedef/services.xml
   ofbiz/trunk/applications/product/servicedef/services.xml
   ofbiz/trunk/applications/product/servicedef/services_pricepromo.xml
   ofbiz/trunk/applications/workeffort/servicedef/services.xml
   ofbiz/trunk/framework/common/servicedef/services.xml
   ofbiz/trunk/framework/common/servicedef/services_email.xml
   ofbiz/trunk/framework/service/dtd/services.xsd
   ofbiz/trunk/framework/service/src/org/ofbiz/service/

ModelService.java

   ofbiz/trunk/specialpurpose/ebaystore/servicedef/services.xml

Modified: ofbiz/trunk/applications/accounting/servicedef/

services_agreement.xml

URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/

accounting/servicedef/services_agreement.xml?rev=
1536324=1536323=1536324=diff

==

---

ofbiz/trunk/applications/accounting/servicedef/services_agreement.xml

(original) +++

ofbiz/trunk/applications/accounting/servicedef/services_agreement.xml

Mon Oct 28 12:12:43 2013 @@ -30,7 +30,7 @@ under the

License. 
main-action="CREATE"/>



-
+


engine="simple"

location="component://accounting/script/org/ofbiz/

accounting/agreement/AgreementServices.xml"

invoke="updateAgreement" auth="true"> @@ -38,7 +38,7 @@ under the

License.


main-actio

Re: Code Improvement for Groovy

2019-05-15 Thread Jacques Le Roux

Hi Pawan,

Sure, we use that from start a lot. But some don't it seems. A Jira fits with me

Le 15/05/2019 à 14:29, Pawan Verma a écrit :

Hello Devs,

As we all know, Groovy is a powerful language with great built-in
functions. Groovy Truth[1] is one of them, which is not used properly in
our code base. We have used UtilValidate Class to validate arguments for
Empty or NotEmpty, which can easily be done in groovy with built-in
functionality.

Current Code: if (UtilValidate.isNotEmpty(locations)) { ... }

Groovy Built-in Code: if (locations) { ... }

IMO, We should use this Groovy Truth feature instead of UtilValidate Class.
Please let me know your thoughts on this. Thanks!
[1] - http://groovy-lang.org/semantics.html#Groovy-Truth

--
Kind Regards
Pawan Verma
Technical Consultant
*HotWax Systems*



Re: buildbot success in on ofbizTrunkFrameworkPlugins

2019-05-15 Thread Jacques Le Roux

All is OK now :)

Le 15/05/2019 à 12:41, build...@apache.org a écrit :

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

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

Buildslave for this Build: silvanus_ubuntu

Build Reason: forced: by IRC user  (privmsg): forces manual build 
after supposed BuildBot error
Build Source Stamp: HEAD
Blamelist:

Build succeeded!

Sincerely,
  -The Buildbot






Re: Re-designing the ‘Security’ interface

2019-05-15 Thread Jacques Le Roux

Hi Michael,

Thanks for mentioning this which came already on the table several times.

We had this discussion in the past[1] (the last one?). But AFAIK only about 
services and came to this agreement[2]

[1] https://markmail.org/message/gqultbcgbonph5ax

[2] https://s.apache.org/12Uq

I don't remember if we took a decision about how handling Java code.

Your proposition for Java seems the same idea but with longer time. Quoting 
Nicolas

   <>

Please review [2], a consensus would be needed about 1 or 2 releases before removing from code. I expect the same rule for all the code (services or 
what not).


From my side I see no urge to remove and 2 releases after deprecation fits with 
me, ie your proposition here.

Beside generalising, we maybe need to state a clearer rule at [2]...

Thanks

Jacques


Le 11/05/2019 à 09:48, Michael Brohl a écrit :

Hi Mathieau,

We had a discussion about deprecation in the past, I currently do not have the 
time to dig it out.

I think we should start annotating  @deprecated with the date/release branch when it was introduced. User should have at least time over 2 releases 
to move from the old to the new implementation.


In this example, we would introduce the deprecation in trunk, so it will first be "visible" for users in release 19.x. We can then remove the 
deprecated code after the 20.x branch was created.


We should also start to track the deprecatations and consequently remove deprecated code when its time (see above). Currently there are some 
depretations for years, with no tags when they were introduced so we can get better at this.


Just wanted to throws this in for a first feedback, more later.

Thanks for your work!

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 10.05.19 um 17:53 schrieb Mathieu Lirzin:

Hello,

I have opened the ticket OFBIZ-11019 which deprecates a method in the
‘org.apache.ofbiz.security.Security’ interface (see rationale in the
JIRA ticket). If nobody disagree in the meantime, I will commit the
attached patch in a week.

With OFBIZ-11019, near half of the declarations of that interface are
now deprecated which is a symptom a poor initial design.  As a
consequence I think it is time to consider re-designing a new interface
to superseed ‘org.apache.ofbiz.security.Security’.

In order to achieve a better design, it would help if people currently
implementing ‘org.apache.ofbiz.security.Security’ outside of the
framework could describe their use-case and requirements.

If nobody step-up, It will consider that as a sign that this extension
mechanism might not be useful anymore and could be removed.

Thanks in advance.

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





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

2019-05-15 Thread Jacques Le Roux

Hi Suraj,

We crossed on wire :)

Buildbot is still recalcitrant (works locally here too), but I'll force it!

Le 15/05/2019 à 08:17, Suraj Khurana a écrit :

I hope this is fixed after rev #1859267.

--
Best Regards,
Suraj Khurana
Technical Consultant





On Tue, May 14, 2019 at 3:10 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Thanks Rishi,

It seems it's something else now.

I'll also have a look, hopefully today

Jacques

Le 14/05/2019 à 11:22, Rishi Solanki a écrit :

Below are the test cases failure list on running "cleanAll loadAll
testIntegration"
1) [JUNIT (failure)] -

production-run-tests.testCreateProductionRunForOrder

: Assertion failed: ( NOT empty[originalOrderItemShipGrpInvRes=null])
2) [JUNIT (failure)] -
invoice-per-shipment-tests.testInvoicePerShipmentSetFalse : No inventory
reservations available; cannot pack this item! [101]
3) [JUNIT (failure)] - productRentalOrder-test : Warning: no shipments
created; could not find anything ready and needing to be shipped.
4) [JUNIT (failure)] - productServiceOrder-test : Warning: no shipments
created; could not find anything ready and needing to be shipped.
5) [JUNIT (failure)] - configurableServiceOrder-test : Warning: no
shipments created; could not find anything ready and needing to be

shipped.

6) [JUNIT (failure)] -

production-run-tests.testCreateProductionRunForOrder

: Assertion failed: ( NOT empty[originalOrderItemShipGrpInvRes=null])
7) [JUNIT (failure)] -
invoice-per-shipment-tests.testInvoicePerShipmentSetFalse : No inventory
reservations available; cannot pack this item! [101]

Are these are somehow related to message component?

Looking more if data in the message component loaded or not. If found
something then will come back.

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems <http://www.hotwaxsystems.com/>
Linkedin: *Rishi Solanki*
<https://www.linkedin.com/in/rishi-solanki-62271b7/>
Direct: +91-9893287847


On Tue, May 14, 2019 at 2:15 PM Rishi Solanki 
wrote:


Jacques,
I have completed my in hand items and closed the ticket -
https://issues.apache.org/jira/browse/OFBIZ-10457

Nothing is pending in my knowledge also sms settings are disabled by
default. I'll check the tests in case something is not working due to
message component then I will fix that. If you have something handy to

fix

then please share, I will look into it.

I will get back on this soon. Thanks!

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems <http://www.hotwaxsystems.com/>
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
Indore, M.P 452010
Linkedin: *Rishi Solanki*
<https://www.linkedin.com/in/rishi-solanki-62271b7/>
Direct: +91-9893287847


On Mon, May 13, 2019 at 12:56 PM Suraj Khurana 
Thanks, Jacques for details and findings.
I think this thread is now concluded. :)

--
Best Regards,
Suraj Khurana
Technical Consultant





On Mon, May 13, 2019 at 12:48 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Oh, rather better refer to
https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins

So it's at
https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/769

and

the msggateway component

We know Rishi is working on it

Le 13/05/2019 à 06:35, Jacques Le Roux a écrit :

At least I can say that it was before March 30:

https://ci.apache.org/builders/ofbizTrunkFramework?numbuilds=100

Le 13/05/2019 à 06:28, Jacques Le Roux a écrit :

Thanks Suraj,

Unfortunately since another issue came in and it's now harder to

detect.:

 <
[101]>>

Have you an idea?

Thanks

Jacques

Le 11/05/2019 à 13:59, Suraj Khurana a écrit :

Hello,

Done at rev #1859111

--
Best Regards,
Suraj Khurana
Technical Consultant





On Fri, May 10, 2019 at 11:24 AM Suraj Khurana <

suraj.khur...@hotwax.co>

wrote:


Sure Jacques,

I will get this done by the weekend. Please proceed in case of any

blocker

or urgency. I am also inclined with your thoughts.
Thanks in advance !!

--
Best Regards,
Suraj Khurana
Technical Consultant

*HotWax Systems Pvt. Ltd*





On Thu, May 9, 2019 at 3:17 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Suraj,

Any chances? I don't mind duplicated data as I mentioned

answering to

Pierre

Thanks

Jacques

Le 27/04/2019 à 15:36, Jacques Le Roux a écrit :

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 S

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

2019-05-15 Thread Jacques Le Roux

Great news, it's resolved with r1859267

Le 14/05/2019 à 11:38, Jacques Le Roux a écrit :

Thanks Rishi,

It seems it's something else now.

I'll also have a look, hopefully today

Jacques

Le 14/05/2019 à 11:22, Rishi Solanki a écrit :

Below are the test cases failure list on running "cleanAll loadAll
testIntegration"
1) [JUNIT (failure)] - production-run-tests.testCreateProductionRunForOrder
: Assertion failed: ( NOT empty[originalOrderItemShipGrpInvRes=null])
2) [JUNIT (failure)] -
invoice-per-shipment-tests.testInvoicePerShipmentSetFalse : No inventory
reservations available; cannot pack this item! [101]
3) [JUNIT (failure)] - productRentalOrder-test : Warning: no shipments
created; could not find anything ready and needing to be shipped.
4) [JUNIT (failure)] - productServiceOrder-test : Warning: no shipments
created; could not find anything ready and needing to be shipped.
5) [JUNIT (failure)] - configurableServiceOrder-test : Warning: no
shipments created; could not find anything ready and needing to be shipped.
6) [JUNIT (failure)] - production-run-tests.testCreateProductionRunForOrder
: Assertion failed: ( NOT empty[originalOrderItemShipGrpInvRes=null])
7) [JUNIT (failure)] -
invoice-per-shipment-tests.testInvoicePerShipmentSetFalse : No inventory
reservations available; cannot pack this item! [101]

Are these are somehow related to message component?

Looking more if data in the message component loaded or not. If found
something then will come back.

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems <http://www.hotwaxsystems.com/>
Linkedin: *Rishi Solanki*
<https://www.linkedin.com/in/rishi-solanki-62271b7/>
Direct: +91-9893287847


On Tue, May 14, 2019 at 2:15 PM Rishi Solanki 
wrote:


Jacques,
I have completed my in hand items and closed the ticket -
https://issues.apache.org/jira/browse/OFBIZ-10457

Nothing is pending in my knowledge also sms settings are disabled by
default. I'll check the tests in case something is not working due to
message component then I will fix that. If you have something handy to fix
then please share, I will look into it.

I will get back on this soon. Thanks!

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems <http://www.hotwaxsystems.com/>
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
Indore, M.P 452010
Linkedin: *Rishi Solanki*
<https://www.linkedin.com/in/rishi-solanki-62271b7/>
Direct: +91-9893287847


On Mon, May 13, 2019 at 12:56 PM Suraj Khurana 
wrote:


Thanks, Jacques for details and findings.
I think this thread is now concluded. :)

--
Best Regards,
Suraj Khurana
Technical Consultant





On Mon, May 13, 2019 at 12:48 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Oh, rather better refer to
https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins

So it's at
https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/769

and

the msggateway component

We know Rishi is working on it

Le 13/05/2019 à 06:35, Jacques Le Roux a écrit :

At least I can say that it was before March 30:

https://ci.apache.org/builders/ofbizTrunkFramework?numbuilds=100

Le 13/05/2019 à 06:28, Jacques Le Roux a écrit :

Thanks Suraj,

Unfortunately since another issue came in and it's now harder to

detect.:

    <
[101]>>

Have you an idea?

Thanks

Jacques

Le 11/05/2019 à 13:59, Suraj Khurana a écrit :

Hello,

Done at rev #1859111

--
Best Regards,
Suraj Khurana
Technical Consultant





On Fri, May 10, 2019 at 11:24 AM Suraj Khurana <

suraj.khur...@hotwax.co>

wrote:


Sure Jacques,

I will get this done by the weekend. Please proceed in case of any

blocker

or urgency. I am also inclined with your thoughts.
Thanks in advance !!

--
Best Regards,
Suraj Khurana
Technical Consultant

*HotWax Systems Pvt. Ltd*





On Thu, May 9, 2019 at 3:17 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Suraj,

Any chances? I don't mind duplicated data as I mentioned

answering to

Pierre

Thanks

Jacques

Le 27/04/2019 à 15:36, Jacques Le Roux a écrit :

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 <

suraj.khur...@hotwax.co>

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...@l

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

2019-05-14 Thread Jacques Le Roux

Thanks Rishi,

It seems it's something else now.

I'll also have a look, hopefully today

Jacques

Le 14/05/2019 à 11:22, Rishi Solanki a écrit :

Below are the test cases failure list on running "cleanAll loadAll
testIntegration"
1) [JUNIT (failure)] - production-run-tests.testCreateProductionRunForOrder
: Assertion failed: ( NOT empty[originalOrderItemShipGrpInvRes=null])
2) [JUNIT (failure)] -
invoice-per-shipment-tests.testInvoicePerShipmentSetFalse : No inventory
reservations available; cannot pack this item! [101]
3) [JUNIT (failure)] - productRentalOrder-test : Warning: no shipments
created; could not find anything ready and needing to be shipped.
4) [JUNIT (failure)] - productServiceOrder-test : Warning: no shipments
created; could not find anything ready and needing to be shipped.
5) [JUNIT (failure)] - configurableServiceOrder-test : Warning: no
shipments created; could not find anything ready and needing to be shipped.
6) [JUNIT (failure)] - production-run-tests.testCreateProductionRunForOrder
: Assertion failed: ( NOT empty[originalOrderItemShipGrpInvRes=null])
7) [JUNIT (failure)] -
invoice-per-shipment-tests.testInvoicePerShipmentSetFalse : No inventory
reservations available; cannot pack this item! [101]

Are these are somehow related to message component?

Looking more if data in the message component loaded or not. If found
something then will come back.

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems <http://www.hotwaxsystems.com/>
Linkedin: *Rishi Solanki*
<https://www.linkedin.com/in/rishi-solanki-62271b7/>
Direct: +91-9893287847


On Tue, May 14, 2019 at 2:15 PM Rishi Solanki 
wrote:


Jacques,
I have completed my in hand items and closed the ticket -
https://issues.apache.org/jira/browse/OFBIZ-10457

Nothing is pending in my knowledge also sms settings are disabled by
default. I'll check the tests in case something is not working due to
message component then I will fix that. If you have something handy to fix
then please share, I will look into it.

I will get back on this soon. Thanks!

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems <http://www.hotwaxsystems.com/>
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
Indore, M.P 452010
Linkedin: *Rishi Solanki*
<https://www.linkedin.com/in/rishi-solanki-62271b7/>
Direct: +91-9893287847


On Mon, May 13, 2019 at 12:56 PM Suraj Khurana 
wrote:


Thanks, Jacques for details and findings.
I think this thread is now concluded. :)

--
Best Regards,
Suraj Khurana
Technical Consultant





On Mon, May 13, 2019 at 12:48 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Oh, rather better refer to
https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins

So it's at
https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/769

and

the msggateway component

We know Rishi is working on it

Le 13/05/2019 à 06:35, Jacques Le Roux a écrit :

At least I can say that it was before March 30:

https://ci.apache.org/builders/ofbizTrunkFramework?numbuilds=100

Le 13/05/2019 à 06:28, Jacques Le Roux a écrit :

Thanks Suraj,

Unfortunately since another issue came in and it's now harder to

detect.:

<
[101]>>

Have you an idea?

Thanks

Jacques

Le 11/05/2019 à 13:59, Suraj Khurana a écrit :

Hello,

Done at rev #1859111

--
Best Regards,
Suraj Khurana
Technical Consultant





On Fri, May 10, 2019 at 11:24 AM Suraj Khurana <

suraj.khur...@hotwax.co>

wrote:


Sure Jacques,

I will get this done by the weekend. Please proceed in case of any

blocker

or urgency. I am also inclined with your thoughts.
Thanks in advance !!

--
Best Regards,
Suraj Khurana
Technical Consultant

*HotWax Systems Pvt. Ltd*





On Thu, May 9, 2019 at 3:17 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Suraj,

Any chances? I don't mind duplicated data as I mentioned

answering to

Pierre

Thanks

Jacques

Le 27/04/2019 à 15:36, Jacques Le Roux a écrit :

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 <

suraj.khur...@hotwax.co>

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

bette

Re: buildbot failure in on ofbizBranch18FrameworkPlugins

2019-05-13 Thread Jacques Le Roux

Thanks Mathieu,

I also get 2 errors locally (Windows) but they are not the same and I agree changing Javadoc could not be related. It must be an OS quirk locally, 
let's forget it


Le 12/05/2019 à 23:20, Mathieu Lirzin a écrit :

build...@apache.org writes:


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

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

Buildslave for this Build: silvanus_ubuntu

Build Reason: downstream
Build Source Stamp: [branch ofbiz/ofbiz-framework/branches/release18.12] 1859124
Blamelist: mthl

BUILD FAILED: failed shell_5

The error is happenning during the :integrationTest task which doesn't
make any sense since the revision 1859124 is not changing any code but
only javadoc comments…

I assume this is unrelated to the commit I made.



Re: buildbot failure in on ofbizBranch16

2019-05-13 Thread Jacques Le Roux

That works locally let's forget it

Le 10/05/2019 à 19:18, build...@apache.org a écrit :

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

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

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'onOfbizR16Commit' 
triggered this build
Build Source Stamp: [branch ofbiz/branches/release16.11] 1859090
Blamelist: jleroux

BUILD FAILED: failed shell_2

Sincerely,
  -The Buildbot






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

2019-05-13 Thread Jacques Le Roux

Oh, rather better refer to 
https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins

So it's at https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/769 
and the msggateway component

We know Rishi is working on it

Le 13/05/2019 à 06:35, Jacques Le Roux a écrit :

At least I can say that it was before March 30:

https://ci.apache.org/builders/ofbizTrunkFramework?numbuilds=100

Le 13/05/2019 à 06:28, Jacques Le Roux a écrit :

Thanks Suraj,

Unfortunately since another issue came in and it's now harder to detect.:

   <>

Have you an idea?

Thanks

Jacques

Le 11/05/2019 à 13:59, Suraj Khurana a écrit :

Hello,

Done at rev #1859111

--
Best Regards,
Suraj Khurana
Technical Consultant





On Fri, May 10, 2019 at 11:24 AM Suraj Khurana 
wrote:


Sure Jacques,

I will get this done by the weekend. Please proceed in case of any blocker
or urgency. I am also inclined with your thoughts.
Thanks in advance !!

--
Best Regards,
Suraj Khurana
Technical Consultant

*HotWax Systems Pvt. Ltd*





On Thu, May 9, 2019 at 3:17 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Suraj,

Any chances? I don't mind duplicated data as I mentioned answering to
Pierre

Thanks

Jacques

Le 27/04/2019 à 15:36, Jacques Le Roux a écrit :

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 <

suraj.khur...@hotwax.co>

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 <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without

privileges)

since 2008*
Apache Steve <https://steve.apache.org>, committer


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

pierresm...@apache.org>

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 <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without

privileges)

since 2008*
Apache Steve <https://steve.apache.org>, 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=or

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

2019-05-12 Thread Jacques Le Roux

At least I can say that it was before March 30:

https://ci.apache.org/builders/ofbizTrunkFramework?numbuilds=100

Le 13/05/2019 à 06:28, Jacques Le Roux a écrit :

Thanks Suraj,

Unfortunately since another issue came in and it's now harder to detect.:

   <>

Have you an idea?

Thanks

Jacques

Le 11/05/2019 à 13:59, Suraj Khurana a écrit :

Hello,

Done at rev #1859111

--
Best Regards,
Suraj Khurana
Technical Consultant





On Fri, May 10, 2019 at 11:24 AM Suraj Khurana 
wrote:


Sure Jacques,

I will get this done by the weekend. Please proceed in case of any blocker
or urgency. I am also inclined with your thoughts.
Thanks in advance !!

--
Best Regards,
Suraj Khurana
Technical Consultant

*HotWax Systems Pvt. Ltd*





On Thu, May 9, 2019 at 3:17 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Suraj,

Any chances? I don't mind duplicated data as I mentioned answering to
Pierre

Thanks

Jacques

Le 27/04/2019 à 15:36, Jacques Le Roux a écrit :

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 <

suraj.khur...@hotwax.co>

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 <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without

privileges)

since 2008*
Apache Steve <https://steve.apache.org>, committer


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

pierresm...@apache.org>

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 <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without

privileges)

since 2008*
Apache Steve <https://steve.apache.org>, 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

c

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

2019-05-12 Thread Jacques Le Roux

Thanks Suraj,

Unfortunately since another issue came in and it's now harder to detect.:

   <>

Have you an idea?

Thanks

Jacques

Le 11/05/2019 à 13:59, Suraj Khurana a écrit :

Hello,

Done at rev #1859111

--
Best Regards,
Suraj Khurana
Technical Consultant





On Fri, May 10, 2019 at 11:24 AM Suraj Khurana 
wrote:


Sure Jacques,

I will get this done by the weekend. Please proceed in case of any blocker
or urgency. I am also inclined with your thoughts.
Thanks in advance !!

--
Best Regards,
Suraj Khurana
Technical Consultant

*HotWax Systems Pvt. Ltd*





On Thu, May 9, 2019 at 3:17 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Suraj,

Any chances? I don't mind duplicated data as I mentioned answering to
Pierre

Thanks

Jacques

Le 27/04/2019 à 15:36, Jacques Le Roux a écrit :

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 <

suraj.khur...@hotwax.co>

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 <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without

privileges)

since 2008*
Apache Steve <https://steve.apache.org>, committer


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

pierresm...@apache.org>

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 <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without

privileges)

since 2008*
Apache Steve <https://steve.apache.org>, 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 f

Re: Reviving the OFBiz community day

2019-05-09 Thread Jacques Le Roux

Hi,

Please help yourself: ofbiz.apache.org/mailing-lists.html

Thanks

Jacques

Le 09/05/2019 à 23:50, Kev2600 a écrit :

Unsubscibe

On Thu, May 9, 2019 at 8:42 AM Pawan Verma 
wrote:


+1 Swapnil

--
Kind Regards,
*Pawan Verma*


On Thu, May 9, 2019 at 4:05 PM Swapnil M Mane 
wrote:


Thanks so much everyone for your comments.

The community days are organized once per quarter so a total of four (4)
events throughout the year. Since we skipped the February 2019 month.

Here

are the proposed dates for this year's community day.
Contributors can select any single day based on there availability and
preferences.


- Q1 - Community Days *February 2019*  - N/A


- Q2 - Community Days *May 2019* are *Friday 24th, Saturday 25th,

Sunday

26th, Monday 27th and Tuesday 28th*


- Q3 - Community Days *August 2019* are *Friday 23rd, Saturday 24th,
Sunday 25th, Monday 26th and Tuesday 27th*


- Q4 - Community Days* November 2019 *are *Friday 22nd, Saturday 23rd,
Sunday 24th, Monday 25th and Tuesday 26nd*


If we are fine these days, I will share the *detailed* updates on user's
mailing list.


- Thanks & Regards,
Swapnil M Mane,
ofbiz.apache.org



On Fri, Apr 26, 2019 at 2:06 PM Nicolas Malin 
wrote:


I follow you on this way :)

On 26/04/2019 09:09, Sanjay Yadav wrote:

Nice initiative, Swapnil. I am in for community day.

Best Regards,

*Sanjay Yadav* | Manager, QA
HotWax Systems 
80, Scheme No. 78, Indore, M.P. 452010, India
Mobile Phone: 787 918 8830 | Linkedin: Sanjay-Yadav



On Thu, Apr 25, 2019 at 10:54 AM Swapnil M Mane <

swapnilmm...@apache.org

wrote:


Hello team,
We are having a great community, I would like to thank everyone for

their

participation.

In year 2017, we start celebrating the OFBiz community days [1].
The contribution during community days played very significant role

in

improvement of framework.
Should we start this celebration again, thought?


[1]

https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Community+Days


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



Re: Change the URL in the browser while redirecting the user to aliasTo option of pathAlias

2019-05-09 Thread Jacques Le Roux

Le 09/05/2019 à 14:28, Pawan Verma a écrit :

Hello Devs,

In CMS, we can redirect the user to different path alias using 'aliasTo'
field of *WebSitePathAlias* entity.

Example -
  

Based on the above data, if the user hit the
https://localhost:8443/cmssite/cms/demoHome, the CMS will internally render
the content for 'newDemoHome' pathAlias.

As per my observation, the content for  "newDemoHome" is rendered properly
(as expected) but the URL of the page (in browser) doesn't change. IMO, we
should also update the URL also, i.e. change browser URL from

https://localhost:8443/cmssite/cms/demoHome to
https://localhost:8443/cmssite/cms/newDemoHome

Please let me know your thoughts. Thanks!

+1

Jacques



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

2019-05-09 Thread Jacques Le Roux

Hi Suraj,

Any chances? I don't mind duplicated data as I mentioned answering to Pierre

Thanks

Jacques

Le 27/04/2019 à 15:36, Jacques Le Roux a écrit :

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 <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without

privileges)

since 2008*
Apache Steve <https://steve.apache.org>, 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 <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without

privileges)

since 2008*
Apache Steve <https://steve.apache.org>, 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: buildbot exception in on ofbizBranch16

2019-05-09 Thread Jacques Le Roux

Actually from Buildbot and local builds it misses only in R16, not sure why.

Any ideas?

Anyway I just put it in R16 at r1858977

Jacques


Le 09/05/2019 à 10:38, Jacques Le Roux a écrit :

I did not see this one coming, because I had it locally in Gradle cache and 
Eclipse classpath. It's not present in any branches, fixing that

Jacques

Le 09/05/2019 à 08:23, build...@apache.org a écrit :

The Buildbot has detected a build exception on builder ofbizBranch16 while 
building . Full details are available at:
 https://ci.apache.org/builders/ofbizBranch16/builds/199

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

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'onOfbizR16Commit' 
triggered this build
Build Source Stamp: [branch ofbiz/branches/release16.11] 1858969
Blamelist: jleroux

BUILD FAILED: exception shell upload

Sincerely,
  -The Buildbot








Re: buildbot exception in on ofbizBranch16

2019-05-09 Thread Jacques Le Roux

I did not see this one coming, because I had it locally in Gradle cache and 
Eclipse classpath. It's not present in any branches, fixing that

Jacques

Le 09/05/2019 à 08:23, build...@apache.org a écrit :

The Buildbot has detected a build exception on builder ofbizBranch16 while 
building . Full details are available at:
 https://ci.apache.org/builders/ofbizBranch16/builds/199

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

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'onOfbizR16Commit' 
triggered this build
Build Source Stamp: [branch ofbiz/branches/release16.11] 1858969
Blamelist: jleroux

BUILD FAILED: exception shell upload

Sincerely,
  -The Buildbot






Re: Missing or not used image in site

2019-05-08 Thread Jacques Le Roux

Actually I guess you mean to check if imgRounded is used or not.

It's not, so we can remove the 3 imgRounded css blocks right?

Thanks

Jacques (still a newb in css :D)

Le 08/05/2019 à 09:28, Jacques Le Roux a écrit :

Hi Suraj,

Yep, saw that but still unsure what to do :)

Jacques

Le 08/05/2019 à 09:19, Suraj Khurana a écrit :

Hello Jacques,

I think rev#1787742 might help.
If they are removed after that (Need to check), we can remove this code
occurrence as well.

--
Kind Regards,
Suraj Khurana







On Wed, May 8, 2019 at 12:43 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi,

While checking links of the site I found that this block in
/site/css/layout.css

.imgRounded {
  -moz-border-radius:50%;
  -webkit-border-radius:50%;
  border-radius:50%;
  height:220px;
  width:220px;
  overflow:hidden;
  background-image:url('../images/team/pic3.jpg') no-repeat center #555;
}

uses images/team/pic3.jpg. Both images/team/ and pic3.jpg don't exist.

Not sure what to do with that

Thanks

Jacques






Re: Missing or not used image in site

2019-05-08 Thread Jacques Le Roux

Hi Suraj,

Yep, saw that but still unsure what to do :)

Jacques

Le 08/05/2019 à 09:19, Suraj Khurana a écrit :

Hello Jacques,

I think rev#1787742 might help.
If they are removed after that (Need to check), we can remove this code
occurrence as well.

--
Kind Regards,
Suraj Khurana







On Wed, May 8, 2019 at 12:43 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi,

While checking links of the site I found that this block in
/site/css/layout.css

.imgRounded {
  -moz-border-radius:50%;
  -webkit-border-radius:50%;
  border-radius:50%;
  height:220px;
  width:220px;
  overflow:hidden;
  background-image:url('../images/team/pic3.jpg') no-repeat center #555;
}

uses images/team/pic3.jpg. Both images/team/ and pic3.jpg don't exist.

Not sure what to do with that

Thanks

Jacques




Missing or not used image in site

2019-05-08 Thread Jacques Le Roux

Hi,

While checking links of the site I found that this block in /site/css/layout.css

.imgRounded {
    -moz-border-radius:50%;
    -webkit-border-radius:50%;
    border-radius:50%;
    height:220px;
    width:220px;
    overflow:hidden;
    background-image:url('../images/team/pic3.jpg') no-repeat center #555;
}

uses images/team/pic3.jpg. Both images/team/ and pic3.jpg don't exist.

Not sure what to do with that

Thanks

Jacques



Re: OFBiz Statistics in monthly blog entries

2019-05-05 Thread Jacques Le Roux

Le 05/05/2019 à 11:58, Sharan Foga a écrit :

You can probably see that I'm a little Kibble focussed at the moment:-)

Thanks
Sharan


Yes I know that Sharan, I also follow Kibble

Thanks for your efforts there and elsewhere :)

Jacques



Re: OFBiz Statistics in monthly blog entries

2019-05-05 Thread Jacques Le Roux

Thanks Sharan, Pierre,

Anyway, even when using Kibble we will always need a human interpretation. And 
that's when it begin to be more work.

Also, stats are driving the world and we see where it's going... I have always preferred the logical branch of AI over the stats branch for this 
reason. Achieving things in the world (yes stats do, or seem to do at least) is not the only thing we should worry about.


But who am I to tell?  I trust you share my view, so... sorry for this Sunday 
digression, I could not resist (again) :D

Jacques

PS: of course we know that nowadays the AI branches are all mixed to get results. I still believe that as long as you instil stats in AI something 
could go wrong.

Disclaimer: my digression (for fun) is about AI, Kibble is not about AI

Le 05/05/2019 à 10:07, Pierre Smits a écrit :

If we're worried about creating a competition, or people gaming the
results, then reporting on a monthly basis may prove to be undesirable, and
it would then be better to report on a quarterly basis. Then the risk of
gaming the outcome should become less.

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 Sun, May 5, 2019 at 10:00 AM Sharan Foga  wrote:


Hi All

+1

I think we need to make sure that it doesn't become like a competition to
beat the previous month's  scores, so  it might be good to rotate and use a
range of indicators. The ones posted in the blog are mailing list and
issues stats, but Kibble also shows what our mailing list mood is like, the
number of newcomers to our community, our pony factor (bus factor), and
also what are the main topics we are discussing. What I'm trying to say is
it might be nice to mix it a bit so that we get different aspects of the
community being reported.

Thanks
Sharan

On 2019/05/03 10:34:03, Aditya Sharma  wrote:

Hi everyone,

I think we should also add monthly statistics in Apache OFBiz blog

entries.

In February 2018


we

have added similar stats.

These stats are already available with Apache Kibble demo
 instance

setup.

WDYT?

--
Thanks and regards,
Aditya Sharma



Re: OFBiz Statistics in monthly blog entries

2019-05-05 Thread Jacques Le Roux

Hi Pierre,

Inline...

Le 05/05/2019 à 09:16, Pierre Smits a écrit :

+1 for communicating more stats about the health of the project, whether
that is monthly or quarterly. We had such in our quarterly reports up to
the one for the 2nd quarter of 2018. Unfortunately, IMO, for the wrong
reasons. If we can bring that back (and coincide with the quarterly report
of the project, I am all for it.


Yes, as long as stats are supported by interpretations. Anyway it's in the hand of the PMC chair. Except if s/he wants to (or must) temporarily 
delegate: https://www.apache.org/foundation/board/reporting





Which kind of stats are we thinking about pulling in and publishing?

I guess, as mentioned Aditya, see 
https://blogs.apache.org/ofbiz/entry/apache-ofbiz-news-february-2018



We have to keep in mind that what is delivered through the Kibble site is
not an ASF service (it is called demo.kibble for a reason), so there are no
guarantees regarding completeness and that it will last.


We can use it as a tool as long as it's available, if it disappears then we 
will see

Jacques




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 Fri, May 3, 2019 at 12:34 PM Aditya Sharma 
wrote:


Hi everyone,

I think we should also add monthly statistics in Apache OFBiz blog entries.
In February 2018
 we
have added similar stats.

These stats are already available with Apache Kibble demo
 instance setup.

WDYT?

--
Thanks and regards,
Aditya Sharma



Re: OFBiz Statistics in monthly blog entries

2019-05-04 Thread Jacques Le Roux

+1

Jacques

Le 03/05/2019 à 13:20, Suraj Khurana a écrit :

+1.

Sounds good to me.

--
Best Regards,
Suraj Khurana
Technical Consultant






On Fri, May 3, 2019 at 4:04 PM Aditya Sharma 
wrote:


Hi everyone,

I think we should also add monthly statistics in Apache OFBiz blog entries.
In February 2018
 we
have added similar stats.

These stats are already available with Apache Kibble demo
 instance setup.

WDYT?

--
Thanks and regards,
Aditya Sharma



Re: ExternalId support in relevant entities

2019-05-03 Thread Jacques Le Roux

Thanks Scott,

I think that if it's well documented the EntityIdentification could be a good 
solution to this problem

Jacques

Le 02/05/2019 à 22:24, Scott Gray a écrit :

I'd tend to agree with Pierre here, following the {entity}Identification
pattern is probably a better approach long term simply because the
externalId pattern breaks as soon as you need more than one identifier.  If
the likelihood of multiple IDs is low, then the {entity}Attribute pattern
might be a better approach.

But with that said, when customizing a system I'll typically just throw an
additional field on the entity and be done with it.  It doesn't take long
to write a helper method get{Entity}ByExternalId(String) to hook it up.
Because there's very little business logic that OFBiz can attach to these
fields, the amount of time we can save developers by having these fields
available in advance is very small.  That changes with the Identification
pattern because we can provide from/thru dating, enforce unique constraints
and regex patterns etc. which will save developers more time.

Regarding Facility, it's useful to have an external identifier when you're
integrating/syncing with a 3PL system or in general if you don't own the
facility that you're using.  But that could be said of almost any table in
the system when you need to keep it in sync with another.

I almost wonder if a generic entity (EntityIdentification) would be a
better approach that contains something like:
- entityName
- entityId
- fromDate
- thruDate
- idType
- value
We could then provide a set of generic helper methods/services to perform
lookups and update values e.g. GenericValue facility =
getEntityById("Facility", "3PL", "123").  The CRUD services could use
another table (EntityIdentificationType) to help with enforcing contraints:
- entityName
- idType
- requireUnique
- validationRegex

The main downsides would be:
- Duplication with the current Identification pattern (confusion)
- Lack of foreign keys back to the entities being identified
- Largely unused pattern in general currently (I think only EntityAuditLog
is similar)

Regards
Scott

On Fri, 3 May 2019 at 00:33, Pierre Smits  wrote:


Current methodology of having the externalId field in the various tables is
limiting the capabilities of OFBiz. With this an object can have only 1
externalId value. However, it is quite feasible that an object can be
associated with various external systems with each having a different
externalId value. This is particularly true for the party entity.

I wonder whether this is necessary for a facility. If a supplier has an Id
value for one of the internally used facilities, why would the adopter
care? Similar thoughts are on contact mech and shipment. But a good example
and explanation for each may help.

The external Id of a product is (as far as it is related to a product
supplied by a 3rd party) captured in SupplierProduct entity. If the intent
is to capture the product Id as it is used by a customer and other parties,
then the same reasoning as used for parties (see above) applies. Why would
an OFBiz adopter care what the external Ids of downstream parties are?

The identification type SKU can't be used for this purpose, as it is
intended to have a value based on internally used variation/feature
combinations. I suggest reading up on [1]. The definitions used by either
supplier, customer, etc. may lead to conflicts.


[1] https://en.wikipedia.org/wiki/Stock_keeping_unit

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 Thu, May 2, 2019 at 1:44 PM Suraj Khurana 
wrote:


Hello team,

As far as my understanding, externalId in OrderHeader is used to save
orderId reference of any other system into our system.

If this is the only case, we should also maintain something similar on
following entities as well as consistency and they will be in need in

case

of a full-fledged integration with OFBiz environment with any other

system:

1. ReturnHeader
2. ContactMech
3. Party (already exist)
4. Facility
5. Product (can be discussed, Identification type SKU can also do the
job)

Please let me know your thoughts on this.

--
Best Regards,
Suraj Khurana
Technical Consultant



Security alerts on monthly blog entries?

2019-05-02 Thread Jacques Le Roux

Hi,

I was wondering: would it not be good to use the blog to alert about resolved 
security issues (both w/ and w/o CVE) when it applies?

Jacques



Re: Adding Apache License link in main navigation (footer) of OFBiz site

2019-05-02 Thread Jacques Le Roux

Great, thanks Swapnil :)

Le 02/05/2019 à 10:53, Swapnil M Mane a écrit :

Changes are pushed at rev #1858515 and #1858519 in ofbiz-site.
Now all the Whimsy site checks [1] are passed.


[1] https://whimsy.apache.org/site/project/ofbiz


- Thanks & Regards,
Swapnil M Mane,
ofbiz.apache.org



On Wed, Apr 24, 2019 at 2:41 PM Swapnil M Mane 
wrote:


Sure Deepak, thank you for the comment.


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



On Wed, Apr 24, 2019 at 11:49 AM Deepak Dixit 
wrote:


Hi Swapnil,

I think we should use the following link as licenses
https://www.apache.org/licenses/LICENSE-2.0

Kind Regards,
Deepak Dixit


On Wed, Apr 24, 2019 at 10:52 AM Swapnil M Mane 
wrote:


Hello team,

Whimsy site check [1] showing the fail result in 'License' check type

for

OFBiz site [2].

It is showing message -
"URL expected to match regular expression: ^https?://.*
apache.org/licenses/?$"

But we already have a link of license [3] in the footer of OFBiz site

with

text Licensed under the Apache License, Version 2.0.

Thus I communicate with Whimy team and here is the response from them,

===
There are no standard navigation links:

https://www.apache.org/foundation/marks/pmcs#navigation
===

Reference from link above


These links can appear in whatever main navigation system your site

uses

on all top level pages for the project or subproject.


So, I think, we should add License link in the "ASF Information"

section,

defined in the *footer* of OFBiz site [2].
Please let me know your thoughts on this.


[1] https://whimsy.apache.org/site/project/ofbiz
[2] https://ofbiz.apache.org/
[3] https://www.apache.org/licenses/


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



Re: buildbot failure in on ofbizBranch17Framework

2019-04-30 Thread Jacques Le Roux

These are only css changes so can fail tests.

Le 30/04/2019 à 18:41, build...@apache.org a écrit :

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

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

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 
'onBranch17FrameworkCommit' triggered this build
Build Source Stamp: [branch ofbiz/ofbiz-framework/branches/release17.12] 1858447
Blamelist: jleroux

BUILD FAILED: failed shell_2

Sincerely,
  -The Buildbot






Re: Manufacturer Support In Promotion Engine

2019-04-30 Thread Jacques Le Roux

I can't see a problem with optional promotions

Jacques

Le 29/04/2019 à 15:44, Rishi Solanki a écrit :

Swapnil/Pierre,
Thanks for your inputs. We can go with both promotion and price rules. I
mean we can add support at both level, and depending upon the business
requirement users can decide the solutions to go with.

In case no one objects then will file Jira for this new feature enhancement
and propose design for it.

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 6:57 PM Pierre Smits  wrote:


I would consider to talk about supplier promotions, because it can also
involve wholesale suppliers.

I am inclined to agree with the latest posting by Swapnil.

Whether a supplier promotion is passed to customers is a commercial (
decision, and may be subject to the agreement between the internal party
and the supplier. But they are always intended to drive sales (from the
supplier to the customer, meaning purchases from the internal party to the
supplier).

When the supplier promotion involves an internal runner (a product that
sells well), then the supplier promotion is often not passed down to the
customer.

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 Sun, Apr 28, 2019 at 2:43 PM Swapnil Shah <
swapnil.s...@hotwaxsystems.com>
wrote:


It should be nice add. However i would have more more liked to have it
supported in the form of Price Rule as well (if it isn't already). Many a
times the mark down or mark up by manufacturers are not necessarily meant
to be propogated as adjustment on top of the existing price to the end
customer. Instead it should be directly billed at the revised prices from
the manufacturer.

Thanks,
Swapnil

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: Applicable Promo Recommendations

2019-04-30 Thread Jacques Le Roux

Thanks Guys,

Rishi, I agree about

   <>

I think this is ready for a Jira :)

Jacques

Le 30/04/2019 à 09:13, Rishi Solanki a écrit :

Devanshu,
Thanks for your reply and help offered. The feature will not be
configurable but the promotions could be, that means from the applicable
list of promotions to cart user will opt. It will be generic at cart level.
Below are applicability base idea, but for sure we can think of
configuration while designing this feature;
- User add an item to cart.
- Promo engine runs and identify 3 promos can be apply to cart. And as per
algorithm it apply one promo.
- Now user have the flexibility to change the default promo or remove it.
Right now I could not think of reason to make it configurable, but we will
discuss and rethink.
- On the whole feature is not to override the existing behavior, it just
give flexibility to user to choice.

Thanks again for putting more thought into this, it really helps.

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 Tue, Apr 30, 2019 at 11:39 AM Devanshu Vyas 
wrote:


Such support in e-commerce sites is very common these days. So a +1 from my
side.

So what I understand from your proposal:
* We will be modifying the promotion engine to not set any promotion on the
cart
* Let the user pick which promotion to be applied on the cart

My initial thoughts(I may be going ahead of the discussion here, but bear
with me :) )
* All promotions applicable on the cart should be listed with the
benefits(in terms of money value) so that the user can decide accordingly.
* If one desires, it can be turned off. I mean, this feature should be
configurable.
* Let the user know if he/she forgets to set a promotion before checkout.

I would like to extend my help in implementing this feature with you.

Thanks & Regards,
Devanshu Vyas.


On Tue, Apr 30, 2019 at 11:02 AM Rishi Solanki 
wrote:


Dear Pritam,
Thank you for your inputs, idea is to give flexibility to customer of
ecommerce site to apply or remove promotions of depending upon her
preferences.
The point raised for #3 and #4, is if an promotion has limit to apply per
customer as 1. Then customer may secure her promotion for next planned
order. It is kind of similar case when customer have promo code and she

can

use once. The change behavior is customer do not have the promo code to

use

instead have capability to remove or add promo of her own choice.

I hope this clarifies the concern raised. 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 Tue, Apr 30, 2019 at 10:20 AM Pritam Kute <
pritam.k...@hotwaxsystems.com>
wrote:


Hello Rishi,

+1. This proposal looks good to me. Use Case 1 and 2 are very common
nowadays on the various popular ecommerce sites. For use case 3 & 4, I
never came across such a scenario in any e-commerce site but IMO, it is
good to have feature.

Let me know if you need any help from my side!

Kind Regards,
--
Pritam Kute


On Sun, Apr 28, 2019 at 4:33 AM Rishi Solanki 
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 

Re: svn commit: r1858350 - in /ofbiz/ofbiz-plugins/trunk: pricat/src/main/java/org/apache/ofbiz/pricat/AbstractPricatParser.java pricat/src/main/java/org/apache/ofbiz/pricat/sample/SamplePricatParser.

2019-04-29 Thread Jacques Le Roux

Yes I reverted it

Thanks Mathieu

Jacques

Le 29/04/2019 à 11:17, Mathieu Lirzin a écrit :

Hello Jacques,

jler...@apache.org writes:


Modified: 
ofbiz/ofbiz-plugins/trunk/pricat/src/main/java/org/apache/ofbiz/pricat/sample/SamplePricatParser.java
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/pricat/src/main/java/org/apache/ofbiz/pricat/sample/SamplePricatParser.java?rev=1858350=1858349=1858350=diff
==
--- 
ofbiz/ofbiz-plugins/trunk/pricat/src/main/java/org/apache/ofbiz/pricat/sample/SamplePricatParser.java
 (original)
+++ 
ofbiz/ofbiz-plugins/trunk/pricat/src/main/java/org/apache/ofbiz/pricat/sample/SamplePricatParser.java
 Mon Apr 29 09:09:20 2019
@@ -346,20 +346,20 @@ public class SamplePricatParser extends
  public boolean isFacilityOk(XSSFRow row, String facilityName, String 
facilityId) {
  if (!facilities.containsKey(facilityId)) {
  if (UtilValidate.isEmpty(facilityId) && 
facilities.keySet().size() == 1) {
-if (UtilValidate.isEmpty(facilityName)) {
-return true;
-} else {
-String theFacilityId = (String) 
facilities.keySet().toArray()[0];
-String name = facilities.get(theFacilityId)[0];
-if (!name.equals(facilityName)) {
-String errorMessage = UtilProperties.getMessage(resource, 
"FacilityNameNotMatchId", new Object[]{theFacilityId, name, facilityName}, 
locale);
-report.println();
-report.print(errorMessage, 
InterfaceReport.FORMAT_ERROR);
-XSSFCell cell = row.getCell(0);
-errorMessages.put(new CellReference(cell), 
errorMessage);
-return false;
-}
+
+return UtilValidate.isEmpty(facilityName);
+
+String theFacilityId = (String) 
facilities.keySet().toArray()[0];
+String name = facilities.get(theFacilityId)[0];
+if (!name.equals(facilityName)) {
+String errorMessage = UtilProperties.getMessage(resource, 
"FacilityNameNotMatchId", new Object[]{theFacilityId, name, facilityName}, 
locale);
+report.println();
+report.print(errorMessage, InterfaceReport.FORMAT_ERROR);
+XSSFCell cell = row.getCell(0);
+errorMessages.put(new CellReference(cell), errorMessage);
+return false;
  
This change seems fishy since it introduces code after a ‘return’

statement in the same block, which mean that this is dead code.

Thanks.



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

2019-04-28 Thread Jacques Le Roux

Actually I rarely use integration tests independently. Most of the time I 
simply use a batch file which does:

C:\projectsASF\ofbiz>type test.bat
gup cleanAll eclipse loadAll testIntegration
C:\projectsASF\ofbiz>type gup.bat
svn up
cd plugins
svn up
cd ..
gradlew  %*
C:\projectsASF\ofbiz>

In other words to test I barely do the same than the Buildbot script does. It's the only way to be sure of what your are doing. That's pragmatic and 
it works, though it's slow.


So in theory I prefer "having all test data loaded before any test starts"

But that's not contradictory to have data duplicates when you want to run a 
test or a suite alone.

Obviously if you want to be pragmatic (ie often meaning fast) you maybe need 
duplicates.

Not sure what we achieve with this discussion :D

Jacques

Le 28/04/2019 à 15:14, Pierre Smits a écrit :

Hi Jacques,

What are you suggesting? More duplicates? Or having all test data loaded
before any test starts?

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Sun, Apr 28, 2019 at 2:29 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Yes you are right Pierre, it's not a worry when it's only for test, missed
that

Jacques

Le 28/04/2019 à 09:52, Pierre Smits a écrit :

Hi Jacques, all,

Currently, we can't avoid having duplicates in test data when we load

such

data just before the execution a test-suite/test-case. We should not
concern ourselves to much with this. After all it is just data for test,
and reloading a few duplicates should not be regarded as a major issue.

However, if the community is adamantly set on removing such duplicates,
then it should work on having test-data being loaded before any and all
test-suites/test-cases gets executed. IMO this involves moving test-data
from within the testdef folder (like in the order component) to the data
folder of the component and having a separate loadTestData task.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without

privileges)

since 2008*
Apache Steve <https://steve.apache.org>, committer


On Sat, Apr 27, 2019 at 3:38 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


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 <

suraj.khur...@hotwax.co>

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 <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without

privileges)

since 2008*
Apache Steve <https://steve.apache.org>, committer


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

pierresm...@apache.org>

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 <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz &l

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

2019-04-28 Thread Jacques Le Roux

Yes you are right Pierre, it's not a worry when it's only for test, missed that

Jacques

Le 28/04/2019 à 09:52, Pierre Smits a écrit :

Hi Jacques, all,

Currently, we can't avoid having duplicates in test data when we load such
data just before the execution a test-suite/test-case. We should not
concern ourselves to much with this. After all it is just data for test,
and reloading a few duplicates should not be regarded as a major issue.

However, if the community is adamantly set on removing such duplicates,
then it should work on having test-data being loaded before any and all
test-suites/test-cases gets executed. IMO this involves moving test-data
from within the testdef folder (like in the order component) to the data
folder of the component and having a separate loadTestData task.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Sat, Apr 27, 2019 at 3:38 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


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 <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without

privileges)

since 2008*
Apache Steve <https://steve.apache.org>, 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 <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without

privileges)

since 2008*
Apache Steve <https://steve.apache.org>, 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. Ex

Re: buildbot failure in on ofbizTrunkFrameworkPlugins

2019-04-27 Thread Jacques Le Roux

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: svn commit: r1856609 - in /ofbiz/ofbiz-framework/trunk/applications/order: groovyScripts/test/OrderTests.groovy testdef/data/OrderTestData.xml

2019-04-27 Thread Jacques Le Roux

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 <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without

privileges)

since 2008*
Apache Steve <https://steve.apache.org>, 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 <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without

privileges)

since 2008*
Apache Steve <https://steve.apache.org>, 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: Unusual logging pattern in Visit Handler

2019-04-27 Thread Jacques Le Roux

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]]

2019-04-27 Thread Jacques Le Roux
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

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 <http://www.hotwaxsystems.com/>
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention

Center,

Indore,

M.P 452010
Linkedin: *Rishi Solanki*
<https://www.linkedin.com/in/rishi-solanki-62271b7/>
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 'lastModifiedByUse

Re: ReturnContactMech is not used

2019-04-27 Thread Jacques Le Roux

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]]

2019-04-27 Thread Jacques Le Roux

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 <http://www.hotwaxsystems.com/>
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention

Center,

Indore,

M.P 452010
Linkedin: *Rishi Solanki*
<https://www.linkedin.com/in/rishi-solanki-62271b7/>
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 <https://trafodion.apache.org>, Vice

President*

*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, comm

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

2019-04-26 Thread Jacques Le Roux

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 
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



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

2019-04-26 Thread Jacques Le Roux

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 <http://www.hotwaxsystems.com/>
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,

Indore,

M.P 452010
Linkedin: *Rishi Solanki*
<https://www.linkedin.com/in/rishi-solanki-62271b7/>
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 <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without

privileges)

since 2008*
Apache Steve <https://steve.apache.org>, committer


On Wed, Apr 24, 2019 at 12:20 PM Michael Brohl <

michael.br...@ecomify.de

wrote:


These fields are not the same, they can differ. The TX fields mark

the

transaction timestamp while the non TX fields mark the "real" update
time. You can see it when you watch closely in the database. All

changes

made within an transaction have the same tx timestamp.

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 24.04.19 um 09:48 schrieb Pierre Smits:

Hi All,

Currently our functions inject following internal fields into the

model

of

each entity:

- createdStamp
- createdTxStamp
- lastUpdatedStamp
- lastUpdatedTxStamp

All of the fields above are of the field type definition

'date-time',

giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This

means

that the createdTxStamp is the same as createdStamp  and

lastUpdatedTxStamp

is the same as lastUpdatedStamp.

Should we get rid of the redundant fields?

Also, a lot of entity definitions in the various models have the
'createdByUserLogin' and 'lastModifiedByUserLogin' added.

Should we have these fields added to the internal fields set so

that

these

are always injected into the model of each entity, and always

filled?

Best rega

Re: svn commit: r1858094 - in /ofbiz/ofbiz-framework/branches/release18.12: ./ framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/RequestHandler.java

2019-04-26 Thread Jacques Le Roux

Le 25/04/2019 à 14:59, Mathieu Lirzin a écrit :

I think it might a good idea to revert and reopen OFBIZ-10895.

Done

Jacques



Re: svn commit: r1858094 - in /ofbiz/ofbiz-framework/branches/release18.12: ./ framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/RequestHandler.java

2019-04-25 Thread Jacques Le Roux

Hi Mathieu,

You are right, we need to review why and how it worked in R15, as I said not an 
easy task. I revert

Jacques

Le 25/04/2019 à 14:59, Mathieu Lirzin a écrit :

Hello Jacques,

jler...@apache.org writes:


Modified: 
ofbiz/ofbiz-framework/branches/release18.12/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/RequestHandler.java
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/branches/release18.12/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/RequestHandler.java?rev=1858094=1858093=1858094=diff
==
--- 
ofbiz/ofbiz-framework/branches/release18.12/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/RequestHandler.java
 (original)
+++ 
ofbiz/ofbiz-framework/branches/release18.12/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/RequestHandler.java
 Thu Apr 25 08:26:07 2019
@@ -22,6 +22,7 @@ import static org.apache.ofbiz.base.util
  
  import java.io.IOException;

  import java.io.Serializable;
+import java.net.MalformedURLException;
  import java.net.URL;
  import java.security.cert.X509Certificate;
  import java.util.Collection;
@@ -38,6 +39,7 @@ import javax.servlet.http.HttpServletReq
  import javax.servlet.http.HttpServletResponse;
  import javax.servlet.http.HttpSession;
  
+import org.apache.ofbiz.base.location.FlexibleLocation;

  import org.apache.ofbiz.base.util.Debug;
  import org.apache.ofbiz.base.util.SSLUtil;
  import org.apache.ofbiz.base.util.StringUtil;
@@ -267,7 +269,7 @@ public class RequestHandler {
  String overrideViewUri = getOverrideViewUri(path);
  
  Collection rmaps = resolveURI(ccfg, request);

-if (rmaps.isEmpty()) {
+if (rmaps == null) {
  if (throwRequestHandlerExceptionOnMissingLocalRequest) {
throw new RequestHandlerException(requestMissingErrorMessage);
  } else {

Checking for ‘null’ here is not a solution since ‘resolveURI’ contract
it to return a non-nullable collection.

This commit is only bypassing the error handling.

I think it might a good idea to revert and reopen OFBIZ-10895.

Thanks.



Re: [PROPOSAL] DataModel - Improve Internal Fields injection

2019-04-25 Thread Jacques Le Roux

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 <http://www.hotwaxsystems.com/>
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,

Indore,

M.P 452010
Linkedin: *Rishi Solanki*
<https://www.linkedin.com/in/rishi-solanki-62271b7/>
Direct: +91-9893287847


On Wed, Apr 24, 2019 at 4:37 PM Michael Brohl 
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 <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without

privileges)

since 2008*
Apache Steve <https://steve.apache.org>, committer


On Wed, Apr 24, 2019 at 12:20 PM Michael Brohl <

michael.br...@ecomify.de

wrote:


These fields are not the same, they can differ. The TX fields mark the
transaction timestamp while the non TX fields mark the "real" update
time. You can see it when you watch closely in the database. All

changes

made within an transaction have the same tx timestamp.

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 24.04.19 um 09:48 schrieb Pierre Smits:

Hi All,

Currently our functions inject following internal fields into the

model

of

each entity:

   - createdStamp
   - createdTxStamp
   - lastUpdatedStamp
   - lastUpdatedTxStamp

All of the fields above are of the field type definition 'date-time',
giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This

means

that the createdTxStamp is the same as createdStamp  and

lastUpdatedTxStamp

is the same as lastUpdatedStamp.

Should we get rid of the redundant fields?

Also, a lot of entity definitions in the various models have the
'createdByUserLogin' and 'lastModifiedByUserLogin' added.

Should we have these fields added to the internal fields set so that

these

are always injected into the model of each entity, and always filled?

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without

privileges)

since 2008*
Apache Steve <https://steve.apache.org>, committer



Re: [DISCUSSION] JIRA notifications and reaching contributors

2019-04-25 Thread Jacques Le Roux

I used to have a filter on "(OFBIZ-" to redirect to my OFBiz Jira folder. 
Having a specific list is easier indeed.

Jacques

Le 25/04/2019 à 13:39, Swapnil M Mane a écrit :

I am also inline with Michael's comments.


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



On Thu, Apr 25, 2019 at 4:48 PM Michael Brohl 
wrote:


I strongly suggest to stay with the split between notifications@ and dev@.

It makes the dev@ discussions a lot better to follow, these would drown
in the Jira notifications. I suspect that we would make users
unsubscribe dev@ if we would have notifications@ in there also.

If people are interested in getting the notifications, they can
subscribe anytime. It might be reasonable to encourage people in the
dev@/user@ lists to subscribe there if we believe they are not aware of
the notifications@ list.

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 25.04.19 um 12:20 schrieb Pierre Smits:

Hi All,

Back in 2016 it was decided that notifications go to the separate mailing
list notifications@ofbiz.a.o. See [1]. And looking at latest numbers
reported regarding subscriptions to our mailing lists, we have:

 - user@: 926
 - dev@: 574
 - commits@: 218
 - notifications@: 78

The numbers regarding user@, dev@ and notifications@ are from

2018-06-20,

and the number regarding notifications@ is from 2018-03-20, see [2].

The numbers indicate that about 14% of our contributor potential

subscribed

to the dev@ sees these notifications about bugs and improvements, and

less

than 9%  of our greater community  (subscribed to user@) are reached.

And

when we factor in the impact of PMC members and committers (I can only
guess how many of those have subscribed) on notifications@) the ratios

are

even worse.

The effect of the low number of subscriptions to notifications@ is that

we

don't reach our potential and that we don't see the input of dev@ and

user@

subscribers, leading to an overload of those working tickets.

Did we take a wrong turn back in 2016? And should we not revert the
resolution of the vote to have notifications go back to dev@ to get more
contributions (potentially leading to more - active - committers that

share

and lessen the work load?

What do you think?


[1] [VOTE] Create a "notifications" mailing list
<

https://ofbiz.markmail.org/message/6hlbap7a6cam3rm2?q=%22%5BVOTE%5D+Create+a+%22notifications%22+mailing+list+%22+list:org%2Eapache%2Eofbiz%2Edev+order:date-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





Re: [PROPOSAL] DataModel - Improve Internal Fields injection

2019-04-24 Thread Jacques Le Roux

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 
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 , committer


On Wed, Apr 24, 2019 at 12:20 PM Michael Brohl 
These fields are not the same, they can differ. The TX fields mark the
transaction timestamp while the non TX fields mark the "real" update
time. You can see it when you watch closely in the database. All changes
made within an transaction have the same tx timestamp.

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 24.04.19 um 09:48 schrieb Pierre Smits:

Hi All,

Currently our functions inject following internal fields into the model

of

each entity:

  - createdStamp
  - createdTxStamp
  - lastUpdatedStamp
  - lastUpdatedTxStamp

All of the fields above are of the field type definition 'date-time',
giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This means
that the createdTxStamp is the same as createdStamp  and

lastUpdatedTxStamp

is the same as lastUpdatedStamp.

Should we get rid of the redundant fields?

Also, a lot of entity definitions in the various models have the
'createdByUserLogin' and 'lastModifiedByUserLogin' added.

Should we have these fields added to the internal fields set so that

these

are always injected into the model of each entity, and always filled?

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-24 Thread Jacques Le Roux

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 
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: [OPTIONS] Java 11 and Java JDK origin

2019-04-19 Thread Jacques Le Roux

Ah OK

Le 19/04/2019 à 21:16, Taher Alkhateeb a écrit :

It's already done. I'm suggesting future actions for future JDKs

On Fri, Apr 19, 2019, 8:53 PM Jacques Le Roux 
wrote:


Hi Taher,

Sounds like a plan, will you create those Jiras Taher?

Maybe as subtasks of OFBIZ-10757, or simply reusing it w/o closing it
until we swap?

I believe the later is the easiest for all of us, but could be confusing
after a moment.

Jacques

Le 17/04/2019 à 10:02, Taher Alkhateeb a écrit :

I see no problem in sticking with 8. It would also probably be
beneficial to get the code base to be compatible with Java 11 so that
people who want to upgrade are not restricted from doing so (which we
have done already). In other words, like Scott said, it should be a
"minimum" instead of a "maximum". When we were trying to upgrade we
faced some obstacles and resolved them. which means this needs to be a
task regularly done.

So we could perhaps regularly create JIRAs like "Ensure OFBiz can
operate on Java version X" so that the code base is always forward
compatible.

On Tue, Apr 16, 2019 at 11:57 AM Scott Gray
 wrote:

Reasons to increase the minimum version:
- compelling new features
- end of support of current minimum

Reasons to not increase the minimum:
- potential instability of new version
- complicates the life of users and contributors who still use the

existing

minimum
- lack of expertise in configuring and using new features

I think every few months we should discuss it but I don't think it's

worth

shifting any time soon. The pros need to outweigh the cons, and

personally

I don't really see it at the moment.

The end of support date for 11 probably shouldn't be a consideration at
this point, by the time we even get close to that java 23 LTS will

probably

be a year old :)

Regards
Scott

On Tue, 16 Apr 2019, 00:50 Michael Brohl, 

wrote:

Ah, sorry Taher if I was not clear enough.

Yes, I think we should do the switch to Adopt Open JDK 8 LTS now for
trunk, 18.12 and 17.12 to make the project independent from the short
cycled releases of the Oracle JDK and the subscription for use of the
Oracle JDK 8 LTS.

I just recognized that Adopt JDK 11 LTS will be available until Sept.
2022. If that is not a mistake I have to refine the timeline: we can
then switch to Adopt Open JDK 11 LTS on trunk right before the release
branch for 19.x is created. I guess that the future LTS releases will
have support for at least 4 years.

That means we would remain Java 8 compatible for the releases 16 to 18
and announce the Java 11 dependency for release 19 and up. This should
give users enough time to plan, test and migrate.

Users could work with release branch 19.x on Open JDK 11 for 2,5 years
then.

For the future, I would suggest to introduce a new Open JDK LTS version
about 3-6 months after the first release, we might want to create a new
release branch in the course of this.

What do you think?

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 15.04.19 um 13:25 schrieb Taher Alkhateeb:

Hi Michael,

So just to understand your suggestion clearly. Are you recommending
that we switch from oracle JDK to open JDK now (in 18 and trunk) and
introduce open jdk 11 in 2021?

On Mon, Apr 15, 2019 at 11:46 AM Michael Brohl <

michael.br...@ecomify.de>

wrote:

Hi Scott, all,

yes, Adopt Open JDK 8 LTS is supported at least untile September 2023

[1]

Thinking about this a bit more I second to stay with Open JDK 8 LTS

for

release branches 17.12, 18.12 and trunk for now.

Professional users/ companies have a very conservative update

strategy

for base technologies like the JDK and we should support it as long

as

it is reasonable.

So, my suggestion would be to introduce Adopt Open JDK 11 LTS with

the

release branch 21.x, meaning that we change to JDK 11 right before

the

release branch will be created. This gives us plenty of time to test
with Java 11 and we can introduce Java 11 features in the trunk after
that. So release branch 22.x would be the first to depend on Java 11.

What do you think?

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


[1] https://adoptopenjdk.net/support.html


Am 15.04.19 um 00:07 schrieb Scott Gray:

My understanding was that openjdk would support java 8 until 2023.

In the past our strategy used to be that we should ensure the code

base

would operate on newer java versions but keep our minimum required

version

as low as possible.  That effectively allows users to run whatever

version

they like.  So unless there are some compelling new features in java
9/10/11 that we think we must have, I'd prefer it if we kept our

minimum

supported version as low as possible.

For myself, all client projects are still running java 8 (openjdk)

so

before I could continue contributing to OFBiz I would have to figure

out

how to run both versions on my machine with minimal disruption.

Since

I

don't have a huge amount of spare time, I would probably

Re: [OPTIONS] Java 11 and Java JDK origin

2019-04-19 Thread Jacques Le Roux
Regards
Scott

On Mon, 15 Apr 2019 at 09:09, Taher Alkhateeb <

slidingfilame...@gmail.com>

wrote:


Well, I could be mistaken but it seems EOL for java 8 is coming soon

(2019

commercial 2020 personal) [1]. This seems to be the case because the

new

LTS is out which is java 11.

Also this new release model from oracle seems to be annoying which is
pushing developers to adopt the openjdk instead. So I guess the

reason for

the upgrade is to strike two birds with one stone: upgrade java and

switch

to openjdk.

With that being said, I don't have a firm opinion on upgrading and I

just

wanted to highlight things, I leave it to other folks to decide.

[1]

https://www.oracle.com/technetwork/java/java-se-support-roadmap.html

On Sun, Apr 14, 2019, 10:38 PM Scott Gray <

scott.g...@hotwaxsystems.com>

wrote:


That would probably halt any further contributions from me in the

short

to

medium term.

Can I ask why we need to require 11 when 8 is supported through to

2023?

Regards
Scott

On Sun, 14 Apr 2019, 23:37 Jacques Le Roux, <

jacques.le.r...@les7arts.com>

wrote:


If nobody disagree, I'll make the last move (ie ask for Java 11 in
build.gradle) in 3 days

Jacques

Le 13/04/2019 à 12:34, Nicolas Malin a écrit :

On 13/04/2019 11:47, Jacques Le Roux wrote:

I just tested, without surprise the trunk HEAD works with Java 11

I did the same with 18.12, works fine

Nicolas






Re: [PROPOSAL] Enable entity timestamp fields

2019-04-19 Thread Jacques Le Roux

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: ofbizsetup

2019-04-17 Thread Jacques Le Roux

At least this helps https://markmail.org/message/s6tl7gi3lra2hrea

You need to be in the setup component, which makes sense but got sidetracked by 
an error as explained at OFBIZ-10898

Le 17/04/2019 à 12:20, Jacques Le Roux a écrit :

Hi,

Should we not add an ofbizsetup menu to access it when only seed are loaded?

AFAIK, for now it seems we have only 
https://svn.apache.org/repos/asf/ofbiz/ofbiz-framework/trunk/applications/commonext/data/helpdata/HELP_SETUP.xml as deprecated info and when you try 
to access this help from a system with only seed it fails.


Jacques




ofbizsetup

2019-04-17 Thread Jacques Le Roux

Hi,

Should we not add an ofbizsetup menu to access it when only seed are loaded?

AFAIK, for now it seems we have only https://svn.apache.org/repos/asf/ofbiz/ofbiz-framework/trunk/applications/commonext/data/helpdata/HELP_SETUP.xml 
as deprecated info and when you try to access this help from a system with only seed it fails.


Jacques



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

2019-04-16 Thread Jacques Le Roux

Thanks Suraj,

Jacques

Le 16/04/2019 à 12:33, Suraj Khurana a écrit :

Hello Jacques,

Thanks for reporting this.

Interestingly, I checked and got fail in a case when I have plugins as well
in the directory structure.

I am using this command to check single test:
./gradlew "ofbiz --test component=order --test suitename=ordertests --test
case=order-tests"

It works fine when I run ./gradlew testIntegration. On a cursory view, IMO,
data is also not dependent anywhere in the plugins directory, so this
should not be the case.

I will have a deeper look into it and provide more details soon (probably
during the weekend).

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






On Tue, Apr 16, 2019 at 3:01 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Suraj,

Any chances?

Thanks

Jacques

Le 12/04/2019 à 12:03, Jacques Le Roux a écrit :

Hi Suraj,

Since this commit

https://ci.apache.org/builders/ofbizTrunkFramework/builds/729 the
testAddRequirementTask test fails when done in trunk framework

only.

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

See also https://ci.apache.org/builders/ofbizTrunkFramework?numbuilds=40

It works when the plugins are also there:

https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins?numbuilds=25

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

I have no ideas why. Maybe some data issue (only in a plugin? Maybe

project, not sure).

|
|

|Thanks|

|Jacques|

|
|

Le 30/03/2019 à 08:12, sur...@apache.org a écrit :

Author: surajk
Date: Sat Mar 30 07:12:25 2019
New Revision: 1856609

URL: http://svn.apache.org/viewvc?rev=1856609=rev
Log:
Added: Unit test case for service - CreateReturnAdjustment.
(OFBIZ-8857)
Thanks Avnindra Sharma for reporting, Pawan Verma for discussion and

Vivek Singh Bisen for providing the updated patch.

Modified:


ofbiz/ofbiz-framework/trunk/applications/order/groovyScripts/test/OrderTests.groovy
ofbiz/ofbiz-framework/trunk/applications/order/testdef/data/OrderTestData.xml

Modified:

ofbiz/ofbiz-framework/trunk/applications/order/groovyScripts/test/OrderTests.groovy

URL:


http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/order/groovyScripts/test/OrderTests.groovy?rev=1856609=1856608=1856609=diff
==

---

ofbiz/ofbiz-framework/trunk/applications/order/groovyScripts/test/OrderTests.groovy
(original)

+++

ofbiz/ofbiz-framework/trunk/applications/order/groovyScripts/test/OrderTests.groovy
Sat Mar 30 07:12:25 2019

@@ -1,6 +1,7 @@
   import org.apache.ofbiz.entity.util.EntityQuery
   import org.apache.ofbiz.service.ServiceUtil
   import org.apache.ofbiz.testtools.GroovyScriptTestCase
+
   class OrderTests extends GroovyScriptTestCase {
   void testAddRequirementTask() {
   Map serviceCtx = [:]
@@ -10,4 +11,13 @@ class OrderTests extends GroovyScriptTes
   Map serviceResult = dispatcher.runSync("addRequirementTask",

serviceCtx)

   assert ServiceUtil.isSuccess(serviceResult)
   }
-}
+void testCreateReturnAdjustment() {
+Map serviceCtx = [:]
+serviceCtx.amount = '2.'
+serviceCtx.returnId = '1009'
+serviceCtx.userLogin =

EntityQuery.use(delegator).from('UserLogin').where('userLoginId',
'system').cache().queryOne()

+Map serviceResult =

dispatcher.runSync('createReturnAdjustment', serviceCtx)

+assert ServiceUtil.isSuccess(serviceResult)
+assert serviceResult.returnAdjustmentId != null
+}
+}
\ No newline at end of file

Modified:

ofbiz/ofbiz-framework/trunk/applications/order/testdef/data/OrderTestData.xml

URL:


http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/order/testdef/data/OrderTestData.xml?rev=1856609=1856608=1856609=diff
==

---

ofbiz/ofbiz-framework/trunk/applications/order/testdef/data/OrderTestData.xml
(original)

+++

ofbiz/ofbiz-framework/trunk/applications/order/testdef/data/OrderTestData.xml
Sat Mar 30 07:12:25 2019

@@ -54,5 +54,6 @@ under the License.
   
roleTypeId="SHIP_TO_CUSTOMER"/>

   
contactMechPurposeTypeId="ORDER_EMAIL" contactMechId="TestContactMech"/>

   
requirementTypeId="CUSTOMER_REQUIREMENT"/>

+
returnHeaderTypeId="CUSTOMER_RETURN"/>

 





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

2019-04-16 Thread Jacques Le Roux

Hi Suraj,

Any chances?

Thanks

Jacques

Le 12/04/2019 à 12:03, Jacques Le Roux a écrit :

Hi Suraj,

Since this commit https://ci.apache.org/builders/ofbizTrunkFramework/builds/729 the testAddRequirementTask test fails when done in trunk framework 
only.


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

See also https://ci.apache.org/builders/ofbizTrunkFramework?numbuilds=40

It works when the plugins are also there: 
https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins?numbuilds=25

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

I have no ideas why. Maybe some data issue (only in a plugin? Maybe project, 
not sure).

|
|

|Thanks|

|Jacques|

|
|

Le 30/03/2019 à 08:12, sur...@apache.org a écrit :

Author: surajk
Date: Sat Mar 30 07:12:25 2019
New Revision: 1856609

URL: http://svn.apache.org/viewvc?rev=1856609=rev
Log:
Added: Unit test case for service - CreateReturnAdjustment.
(OFBIZ-8857)
Thanks Avnindra Sharma for reporting, Pawan Verma for discussion and Vivek 
Singh Bisen for providing the updated patch.

Modified:
ofbiz/ofbiz-framework/trunk/applications/order/groovyScripts/test/OrderTests.groovy
ofbiz/ofbiz-framework/trunk/applications/order/testdef/data/OrderTestData.xml

Modified: 
ofbiz/ofbiz-framework/trunk/applications/order/groovyScripts/test/OrderTests.groovy
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/order/groovyScripts/test/OrderTests.groovy?rev=1856609=1856608=1856609=diff

==
--- 
ofbiz/ofbiz-framework/trunk/applications/order/groovyScripts/test/OrderTests.groovy
 (original)
+++ 
ofbiz/ofbiz-framework/trunk/applications/order/groovyScripts/test/OrderTests.groovy
 Sat Mar 30 07:12:25 2019
@@ -1,6 +1,7 @@
  import org.apache.ofbiz.entity.util.EntityQuery
  import org.apache.ofbiz.service.ServiceUtil
  import org.apache.ofbiz.testtools.GroovyScriptTestCase
+
  class OrderTests extends GroovyScriptTestCase {
  void testAddRequirementTask() {
  Map serviceCtx = [:]
@@ -10,4 +11,13 @@ class OrderTests extends GroovyScriptTes
  Map serviceResult = dispatcher.runSync("addRequirementTask", 
serviceCtx)
  assert ServiceUtil.isSuccess(serviceResult)
  }
-}
+    void testCreateReturnAdjustment() {
+    Map serviceCtx = [:]
+    serviceCtx.amount = '2.'
+    serviceCtx.returnId = '1009'
+    serviceCtx.userLogin = 
EntityQuery.use(delegator).from('UserLogin').where('userLoginId', 
'system').cache().queryOne()
+    Map serviceResult = dispatcher.runSync('createReturnAdjustment', 
serviceCtx)
+    assert ServiceUtil.isSuccess(serviceResult)
+    assert serviceResult.returnAdjustmentId != null
+    }
+}
\ No newline at end of file

Modified: 
ofbiz/ofbiz-framework/trunk/applications/order/testdef/data/OrderTestData.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/order/testdef/data/OrderTestData.xml?rev=1856609=1856608=1856609=diff

==
--- 
ofbiz/ofbiz-framework/trunk/applications/order/testdef/data/OrderTestData.xml 
(original)
+++ 
ofbiz/ofbiz-framework/trunk/applications/order/testdef/data/OrderTestData.xml 
Sat Mar 30 07:12:25 2019
@@ -54,5 +54,6 @@ under the License.
  
  
  
+    
    







Re: PrepareLocalesForDropDown.groovy

2019-04-16 Thread Jacques Le Roux
To reassure you: I had a look at log history before removing it. It was part of the Sascha's Apache Jackrabbit effort 7 years ago. Jackrabbit was 
never adopted: https://issues.apache.org/jira/browse/OFBIZ-4659


Jacques

Le 16/04/2019 à 10:07, Olivier Heintz a écrit :

One of Example Component goal is to have some example of code or manner to do.

So, code present in example not using in a production environment is not a 
argument to say we should remove it or not.

If this code could be use in a localized OFBiz, we should retain it.

My 2 cent.
Olivier


Le 16/04/2019 à 08:37, Pierre Smits a écrit :

Why is this even a discussion topic? Are we not going overboard here with
having to discuss everything and thus stifling furthering the code and the
project?

We should not keep stuff in the code base that is not used in production
implementations and/or for development.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Tue, Apr 16, 2019 at 8:30 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Thanks Nicolas,

Removed at revision: 1857622

Jacques

Le 15/04/2019 à 15:49, Nicolas Malin a écrit :

:) ok for me just go out

Nicolas

On 14/04/2019 20:42, Jacques Le Roux wrote:

This: plugins\example\groovyScripts\PrepareLocalesForDropDown.groovy

Le 14/04/2019 à 19:01, Nicolas Malin a écrit :

Hello

poveglia$ svn up

Actualisé à la révision 1857522.
poveglia$ find . -iname PrepareLocalesForDropDown.groovy
poveglia$

What this file ?

Nicolas

On 14/04/2019 18:44, Jacques Le Roux wrote:

Hi,

PrepareLocalesForDropDown.groovy is not used at all OOTB

Should we not remove it?

Jacques




Re: [OPTIONS] Java 11 and Java JDK origin

2019-04-16 Thread Jacques Le Roux
 continue contributing to OFBiz I would have to figure out
how to run both versions on my machine with minimal disruption. Since I
don't have a huge amount of spare time, I would probably just put it off
for quite a while and work on other things.

I'm not trying to veto the idea, if the community wants to proceed then it
should but I doubt I'm the only contributor we'd be putting another hurdle
in front of.

Regards
Scott

On Mon, 15 Apr 2019 at 09:09, Taher Alkhateeb 
wrote:


Well, I could be mistaken but it seems EOL for java 8 is coming soon (2019
commercial 2020 personal) [1]. This seems to be the case because the new
LTS is out which is java 11.

Also this new release model from oracle seems to be annoying which is
pushing developers to adopt the openjdk instead. So I guess the reason for
the upgrade is to strike two birds with one stone: upgrade java and switch
to openjdk.

With that being said, I don't have a firm opinion on upgrading and I just
wanted to highlight things, I leave it to other folks to decide.

[1] https://www.oracle.com/technetwork/java/java-se-support-roadmap.html

On Sun, Apr 14, 2019, 10:38 PM Scott Gray 
wrote:


That would probably halt any further contributions from me in the short

to

medium term.

Can I ask why we need to require 11 when 8 is supported through to 2023?

Regards
Scott

On Sun, 14 Apr 2019, 23:37 Jacques Le Roux, <

jacques.le.r...@les7arts.com>

wrote:


If nobody disagree, I'll make the last move (ie ask for Java 11 in
build.gradle) in 3 days

Jacques

Le 13/04/2019 à 12:34, Nicolas Malin a écrit :

On 13/04/2019 11:47, Jacques Le Roux wrote:

I just tested, without surprise the trunk HEAD works with Java 11

I did the same with 18.12, works fine

Nicolas






Re: PrepareLocalesForDropDown.groovy

2019-04-16 Thread Jacques Le Roux

Thanks Nicolas,

Removed at revision: 1857622

Jacques

Le 15/04/2019 à 15:49, Nicolas Malin a écrit :

:) ok for me just go out

Nicolas

On 14/04/2019 20:42, Jacques Le Roux wrote:

This: plugins\example\groovyScripts\PrepareLocalesForDropDown.groovy

Le 14/04/2019 à 19:01, Nicolas Malin a écrit :

Hello

poveglia$ svn up

Actualisé à la révision 1857522.
poveglia$ find . -iname PrepareLocalesForDropDown.groovy
poveglia$

What this file ?

Nicolas

On 14/04/2019 18:44, Jacques Le Roux wrote:

Hi,

PrepareLocalesForDropDown.groovy is not used at all OOTB

Should we not remove it?

Jacques










Re: [OPTIONS] Java 11 and Java JDK origin

2019-04-15 Thread Jacques Le Roux

Thanks Taher,

I believe it helps. Maybe you can share in tools?

I have something similar on Windows 7. A bit more convoluted because I copy the selected JDK on a RAM Disk (it's still faster than SSD 
<https://dzone.com/articles/accelerating-build-using-ram-disk>) and switch between them with bat files.


My intent is to share the mechanism with the community. I know not much OFBiz 
dev work with Windows, but it seems more users are.

Jacques

Le 15/04/2019 à 09:34, Taher Alkhateeb a écrit :

Hi Scott,

I'm not sure if this helps with running two versions simultaneously, but I
have multiple versions on my machine, and I setup the $JAVA_HOME to point
to /opt/jdk which in turn is a symlink to the JDK found in /opt/java/jdk8.
This way changing the jdk version is as fast as changing the symlink. I
even wrote a little script that looks up versions and I select the one most
appropriate.

Of course this is a side note, staying on Java 8 is fine by me given
getting more contributions from the community including yourself. I remain
on the fence.


On Mon, Apr 15, 2019, 1:08 AM Scott Gray 
wrote:


My understanding was that openjdk would support java 8 until 2023.

In the past our strategy used to be that we should ensure the code base
would operate on newer java versions but keep our minimum required version
as low as possible.  That effectively allows users to run whatever version
they like.  So unless there are some compelling new features in java
9/10/11 that we think we must have, I'd prefer it if we kept our minimum
supported version as low as possible.

For myself, all client projects are still running java 8 (openjdk) so
before I could continue contributing to OFBiz I would have to figure out
how to run both versions on my machine with minimal disruption.  Since I
don't have a huge amount of spare time, I would probably just put it off
for quite a while and work on other things.

I'm not trying to veto the idea, if the community wants to proceed then it
should but I doubt I'm the only contributor we'd be putting another hurdle
in front of.

Regards
Scott

On Mon, 15 Apr 2019 at 09:09, Taher Alkhateeb 
wrote:


Well, I could be mistaken but it seems EOL for java 8 is coming soon

(2019

commercial 2020 personal) [1]. This seems to be the case because the new
LTS is out which is java 11.

Also this new release model from oracle seems to be annoying which is
pushing developers to adopt the openjdk instead. So I guess the reason

for

the upgrade is to strike two birds with one stone: upgrade java and

switch

to openjdk.

With that being said, I don't have a firm opinion on upgrading and I just
wanted to highlight things, I leave it to other folks to decide.

[1] https://www.oracle.com/technetwork/java/java-se-support-roadmap.html

On Sun, Apr 14, 2019, 10:38 PM Scott Gray 
wrote:


That would probably halt any further contributions from me in the short

to

medium term.

Can I ask why we need to require 11 when 8 is supported through to

2023?

Regards
Scott

On Sun, 14 Apr 2019, 23:37 Jacques Le Roux, <

jacques.le.r...@les7arts.com>

wrote:


If nobody disagree, I'll make the last move (ie ask for Java 11 in
build.gradle) in 3 days

Jacques

Le 13/04/2019 à 12:34, Nicolas Malin a écrit :

On 13/04/2019 11:47, Jacques Le Roux wrote:

I just tested, without surprise the trunk HEAD works with Java 11

I did the same with 18.12, works fine

Nicolas




Re: PrepareLocalesForDropDown.groovy

2019-04-14 Thread Jacques Le Roux

This: plugins\example\groovyScripts\PrepareLocalesForDropDown.groovy

Le 14/04/2019 à 19:01, Nicolas Malin a écrit :

Hello

poveglia$ svn up

Actualisé à la révision 1857522.
poveglia$ find . -iname PrepareLocalesForDropDown.groovy
poveglia$

What this file ?

Nicolas

On 14/04/2019 18:44, Jacques Le Roux wrote:

Hi,

PrepareLocalesForDropDown.groovy is not used at all OOTB

Should we not remove it?

Jacques






PrepareLocalesForDropDown.groovy

2019-04-14 Thread Jacques Le Roux

Hi,

PrepareLocalesForDropDown.groovy is not used at all OOTB

Should we not remove it?

Jacques



Re: [OPTIONS] Java 11 and Java JDK origin

2019-04-14 Thread Jacques Le Roux

If nobody disagree, I'll make the last move (ie ask for Java 11 in 
build.gradle) in 3 days

Jacques

Le 13/04/2019 à 12:34, Nicolas Malin a écrit :

On 13/04/2019 11:47, Jacques Le Roux wrote:
I just tested, without surprise the trunk HEAD works with Java 11 


I did the same with 18.12, works fine

Nicolas




Re: [OPTIONS] Java 11 and Java JDK origin

2019-04-13 Thread Jacques Le Roux

Since I did the update of the README files at r1857381, I believe we simply 
need to switch R18 and trunk to Java 11 and tackle the 18 remaining warnings

For instance we need to handle https://issues.apache.org/jira/browse/OFBIZ-6747 
which is 12 warnings.

I just tested, without surprise the trunk HEAD works with Java 11

Jacques

Le 13/04/2019 à 00:20, Taher Alkhateeb a écrit :

I would suggest to make the move as soon as ready. This includes a
final patch and an update of README

On Fri, Apr 12, 2019 at 3:28 PM Jacques Le Roux
 wrote:

Hi All,

This is now done. When should we switch the trunk and R18 to Java 11?

Thanks

Jacques

Le 05/03/2019 à 17:53, Nicolas Malin a écrit :

I agree with all proposal that make sens :)

Nicolas

On 04/03/2019 12:31, Jacques Le Roux wrote:

+1

Jacques

Le 04/03/2019 à 11:34, Jacopo Cappellato a écrit :

I think that the simplest way to convey this message is to edit the README
document with a link to OpenJDK rather than Oracle JDK.

Jacopo

On Mon, Mar 4, 2019 at 10:22 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


We should then make clear to our users that they will need to switch to
OpenJDK if they want free security support.

I guess most are aware, but maybe not small companies or single users.

Jacques

Le 28/02/2019 à 18:48, Michael Brohl a écrit :

+1 for Taher's suggestion.

Thanks, Michael

Am 28.02.19 um 12:32 schrieb Taher Alkhateeb:

Perhaps we can keep ofbiz 17.12 on java 8, and let 18.12 and trunk
switch to java 11 on openjdk. This might provide stability expected by
users as indicated by Michael.

On Thu, Feb 28, 2019 at 2:27 PM Jacques Le Roux
 wrote:

Hi,

During discussions in the "Oracle Java release model changes and

consequences for the project" thread, we created "Upgrade OFBiz to use Java
JDK

Version 11" aka OFBIZ-10757.

There we began to discuss not only if we should switch to Java 11 LTS

(Long Time Support), which is obviously the best current choice, but also
which

Java JDK origin we should use OOTB.

So we have few options and we should clarify what the community wants.

Options are:

1. Do we agree to use https://adoptopenjdk.net/releases.html as

Java JDK origin OOTB?

2. Which branches should switch to Java1? Obviously the trunk and

R18 should. Should R17, which is not yet released, switch also?

I hope we don't need a vote and will quickly find a consensus.

Thanks

Jacques



Re: [OPTIONS] Java 11 and Java JDK origin

2019-04-12 Thread Jacques Le Roux

Hi All,

This is now done. When should we switch the trunk and R18 to Java 11?

Thanks

Jacques

Le 05/03/2019 à 17:53, Nicolas Malin a écrit :

I agree with all proposal that make sens :)

Nicolas

On 04/03/2019 12:31, Jacques Le Roux wrote:

+1

Jacques

Le 04/03/2019 à 11:34, Jacopo Cappellato a écrit :

I think that the simplest way to convey this message is to edit the README
document with a link to OpenJDK rather than Oracle JDK.

Jacopo

On Mon, Mar 4, 2019 at 10:22 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


We should then make clear to our users that they will need to switch to
OpenJDK if they want free security support.

I guess most are aware, but maybe not small companies or single users.

Jacques

Le 28/02/2019 à 18:48, Michael Brohl a écrit :

+1 for Taher's suggestion.

Thanks, Michael

Am 28.02.19 um 12:32 schrieb Taher Alkhateeb:

Perhaps we can keep ofbiz 17.12 on java 8, and let 18.12 and trunk
switch to java 11 on openjdk. This might provide stability expected by
users as indicated by Michael.

On Thu, Feb 28, 2019 at 2:27 PM Jacques Le Roux
 wrote:

Hi,

During discussions in the "Oracle Java release model changes and

consequences for the project" thread, we created "Upgrade OFBiz to use Java
JDK

Version 11" aka OFBIZ-10757.

There we began to discuss not only if we should switch to Java 11 LTS

(Long Time Support), which is obviously the best current choice, but also
which

Java JDK origin we should use OOTB.

So we have few options and we should clarify what the community wants.

Options are:

   1. Do we agree to use https://adoptopenjdk.net/releases.html as

Java JDK origin OOTB?

   2. Which branches should switch to Java1? Obviously the trunk and

R18 should. Should R17, which is not yet released, switch also?

I hope we don't need a vote and will quickly find a consensus.

Thanks

Jacques







Re: svn commit: r1856618 - in /ofbiz/ofbiz-plugins/trunk/msg91: ./ config/ data/ data/helpdata/ documents/ entitydef/ servicedef/ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apa

2019-04-12 Thread Jacques Le Roux

+1, thanks Rishi!

Le 12/04/2019 à 12:02, Rishi Solanki a écrit :

Jacques,
Thanks for pointing this, I made code changes before committing this as
plugin. And as we uses free services from them (by mentioning OFBiz as open
source apache software) so didn't give a thought to name of component and
mentioning of commercial services.

I'm completely agree with you on this, I will change the component name and
all occurrences in the code. Please let me know if we are good if we do so,
or something else needs to be done. Thanks!

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems <http://www.hotwaxsystems.com/>
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P 452010
Linkedin: *Rishi Solanki*
<https://www.linkedin.com/in/rishi-solanki-62271b7/>
Direct: +91-9893287847


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


Hi Rishi,

In understand that this component currently uses "msg91 services to send
sms".

But could we not have another name, more explicit, for this component,
like sms or sendsms for instance?

Services tend to disappear or change (Google is the best example). So I'd
not associate the name of an open source component to a commercial services
provider (with a free SMS quota option). Even if hopefully it will stay as
is...

Thanks

Jacques

Le 30/03/2019 à 13:43, ri...@apache.org a écrit :

Author: rishi
Date: Sat Mar 30 12:43:46 2019
New Revision: 1856618

URL: http://svn.apache.org/viewvc?rev=1856618=rev
Log:
[Implemented] Short Messaging Service(SMS) Gateway Integration. Added

msg91 component to plugins. It uses msg91 services to send sms. An example
to demonstrate how to use SMS gateway integration with OFBiz.

(OFBIZ-10457)
Thanks to Pritam Kute for your contribution and Michael Brohi for review

and feedback.

Added:
  ofbiz/ofbiz-plugins/trunk/msg91/
  ofbiz/ofbiz-plugins/trunk/msg91/config/
  ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml   (with

props)

  ofbiz/ofbiz-plugins/trunk/msg91/data/
  ofbiz/ofbiz-plugins/trunk/msg91/data/Msg91DemoData.xml   (with

props)
ofbiz/ofbiz-plugins/trunk/msg91/data/Msg91SecurityGroupDemoData.xml   (with
props)
ofbiz/ofbiz-plugins/trunk/msg91/data/Msg91SecurityPermissionSeedData.xml
  (with props)

  ofbiz/ofbiz-plugins/trunk/msg91/data/helpdata/
  ofbiz/ofbiz-plugins/trunk/msg91/data/helpdata/HELP_Msg91.xml

  (with props)

  ofbiz/ofbiz-plugins/trunk/msg91/documents/
  ofbiz/ofbiz-plugins/trunk/msg91/documents/Msg91.xml   (with props)
  ofbiz/ofbiz-plugins/trunk/msg91/entitydef/
  ofbiz/ofbiz-plugins/trunk/msg91/entitydef/entitymodel.xml   (with

props)

  ofbiz/ofbiz-plugins/trunk/msg91/ofbiz-component.xml   (with props)
  ofbiz/ofbiz-plugins/trunk/msg91/servicedef/
  ofbiz/ofbiz-plugins/trunk/msg91/servicedef/services.xml   (with

props)

  ofbiz/ofbiz-plugins/trunk/msg91/src/
  ofbiz/ofbiz-plugins/trunk/msg91/src/main/
  ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/
  ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/org/
  ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/org/apache/
  ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/org/apache/ofbiz/


ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/org/apache/ofbiz/msg91/
ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/org/apache/ofbiz/msg91/Msg91Services.java
  (with props)

  ofbiz/ofbiz-plugins/trunk/msg91/webapp/
  ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/
  ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/WEB-INF/
  ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/WEB-INF/actions/


ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/WEB-INF/controller.xml   (with
props)

  ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/WEB-INF/web.xml

  (with props)

  ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/error/
  ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/error/error.jsp

  (with props)

  ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/index.jsp   (with

props)

  ofbiz/ofbiz-plugins/trunk/msg91/widget/
  ofbiz/ofbiz-plugins/trunk/msg91/widget/CommonScreens.xml   (with

props)

  ofbiz/ofbiz-plugins/trunk/msg91/widget/Msg91Menus.xml   (with props)
  ofbiz/ofbiz-plugins/trunk/msg91/widget/Msg91Screens.xml   (with

props)

Added: ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml
URL:

http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml?rev=1856618=auto
==

--- ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml (added)
+++ ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml Sat Mar 30

12:43:46 2019

@@ -0,0 +1,42 @@
+
+
+
+http://www.w3.org/2001/XMLSchema-instance;

xsi:noNamespaceSchemaLocation="
http://ofbiz.apache.org/dtds/ofbiz-properties.xsd;>

+
+Msg91 Application
+Msg91å

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

2019-04-12 Thread Jacques Le Roux

Hi Suraj,

Since this commit https://ci.apache.org/builders/ofbizTrunkFramework/builds/729 
the testAddRequirementTask test fails when done in trunk framework only.

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

See also https://ci.apache.org/builders/ofbizTrunkFramework?numbuilds=40

It works when the plugins are also there: 
https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins?numbuilds=25

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

I have no ideas why. Maybe some data issue (only in a plugin? Maybe project, 
not sure).

|
|

|Thanks|

|Jacques|

|
|

Le 30/03/2019 à 08:12, sur...@apache.org a écrit :

Author: surajk
Date: Sat Mar 30 07:12:25 2019
New Revision: 1856609

URL: http://svn.apache.org/viewvc?rev=1856609=rev
Log:
Added: Unit test case for service - CreateReturnAdjustment.
(OFBIZ-8857)
Thanks Avnindra Sharma for reporting, Pawan Verma for discussion and Vivek 
Singh Bisen for providing the updated patch.

Modified:
 
ofbiz/ofbiz-framework/trunk/applications/order/groovyScripts/test/OrderTests.groovy
 
ofbiz/ofbiz-framework/trunk/applications/order/testdef/data/OrderTestData.xml

Modified: 
ofbiz/ofbiz-framework/trunk/applications/order/groovyScripts/test/OrderTests.groovy
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/order/groovyScripts/test/OrderTests.groovy?rev=1856609=1856608=1856609=diff
==
--- 
ofbiz/ofbiz-framework/trunk/applications/order/groovyScripts/test/OrderTests.groovy
 (original)
+++ 
ofbiz/ofbiz-framework/trunk/applications/order/groovyScripts/test/OrderTests.groovy
 Sat Mar 30 07:12:25 2019
@@ -1,6 +1,7 @@
  import org.apache.ofbiz.entity.util.EntityQuery
  import org.apache.ofbiz.service.ServiceUtil
  import org.apache.ofbiz.testtools.GroovyScriptTestCase
+
  class OrderTests extends GroovyScriptTestCase {
  void testAddRequirementTask() {
  Map serviceCtx = [:]
@@ -10,4 +11,13 @@ class OrderTests extends GroovyScriptTes
  Map serviceResult = dispatcher.runSync("addRequirementTask", 
serviceCtx)
  assert ServiceUtil.isSuccess(serviceResult)
  }
-}
+void testCreateReturnAdjustment() {
+Map serviceCtx = [:]
+serviceCtx.amount = '2.'
+serviceCtx.returnId = '1009'
+serviceCtx.userLogin = 
EntityQuery.use(delegator).from('UserLogin').where('userLoginId', 
'system').cache().queryOne()
+Map serviceResult = dispatcher.runSync('createReturnAdjustment', 
serviceCtx)
+assert ServiceUtil.isSuccess(serviceResult)
+assert serviceResult.returnAdjustmentId != null
+}
+}
\ No newline at end of file

Modified: 
ofbiz/ofbiz-framework/trunk/applications/order/testdef/data/OrderTestData.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/order/testdef/data/OrderTestData.xml?rev=1856609=1856608=1856609=diff
==
--- 
ofbiz/ofbiz-framework/trunk/applications/order/testdef/data/OrderTestData.xml 
(original)
+++ 
ofbiz/ofbiz-framework/trunk/applications/order/testdef/data/OrderTestData.xml 
Sat Mar 30 07:12:25 2019
@@ -54,5 +54,6 @@ under the License.
  
  
  
+
  
  






Re: svn commit: r1856618 - in /ofbiz/ofbiz-plugins/trunk/msg91: ./ config/ data/ data/helpdata/ documents/ entitydef/ servicedef/ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apa

2019-04-11 Thread Jacques Le Roux

Hi Rishi,

In understand that this component currently uses "msg91 services to send sms".

But could we not have another name, more explicit, for this component, like sms 
or sendsms for instance?

Services tend to disappear or change (Google is the best example). So I'd not associate the name of an open source component to a commercial services 
provider (with a free SMS quota option). Even if hopefully it will stay as is...


Thanks

Jacques

Le 30/03/2019 à 13:43, ri...@apache.org a écrit :

Author: rishi
Date: Sat Mar 30 12:43:46 2019
New Revision: 1856618

URL: http://svn.apache.org/viewvc?rev=1856618=rev
Log:
[Implemented] Short Messaging Service(SMS) Gateway Integration. Added msg91 
component to plugins. It uses msg91 services to send sms. An example to 
demonstrate how to use SMS gateway integration with OFBiz.
(OFBIZ-10457)
Thanks to Pritam Kute for your contribution and Michael Brohi for review and 
feedback.

Added:
 ofbiz/ofbiz-plugins/trunk/msg91/
 ofbiz/ofbiz-plugins/trunk/msg91/config/
 ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml   (with props)
 ofbiz/ofbiz-plugins/trunk/msg91/data/
 ofbiz/ofbiz-plugins/trunk/msg91/data/Msg91DemoData.xml   (with props)
 ofbiz/ofbiz-plugins/trunk/msg91/data/Msg91SecurityGroupDemoData.xml   
(with props)
 ofbiz/ofbiz-plugins/trunk/msg91/data/Msg91SecurityPermissionSeedData.xml   
(with props)
 ofbiz/ofbiz-plugins/trunk/msg91/data/helpdata/
 ofbiz/ofbiz-plugins/trunk/msg91/data/helpdata/HELP_Msg91.xml   (with props)
 ofbiz/ofbiz-plugins/trunk/msg91/documents/
 ofbiz/ofbiz-plugins/trunk/msg91/documents/Msg91.xml   (with props)
 ofbiz/ofbiz-plugins/trunk/msg91/entitydef/
 ofbiz/ofbiz-plugins/trunk/msg91/entitydef/entitymodel.xml   (with props)
 ofbiz/ofbiz-plugins/trunk/msg91/ofbiz-component.xml   (with props)
 ofbiz/ofbiz-plugins/trunk/msg91/servicedef/
 ofbiz/ofbiz-plugins/trunk/msg91/servicedef/services.xml   (with props)
 ofbiz/ofbiz-plugins/trunk/msg91/src/
 ofbiz/ofbiz-plugins/trunk/msg91/src/main/
 ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/
 ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/org/
 ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/org/apache/
 ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/org/apache/ofbiz/
 ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/org/apache/ofbiz/msg91/
 
ofbiz/ofbiz-plugins/trunk/msg91/src/main/java/org/apache/ofbiz/msg91/Msg91Services.java
   (with props)
 ofbiz/ofbiz-plugins/trunk/msg91/webapp/
 ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/
 ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/WEB-INF/
 ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/WEB-INF/actions/
 ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/WEB-INF/controller.xml   
(with props)
 ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/WEB-INF/web.xml   (with props)
 ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/error/
 ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/error/error.jsp   (with props)
 ofbiz/ofbiz-plugins/trunk/msg91/webapp/msg91/index.jsp   (with props)
 ofbiz/ofbiz-plugins/trunk/msg91/widget/
 ofbiz/ofbiz-plugins/trunk/msg91/widget/CommonScreens.xml   (with props)
 ofbiz/ofbiz-plugins/trunk/msg91/widget/Msg91Menus.xml   (with props)
 ofbiz/ofbiz-plugins/trunk/msg91/widget/Msg91Screens.xml   (with props)

Added: ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml?rev=1856618=auto
==
--- ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml (added)
+++ ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml Sat Mar 30 
12:43:46 2019
@@ -0,0 +1,42 @@
+
+
+
+http://www.w3.org/2001/XMLSchema-instance; 
xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/ofbiz-properties.xsd;>
+
+Msg91 Application
+Msg91应用程序
+Msg91應用程式
+
+
+OFBiz: Msg91
+OFBiz: Msg91
+
+
+Part of the Apache OFBiz Family of Open Source 
Software
+Un modulo della famiglia di software open source Apache 
OFBiz
+开源软件OFBiz的组成部分
+開源軟體OFBiz的組成部分
+
+
+You are not allowed to view this page.
+不允许你浏览这个页面。
+不允許您檢視這個頁面.
+
+

Propchange: ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml
--
 svn:eol-style = native

Propchange: ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml
--
 svn:keywords = Date Rev Author URL Id

Propchange: ofbiz/ofbiz-plugins/trunk/msg91/config/Msg91UiLabels.xml
--
 svn:mime-type = 

Re: Marital Status not managed properly in Person entity

2019-04-09 Thread Jacques Le Roux

Le 09/04/2019 à 14:08, Nicolas Malin a écrit :

personally I'm more in favor to use a party classification if you want to know 
the lifespan of each state.

+1, but needs more work...

Jacques



Re: ***UNCHECKED*** Marital Status not managed properly in Person entity

2019-04-09 Thread Jacques Le Roux

+1

Jacques

Le 09/04/2019 à 10:59, Suraj Khurana a écrit :

+1.

Technically, as per Pierre, we should also mark this field as encrypted in
the entity definition.

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






On Tue, Apr 9, 2019 at 2:08 PM Pierre Smits  wrote:


Although I am inclined to agree with having the options come from
appropriate records/values in the Enumeration entity, I must caution about
how the final solution will be implemented in our code base. We all know
that this falls in the category of sensitive data which has come under a
tighter scrutiny due to GDPR and security breaches.

Such privacy sensitive element should be implemented in tighter permissions
applied than we generally apply to screens/forms/fields etc.

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 Tue, Apr 9, 2019 at 10:19 AM Aditya Sharma 
wrote:


+1

Best Regards,
Aditya Sharma,
http://ofbiz.apache.org


On Tue, Apr 9, 2019 at 1:09 PM Swapnil M Mane 
wrote:


+1


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



On Tue, Apr 9, 2019 at 12:51 PM Suraj Khurana 
Hello,

Currently, *maritalStatus* is managed as an indicator (Y/N) in

*Person*

entity. I think we can enhance it and make it derived from

*Enumeration*

pattern.

*Classification of legal marital status*

- 1 - Married (and not separated) ...
- 2 - Widowed (including living common law) ...
- 3 - Separated (and not Divorced) ...
- 4 - Divorced (including living common law) ...
- 5 - Single (including living common law)

Please share your thoughts.

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



Re: ***UNCHECKED*** Marital Status not managed properly in Person entity

2019-04-09 Thread Jacques Le Roux

+1

Jacques

Le 09/04/2019 à 09:20, Suraj Khurana a écrit :

Hello,

Currently, *maritalStatus* is managed as an indicator (Y/N) in *Person*
entity. I think we can enhance it and make it derived from *Enumeration*
pattern.

*Classification of legal marital status*

- 1 - Married (and not separated) ...
- 2 - Widowed (including living common law) ...
- 3 - Separated (and not Divorced) ...
- 4 - Divorced (including living common law) ...
- 5 - Single (including living common law)

Please share your thoughts.

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



Re: Supply chain example

2019-04-04 Thread Jacques Le Roux

As you can see the Nabble forum is not the best place to ask questions and get 
answers.
I mean can you see your message there? Err no, as long as you don't subscribe 
to OFBiz MLs!

So, please rather subscribe to the user ML and use your email client:
http://ofbiz.apache.org/mailing-lists.html
You will get a better support and it's more fair to share with everybody

The wider the audience the better the answers you might get

Also it's more work for moderators who have to accept your messages as long as 
you have not subscribed.
I'll personally no longer accept them (other moderators still could)

Thanks

Jacques

Le 05/04/2019 à 07:31, laxman a écrit :

Hi, I want to create an application in which we have soft drink manufacture
company. They will fill the information in our supply chain. and end user
can we get information bases on soft drink number



--
Sent from: http://ofbiz.135035.n4.nabble.com/OFBiz-Dev-f165671.html



Re: Supply chain example

2019-04-04 Thread Jacques Le Roux

Hi,

Your message has been moderated.

Please subscribe to the user ML for such questions and then use your email 
client
See also why here http://ofbiz.apache.org/mailing-lists.html

You will get a better support , it's more fair to share with everybody  and 
people can answer you on the ML rather than directly to you
The wider the audience the better the answers you might get

Also it's more work for moderators who have to accept your messages as long as 
you have not subscribed.
I'll personally no longer accept them (other moderators still could)

Thanks

Jacques

Le 04/04/2019 à 06:13, lax...@akeo.no a écrit :

Hi all,
can anyone suggest me any supply chain example with ofbiz.apache as I am new 
for ofbiz.apache



Re: Reg Ofbiz inventory valuation

2019-03-27 Thread Jacques Le Roux

Hi Pavan,

Your message has been moderated.

Please subscribe to the user ML for such questions and then use your email 
client
See also why here http://ofbiz.apache.org/mailing-lists.html

You will get a better support , it's more fair to share with everybody  and 
people can answer you on the ML rather than directly to you
The wider the audience the better the answers you might get

Thanks

Jacques

Le 27/03/2019 à 12:46, Pavan Kumar a écrit :

Hi,

Can we check stock of older date, suppose i want stock of 1st march for all
facilities. We will use inventory transfers between facilities

Thanks,
Pavan Kumar.



Re: Reg Ofbiz inventory valuation

2019-03-27 Thread Jacques Le Roux

Hi Pavan,

Your message has been moderated.

Please subscribe to the user ML for such questions and then use your email 
client
See also why here http://ofbiz.apache.org/mailing-lists.html

You will get a better support , it's more fair to share with everybody  and 
people can answer you on the ML rather than directly to you
The wider the audience the better the answers you might get

Also it's more work for moderators who have to accept your messages as long as 
you have not subscribed.
I'll personally no longer accept them (other moderators still could)

Thanks

Jacques

Le 27/03/2019 à 12:47, devendrapavanku...@gmail.com a écrit :

Hi,

Can we check stock of older date, suppose i want stock of 1st march for all 
facilities. We will use inventory transfers between facilities

Thanks,
Pavan Kumar.



Re: svn commit: r1856372 - /ofbiz/site/template/region/head.tpl.php

2019-03-27 Thread Jacques Le Roux

Hi Deepak,

Does this not miss the html equivalent?

Le 27/03/2019 à 08:40, dee...@apache.org a écrit :

Author: deepak
Date: Wed Mar 27 07:40:11 2019
New Revision: 1856372

URL: http://svn.apache.org/viewvc?rev=1856372=rev
Log:
Updated the js/css/images path, if you hit the wrong url like 
https://ofbiz.apache.org/mailing-lists/test ofbiz site fails to laod the 
resources.

Modified:
 ofbiz/site/template/region/head.tpl.php

Modified: ofbiz/site/template/region/head.tpl.php
URL: 
http://svn.apache.org/viewvc/ofbiz/site/template/region/head.tpl.php?rev=1856372=1856371=1856372=diff
==
--- ofbiz/site/template/region/head.tpl.php (original)
+++ ofbiz/site/template/region/head.tpl.php Wed Mar 27 07:40:11 2019
@@ -15,26 +15,26 @@
  
  
-
+
  
  
  
-
-
-
+
+
+
  
-
-
+
+
  
-
-
+
+
  
  
  
  
-
-
-
-
-
+
+
+
+
+





Re: svn commit: r1855798 - /ofbiz/ofbiz-framework/trunk/build.gradle

2019-03-27 Thread Jacques Le Roux

We should complete and decide about 
https://cwiki.apache.org/confluence/display/OFBIZ/Guidelines+For+Using+JIRA

And then refer to it from where needed

That would be the last time we would have this convo ;)

Jacques

Le 27/03/2019 à 03:43, Scott Gray a écrit :

I think minor refactors (lots or few is irrelevant) shouldn't need a jira
ticket and aren't worth mentioning in a blog post.  Anything that requires
discussion and/or changes the behavior of the application, the API or
documentation should go through jira.

Regards
Scott

On Thu, 21 Mar 2019 at 10:19, Mathieu Lirzin  wrote:


Hello Michael,

Michael Brohl  writes:


don't we have Jira's for all these changes?

If yes, please provide the issue number within the commit message so
that we have them in the monthly blog post/dev details.

If no, we should have them, at least in the future.

Sorry if the process I followed was not the right one.

I must confess that the policy regarding how refactoring (done by
committers) must be handled in term of JIRA creation, is not clear to
me.  The block “When to create a Jira issue” on OFBiz wiki [1] is not
helping much in that regard.  Maybe there is an implicit consensus in
that regard that I am not aware of?

My reasoning for not creating a JIRA was that those commits are pure
refactoring meaning they are implementation details that don't change
the observable behavior of the build and they are not part of a global
plan.  Basically those cleanups happened by looking around while working
on OFBIZ-10866 [2] but are unrelated to the endeavour of that task.

What would you recommend in that scenario?


If these changes affect the documentation, the README.md should also
be edited to reflect them and stay in sync with the code.

Sure I agree that's an important guideline to follow.

Thanks.

[1]
https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices
[2] https://issues.apache.org/jira/browse/OFBIZ-10866

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



Re: buildbot failure in on ofbizTrunkFrameworkPlugins

2019-03-26 Thread Jacques Le Roux

The errors are inconsistent in both Buildbot and locally, I consider as not an 
issue

Jacques

Le 25/03/2019 à 19:43, 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/745

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

Buildslave for this Build: silvanus_ubuntu

Build Reason: downstream
Build Source Stamp: [branch ofbiz/ofbiz-framework/trunk] 1856212
Blamelist: jleroux

BUILD FAILED: failed shell_4

Sincerely,
  -The Buildbot






Re: Send E-Mails

2019-03-26 Thread Jacques Le Roux

Yep

Jacques

Le 26/03/2019 à 09:37, Gil Portenseigne a écrit :

What I understand is that to keep granted right after the migration if
our confluence id is différent from our apache id, we must fill in a
INFRA Jira to make the switch ?


Le 09:23 - mardi 26 mars, Jacques Le Roux a écrit :

Makes sense Pierre,

Please Gil checks https://issues.apache.org/jira/browse/INFRA-18028

HTH

Jacques

Le 26/03/2019 à 09:16, Pierre Smits a écrit :

Hi Gil,

Does this maybe have something to do with recent migration by INFRA to have
ApacheIds (LDAP)+password being usable as login credentials? I can't edit
either.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>,  10 years a contributor without
privileges*
Apache Steve <https://steve.apache.org>, committer


On Tue, Mar 26, 2019 at 8:56 AM Gil Portenseigne <
gil.portensei...@nereide.fr> wrote:


Hello there,

Do somes actions have been taken on documenting the existence of
SystemProperty ?

I like the idea of migrating documentation into embedded one.

I just wanted to add a note into https://s.apache.org/BPJ5 that alert
about SystemProperty, but i seem to miss the modification permission...
can someone grant me access ?

Thanks

Gil


Le 12:50 - vendredi 11 mai, Taher Alkhateeb a écrit :

Actually, I think whatever need to be documented is best placed in our
embedded documentation. We should probably consider freezing all new
documentation in any place that is not the embedded documentation and try
to migrate everything to it. So email setting docs could be placed
somewhere in our user manual.

On Fri, May 11, 2018, 11:51 AM Jacques Le Roux <

jacques.le.r...@les7arts.com>

wrote:


Hi Rishi,


Le 09/05/2018 ą 11:12, Rishi Solanki a écrit :

Community, I think we should mention the SystemProperty where

required in

Production Setup Guide or may be we can add version of production

setup

guide which will tells user upto which release this production setup

guide

will work. I know we discuss this kind of effort in past for all the
documents and we agree on some point. But this is quicker to manage
Production Setup Guide, if we agree then I can do it.

Yes good idea, a simple information for concerned versions in the

current

Production Setup Guide fits with me

Jacques

I'm fine with either change the existing one or maintain the

version. But

first we should have one which works always with latest. Thanks!


Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co

On Wed, May 9, 2018 at 3:33 AM, i...@agentur-m3.de <

i...@agentur-m3.de>

wrote:


Hello,

here is a problem with my e-mail base-configuration.

I configured email according to the setup guide:



https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Technical+

Production+Setup+Guide#ApacheOFBizTechnicalProduction
SetupGuide-EmailServerSettings


Unfortunately no email seems to be sent from server
(the send email button in partymgr works fine now (thanks to

Jacques!),

but no email reaches client). No error message, no error in log.

Also I tried to register in the ecommerce system and send
an "Forgot Your Password" email, but none of the emails were sent.

To get more info about the problem, I wrote a groovy script and

copied

parts of the sendEmail-code from EmailServices.java.
The script below surprisingly works fine and sends emails!

So I don't understand, why OFBiz itself does not send mails.
Is there any further configuration necessary?



The script (which sends mails):

import javax.mail.Session;

import javax.activation.DataHandler;
import javax.activation.DataSource;
import javax.mail.Message;
import javax.mail.MessagingException;
import javax.mail.SendFailedException;
import javax.mail.Session;
import javax.mail.Transport;
import javax.mail.internet.InternetAddress;
import javax.mail.internet.MimeBodyPart;
import javax.mail.internet.MimeMessage;
import javax.mail.internet.MimeMultipart;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.transform.stream.StreamSource;

import org.apache.fop.apps.Fop;
import org.apache.fop.apps.MimeConstants;
import org.apache.ofbiz.base.util.Debug;
import org.apache.ofbiz.base.util.GeneralException;
import org.apache.ofbiz.base.util.HttpClient;
import org.apache.ofbiz.base.util.HttpClientException;
import org.apache.ofbiz.base.util.UtilGenerics;
import org.apache.ofbiz.base.util.UtilMisc;
import org.apache.ofbiz.base.util.UtilProperties;
import org.apache.ofbiz.base.util.UtilValidate;
import org.apache.ofbiz.base.util.collections.MapStack;
import org.apache.ofbiz.base.util.string.FlexibleStringExpander;
import org.apache.ofbiz.entity.Dele

Re: Send E-Mails

2019-03-26 Thread Jacques Le Roux

Makes sense Pierre,

Please Gil checks https://issues.apache.org/jira/browse/INFRA-18028

HTH

Jacques

Le 26/03/2019 à 09:16, Pierre Smits a écrit :

Hi Gil,

Does this maybe have something to do with recent migration by INFRA to have
ApacheIds (LDAP)+password being usable as login credentials? I can't edit
either.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>,  10 years a contributor without
privileges*
Apache Steve <https://steve.apache.org>, committer


On Tue, Mar 26, 2019 at 8:56 AM Gil Portenseigne <
gil.portensei...@nereide.fr> wrote:


Hello there,

Do somes actions have been taken on documenting the existence of
SystemProperty ?

I like the idea of migrating documentation into embedded one.

I just wanted to add a note into https://s.apache.org/BPJ5 that alert
about SystemProperty, but i seem to miss the modification permission...
can someone grant me access ?

Thanks

Gil


Le 12:50 - vendredi 11 mai, Taher Alkhateeb a écrit :

Actually, I think whatever need to be documented is best placed in our
embedded documentation. We should probably consider freezing all new
documentation in any place that is not the embedded documentation and try
to migrate everything to it. So email setting docs could be placed
somewhere in our user manual.

On Fri, May 11, 2018, 11:51 AM Jacques Le Roux <

jacques.le.r...@les7arts.com>

wrote:


Hi Rishi,


Le 09/05/2018 ą 11:12, Rishi Solanki a écrit :

Community, I think we should mention the SystemProperty where

required in

Production Setup Guide or may be we can add version of production

setup

guide which will tells user upto which release this production setup

guide

will work. I know we discuss this kind of effort in past for all the
documents and we agree on some point. But this is quicker to manage
Production Setup Guide, if we agree then I can do it.

Yes good idea, a simple information for concerned versions in the

current

Production Setup Guide fits with me

Jacques

I'm fine with either change the existing one or maintain the

version. But

first we should have one which works always with latest. Thanks!


Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co

On Wed, May 9, 2018 at 3:33 AM, i...@agentur-m3.de <

i...@agentur-m3.de>

wrote:


Hello,

here is a problem with my e-mail base-configuration.

I configured email according to the setup guide:



https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Technical+

Production+Setup+Guide#ApacheOFBizTechnicalProduction
SetupGuide-EmailServerSettings


Unfortunately no email seems to be sent from server
(the send email button in partymgr works fine now (thanks to

Jacques!),

but no email reaches client). No error message, no error in log.

Also I tried to register in the ecommerce system and send
an "Forgot Your Password" email, but none of the emails were sent.

To get more info about the problem, I wrote a groovy script and

copied

parts of the sendEmail-code from EmailServices.java.
The script below surprisingly works fine and sends emails!

So I don't understand, why OFBiz itself does not send mails.
Is there any further configuration necessary?



The script (which sends mails):

import javax.mail.Session;

import javax.activation.DataHandler;
import javax.activation.DataSource;
import javax.mail.Message;
import javax.mail.MessagingException;
import javax.mail.SendFailedException;
import javax.mail.Session;
import javax.mail.Transport;
import javax.mail.internet.InternetAddress;
import javax.mail.internet.MimeBodyPart;
import javax.mail.internet.MimeMessage;
import javax.mail.internet.MimeMultipart;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.transform.stream.StreamSource;

import org.apache.fop.apps.Fop;
import org.apache.fop.apps.MimeConstants;
import org.apache.ofbiz.base.util.Debug;
import org.apache.ofbiz.base.util.GeneralException;
import org.apache.ofbiz.base.util.HttpClient;
import org.apache.ofbiz.base.util.HttpClientException;
import org.apache.ofbiz.base.util.UtilGenerics;
import org.apache.ofbiz.base.util.UtilMisc;
import org.apache.ofbiz.base.util.UtilProperties;
import org.apache.ofbiz.base.util.UtilValidate;
import org.apache.ofbiz.base.util.collections.MapStack;
import org.apache.ofbiz.base.util.string.FlexibleStringExpander;
import org.apache.ofbiz.entity.Delegator;
import org.apache.ofbiz.entity.GenericValue;
import org.apache.ofbiz.entity.util.EntityUtilProperties;
import org.apache.ofbiz.service.DispatchContext;
import org.apache.ofbiz.service.GenericServiceException;
import org.apache.ofbiz.service.LocalDispatcher;
import org.apache.ofbiz.service.ServiceUtil;
impor

Re: Send E-Mails

2019-03-26 Thread Jacques Le Roux

Hi Gil,

Let me check

Jacques

Le 26/03/2019 à 08:56, Gil Portenseigne a écrit :

Hello there,

Do somes actions have been taken on documenting the existence of
SystemProperty ?

I like the idea of migrating documentation into embedded one.

I just wanted to add a note into https://s.apache.org/BPJ5 that alert
about SystemProperty, but i seem to miss the modification permission...
can someone grant me access ?

Thanks

Gil


Le 12:50 - vendredi 11 mai, Taher Alkhateeb a écrit :

Actually, I think whatever need to be documented is best placed in our
embedded documentation. We should probably consider freezing all new
documentation in any place that is not the embedded documentation and try
to migrate everything to it. So email setting docs could be placed
somewhere in our user manual.

On Fri, May 11, 2018, 11:51 AM Jacques Le Roux 
wrote:


Hi Rishi,


Le 09/05/2018 à 11:12, Rishi Solanki a écrit :

Community, I think we should mention the SystemProperty where required in
Production Setup Guide or may be we can add version of production setup
guide which will tells user upto which release this production setup

guide

will work. I know we discuss this kind of effort in past for all the
documents and we agree on some point. But this is quicker to manage
Production Setup Guide, if we agree then I can do it.

Yes good idea, a simple information for concerned versions in the current
Production Setup Guide fits with me

Jacques

I'm fine with either change the existing one or maintain the version. But
first we should have one which works always with latest. Thanks!


Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co

On Wed, May 9, 2018 at 3:33 AM, i...@agentur-m3.de 
wrote:


Hello,

here is a problem with my e-mail base-configuration.

I configured email according to the setup guide:



https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Technical+

Production+Setup+Guide#ApacheOFBizTechnicalProduction
SetupGuide-EmailServerSettings


Unfortunately no email seems to be sent from server
(the send email button in partymgr works fine now (thanks to Jacques!),
but no email reaches client). No error message, no error in log.

Also I tried to register in the ecommerce system and send
an "Forgot Your Password" email, but none of the emails were sent.

To get more info about the problem, I wrote a groovy script and copied
parts of the sendEmail-code from EmailServices.java.
The script below surprisingly works fine and sends emails!

So I don't understand, why OFBiz itself does not send mails.
Is there any further configuration necessary?



The script (which sends mails):

import javax.mail.Session;

import javax.activation.DataHandler;
import javax.activation.DataSource;
import javax.mail.Message;
import javax.mail.MessagingException;
import javax.mail.SendFailedException;
import javax.mail.Session;
import javax.mail.Transport;
import javax.mail.internet.InternetAddress;
import javax.mail.internet.MimeBodyPart;
import javax.mail.internet.MimeMessage;
import javax.mail.internet.MimeMultipart;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.transform.stream.StreamSource;

import org.apache.fop.apps.Fop;
import org.apache.fop.apps.MimeConstants;
import org.apache.ofbiz.base.util.Debug;
import org.apache.ofbiz.base.util.GeneralException;
import org.apache.ofbiz.base.util.HttpClient;
import org.apache.ofbiz.base.util.HttpClientException;
import org.apache.ofbiz.base.util.UtilGenerics;
import org.apache.ofbiz.base.util.UtilMisc;
import org.apache.ofbiz.base.util.UtilProperties;
import org.apache.ofbiz.base.util.UtilValidate;
import org.apache.ofbiz.base.util.collections.MapStack;
import org.apache.ofbiz.base.util.string.FlexibleStringExpander;
import org.apache.ofbiz.entity.Delegator;
import org.apache.ofbiz.entity.GenericValue;
import org.apache.ofbiz.entity.util.EntityUtilProperties;
import org.apache.ofbiz.service.DispatchContext;
import org.apache.ofbiz.service.GenericServiceException;
import org.apache.ofbiz.service.LocalDispatcher;
import org.apache.ofbiz.service.ServiceUtil;
import org.apache.ofbiz.service.mail.MimeMessageWrapper;
import org.apache.ofbiz.webapp.view.ApacheFopWorker;
import org.apache.ofbiz.widget.renderer.macro.MacroScreenRenderer;
import org.apache.ofbiz.widget.renderer.ScreenRenderer;
import org.apache.ofbiz.widget.renderer.ScreenStringRenderer;
import org.xml.sax.SAXException;

def testMail() {
  sendType = "mail.smtp.host"
  sendVia = "smtp.myhost.com"
  Properties props = System.getProperties()
  props.put(sendType, sendVia)
  Session session
  session = Session.getInstance(props);
  MimeMessage mail
  mail = new MimeMessage(session);
  Transport trans = null
  sendFrom = "obfiz.example.com"
  sendTo = "m...@myserver.de"
  

Re: svn commit: r1855798 - /ofbiz/ofbiz-framework/trunk/build.gradle

2019-03-23 Thread Jacques Le Roux

Ah forgot we have that pending also: 
https://cwiki.apache.org/confluence/display/OFBIZ/Guidelines+For+Using+JIRA

Le 23/03/2019 à 11:59, Jacques Le Roux a écrit :

Hi Mathieu,

Le 20/03/2019 à 22:19, Mathieu Lirzin a écrit :

I must confess that the policy regarding how refactoring (done by
committers) must be handled in term of JIRA creation, is not clear to
me.  The block “When to create a Jira issue” on OFBiz wiki [1] is not
helping much in that regard.  Maybe there is an implicit consensus in
that regard that I am not aware of?

My reasoning for not creating a JIRA was that those commits are pure
refactoring meaning they are implementation details that don't change
the observable behavior of the build and they are not part of a global
plan.  Basically those cleanups happened by looking around while working
on OFBIZ-10866 [2] but are unrelated to the endeavour of that task.

What would you recommend in that scenario?
I don't remember that we discussed specifically about Jira and refactoring (with no functional changes, which is the implicit definition of 
refactoring). At least we did not write about it.


One thing I do for very simple no functional changes (not only for refactoring) 
is to use this syntax in commits comments :

   Improved: no functional change

   Explanations...

When the changes are considerable (which is subjective, it's hard to set a 
line) I create a Jira and explain the changes.

We could write something about that in the wiki section “When to create a Jira issue” which is quite old and has not been reviewed for a long time. 
Rest that it will always be subjective, we can say that.


The same idea applies to Javadoc changes: big one a Jira, simple one no Jira.

It's a matter of judgement, when it take much more time to create a Jira than 
to only explain in a commit comment for instance.

The changes you did (from r1855674 to r1855798) did not hurt me. I just reviewed again and for me none of them need more explanations than in the 
commits.


Now, the fact that there was 9 commits in a row could be interpreted as a 
substantial change and maybe explains Michael's perspective.
Then maybe a Jira referring to these commits with a summary in description could help reassuring users about these changes. Both (Jira or not) fits 
with me in this case.


My 2cts

Jacques




Re: svn commit: r1855798 - /ofbiz/ofbiz-framework/trunk/build.gradle

2019-03-23 Thread Jacques Le Roux

Hi Mathieu,

Le 20/03/2019 à 22:19, Mathieu Lirzin a écrit :

I must confess that the policy regarding how refactoring (done by
committers) must be handled in term of JIRA creation, is not clear to
me.  The block “When to create a Jira issue” on OFBiz wiki [1] is not
helping much in that regard.  Maybe there is an implicit consensus in
that regard that I am not aware of?

My reasoning for not creating a JIRA was that those commits are pure
refactoring meaning they are implementation details that don't change
the observable behavior of the build and they are not part of a global
plan.  Basically those cleanups happened by looking around while working
on OFBIZ-10866 [2] but are unrelated to the endeavour of that task.

What would you recommend in that scenario?
I don't remember that we discussed specifically about Jira and refactoring (with no functional changes, which is the implicit definition of 
refactoring). At least we did not write about it.


One thing I do for very simple no functional changes (not only for refactoring) 
is to use this syntax in commits comments :

   Improved: no functional change

   Explanations...

When the changes are considerable (which is subjective, it's hard to set a 
line) I create a Jira and explain the changes.

We could write something about that in the wiki section “When to create a Jira issue” which is quite old and has not been reviewed for a long time. 
Rest that it will always be subjective, we can say that.


The same idea applies to Javadoc changes: big one a Jira, simple one no Jira.

It's a matter of judgement, when it take much more time to create a Jira than 
to only explain in a commit comment for instance.

The changes you did (from r1855674 to r1855798) did not hurt me. I just reviewed again and for me none of them need more explanations than in the 
commits.


Now, the fact that there was 9 commits in a row could be interpreted as a 
substantial change and maybe explains Michael's perspective.
Then maybe a Jira referring to these commits with a summary in description could help reassuring users about these changes. Both (Jira or not) fits 
with me in this case.


My 2cts

Jacques



Re: OFBiz Video Tutorial Series

2019-03-18 Thread Jacques Le Roux

Just had a quick look, it sounds quite promising!

Thanks Pranay and Swapnil for this effort

Looking forward

Jacques

Le 18/03/2019 à 15:08, Swapnil M Mane a écrit :

Hello team,

Here are some updates on the OFBiz video tutorial effort.
As a first step, created a playlist for Apache OFBiz [1].

Highlights of this playlist are
1.) It contains the videos in a sequential manner from beginner to expert.
2.) This playlist will *always* be in sync with the trunk branch.
The main idea is to always have videos which work with OFBiz trunk branch.
This surely helps the beginner developers.

Thus, I have made some changes in the video description, like added the
following information in the video description -
"Reference OFBiz release in the video is Release 16.11. This process will
also work with the OFBiz trunk branch."

In the future, if any video is not synced with trunk, we will create the
new video and will add it in the playlist. The title of the old video will
be changed and will include the compatible release-specific detail.

I am currently working on 'OFBiz directory structure and component' video,
after adding it in the playlist. I will share the playlist information on
the user mailing list also.

Thanks, Pranay Pandey for your continuous contribution and help on this.
Everyone, please feel free to add your comments and thoughts.

[1]
https://www.youtube.com/watch?v=bIS2kftvsq4=PLobIkeUbRXqc-lwvbdbajPJdbWjFm82Dj

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



Re: gradlew generateOfbizDocumentation error

2019-03-18 Thread Jacques Le Roux

Thanks Mathieu,

At least we could comment it out. So people interested (good luck) would be 
able to use it.

HTH

Jacques

Le 18/03/2019 à 14:21, Mathieu Lirzin a écrit :

Hello,

Jacques Le Roux  writes:


A Jira is appropriate

In the meantime I have investigated, and it seems that revision 1854818
introduced this issue. When I comment the OWASP plugin line things works
again.  I don't understand the rationale of this bug but maybe this is
an argument for removing the OWASP plugin as you suggested on the ML.


Le 18/03/2019 à 09:46, Olivier Heintz a écrit :

Hello,

on trunk, last release
gradlew generateOfbizDocumentation
generate an error message :

-
└─$ ./gradlew generateOfbizDocumentation

Task :generateOfbizDocumentation FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':generateOfbizDocumentation'.

(LoadError) no such file to load -- asciidoctor

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org


on svn release 1854593 generation seems correct
with 1854595 generation works but with a lot of messages
with 1854818 generation failed

on trunk , if I remove line
      id 'org.owasp.dependencycheck' version '3.0.2' apply false

generation works but with a lot of messages.




Re: gradlew generateOfbizDocumentation error

2019-03-18 Thread Jacques Le Roux

Thanks Olivier,

A Jira is appropriate

Jacques

Le 18/03/2019 à 09:46, Olivier Heintz a écrit :

Hello,

on trunk, last release
gradlew generateOfbizDocumentation
generate an error message :

-
└─$ ./gradlew generateOfbizDocumentation

Task :generateOfbizDocumentation FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':generateOfbizDocumentation'.

(LoadError) no such file to load -- asciidoctor

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org


on svn release 1854593 generation seems correct
with 1854595 generation works but with a lot of messages
with 1854818 generation failed

on trunk , if I remove line
     id 'org.owasp.dependencycheck' version '3.0.2' apply false

generation works but with a lot of messages.




Fwd: Confluence Upgrade Monday and LDAP enable

2019-03-17 Thread Jacques Le Roux

Forwarded, for committers only

Jacques


 Message transféré 
Sujet : Confluence Upgrade Monday and LDAP enable
Date :  Sat, 16 Mar 2019 19:43:28 +
De :Gavin McDonald 
Répondre à :us...@infra.apache.org
Pour :  committ...@apache.org,  



Hi All,

Confluence will be upgraded to the latest release on Monday 19th March starting 
at 11am. Backups will be taken. The service is moving to a new VM.

After a month of testing and feedback, we are also happy to proceed and enable LDAP on the service. Should you not have your Confluence username match 
your asf id then get a infra jira in quick.


Downtime should be around 3 hours.

Thanks

Gav... (ASF Infra)


Re: svn commit: r1854306 - /ofbiz/ofbiz-framework/trunk/framework/common/config/CommonUiLabels.xml

2019-03-14 Thread Jacques Le Roux

Thanks Deepak!

Le 14/03/2019 à 10:38, Deepak Dixit a écrit :

Done, Committed slightly modified version of the suggested patch.

Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org


On Thu, Mar 14, 2019 at 2:41 PM Deepak Dixit  wrote:


Sure Jacques, Will do
Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org


On Thu, Mar 14, 2019 at 2:16 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Thanks Deepak,

Unfortunately it's difficult to use it as us and I have not created a
Jira for that.

Could you please commit it?

TIA

Jacques

Le 13/03/2019 à 06:42, Deepak Dixit a écrit :

Hi Jacques,

I tested the following patch and it works
=

Index: build.gradle

===

--- build.gradle (revision 1855081)

+++ build.gradle (working copy)

@@ -638,7 +638,7 @@

   revision = revisionOutput.toString()

   gitFooterFile.delete()

   gitFooterFile.createNewFile()

-gitFooterFile << '${uiLabelMap.CommonBranch} : ' + "${branch}"

+

System.lineSeparator()

+gitFooterFile << ' ${uiLabelMap.CommonBranch} : ' +

"${branch}" +

System.lineSeparator()

   gitFooterFile << '${uiLabelMap.CommonRevision} : ' +

"${revision}"

+ System.lineSeparator()

   gitFooterFile << '${uiLabelMap.CommonBuiltOn} : ' +

"${timestamp}"

+ System.lineSeparator()

   gitFooterFile << '${uiLabelMap.CommonJavaVersion} : ' +
"${org.gradle.internal.jvm.Jvm.current()}"

@@ -663,7 +663,7 @@

   def info = new XmlParser().parseText(svnOutput.toString())

   svnFooterFile.delete()

   svnFooterFile.createNewFile()

-svnFooterFile << '${uiLabelMap.CommonBranch} : ' +
"${info.entry.url.text()}" + System.lineSeparator()

+svnFooterFile << ' ${uiLabelMap.CommonBranch} : ' +
"${info.entry.url.text()}" + System.lineSeparator()

   svnFooterFile << '${uiLabelMap.CommonRevision} : ' +
"${info.entry.commit.@revision}" + System.lineSeparator()

   svnFooterFile << '${uiLabelMap.CommonBuiltOn} : ' +

"${timestamp}"

+ System.lineSeparator()

   svnFooterFile << '${uiLabelMap.CommonJavaVersion} : ' +
"${org.gradle.internal.jvm.Jvm.current()}"

Index: framework/common/config/CommonUiLabels.xml

===

--- framework/common/config/CommonUiLabels.xml (revision 1855081)

+++ framework/common/config/CommonUiLabels.xml (working copy)

@@ -1389,9 +1389,9 @@

   回報

   

   

- branch

- rama

- branche

+    branch

+rama

+branche

   

   

   built on


=


Kind Regards,
Deepak Dixit

On Wed, Mar 13, 2019 at 2:16 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Actually I changed it there because it does not work in build.gradle

where

it's already

gitFooterFile << '${uiLabelMap.CommonBranch} : ' + "${branch}" +
System.lineSeparator()

svnFooterFile << '${uiLabelMap.CommonBranch} : ' +
"${info.entry.url.text()}" + System.lineSeparator()

Jacques

Le 12/03/2019 à 10:33, Jacques Le Roux a écrit :

Agreed Deepak,

Makes sense, I 'll change that

Thanks

Jacques

Le 12/03/2019 à 10:07, Deepak Dixit a écrit :

Hi Jacques,

I think instead of adding space in uiLabel it would be food if we add

space in the template

Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org <http://ofbiz.apache.org>


On Mon, Feb 25, 2019 at 4:03 PM 
jler...@apache.org>> wrote:

  Author: jleroux
  Date: Mon Feb 25 10:33:53 2019
  New Revision: 1854306

  URL: http://svn.apache.org/viewvc?rev=1854306=rev
  Log:
  Improved: no functional change

  A missing space before CommonBranch label made the word

trunkbranch

instead of

  trunk branch.

  I'll backport this

  Modified:


  ofbiz/ofbiz-framework/trunk/framework/common/config/CommonUiLabels.xml

  Modified:

ofbiz/ofbiz-framework/trunk/framework/common/config/CommonUiLabels.xml

  URL:


http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/common/config/CommonUiLabels.xml?rev=1854306=1854305=1854306=diff
  ==

  ---

ofbiz/ofbiz-framework/trunk/framework/common/config/CommonUiLabels.xml
(original)

  +++

ofbiz/ofbiz-framework/trunk/framework/common/config/CommonUiLabels.xml

Mon

Feb 25 10:33:53 2019

  @@ -1389,9 +1389,9 @@
   å›žå ±
   
   
  -branch
  -rama
  -branche
  + branch
  + rama
  + branche
   
   
   built on




Re: svn commit: r1854306 - /ofbiz/ofbiz-framework/trunk/framework/common/config/CommonUiLabels.xml

2019-03-14 Thread Jacques Le Roux

Thanks Deepak,

Unfortunately it's difficult to use it as us and I have not created a Jira for 
that.

Could you please commit it?

TIA

Jacques

Le 13/03/2019 à 06:42, Deepak Dixit a écrit :

Hi Jacques,

I tested the following patch and it works
=

Index: build.gradle

===

--- build.gradle (revision 1855081)

+++ build.gradle (working copy)

@@ -638,7 +638,7 @@

  revision = revisionOutput.toString()

  gitFooterFile.delete()

  gitFooterFile.createNewFile()

-gitFooterFile << '${uiLabelMap.CommonBranch} : ' + "${branch}" +
System.lineSeparator()

+gitFooterFile << ' ${uiLabelMap.CommonBranch} : ' + "${branch}" +
System.lineSeparator()

  gitFooterFile << '${uiLabelMap.CommonRevision} : ' + "${revision}"
+ System.lineSeparator()

  gitFooterFile << '${uiLabelMap.CommonBuiltOn} : ' + "${timestamp}"
+ System.lineSeparator()

  gitFooterFile << '${uiLabelMap.CommonJavaVersion} : ' +
"${org.gradle.internal.jvm.Jvm.current()}"

@@ -663,7 +663,7 @@

  def info = new XmlParser().parseText(svnOutput.toString())

  svnFooterFile.delete()

  svnFooterFile.createNewFile()

-svnFooterFile << '${uiLabelMap.CommonBranch} : ' +
"${info.entry.url.text()}" + System.lineSeparator()

+svnFooterFile << ' ${uiLabelMap.CommonBranch} : ' +
"${info.entry.url.text()}" + System.lineSeparator()

  svnFooterFile << '${uiLabelMap.CommonRevision} : ' +
"${info.entry.commit.@revision}" + System.lineSeparator()

  svnFooterFile << '${uiLabelMap.CommonBuiltOn} : ' + "${timestamp}"
+ System.lineSeparator()

  svnFooterFile << '${uiLabelMap.CommonJavaVersion} : ' +
"${org.gradle.internal.jvm.Jvm.current()}"

Index: framework/common/config/CommonUiLabels.xml

===

--- framework/common/config/CommonUiLabels.xml (revision 1855081)

+++ framework/common/config/CommonUiLabels.xml (working copy)

@@ -1389,9 +1389,9 @@

  回報

  

  

- branch

- rama

- branche

+branch

+    rama

+branche

  

  

  built on


=


Kind Regards,
Deepak Dixit

On Wed, Mar 13, 2019 at 2:16 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Actually I changed it there because it does not work in build.gradle where
it's already

gitFooterFile << '${uiLabelMap.CommonBranch} : ' + "${branch}" +
System.lineSeparator()

svnFooterFile << '${uiLabelMap.CommonBranch} : ' +
"${info.entry.url.text()}" + System.lineSeparator()

Jacques

Le 12/03/2019 à 10:33, Jacques Le Roux a écrit :

Agreed Deepak,

Makes sense, I 'll change that

Thanks

Jacques

Le 12/03/2019 à 10:07, Deepak Dixit a écrit :

Hi Jacques,

I think instead of adding space in uiLabel it would be food if we add

space in the template

Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org <http://ofbiz.apache.org>


On Mon, Feb 25, 2019 at 4:03 PM 
jler...@apache.org>> wrote:

 Author: jleroux
 Date: Mon Feb 25 10:33:53 2019
 New Revision: 1854306

 URL: http://svn.apache.org/viewvc?rev=1854306=rev
 Log:
 Improved: no functional change

 A missing space before CommonBranch label made the word trunkbranch

instead of

 trunk branch.

 I'll backport this

 Modified:


  ofbiz/ofbiz-framework/trunk/framework/common/config/CommonUiLabels.xml

 Modified:

ofbiz/ofbiz-framework/trunk/framework/common/config/CommonUiLabels.xml

 URL:


http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/common/config/CommonUiLabels.xml?rev=1854306=1854305=1854306=diff
  ==

 ---

ofbiz/ofbiz-framework/trunk/framework/common/config/CommonUiLabels.xml
(original)

 +++

ofbiz/ofbiz-framework/trunk/framework/common/config/CommonUiLabels.xml Mon
Feb 25 10:33:53 2019

 @@ -1389,9 +1389,9 @@
  å›žå ±
  
  
 -branch
 -rama
 -branche
 + branch
 + rama
 + branche
  
  
  built on




Issue with images path

2019-03-14 Thread Jacques Le Roux

Hi All,

While working on https://markmail.org/message/q5etvmwtkswgyakj I noticed this 
issue

2019-03-14 09:28:01,585 |sse-nio-8443-exec-10 |ControlServlet    |T| [[[images(Domain:https://localhost)] Request Begun, encoding=[UTF-8]- 
total:0.0,since last(Begin):0.0]]

2019-03-14 09:28:01,586 |sse-nio-8443-exec-10 |ControlServlet    
|E| Error in request handler:
org.apache.ofbiz.webapp.control.RequestHandlerException: Unknown request 
[images]; this request does not exist or cannot be called directly.

I checked I have no locally specific related changes. Sorry I have no more time 
to look at it now...

Jacques



Re: svn commit: r1854306 - /ofbiz/ofbiz-framework/trunk/framework/common/config/CommonUiLabels.xml

2019-03-12 Thread Jacques Le Roux

Actually I changed it there because it does not work in build.gradle where it's 
already

gitFooterFile << '${uiLabelMap.CommonBranch} : ' + "${branch}" + 
System.lineSeparator()

svnFooterFile << '${uiLabelMap.CommonBranch} : ' + "${info.entry.url.text()}" + 
System.lineSeparator()

Jacques

Le 12/03/2019 à 10:33, Jacques Le Roux a écrit :


Agreed Deepak,

Makes sense, I 'll change that

Thanks

Jacques

Le 12/03/2019 à 10:07, Deepak Dixit a écrit :

Hi Jacques,

I think instead of adding space in uiLabel it would be food if we add space in 
the template

Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org <http://ofbiz.apache.org>


On Mon, Feb 25, 2019 at 4:03 PM mailto:jler...@apache.org>> wrote:

Author: jleroux
Date: Mon Feb 25 10:33:53 2019
New Revision: 1854306

URL: http://svn.apache.org/viewvc?rev=1854306=rev
Log:
Improved: no functional change

A missing space before CommonBranch label made the word trunkbranch instead 
of
trunk branch.

I'll backport this

Modified:
ofbiz/ofbiz-framework/trunk/framework/common/config/CommonUiLabels.xml

Modified: 
ofbiz/ofbiz-framework/trunk/framework/common/config/CommonUiLabels.xml
URL:

http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/common/config/CommonUiLabels.xml?rev=1854306=1854305=1854306=diff

==
--- ofbiz/ofbiz-framework/trunk/framework/common/config/CommonUiLabels.xml 
(original)
+++ ofbiz/ofbiz-framework/trunk/framework/common/config/CommonUiLabels.xml 
Mon Feb 25 10:33:53 2019
@@ -1389,9 +1389,9 @@
         å›žå ±
     
     
-        branch
-        rama
-        branche
+         branch
+         rama
+         branche
     
     
         built on




Re: Google Map in demo

2019-03-05 Thread Jacques Le Roux

Hi Nicolas,

Agreed, but who is jar :) ?

Jacques

Le 05/03/2019 à 18:02, Nicolas Malin a écrit :

Do need promote non free map solution ?

Like jar, I prefer keep on source code only community free service like OSM and 
document as information for other solution like googlemap

Nicolas

On 24/01/2019 10:50, Deepak Dixit wrote:

Google updated their licensing model and now you need a valid api key to
access the google api.

https://developers.google.com/maps/documentation/javascript/usage-and-billing


Thanks & Regards
--
Deepak Dixit



On Thu, Jan 24, 2019 at 2:12 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi,

I just spotted that now at the geolocation tab in example all the Google
Map examples a message from Google shows:

Do you own this website?
<
https://developers.google.com/maps/documentation/javascript/error-messages?utm_source=maps_js_medium=degraded_campaign=billing#api-key-and-billing-errors> 



with a button OK

Even if you valid, the result is random, most of the time not good

Not sure what we should do.

Ideas?

Jacques






Re: [REMOVE?] OWASP Dependency Check feature (Gradle plugin)

2019-03-05 Thread Jacques Le Roux

Done at revision 1854818.

Le 04/03/2019 à 11:14, Shi Jinghai a écrit :

+1 to the OWASP-failure patch.

I applied the patch and ran "gradlew -PenableOwasp dependencyCheckAnalyze" on Windows 10, 
JDK 8, "BUILD SUCCESSFUL in 23m 16s".


-邮件原件-
发件人: Mathieu Lirzin [mailto:mathieu.lir...@nereide.fr]
发送时间: 2019年3月3日 18:39
收件人: dev@ofbiz.apache.org
主题: Re: [REMOVE?] OWASP Dependency Check feature (Gradle plugin)

Hello Jacques,

Jacques Le Roux  writes:


I added the OWASP Dependency Check feature before we switched to
Gradle. It was then really useful, but it's no disputable as explained
at
https://cwiki.apache.org/confluence/display/OFBIZ/About+OWASP+Dependency+Check:

Since OFBiz uses Gradle, all dependent libraries (ie also
dependencies from the libraries OFBiz uses and recursively) are
loaded by Gradle and analysed by the OWASP Dependency Check
plugin. So it's materially impossible to check all the possible
vulnerabilities. I decided to only check the higher ones, currently
(2017-09-29) we have only already know ones:

So one option could be to completely remove this feature, what do you
think? (see more at OFBIZ-10700)

I am not familiar with OWASP dependency check, but since it doesn't work
on my machine (See OFBIZ-10700) I can hardly see any reason to keep it.



Re: [OPTIONS] Java 11 and Java JDK origin

2019-03-04 Thread Jacques Le Roux

Maybe adding a link to 
https://medium.com/@javachampions/java-is-still-free-2-0-0-6b9aa8d6d244 would 
help also

Le 04/03/2019 à 12:31, Jacques Le Roux a écrit :

+1

Jacques

Le 04/03/2019 à 11:34, Jacopo Cappellato a écrit :

I think that the simplest way to convey this message is to edit the README
document with a link to OpenJDK rather than Oracle JDK.

Jacopo

On Mon, Mar 4, 2019 at 10:22 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


We should then make clear to our users that they will need to switch to
OpenJDK if they want free security support.

I guess most are aware, but maybe not small companies or single users.

Jacques

Le 28/02/2019 à 18:48, Michael Brohl a écrit :

+1 for Taher's suggestion.

Thanks, Michael

Am 28.02.19 um 12:32 schrieb Taher Alkhateeb:

Perhaps we can keep ofbiz 17.12 on java 8, and let 18.12 and trunk
switch to java 11 on openjdk. This might provide stability expected by
users as indicated by Michael.

On Thu, Feb 28, 2019 at 2:27 PM Jacques Le Roux
 wrote:

Hi,

During discussions in the "Oracle Java release model changes and

consequences for the project" thread, we created "Upgrade OFBiz to use Java
JDK

Version 11" aka OFBIZ-10757.

There we began to discuss not only if we should switch to Java 11 LTS

(Long Time Support), which is obviously the best current choice, but also
which

Java JDK origin we should use OOTB.

So we have few options and we should clarify what the community wants.

Options are:

   1. Do we agree to use https://adoptopenjdk.net/releases.html as

Java JDK origin OOTB?

   2. Which branches should switch to Java1? Obviously the trunk and

R18 should. Should R17, which is not yet released, switch also?

I hope we don't need a vote and will quickly find a consensus.

Thanks

Jacques





Re: [OPTIONS] Java 11 and Java JDK origin

2019-03-04 Thread Jacques Le Roux

+1

Jacques

Le 04/03/2019 à 11:34, Jacopo Cappellato a écrit :

I think that the simplest way to convey this message is to edit the README
document with a link to OpenJDK rather than Oracle JDK.

Jacopo

On Mon, Mar 4, 2019 at 10:22 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


We should then make clear to our users that they will need to switch to
OpenJDK if they want free security support.

I guess most are aware, but maybe not small companies or single users.

Jacques

Le 28/02/2019 à 18:48, Michael Brohl a écrit :

+1 for Taher's suggestion.

Thanks, Michael

Am 28.02.19 um 12:32 schrieb Taher Alkhateeb:

Perhaps we can keep ofbiz 17.12 on java 8, and let 18.12 and trunk
switch to java 11 on openjdk. This might provide stability expected by
users as indicated by Michael.

On Thu, Feb 28, 2019 at 2:27 PM Jacques Le Roux
 wrote:

Hi,

During discussions in the "Oracle Java release model changes and

consequences for the project" thread, we created "Upgrade OFBiz to use Java
JDK

Version 11" aka OFBIZ-10757.

There we began to discuss not only if we should switch to Java 11 LTS

(Long Time Support), which is obviously the best current choice, but also
which

Java JDK origin we should use OOTB.

So we have few options and we should clarify what the community wants.

Options are:

   1. Do we agree to use https://adoptopenjdk.net/releases.html as

Java JDK origin OOTB?

   2. Which branches should switch to Java1? Obviously the trunk and

R18 should. Should R17, which is not yet released, switch also?

I hope we don't need a vote and will quickly find a consensus.

Thanks

Jacques



Re: [OPTIONS] Java 11 and Java JDK origin

2019-03-04 Thread Jacques Le Roux

We should then make clear to our users that they will need to switch to OpenJDK 
if they want free security support.

I guess most are aware, but maybe not small companies or single users.

Jacques

Le 28/02/2019 à 18:48, Michael Brohl a écrit :

+1 for Taher's suggestion.

Thanks, Michael

Am 28.02.19 um 12:32 schrieb Taher Alkhateeb:

Perhaps we can keep ofbiz 17.12 on java 8, and let 18.12 and trunk
switch to java 11 on openjdk. This might provide stability expected by
users as indicated by Michael.

On Thu, Feb 28, 2019 at 2:27 PM Jacques Le Roux
 wrote:

Hi,

During discussions in the "Oracle Java release model changes and consequences for the 
project" thread, we created "Upgrade OFBiz to use Java JDK
Version 11" aka OFBIZ-10757.

There we began to discuss not only if we should switch to Java 11 LTS (Long 
Time Support), which is obviously the best current choice, but also which
Java JDK origin we should use OOTB.

So we have few options and we should clarify what the community wants.

Options are:

  1. Do we agree to use https://adoptopenjdk.net/releases.html as Java JDK 
origin OOTB?
  2. Which branches should switch to Java1? Obviously the trunk and R18 should. 
Should R17, which is not yet released, switch also?

I hope we don't need a vote and will quickly find a consensus.

Thanks

Jacques





Re: [REMOVE?] OWASP Dependency Check feature (Gradle plugin)

2019-03-03 Thread Jacques Le Roux

Le 03/03/2019 à 10:53, Jacques Le Roux a écrit :
but it's no disputable as explained 

now



Re: svn propchange: r1854683 - svn:log

2019-03-03 Thread Jacques Le Roux

Hi Deepak,

Should we not make a reference to OFBIZ-10757? Even if it's not a final commit.

Jacques

Le 03/03/2019 à 11:34, dee...@apache.org a écrit :

Author: deepak
Revision: 1854683
Modified property: svn:log

Modified: svn:log at Sun Mar  3 10:34:36 2019
--
--- svn:log (original)
+++ svn:log Sun Mar  3 10:34:36 2019
@@ -1,3 +1,3 @@
-Preparation for JDK11 update, Updated code to fix following warning with 
respect to JDK11
-- Replaced Class::newInstance method occurrences
-- Removed deprecated override method Object::finalize
+Preparation for JDK11 update, Updated following code to fix warning with 
respect to JDK11
+- Replaced Class::newInstance occurrences
+- Removed deprecated override method Object::finalize




  1   2   3   4   5   6   7   8   9   10   >