Re: Cookie Consent In E-Coomerce

2019-06-15 Thread Jacques Le Roux

Hi,

Deepak has provided a working patch where he removed the 'Customized Cookies' 
feature of https://github.com/ketanmistry/ihavecookies

To compare apply the patch (directly on ecommerce component for now) load 
ecommerce in OFBiz and compare with https://iamketan.com.au/

I'm unsure it would be helpful but should not our users be able by default to 
have all the features?

Thanks

Jacques

Le 05/11/2018 à 05:43, Deepak Nigam a écrit :

FYI, here is the Jira ticket
<https://issues.apache.org/jira/browse/OFBIZ-10639> for further discussion
and research.

On Thu, Nov 1, 2018 at 3:02 PM Deepak Nigam 
wrote:


Thanks, Benjamin, Jacques.

Definitely, we will move forward only after studying  OFBiz cookies in
depth. I just put initial thought came to my mind.



On Wed, Oct 31, 2018 at 9:03 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Thanks Deepak, Benjamin,

We are indeed only concerned by the ecommerce webapps (both ecommerce and
ecomse). They are the sole to be public. The backend applications should
not
be concerned.

Actually, in ecommerce webapps, we use technical cookies: JSSESSIONID,
possibly cookie.domain and maybe jstree* ones. I believe they all fall in
the
exempt cases.

With OFBIZ-10635 I'm currently working on autoUserLoginId cookies. While
doing so I spotted that securedLoginId has the same duration (1 year) than
autoUserLoginId. I have reduced it to the browser session so it also
falls in the exempt cases. I'll commit that very soon.

I have not read all the details but I believe the only ones we should
think about are the autoUserLoginId and OFBiz.Visitor cookies. They
inherently
does not contain party data, but from the visitorId or userLoginId fields
it's possible to get to the party data. Not sure it's an issue as is,
because AFAIK we use only first‑party cookies[1] but the problem seems
their durations: one year.

[1]
https://www.opentracker.net/article/third-party-cookies-vs-first-party-cookies

Jacques

Le 31/10/2018 à 14:05, Benjamin Jugl a écrit :

Hello all,

just before you go in head over heels, please consider the following:

"However, some cookies are exempt from this requirement. Consent is
not required if the cookie is:

  * used for the sole purpose of carrying out the transmission of a
communication, and
  * strictly necessary in order for the provider of an information
society service explicitly required by the user to provide that
service.

Cookies clearly exempt from consent according to the EU advisory
body on data protection- WP29pdf
<

http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf

include:

  * *user‑input* cookies (session-id) such as first‑party cookies to
keep track of the user's input when filling online forms,
shopping carts, etc., for the duration of a session or
persistent cookies limited to a few hours in some cases
  * *authentication* cookies, to identify the user once he has
logged in, for the duration of a session
  * *user‑centric security* cookies, used to detect authentication
abuses, for a limited persistent duration
  * *multimedia content player* cookies, used to store technical
data to play back video or audio content, for the duration of a
session
  * *load‑balancing* cookies, for the duration of session
  * *user‑interface customisation* cookies such as language or font
preferences, for the duration of a session (or slightly longer)
  * *third‑party social plug‑in content‑sharing* cookies, for
logged‑in members of a social network."

(http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm)

Does OFBiz even set other cookies? If yes, for what are they needed?

Kind regards, Benjamin Jugl



On 31.10.18 13:11, Deepak Nigam wrote:

Hello All,

The Cookie Law is a piece of privacy legislation that requires

websites to

get consent from visitors to store or retrieve any information on their
computer, smartphone or tablet. It was designed to protect online

privacy,

by making consumers aware of how information about them is collected

and

used online, and give them a choice to allow it or not.

The EU Cookie Legislation began as a directive from the European Union.
Some variation on the policy has since been adopted by all countries

within

the EU.

The EU Cookie Legislation requires 4 actions from website owners who

use

cookies:
1. When someone visits your website, you need to let them know that

your

site uses cookies.
2. You need to provide detailed information regarding how that cookie

data

will be utilized.
3. You need to provide visitors with some means of accepting or

refusing

the use of cookies in your site.
4. If they refuse, you need to ensure that cookies will not be placed

on

their machine.

For more information about EU cookie policy, please visit here
<http://e

Re: Cookie Consent In E-Coomerce

2019-06-15 Thread Jacques Le Roux

Le 31/10/2018 à 16:32, Jacques Le Roux a écrit :
With OFBIZ-10635 I'm currently working on autoUserLoginId cookies. While doing so I spotted that securedLoginId has the same duration (1 year) than 
autoUserLoginId. I have reduced it to the browser session so it also falls in the exempt cases. I'll commit that very soon.


I have not read all the details but I believe the only ones we should think about are the autoUserLoginId and OFBiz.Visitor cookies. They inherently 
does not contain party data, but from the visitorId or userLoginId fields it's possible to get to the party data. Not sure it's an issue as is, 
because AFAIK we use only first‑party cookies[1] but the problem seems their durations: one year.


[1] 
https://www.opentracker.net/article/third-party-cookies-vs-first-party-cookies


I re-read above and the Benjamin's copy from " WP29pdf ".

It seems to me that autoUserLoginId and OFBiz.Visitor cookies don't fit in any 
of these categories, and we don't inform the visitor about these cookies.
Deepak's proposition in OFBIZ-10639 does not allow to not consent.  But I guess in this case it's the user's responsibility to quit the site before 
login in and so we are covered.


Please chime in if you disagree

Jacques



Re: Reply-to address missing for dev and user mailing list

2019-06-14 Thread Jacques Le Roux

Le 14/06/2019 à 11:03, Aditya Sharma a écrit :

The sole purpose of the mailing list is served only when the emails are
sent on the list so reply being its primary action need to point to the
list only.


Though I don't think

   "The sole purpose of the mailing list is served only when the emails are sent on 
the list"

and I don't like much statistics (percentage of other uses here), I tend to 
agree with you Aditya.

I rarely answer directly to a person before exchanging with her/him and then 
sending to the dev ML.
And when I do that I simply use "Reply All" and remove the dev ML before 
sending.

I must though say that I'm lucky to use Thunderbird which has the "Reply list" 
button (not OOTB IIRW).
So I'm able to never send a respond to dev ML, AND other people, in much cases.

But at the moment those who have not a such functionality at hand and want the 
same (reply only to list) must manually change things.
It's a bummer when you have other more important things to think about and do.

Do we need a vote here to temporarily adopt the not optimal solution (as in 
INFRA-18478), Mathieu?

And should we create a specific thread to decide on what do as optimal (ie 
based on a consensus or even a vote)?

Please refer to the links I posted above as food for thoughts, I copy them here:

http://www.unicom.com/pw/reply-to-harmful.html
http://david.woodhou.se/reply-to-list.html

Thanks

Jacques



Re: svn commit: r1861262 - /ofbiz/ofbiz-plugins/trunk/example/build.gradle

2019-06-14 Thread Jacques Le Roux

Sorry, forget it, it's only about websocket here, so needed

Le 13/06/2019 à 16:26, Jacques Le Roux a écrit :

Le 13/06/2019 à 16:21, jler...@apache.org a écrit :

Author: jleroux
Date: Thu Jun 13 14:21:48 2019
New Revision: 1861262

URL: http://svn.apache.org/viewvc?rev=1861262=rev
Log:
Improved: Update Tomcat to 9.0.21
(OFBIZ-11102)

Mostly because of various concurrency and stability fixes for HTTP/2 as reported
in the official announcement

Once again missed to commit in example/build.gradle

Modified:
 ofbiz/ofbiz-plugins/trunk/example/build.gradle

Modified: ofbiz/ofbiz-plugins/trunk/example/build.gradle
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/example/build.gradle?rev=1861262=1861261=1861262=diff
==
--- ofbiz/ofbiz-plugins/trunk/example/build.gradle (original)
+++ ofbiz/ofbiz-plugins/trunk/example/build.gradle Thu Jun 13 14:21:48 2019
@@ -18,5 +18,5 @@
   */
    dependencies {
-    pluginLibsCompile 'org.apache.tomcat.embed:tomcat-embed-websocket:9.0.19'
+    pluginLibsCompile 'org.apache.tomcat.embed:tomcat-embed-websocket:9.0.21'
  }
\ No newline at end of file



Hi,

Reading the initial log comment:

   <>

Do we really need  this line?

Jacques




Re: Reply-to address missing for dev and user mailing list

2019-06-14 Thread Jacques Le Roux

Hi Mathieu, All,

I think it's an important discussion, but I fear there will be a lot of 
bikeshedding too

Le 13/06/2019 à 15:19, Mathieu Lirzin a écrit :

Jacques Le Roux  writes:


Le 13/06/2019 à 13:02, Mathieu Lirzin a écrit :
Actually we should never use “Replying all” when replying to an ML.
Else you get these useless and annoying duplicates not filtered, that's what I 
meant.

If you have duplicates, then it's a bug in the mailing-list software
that should be reported to INFRA.  The right thing would be to not
resend an email to user both present in the recipients and subscribed to
a list (GNU Mailman is doing that).


By duplicates I mean emails sent to the dev ML and to me directly. That depends 
mostly on sender I guess.

For instance, I received 2 versions (one to the dev ML, one directly to me) 
from (almost?) all people welcoming Pawan and Deepak.
As it does not make sense to filter emails sent directly to me, all those messages (both of them) end in my main inbox folder and I have to put them 
manually in OFBiz.

I'd prefer to remove the duplicates (the ones sent directly to me) but it's too 
much work.
So I now have twice the size in this folder. As I keep archives of all messages for easier later searches it's a real problem for future (13.8 Go, for 
all msgs today)






We should use "Replied to List" when it exists. It appears for me in 
Thunderbird when fitting.
I hope other email clients and webmails are allowing the same.
I guess for that the reply-to value must be set to dev@ofbiz.apache.org and 
Infra can handle that.
It was working for a very long time and I suddenly these burst of duplicates, 
as Aditya found, don't you?

Asking people to use “Reply to list” would be acceptable if we were
assuming that everybody participating in the discussion is subscribed to
the mailing-list which is only partially true in our case, given our
current process which consist of accepting email from non-subscribed
users but yelling at them for not not being subscribed.


As a moderator I think we don't chastise enough people sending mails to the MLs 
w/o being subscribed! :D

Joke aside, I understand the "duplicates" issue depends on senders.
And (it seems?) only people using Thunderbird have the opportunity to have a Reply-to-list button, based on List-Post header[1][2] So when they reply 
using Reply-to they send 2 emails.


[1] https://www.ietf.org/rfc/rfc2369.txt
[2] https://github.com/k9mail/k-9/issues/2588

The ASF uses ezmlm, http://untroubled.org recommends 
(https://untroubled.org/ezmlmmanual/Replying.html)

   <>

I'm unsure, but it seems to me that I used “Reply-to” for years to send back only to the OFBiz MLs, before I had to turn to Reply to List and 
“Reply-to-all” (which fits to me. For me the problem is others senders)

So I guess then we had the setting "Reply-To: list@host" maybe as (not 
recommended) in[3] and as suggested by Deepak.

[3] 
http://untroubled.org/ezmlm/faq/Setting-Reply_002dTo-list_0040host.html#Setting-Reply_002dTo-list_0040host



Please configure your email client to add “Reply-to: dev@ofbiz.apache.org”
in the header of the messages you are sending to that list. That will
allow other email clients to automatically respect your personnal
preferences.


You mean that I do it once for a message to a list and then it's OK for all 
further messages to this list?
I'm not even sure how to do that in Thunderbird :/
And I want something quick to answer. A button to click, not to have to select 
in a drop-down or such. I pass already much time answering...

Anyway I need to read carefully
http://www.unicom.com/pw/reply-to-harmful.html
and
http://david.woodhou.se/reply-to-list.html

Before giving my opinion


I don't agree, as an ASF member I reply to a lot of MLs. I don't want to be 
bothered by that for all of them.
Deepak's answer with INFRA-18478 seems to be the way we should handle that.

I often don't want to cut the grass in my garden, but sometimes I have
too. ;-)

If you have a huge pile of ML subscriptions (50? 100?), you can
configure your email client incrementally each time you send an email to
a list that is not already configured and someday they will eventually
all be properly configured. \o/

Thanks.

I tried but could not find a way in a reasonable time

Jacques



Re: svn commit: r1861262 - /ofbiz/ofbiz-plugins/trunk/example/build.gradle

2019-06-13 Thread Jacques Le Roux

Le 13/06/2019 à 16:21, jler...@apache.org a écrit :

Author: jleroux
Date: Thu Jun 13 14:21:48 2019
New Revision: 1861262

URL: http://svn.apache.org/viewvc?rev=1861262=rev
Log:
Improved: Update Tomcat to 9.0.21
(OFBIZ-11102)

Mostly because of various concurrency and stability fixes for HTTP/2 as reported
in the official announcement

Once again missed to commit in example/build.gradle

Modified:
 ofbiz/ofbiz-plugins/trunk/example/build.gradle

Modified: ofbiz/ofbiz-plugins/trunk/example/build.gradle
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/example/build.gradle?rev=1861262=1861261=1861262=diff
==
--- ofbiz/ofbiz-plugins/trunk/example/build.gradle (original)
+++ ofbiz/ofbiz-plugins/trunk/example/build.gradle Thu Jun 13 14:21:48 2019
@@ -18,5 +18,5 @@
   */
  
  dependencies {

-pluginLibsCompile 'org.apache.tomcat.embed:tomcat-embed-websocket:9.0.19'
+pluginLibsCompile 'org.apache.tomcat.embed:tomcat-embed-websocket:9.0.21'
  }
\ No newline at end of file



Hi,

Reading the initial log comment:

   <>

Do we really need  this line?

Jacques



Re: Reply-to address missing for dev and user mailing list

2019-06-13 Thread Jacques Le Roux

Le 13/06/2019 à 14:37, Jacques Le Roux a écrit :

OK we need to clarify this with Infra, your link should help.
We should discuss it before exposing our conclusions to Infra

My 2cts

Jacques

Answering myself: maybe we can ask infra to add reply-to as in INFRA-18478 
while we discuss a better solution.

Doing that, we should let them know that we are not totally satisfied with the reply-to solution and are discussing about it. Maybe they will suggest 
something!


At least in the meantime we will not get all those duplicates :/

Of course for that we must agree it's a temporary solution... At least as long 
as we can't agree on better

Jacques



Re: Reply-to address missing for dev and user mailing list

2019-06-13 Thread Jacques Le Roux

Le 13/06/2019 à 14:27, Aditya Sharma a écrit :

Yes that's it. Who will handle it?

I will raise a Jira at infra if it's fine.


Please wait Aditya, I think Mathieu has a point here and we need to clarify
See my last previous message in response to him.

Thanks

Jacques



Re: Reply-to address missing for dev and user mailing list

2019-06-13 Thread Jacques Le Roux

Le 13/06/2019 à 14:23, Jacques Le Roux a écrit :

Matthieu,

Le 13/06/2019 à 14:08, Mathieu Lirzin a écrit :

Hello Deepak,

Deepak Dixit  writes:


On Thu, Jun 13, 2019 at 4:14 PM Mathieu Lirzin  
wrote:

  Hello Aditya,

  Aditya Sharma  writes:

  > We can configure reply-to email address for the mailing list which means
  > when the user clicks the reply button, the specified email address will be
  > automatically in the *To* field.

  I know some people here prefer their personal email address to not
  appear in the ‘To’ header when replying to them and the mailing-list but
  that's a personnal preference that can/should be defined only by the
  sender of a message not the administrators of a mailing-list. [1]

  Please configure your email client to add the ‘Reply-to’ header
  accordingly, but let others have different preferences. :-)

I think if we are doing communication on the mailing list, its good to
have mailing list address in reply-to irrespective personal
preference.  We can ask infra for the same.

I will answer to you by using a citation from
<http://www.unicom.com/pw/reply-to-harmful.html>

--8<---cut here---start->8---
Some administrators justify Reply-To munging by saying, "All responses
should go directly to the list anyway." This is arrogant. You should
allow me to decide exactly how I wish to respond to a message. If I feel
a public response is justified, I'll hit the "g" key and tell Elm to do
a group-reply. If I believe a private response is more appropriate, I'll
use "r" to send one. Please allow me the freedom to decide how to handle
a message.
--8<---cut here---end--->8---

Please read the arguments provided by this short article. I hope it will
let you understand the drawbacks of what you are proposing.

Thanks.


Then we should ask what Infra was doing before and discuss about it.
I hope that we will find a consensus and in the process discover why this 
changed recently. I like the way it worked so far

Jacques



Ah, I just tried something and I think I got your point.

You don't want to have to manually put the email address/es you want to respond 
to by hand.

And when I try to answer to myself to the message I answer here, I can only 
answer to the ML.

On the other hand, some months ago (in 2018 IIRW) I dropped the Reply to button.
It was because the behaviour then changed.
And it was easier then for me to have only a "Reply to list" and "Reply all" 
buttons.
Since then I use that and it's OK with me. I just have to remove now and then few email 
address I don't want to send when using the "Reply all" button.

And using "Reply all" for your last message I answer not only to you, but also 
to Deepak, Aditya and the ML.
So I clearly miss a "Reply to" button in this case (If I want to reply only to 
you).

OK we need to clarify this with Infra, your link should help.
We should discuss it before exposing our conclusions to Infra

My 2cts

Jacques



Re: Reply-to address missing for dev and user mailing list

2019-06-13 Thread Jacques Le Roux

Matthieu,

Le 13/06/2019 à 14:08, Mathieu Lirzin a écrit :

Hello Deepak,

Deepak Dixit  writes:


On Thu, Jun 13, 2019 at 4:14 PM Mathieu Lirzin  
wrote:

  Hello Aditya,

  Aditya Sharma  writes:

  > We can configure reply-to email address for the mailing list which means
  > when the user clicks the reply button, the specified email address will be
  > automatically in the *To* field.

  I know some people here prefer their personal email address to not
  appear in the ‘To’ header when replying to them and the mailing-list but
  that's a personnal preference that can/should be defined only by the
  sender of a message not the administrators of a mailing-list. [1]

  Please configure your email client to add the ‘Reply-to’ header
  accordingly, but let others have different preferences. :-)

I think if we are doing communication on the mailing list, its good to
have mailing list address in reply-to irrespective personal
preference.  We can ask infra for the same.

I will answer to you by using a citation from


--8<---cut here---start->8---
Some administrators justify Reply-To munging by saying, "All responses
should go directly to the list anyway." This is arrogant. You should
allow me to decide exactly how I wish to respond to a message. If I feel
a public response is justified, I'll hit the "g" key and tell Elm to do
a group-reply. If I believe a private response is more appropriate, I'll
use "r" to send one. Please allow me the freedom to decide how to handle
a message.
--8<---cut here---end--->8---

Please read the arguments provided by this short article. I hope it will
let you understand the drawbacks of what you are proposing.

Thanks.


Then we should ask what Infra was doing before and discuss about it.
I hope that we will find a consensus and in the process discover why this 
changed recently. I like the way it worked so far

Jacques



Re: Reply-to address missing for dev and user mailing list

2019-06-13 Thread Jacques Le Roux

Le 13/06/2019 à 13:35, Aditya Sharma a écrit :

Sorry for bothering you for that Jacques. Even I like my inbox clean and it
bothers me when any filtered email finds it's way to my inbox. Anyways I
will be more careful further.


Oh I did not mean that, actually I did not get your mail at 1st reading and then striked the 1st section of my email out, but of course it does not 
work for plain text.



But yes we cannot expect everyone using the mailing list making sure to use
the right way (manually removing the personal email ids).

Thanks Deepak for sharing the ticket :)


Yes that's it. Who will handle it?

Jacques



Thanks and Regards,
Aditya Sharma

On Thu, Jun 13, 2019 at 5:00 PM Deepak Dixit  wrote:


On Thu, Jun 13, 2019 at 4:14 PM Mathieu Lirzin 
wrote:


Hello Aditya,

Aditya Sharma  writes:


We can configure reply-to email address for the mailing list which

means

when the user clicks the reply button, the specified email address will

be

automatically in the *To* field.

I know some people here prefer their personal email address to not
appear in the ‘To’ header when replying to them and the mailing-list but
that's a personnal preference that can/should be defined only by the
sender of a message not the administrators of a mailing-list. [1]

Please configure your email client to add the ‘Reply-to’ header
accordingly, but let others have different preferences. :-)


I think if we are doing communication on the mailing list, its good to have
mailing list address in reply-to irrespective personal preference.
We can ask infra for the same.


Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org



When you click on the reply button for notifications or commits emails

it

automatically adds dev@ofbiz.apache.org as *To *field but in case of

dev or

user list, the sender's email address is added.

If things are properly configured then the ‘reply-to’ is set by
‘svnmailer’ (the program sending commit emails) not the mailing list
administrator.


If I am replying to an email sent by you, only your email will be
added to *To* field. Thus more chances of skipping the mailing list.

[...]

We will now have to use reply-all every time.

Yes, this is how it is supposed to work, you should use "Reply all" when
communicating with a group of people.

[1] http://www.unicom.com/pw/reply-to-harmful.html

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



Re: Reply-to address missing for dev and user mailing list

2019-06-13 Thread Jacques Le Roux

Le 13/06/2019 à 13:02, Mathieu Lirzin a écrit :

Hello Jacques

Jacques Le Roux  writes:


1st please when you answer to dev ML don't add my email to this
answer. I continuously and indefectibly follows this ML (as we are
required as committer). I have an email filter to redirect all dev ML
emails to a dev ML folder in my email clients (Thunderbird). Actually
I have 263 such filters (OK I filter a lot :D). It's not much about
you but I have seen a such pattern appearing these last times. So
please guys, we don't need a copy ;)

Asking every person on that list to remember your personnal preferences
and requiring them to manually remove your email address from recipients
when using “Replying all” does not scale. :-)


Actually we should never use “Replying all” when replying to an ML.
Else you get these useless and annoying duplicates not filtered, that's what I 
meant.

We should use "Replied to List" when it exists. It appears for me in 
Thunderbird when fitting.
I hope other email clients and webmails are allowing the same.
I guess for that the reply-to value must be set to dev@ofbiz.apache.org and 
Infra can handle that.
It was working for a very long time and I suddenly these burst of duplicates, 
as Aditya found, don't you?



Please configure your email client to add “Reply-to: dev@ofbiz.apache.org”
in the header of the messages you are sending to that list. That will
allow other email clients to automatically respect your personnal
preferences.


I don't agree, as an ASF member I reply to a lot of MLs. I don't want to be 
bothered by that for all of them.
Deepak's answer with INFRA-18478 seems to be the way we should handle that.

Jacques


Re: Reply-to address missing for dev and user mailing list

2019-06-13 Thread Jacques Le Roux

+1

Jacques

Le 13/06/2019 à 13:30, Deepak Dixit a écrit :

I think if we are doing communication on the mailing list, its good to have
mailing list address in reply-to irrespective personal preference.
We can ask infra for the same.




Re: Reply-to address missing for dev and user mailing list

2019-06-13 Thread Jacques Le Roux

Aditya,

1st please when you answer to dev ML don't add my email to this answer. I continuously and indefectibly follows this ML (as we are required as 
committer). I have an email filter to redirect all dev ML emails to a dev ML folder in my email clients (Thunderbird). Actually I have 263 such 
filters (OK I filter a lot :D). It's not much about you but I have seen a such pattern appearing these last times. So please guys, we don't need a copy ;)


OK I have not this problem because I tweaked Thunderbird to have only 2 buttons:

 * "Reply to list" (it exists OOTB and works only for MLs) and
 * "Reply to All" OOTB also I then remove the ones I don't want to send to.

This said I don't use Gmail (seen in your screenshots) and I'm not confident in any Google tools at all, I only use them when I'm forced to, paid work 
generally. So I understand now this burst of copies I speak about above (striked out, but not in plain text). And I guess I had to make the changes I 
speak above when this started to happen. I have no clues yet. I'll 1st look to see if we can resolved that by ourselves, I guess we will need Infra help.


I'll keep you informed

Jacques

Le 13/06/2019 à 11:41, Aditya Sharma a écrit :

Hi Jacques,

We can configure reply-to email address for the mailing list which means
when the user clicks the reply button, the specified email address will be
automatically in the *To* field.

When you click on the reply button for notifications or commits emails it
automatically adds dev@ofbiz.apache.org as *To *field but in case of dev or
user list, the sender's email address is added. If I am replying to an
email sent by you, only your email will be added to *To* field. Thus more
chances of skipping the mailing list.
You can see reply-to email address using the show details. I have attached
some screenshots.

  Screenshot from 2019-06-13 14-41-14.png
<https://drive.google.com/a/hotwaxsystems.com/file/d/13oRTEZr3825jYMXK8mx4F_He9BhzHy4I/view?usp=drive_web>
  Screenshot from 2019-06-13 14-44-23.png
<https://drive.google.com/a/hotwaxsystems.com/file/d/15OEB-nBQIVkb6RN4E_06da3Pdw1az5fN/view?usp=drive_web>

Earlier it was working fine(It works right see email titled Re:
[DISCUSSION] Having to use parent tickets to group tickets).
  Screenshot from 2019-06-13 15-03-37.png
<https://drive.google.com/a/hotwaxsystems.com/file/d/1AuKUmI3f2ewTlccHUqTmh5mSvH1vx922/view?usp=drive_web>

We will now have to use reply-all every time.


On Thu, Jun 13, 2019 at 2:30 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Aditya,

I don't clearly understand the problem. I can see the thread <> on both

Markmail https://s.apache.org/H751 (needs Flash)

and

lists.apache.org: https://s.apache.org/X5If

I can also respond to either dev ML, Mathieu or both from the initial
Mathieu's message (only Michael did so far)

Jacques

Le 13/06/2019 à 07:22, Aditya Sharma a écrit :

Hi team,
It seems reply-to address configuration is missing for some emails from

dev

and user mailing list (for reference see *Removing support for global
"ofbiz-containers.xml"*) while I can still find it on the notifications
mailing list.
Anyone having any idea about it?

Thanks and regards,
Aditya Sharma



Re: Reply-to address missing for dev and user mailing list

2019-06-13 Thread Jacques Le Roux

Hi Aditya,

I don't clearly understand the problem. I can see the thread <> on both

Markmail https://s.apache.org/H751 (needs Flash)

and

lists.apache.org: https://s.apache.org/X5If

I can also respond to either dev ML, Mathieu or both from the initial Mathieu's 
message (only Michael did so far)

Jacques

Le 13/06/2019 à 07:22, Aditya Sharma a écrit :

Hi team,
It seems reply-to address configuration is missing for some emails from dev
and user mailing list (for reference see *Removing support for global
"ofbiz-containers.xml"*) while I can still find it on the notifications
mailing list.
Anyone having any idea about it?

Thanks and regards,
Aditya Sharma



Re: Ofbiz Support

2019-06-13 Thread Jacques Le Roux

Hi Lesley ,

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 13/06/2019 à 09:22, lesley Netshiavhela a écrit :

Good day,

We currently on very early stage of assessing OFbiz on our organization, so
far every body is impressed and they think it meets their
minimum requirements.

My Manager was asking, if ever we reach a problem that we can not resolve
as team here in South Africa,  how do we get professional support from
ofbiz team?

Your help will be mush appreciated.




Welcome to Pawan Verma as new committer!

2019-06-12 Thread Jacques Le Roux

The OFBiz PMC has invited Pawan to become a new committer and we are pleased  
to announce that he has accepted.

Pawan is part of the community for 2 years and has being quite active and 
proficient, notably these last times with several smart propositions.

He also helps a lot of Jiras and answers properly on MLs.

Please join me in welcoming and congratulating Pawan.

Jacques



Welcome to Deepak Nigam as new committer!

2019-06-12 Thread Jacques Le Roux

The OFBiz PMC has invited Deepak to become a new committer and we are pleased  
to announce that he has accepted.

Deepak  is part of the community since January 2016 and has proved to be 
committed since.

He notably made a great work for OFBIZ-10518 "Inventory (Supply) Allocation Planning 
"

He not only worked in Jira,  but also answered accurately on MLs where he 
supported our users.

Please join me in welcoming and congratulating Deepak.

Jacques



Re: Rat flag for failure or success

2019-06-11 Thread Jacques Le Roux

Hi Jochen, All,

Kinda message in a bottle :)

I have created https://issues.apache.org/jira/browse/OFBIZ-11097 for that

But I'm unsure on how I should use numUnapprovedLicenses inside the Buildbot 
OFBiz RAT script.

Would something like

diff --git a/modules/buildbot_slave/files/ofbiz.xml 
b/modules/buildbot_slave/files/ofbiz.xml
index 38fddfa2..1c78af4f 100644
--- a/modules/buildbot_slave/files/ofbiz.xml
+++ b/modules/buildbot_slave/files/ofbiz.xml
@@ -40,6 +40,7 @@
   
 
   
+  
 
   

work (correct syntax? I know 0 unapproved licenses is the default)?
But then how to alert the OFBiz dev ML in case of issues?

Reading http://creadur.apache.org/rat/apache-rat-plugin/check-mojo.html, I 
can't clearly find a way to send an email when numUnapprovedLicenses is not 0.

If I refer to other OFBiz builds we receive an email when the state change. 
Could we do something like that?

Thanks

Jacques

Le 15/02/2018 à 11:23, Jochen Wiedmann a écrit :

See numUnapprovedLicenses on
http://creadur.apache.org/rat/apache-rat-plugin/check-mojo.html,


On Thu, Feb 15, 2018 at 11:19 AM, Jacques Le Roux
 wrote:

Hi,

I recently had this discussion in the infra HipChat room

[10:03 AM] Jacques Le Roux: Dear Infra team :) We use RAT and have this
report https://ci.apache.org/projects/ofbiz/rat-output.html
I was wondering if there is a way in RAT to get an alert when the status
change from "ALL OK" to an issue?
If not I guess I should ask the RAT project?
[10:05 AM] Daniel Takamori (pono): I'm not too familiar with RAT, so not
sure it's possible in buildbot besides adding a step to grep for errors or
something
[10:05 AM] Gavin McDonald: that would need some thought
[10:06 AM] Gavin McDonald: you could ask the RAT project if there output
might contain a flag or something we can use in builbot
[10:06 AM] Jacques Le Roux: Yes makes sense Daniel, I'll ask RAT and see if
we can get something for everybody...
And indeed need some thoughts
[10:07 AM] Jacques Le Roux: Thanks guys

So here is my request: is there a such flag? If not could there be one?

Thanks

Jacques



Re: Files w/o licenses

2019-06-10 Thread Jacques Le Roux

Hi Suraj,

Welcome

Actually Pierre is right: Buildbot RAT build should alert us.

Like other builds does for failing tests for instance.

I have created OFBIZ-11097 for that

Jacques


Le 10/06/2019 à 06:59, Suraj Khurana a écrit :

Thanks Jacques for taking care of this.

--
Best Regards,
Suraj Khurana
Technical Consultant
HotWax Systems






On Sun, Jun 9, 2019 at 6:44 PM Jacques Le Roux 
wrote:


Done.

Here we go, there were:


   Unapproved Licenses:

  1.
/home/buildslave/slave/ofbizTrunkFrameworkRat/build/applications/accounting/groovyScripts/test/AutoAcctgInvoiceTests.groovy
  2.
/home/buildslave/slave/ofbizTrunkFrameworkRat/build/applications/order/groovyScripts/test/OrderTests.groovy
  3.
/home/buildslave/slave/ofbizTrunkFrameworkRat/build/framework/service/src/main/java/org/apache/ofbiz/service/job/JobPriority.java
  4.
/home/buildslave/slave/ofbizTrunkFrameworkRat/build/plugins/msggateway/src/main/java/org/apache/ofbiz/msg91/Msg91Services.java

  1. Patch Vivek Singh Bisen, commit Suraj
  2. Initial Pach Pawan Verma, commit Suraj
  3. Scott
  4. Patch Pritam Kute, commit Rishi. Went unnoticed by Mathieu later but
that does not count, it's harder to spot then but with RAT's help. The RAT
 name was well chosen, reminds me Jack Nicholson in "The Departed" :)

That's all for the shame today :D

Jacques


Le 03/06/2019 à 13:07, Jacques Le Roux a écrit :

Damn, I hope I'm not one of them ;)

Le 03/06/2019 à 10:04, Scott Gray a écrit :

I hope you'll name the reviewers that missed them as well :-)

On Sun, 2 Jun 2019 at 07:33, Jacques Le Roux <

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

wrote:


OK, I'll do it in a week if nobody beats me on it.

But I'll name those that should have done it before :p

Jacques

Le 28/05/2019 à 14:49, Jacques Le Roux a écrit :

Hi Committers,

Please guys make an effort:

https://ci.apache.org/projects/ofbiz/rat-output.html

I normally do it (add missing licences) but the RAT build was off for

months and they piled up

(OK now as it specifically depends on lares_ubuntu Buildbot server:

https://issues.apache.org/jira/browse/INFRA-18500)

You should be able to recognise your own commits, and it's better for

you to learn and remember ;)

Thanks

Jacques



-
To unsubscribe, e-mail: dev-unsubscr...@ofbiz.apache.org
For additional commands, e-mail: dev-h...@ofbiz.apache.org




Re: Files w/o licenses

2019-06-09 Thread Jacques Le Roux

Done.

Here we go, there were:


 Unapproved Licenses:

1. 
/home/buildslave/slave/ofbizTrunkFrameworkRat/build/applications/accounting/groovyScripts/test/AutoAcctgInvoiceTests.groovy
2. 
/home/buildslave/slave/ofbizTrunkFrameworkRat/build/applications/order/groovyScripts/test/OrderTests.groovy
3. 
/home/buildslave/slave/ofbizTrunkFrameworkRat/build/framework/service/src/main/java/org/apache/ofbiz/service/job/JobPriority.java
4. 
/home/buildslave/slave/ofbizTrunkFrameworkRat/build/plugins/msggateway/src/main/java/org/apache/ofbiz/msg91/Msg91Services.java

1. Patch Vivek Singh Bisen, commit Suraj
2. Initial Pach Pawan Verma, commit Suraj
3. Scott
4. Patch Pritam Kute, commit Rishi. Went unnoticed by Mathieu later but that 
does not count, it's harder to spot then but with RAT's help. The RAT
   name was well chosen, reminds me Jack Nicholson in "The Departed" :)

That's all for the shame today :D

Jacques


Le 03/06/2019 à 13:07, Jacques Le Roux a écrit :

Damn, I hope I'm not one of them ;)

Le 03/06/2019 à 10:04, Scott Gray a écrit :

I hope you'll name the reviewers that missed them as well :-)

On Sun, 2 Jun 2019 at 07:33, Jacques Le Roux 
wrote:


OK, I'll do it in a week if nobody beats me on it.

But I'll name those that should have done it before :p

Jacques

Le 28/05/2019 à 14:49, Jacques Le Roux a écrit :

Hi Committers,

Please guys make an effort:

https://ci.apache.org/projects/ofbiz/rat-output.html

I normally do it (add missing licences) but the RAT build was off for

months and they piled up

(OK now as it specifically depends on lares_ubuntu Buildbot server:

https://issues.apache.org/jira/browse/INFRA-18500)

You should be able to recognise your own commits, and it's better for

you to learn and remember ;)

Thanks

Jacques




-
To unsubscribe, e-mail: dev-unsubscr...@ofbiz.apache.org
For additional commands, e-mail: dev-h...@ofbiz.apache.org




Re: Ecommerce image distorted in trunk demo main page

2019-06-08 Thread Jacques Le Roux

:)

Le 08/06/2019 à 07:25, Nitish Mishra a écrit :

Yes

This issue has been fixed in
https://issues.apache.org/jira/browse/OFBIZ-11095

On Tue, Jun 4, 2019 at 6:34 PM Jacques Le Roux 
wrote:


Thanks Nitish,

Much appreciated, will you create the Jira?

Jacques
Le 04/06/2019 à 13:14, Nitish Mishra a écrit :

Hi Jacques

Thanks for figuring it out. Yes, it is due to bootstrap changes.
I will fix it soon.


On Tue, Jun 4, 2019 at 1:40 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi,

I'm not sure why, I guess a Bootstrap change (see subject)

Thanks

Jacques


-
To unsubscribe, e-mail: dev-unsubscr...@ofbiz.apache.org
For additional commands, e-mail: dev-h...@ofbiz.apache.org



--

Kind Regards,
Nitish Mishra
Enterprise Software Engineer
*HotWax Systems*
*Enterprise open source experts*
cell: +91-81032-58737
office: 0731-409-3684
http://www.hotwaxsystems.com




Re: Integrating OFBiz with Microsoft Dynamics AX, NAV(Business Central) and Dynamics 365

2019-06-06 Thread Jacques Le Roux

Hi Pranay,

Did you succeed with the MSDN process? It worked for me few months ago this 
year, so I can help if you need...

Jacques

Le 03/06/2019 à 16:27, Pranay Pandey a écrit :

Hello Infra Team, Devs

I am willing to work on OFBiz integration with Microsoft AX, NAV(Business Central) and Dynamics 365. Tried locating my access to MSDN that I 
requested last year, not able to get through though.


Can anyone please guide me to get the access to MSDN? I requested for the same as OFBiz Committer last time, reapplied as per instructions here - 
https://svn.apache.org/repos/private/committers/donated-licenses/msdn.txt 

Apache ID: pran...@apache.org 

Looking forward to hearing from you.

Best regards,
Pranay Pandey




Re: buildbot failure in on ofbizBranch18Framework

2019-06-06 Thread Jacques Le Roux

We can neglect that. There were no commits, only changes in the Buildbot 
scripts. So test failure is irrelevant.

Le 06/06/2019 à 19:12, build...@apache.org a écrit :

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

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

Buildslave for this Build: orcus_ubuntu

Build Reason: forced: by IRC user  (privmsg): forces manual build to 
test gradle wrapper copy from tools
Build Source Stamp: HEAD
Blamelist:

BUILD FAILED: failed shell_4

Sincerely,
  -The Buildbot






Releasing 16.11.06 and vulnerable js libs

2019-06-06 Thread Jacques Le Roux

Hi,

The PMC wants to release the 16.11.06 version "soon" (ASAP actually). For that 
some points need to be done.

One notably is OFBIZ-10678 "Check embedded Javascript libs vulnerabilities using 
retire.js"

I had a look today and there are no high vulnerabilities which is good.

There are few medium and low and it would be better to fix them. Notably 
because 16.11.06 will certainly be our last R16 version.

I expect to work on it but I have other important tasks to do before we can release (removing Gradle and OFBIZ-10427 come to mind) and all help would 
be appreciated


TIA

Jacques



Re: [DISCUSSION] Committing Minilang test patches under OFBIZ-1463

2019-06-05 Thread Jacques Le Roux

Le 05/06/2019 à 09:24, Jacques Le Roux a écrit :

To explain my hard feeling regarding OFBiz integration tests. I find
them really hard to understand/debug due to the following points:

- Logs are unreadable! I mean understanding which test has failed is
   already an endeavour.


Oh that! I never look at integration test logs, it's impossible indeed.
I simply look at the result of the tests where the error logs are.


BTW, thinking about it, I agree it does not help to fix wrong tests.

Not sure how to do that, but by running suspected culprits one by one

Jacques



Re: [DISCUSSION] Committing Minilang test patches under OFBIZ-1463

2019-06-05 Thread Jacques Le Roux

Hi Mathieu,

[snip]

Then I see no problems doing that and having already Minilang tests
present. We "just have" to drop Minilang tests when Groovy ones are
ready.

What I'm missing?

The problem I see is that if the people proposing the patches are not
willing to do the migration work right now, I see no reason why they
would want to do it afterwards when there will be no incentives to do
so.


Could be indeed



If we apply those patches as they are, then the rest of us will
eventually have to understand/maintain/debug them when they fail. Given
the current sad state of OFBiz integration tests we cannot afford to let
more “stuff to be cleaned up later” enter the codebase.


I see your point, you kinda expect people having created Minilang test patches 
to convert them themselves.  Not sure that will we work.
If I get empathic (something I easily do when reviewing) I can understand the 
frustration of those people.
They create a patch before the decision is made and bam, it's no good :/
So it does not help to "put the blame" (OK I emphasise a bit here ;)) on them
Also we can't even rely on an expectation they will do the work. Some people 
come and go...
Anyway at some point someone will have to do it
And at least, I believe it's better to inspire from those patches than to start 
anew



To explain my hard feeling regarding OFBiz integration tests. I find
them really hard to understand/debug due to the following points:

- Logs are unreadable! I mean understanding which test has failed is
   already an endeavour.


Oh that! I never look at integration test logs, it's impossible indeed.
I simply look at the result of the tests where the error logs are.



- The global nature of the data loaded during the tests makes things
   brittle. We saw a lot of that in previous weeks where tests were
   succeding when having both the framework and the plugins but failing
   when having only the framework.

- People tend to be confused between integration and unit tests,
   resulting in integration tests written in an atomic way which is not a
   good thing. For example for testing services manipulating an
   hypothetical entity ‘foo’, we would have a ‘testCreateFooService’ that
   adds some stuff in the database and ‘testUpdateFooService’ that
   retrieve the stuff added by the other.  This is bad since it
   introduces a order dependency between those tests.  Instead of small
   integration tests we should have bigger independant ones following a
   scenario with multiple asserts.


Makes totally sense, unfortunately with 1300+ tests [1] I don't expect that to 
happen soon

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


Sorry for being long but I wanted to make clear that this is a real
issue.


Thanks for expression your opinion, that helps!

After 3 days, only people against expressed their opinions, so I think the 
discussion is closed.

Jacques


-
To unsubscribe, e-mail: dev-unsubscr...@ofbiz.apache.org
For additional commands, e-mail: dev-h...@ofbiz.apache.org



Re: Improve steps on Mailing Lists page

2019-06-05 Thread Jacques Le Roux

Good idea, thanks Aditya

+1

Jacques

Le 05/06/2019 à 07:18, Aditya Sharma a écrit :

Hello everyone,

The current steps for subscribing on Mailing lists page[1]:
1. Click the button of the mailing list you want to subscribe to
2. On the following page, click the 'Subscribe' button
3. Send the automatically created email from your email client
4. You will receive an email about the mailing list manager program (EZMLM)
Congratulations! You are now subscribed

The issue with current steps is on list page[2] when user clicks subscribe
button it opens up the email client but it is not necessary that user uses
any email client. I think we should also add direct steps as available for
unsubscribing.

To subscribe from any of the following lists, please send an empty,
subjectless email to mailing list subscribe addresses.

-  user-subscr...@ofbiz.apache.org
-  dev-subscr...@ofbiz.apache.org
-  commits-subscr...@ofbiz.apache.org
-  notifications-subscr...@ofbiz.apache.org

1. https://ofbiz.apache.org/mailing-lists.html
2. https://lists.apache.org/list.html?u...@ofbiz.apache.org

Thanks and Regards
Aditya Sharma



-
To unsubscribe, e-mail: dev-unsubscr...@ofbiz.apache.org
For additional commands, e-mail: dev-h...@ofbiz.apache.org



Re: Ecommerce image distorted in trunk demo main page

2019-06-04 Thread Jacques Le Roux

Thanks Nitish,

Much appreciated, will you create the Jira?

Jacques

Le 04/06/2019 à 13:14, Nitish Mishra a écrit :

Hi Jacques

Thanks for figuring it out. Yes, it is due to bootstrap changes.
I will fix it soon.


On Tue, Jun 4, 2019 at 1:40 PM Jacques Le Roux mailto:jacques.le.r...@les7arts.com>> wrote:

Hi,

I'm not sure why, I guess a Bootstrap change (see subject)

Thanks

Jacques


-
To unsubscribe, e-mail: dev-unsubscr...@ofbiz.apache.org 
<mailto:dev-unsubscr...@ofbiz.apache.org>
For additional commands, e-mail: dev-h...@ofbiz.apache.org 
<mailto:dev-h...@ofbiz.apache.org>



--

Kind Regards,
Nitish Mishra
Enterprise Software Engineer
*HotWax Systems*
/Enterprise open source experts/
cell: +91-81032-58737
office: 0731-409-3684
http://www.hotwaxsystems.com <http://www.hotwaxsystems.com/>




Ecommerce image distorted in trunk demo main page

2019-06-04 Thread Jacques Le Roux

Hi,

I'm not sure why, I guess a Bootstrap change (see subject)

Thanks

Jacques


-
To unsubscribe, e-mail: dev-unsubscr...@ofbiz.apache.org
For additional commands, e-mail: dev-h...@ofbiz.apache.org



Re: [DISCUSSION] Committing Minilang test patches under OFBIZ-1463

2019-06-03 Thread Jacques Le Roux

Le 03/06/2019 à 15:20, Michael Brohl a écrit :

I explained my POV in the Jira [1].

Why not encourage the contributors to move their minilang tests to Groovy code? I can see that this has already been done, e.g. here [2] (thanks 
everyone involved!).


I'm sure that the remaining patches will get converted soon, no need to choose the 
"easy way" and commit the minilang versions.

I hope you are right for now I don't see a lot of such cases, but it's hard to 
track


If we will allow more minilang commits, we will always have the discussion and 
won't ever get rid of it.


That's a possible issue indeed

Jacques



Thanks,

Michael

[1] https://issues.apache.org/jira/projects/OFBIZ/issues/OFBIZ-1463

[2] https://issues.apache.org/jira/browse/OFBIZ-9002



Am 03.06.19 um 13:21 schrieb Jacques Le Roux:

OK if this is a veto, no need to continue the discussion.-

Else could you explain your POV Michael, notably about missing to put in some 
new tests that could be helpful in the meantime?

Thanks

Le 02/06/2019 à 21:27, Michael Brohl a écrit :

-1 to introduce more minilang code to the codebase. New code should be provided 
in either Java or Groovy code.

Thanks,
Michael




Am 02.06.2019 um 12:56 schrieb Jacques Le Roux :

Hi All,

We started a discussion in OFBIZ-1463 about committing or not the Minilang test 
patches.

There are already few mixed opinions there (Michael, Aditya, Suraj and I).

Before voting I'd like to know if we can come to a consensus.

Please read in OFBIZ-1463 and come back with your opinion.

I have just changed mine because I believe using the tests as soon they are 
reading is a good thing.

Waiting would be a waste of not only work done but also time for code safety. We can still move them to Groovy later, it's not more work, I guess 
it's

even less.

Jacques







-
To unsubscribe, e-mail: dev-unsubscr...@ofbiz.apache.org
For additional commands, e-mail: dev-h...@ofbiz.apache.org



Re: [DISCUSSION] Committing Minilang test patches under OFBIZ-1463

2019-06-03 Thread Jacques Le Roux

OK if this is a veto, no need to continue the discussion.-

Else could you explain your POV Michael, notably about missing to put in some 
new tests that could be helpful in the meantime?

Thanks

Le 02/06/2019 à 21:27, Michael Brohl a écrit :

-1 to introduce more minilang code to the codebase. New code should be provided 
in either Java or Groovy code.

Thanks,
Michael




Am 02.06.2019 um 12:56 schrieb Jacques Le Roux :

Hi All,

We started a discussion in OFBIZ-1463 about committing or not the Minilang test 
patches.

There are already few mixed opinions there (Michael, Aditya, Suraj and I).

Before voting I'd like to know if we can come to a consensus.

Please read in OFBIZ-1463 and come back with your opinion.

I have just changed mine because I believe using the tests as soon they are 
reading is a good thing.

Waiting would be a waste of not only work done but also time for code safety. 
We can still move them to Groovy later, it's not more work, I guess it's
even less.

Jacques



-
To unsubscribe, e-mail: dev-unsubscr...@ofbiz.apache.org
For additional commands, e-mail: dev-h...@ofbiz.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@ofbiz.apache.org
For additional commands, e-mail: dev-h...@ofbiz.apache.org



Re: Files w/o licenses

2019-06-03 Thread Jacques Le Roux

Damn, I hope I'm not one of them ;)

Le 03/06/2019 à 10:04, Scott Gray a écrit :

I hope you'll name the reviewers that missed them as well :-)

On Sun, 2 Jun 2019 at 07:33, Jacques Le Roux 
wrote:


OK, I'll do it in a week if nobody beats me on it.

But I'll name those that should have done it before :p

Jacques

Le 28/05/2019 à 14:49, Jacques Le Roux a écrit :

Hi Committers,

Please guys make an effort:

https://ci.apache.org/projects/ofbiz/rat-output.html

I normally do it (add missing licences) but the RAT build was off for

months and they piled up

(OK now as it specifically depends on lares_ubuntu Buildbot server:

https://issues.apache.org/jira/browse/INFRA-18500)

You should be able to recognise your own commits, and it's better for

you to learn and remember ;)

Thanks

Jacques




-
To unsubscribe, e-mail: dev-unsubscr...@ofbiz.apache.org
For additional commands, e-mail: dev-h...@ofbiz.apache.org



Re: [DISCUSSION] Committing Minilang test patches under OFBIZ-1463

2019-06-02 Thread Jacques Le Roux

Le 02/06/2019 à 15:50, Mathieu Lirzin a écrit :

Hello Jacques,

Jacques Le Roux  writes:


We started a discussion in OFBIZ-1463 about committing or not the Minilang test 
patches.

There are already few mixed opinions there (Michael, Aditya, Suraj and I).

Before voting I'd like to know if we can come to a consensus.

Please read in OFBIZ-1463 and come back with your opinion.

I have just changed mine because I believe using the tests as soon they are 
reading is a good thing.

Waiting would be a waste of not only work done but also time for code
safety. We can still move them to Groovy later, it's not more work, I
guess it's even less.

If it's less work, then why people interested in having those patches
applied has not migrate those tests yet? :-)

Having contributed to the migration of the “quoteTests” I know for a
fact that this is painful work. Applying those patches in their current
state would simply mean putting the burden on someone else to do the
work. So I am strongly opposed to committing thoses patches before the
tests are migrated.

As far as I am concerned, if people want stuff to be committed then they
have to do their homework first.


Wait Mathieu,

Could you explain why it would me more work to migrate from a patch than to 
migrate from code already in the repo?

Maybe you mean that migrating is a burden anyway, and it's better to directly 
write test in Groovy?

Then I see no problems doing that and having already Minilang tests present. We 
"just have" to drop Minilang tests when Groovy ones are ready.

What I'm missing?

Thanks

--
Jacques

-
To unsubscribe, e-mail: dev-unsubscr...@ofbiz.apache.org
For additional commands, e-mail: dev-h...@ofbiz.apache.org



[DISCUSSION] Committing Minilang test patches under OFBIZ-1463

2019-06-02 Thread Jacques Le Roux

Hi All,

We started a discussion in OFBIZ-1463 about committing or not the Minilang test 
patches.

There are already few mixed opinions there (Michael, Aditya, Suraj and I).

Before voting I'd like to know if we can come to a consensus.

Please read in OFBIZ-1463 and come back with your opinion.

I have just changed mine because I believe using the tests as soon they are 
reading is a good thing.

Waiting would be a waste of not only work done but also time for code safety. We can still move them to Groovy later, it's not more work, I guess it's 
even less.


Jacques



Re: Files w/o licenses

2019-06-01 Thread Jacques Le Roux

OK, I'll do it in a week if nobody beats me on it.

But I'll name those that should have done it before :p

Jacques

Le 28/05/2019 à 14:49, Jacques Le Roux a écrit :

Hi Committers,

Please guys make an effort: https://ci.apache.org/projects/ofbiz/rat-output.html

I normally do it (add missing licences) but the RAT build was off for months 
and they piled up

(OK now as it specifically depends on lares_ubuntu Buildbot server: 
https://issues.apache.org/jira/browse/INFRA-18500)

You should be able to recognise your own commits, and it's better for you to 
learn and remember ;)

Thanks

Jacques




Re: svn commit: r1859876 - in /ofbiz/tools/demo-backup: Nicolas/functions.sh Nicolas/trunk.sh trunk.sh

2019-05-31 Thread Jacques Le Roux

+1 pour Maurice (as my question was wondering)

Jacques

Le 31/05/2019 à 00:02, Mathieu Lirzin a écrit :

Nicolas Malin  writes:


On 30/05/2019 13:04, Mathieu Lirzin wrote:


Nicolas Malin  writes:


hmm not, I just control that if we haven't gradlew we init it.

Your remark just alert me that I forget to set the gradlew on .ignore

I am confused. Are you proposing to add "gradlew" in the “./gitignore”
and “./hgignore” files in the framework repository? If not what is
“.ignore”?

Tu pinalles Maurice :)

You right, the better syntax would be ./*ignore so yes complete
./gitignore and ./hgignore

I wasn't nitpicking on your spelling, I was just checking that I was I
was understanding you correctly before disagreeing. :-)

IMO “./gradlew” should definitely be kept in our Version Controlled
System (VCS) in order to follow Gradle recommendations and avoid
specific build instructions.

The requirement of not distributing “gradle-wrapper.jar” in OFBiz
releases should only impact the build process of the release archives
and *not* the build process of the VCS branches.



Re: svn commit: r1859876 - in /ofbiz/tools/demo-backup: Nicolas/functions.sh Nicolas/trunk.sh trunk.sh

2019-05-30 Thread Jacques Le Roux

But since gradlew is our own and will not be remobed then why testing?

   if [ ! -r "$OFBIZ_DIR/gradlew" ]; then

Jacques

Le 30/05/2019 à 12:47, Nicolas Malin a écrit :

hmm not, I just control that if we haven't gradlew we init it.

Your remark just alert me that I forget to set the gradlew on .ignore

Nicolas


On 30/05/2019 12:25, Jacques Le Roux wrote:

Hi Nicolas,

So the idea is to remove also gradlew from OFBiz dir?

Jacques

Le 24/05/2019 à 15:44, nma...@apache.org a écrit :

Author: nmalin
Date: Fri May 24 13:44:11 2019
New Revision: 1859876

URL: http://svn.apache.org/viewvc?rev=1859876=rev
Log:
Improved: Call nit-gradle-wrapper.sh if gradlew not present
To prepare commit issue :
 Remove the Gradle wrapper from our release packages
 and add a step to our build notes (OFBIZ-10145)

Modified:
 ofbiz/tools/demo-backup/Nicolas/functions.sh
 ofbiz/tools/demo-backup/Nicolas/trunk.sh
 ofbiz/tools/demo-backup/trunk.sh

Modified: ofbiz/tools/demo-backup/Nicolas/functions.sh
URL: 
http://svn.apache.org/viewvc/ofbiz/tools/demo-backup/Nicolas/functions.sh?rev=1859876=1859875=1859876=diff
==
--- ofbiz/tools/demo-backup/Nicolas/functions.sh (original)
+++ ofbiz/tools/demo-backup/Nicolas/functions.sh Fri May 24 13:44:11 2019
@@ -37,4 +37,11 @@ applyPatches () {
  for i in $(ls $2); do
  patch -p0 < $2/$i;
  done
+}
+
+#control if gradlew is present, otherwise init it before
+checkGradlew () {
+    if [ ! -r "$OFBIZ_DIR/gradlew" ]; then
+    sh $OFBIZ_DIR/gradle/init-gradle-wrapper.sh
+    fi
  }
\ No newline at end of file

Modified: ofbiz/tools/demo-backup/Nicolas/trunk.sh
URL: 
http://svn.apache.org/viewvc/ofbiz/tools/demo-backup/Nicolas/trunk.sh?rev=1859876=1859875=1859876=diff
==
--- ofbiz/tools/demo-backup/Nicolas/trunk.sh (original)
+++ ofbiz/tools/demo-backup/Nicolas/trunk.sh Fri May 24 13:44:11 2019
@@ -18,6 +18,8 @@ removeUneededFiles $OFBIZ_DIR
    applyPatches $OFBIZ_DIR ~/patch/trunk
  +checkGradlew
+
  # run OFBiz
  ./gradlew --no-daemon loadAll
  ./gradlew --no-daemon svnInfoFooter

Modified: ofbiz/tools/demo-backup/trunk.sh
URL: 
http://svn.apache.org/viewvc/ofbiz/tools/demo-backup/trunk.sh?rev=1859876=1859875=1859876=diff
==
--- ofbiz/tools/demo-backup/trunk.sh (original)
+++ ofbiz/tools/demo-backup/trunk.sh Fri May 24 13:44:11 2019
@@ -4,6 +4,11 @@ cd /home/ofbizDemo/trunk
  svn up
  rm /home/ofbizDemo/trunk/framework/base/config/*.jks
  rm /home/ofbizDemo/trunk/framework/base/config/jesse.properties
+
+if [ ! -r "$OFBIZ_DIR/gradlew" ]; then
+    sh $OFBIZ_DIR/gradle/init-gradle-wrapper.sh
+fi
+
  ./gradlew --no-daemon pullAllPluginsSource
  ./gradlew --no-daemon terminateOfbiz
  ./gradlew --no-daemon cleanAll









Re: svn commit: r1859876 - in /ofbiz/tools/demo-backup: Nicolas/functions.sh Nicolas/trunk.sh trunk.sh

2019-05-30 Thread Jacques Le Roux

Hi Nicolas,

So the idea is to remove also gradlew from OFBiz dir?

Jacques

Le 24/05/2019 à 15:44, nma...@apache.org a écrit :

Author: nmalin
Date: Fri May 24 13:44:11 2019
New Revision: 1859876

URL: http://svn.apache.org/viewvc?rev=1859876=rev
Log:
Improved: Call nit-gradle-wrapper.sh if gradlew not present
To prepare commit issue :
 Remove the Gradle wrapper from our release packages
 and add a step to our build notes (OFBIZ-10145)

Modified:
 ofbiz/tools/demo-backup/Nicolas/functions.sh
 ofbiz/tools/demo-backup/Nicolas/trunk.sh
 ofbiz/tools/demo-backup/trunk.sh

Modified: ofbiz/tools/demo-backup/Nicolas/functions.sh
URL: 
http://svn.apache.org/viewvc/ofbiz/tools/demo-backup/Nicolas/functions.sh?rev=1859876=1859875=1859876=diff
==
--- ofbiz/tools/demo-backup/Nicolas/functions.sh (original)
+++ ofbiz/tools/demo-backup/Nicolas/functions.sh Fri May 24 13:44:11 2019
@@ -37,4 +37,11 @@ applyPatches () {
  for i in $(ls $2); do
  patch -p0 < $2/$i;
  done
+}
+
+#control if gradlew is present, otherwise init it before
+checkGradlew () {
+if [ ! -r "$OFBIZ_DIR/gradlew" ]; then
+sh $OFBIZ_DIR/gradle/init-gradle-wrapper.sh
+fi
  }
\ No newline at end of file

Modified: ofbiz/tools/demo-backup/Nicolas/trunk.sh
URL: 
http://svn.apache.org/viewvc/ofbiz/tools/demo-backup/Nicolas/trunk.sh?rev=1859876=1859875=1859876=diff
==
--- ofbiz/tools/demo-backup/Nicolas/trunk.sh (original)
+++ ofbiz/tools/demo-backup/Nicolas/trunk.sh Fri May 24 13:44:11 2019
@@ -18,6 +18,8 @@ removeUneededFiles $OFBIZ_DIR
  
  applyPatches $OFBIZ_DIR ~/patch/trunk
  
+checkGradlew

+
  # run OFBiz
  ./gradlew --no-daemon loadAll
  ./gradlew --no-daemon svnInfoFooter

Modified: ofbiz/tools/demo-backup/trunk.sh
URL: 
http://svn.apache.org/viewvc/ofbiz/tools/demo-backup/trunk.sh?rev=1859876=1859875=1859876=diff
==
--- ofbiz/tools/demo-backup/trunk.sh (original)
+++ ofbiz/tools/demo-backup/trunk.sh Fri May 24 13:44:11 2019
@@ -4,6 +4,11 @@ cd /home/ofbizDemo/trunk
  svn up
  rm /home/ofbizDemo/trunk/framework/base/config/*.jks
  rm /home/ofbizDemo/trunk/framework/base/config/jesse.properties
+
+if [ ! -r "$OFBIZ_DIR/gradlew" ]; then
+sh $OFBIZ_DIR/gradle/init-gradle-wrapper.sh
+fi
+
  ./gradlew --no-daemon pullAllPluginsSource
  ./gradlew --no-daemon terminateOfbiz
  ./gradlew --no-daemon cleanAll





Re: Files w/o licenses

2019-05-28 Thread Jacques Le Roux

I asked, it was possible but hard then to do from RAT (Creadur TLP now). Maybe 
it enhanced...

Le 28/05/2019 à 15:27, Pierre Smits a écrit :

Should the ci not raise such issues?

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, May 28, 2019 at 3:09 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Committers,

Please guys make an effort:
https://ci.apache.org/projects/ofbiz/rat-output.html

I normally do it (add missing licences) but the RAT build was off for
months and they piled up

(OK now as it specifically depends on lares_ubuntu Buildbot server:
https://issues.apache.org/jira/browse/INFRA-18500)

You should be able to recognise your own commits, and it's better for you
to learn and remember ;)

Thanks

Jacques




Files w/o licenses

2019-05-28 Thread Jacques Le Roux

Hi Committers,

Please guys make an effort: https://ci.apache.org/projects/ofbiz/rat-output.html

I normally do it (add missing licences) but the RAT build was off for months 
and they piled up

(OK now as it specifically depends on lares_ubuntu Buildbot server: 
https://issues.apache.org/jira/browse/INFRA-18500)

You should be able to recognise your own commits, and it's better for you to 
learn and remember ;)

Thanks

Jacques



Re: Data load issue on https://demo-trunk.ofbiz.apache.org/

2019-05-27 Thread Jacques Le Roux
DataLoadContainer.java:432)
    ... 8 more
Caused by: org.xml.sax.SAXException: A transaction error occurred reading data
org.xml.sax.SAXException: Fatal Error reading XML on line 1, column 1
org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; Content is not 
allowed in prolog.
    at 
org.apache.ofbiz.entity.util.EntitySaxReader.parse(EntitySaxReader.java:240)
    at 
org.apache.ofbiz.entity.util.EntitySaxReader.parse(EntitySaxReader.java:205)
    at 
org.apache.ofbiz.entity.util.EntityDataLoader.loadData(EntityDataLoader.java:268)
    ... 9 more
Caused by: org.xml.sax.SAXException: Fatal Error reading XML on line 1, column 1
org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; Content is not 
allowed in prolog.
    at 
org.apache.ofbiz.entity.util.EntitySaxReader.fatalError(EntitySaxReader.java:599)
    at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
    at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
    at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
    at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
    at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source)
    at 
org.apache.xerces.impl.XMLDocumentScannerImpl$PrologDispatcher.dispatch(Unknown 
Source)
    at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
Source)
    at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
    at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
    at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
    at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
    at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
Source)
    at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
    at javax.xml.parsers.SAXParser.parse(SAXParser.java:195)
    at 
org.apache.ofbiz.entity.util.EntitySaxReader.parse(EntitySaxReader.java:225)
    ... 11 more
Caused by: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; 
Content is not allowed in prolog.
    at 
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown 
Source)

This was reproducible

Restarting demos again

Jacques


Le 27/05/2019 à 10:59, Jacques Le Roux a écrit :

As we know (or not :)) this needs a complete restart of all demos, currently 
running...

Jacques

Le 27/05/2019 à 10:53, Jacques Le Roux a écrit :

Thanks Deepak,

Not sure what happened. I have no time to investigate at the moment. I took a copy of console.log. I'll investigate later. Trying to restart trunk 
for now...


Jacques

Le 27/05/2019 à 09:08, Deepak Dixit a écrit :

It seems data not loaded on demo-trunk
https://demo-trunk.ofbiz.apache.org/ecommerce/control/main
=
A Product Store has not been defined for this ecommerce site. A Product
Store can be created using the ofbizsetup wizard.

==


Kind Regards,
Deepak Dixit







Re: Data load issue on https://demo-trunk.ofbiz.apache.org/

2019-05-27 Thread Jacques Le Roux

As we know (or not :)) this needs a complete restart of all demos, currently 
running...

Jacques

Le 27/05/2019 à 10:53, Jacques Le Roux a écrit :

Thanks Deepak,

Not sure what happened. I have no time to investigate at the moment. I took a copy of console.log. I'll investigate later. Trying to restart trunk 
for now...


Jacques

Le 27/05/2019 à 09:08, Deepak Dixit a écrit :

It seems data not loaded on demo-trunk
https://demo-trunk.ofbiz.apache.org/ecommerce/control/main
=
A Product Store has not been defined for this ecommerce site. A Product
Store can be created using the ofbizsetup wizard.

==


Kind Regards,
Deepak Dixit





Re: Missing microseconds support in date-time picker

2019-05-27 Thread Jacques Le Roux

OK then

Jacques

Le 27/05/2019 à 09:15, Aditya Sharma a écrit :

Indeed. I have already started working on OFBIZ-10782 but if the community
decides we can include that with the current work.

1. https://issues.apache.org/jira/browse/OFBIZ-10782

Thanks and regards,
Aditya Sharma
Enterprise Software Engineer
*HotWax Systems*
*Enterprise open source experts*
office: 0731-409-3684
http://www.hotwaxsystems.com




On Mon, May 27, 2019 at 12:34 PM Deepak Dixit 
wrote:


I'd like to add support in date-time picker for microseconds, As it's
possible that data generated at runtime may contain microseconds.
Removing microsecond from the demo is not a proper solution.
As per current implementation, we are using Date.parseExact in
OfbizUtil.js, and Date.parse does not support the microseconds. We can use
the moment js to format date in the proper format.


Kind Regards,
Deepak Dixit
DIRECTOR OF PRODUCT ENGINEERING
mobile: +91 9826754548
email: deepak.di...@hotwax.co
*www.hotwax.co <http://www.hotwax.co/>*


On Sat, May 25, 2019 at 7:09 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Le 25/05/2019 à 14:22, Pawan Verma a écrit :

Hello Devs,

While working on OFBIZ-11022, I have found that current date-time

picker

does not have support for microseconds.
In existing demo data for WebSitePathAlias, we have microseconds in it.

But

on Edit webSitePathAlias screen date-time picker does not pass

microseconds

and due to this system can not find the exact record for update.

Should we add support in date-time picker for microseconds or remove it
from demo data?

Suggestions and thoughts are welcome. Thanks!

Hi Pawan,

I'd be more inclined to remove microseconds from demo data

Thanks

Jacques




Re: Data load issue on https://demo-trunk.ofbiz.apache.org/

2019-05-27 Thread Jacques Le Roux

Thanks Deepak,

Not sure what happened. I have no time to investigate at the moment. I took a copy of console.log. I'll investigate later. Trying to restart trunk for 
now...


Jacques

Le 27/05/2019 à 09:08, Deepak Dixit a écrit :

It seems data not loaded on demo-trunk
https://demo-trunk.ofbiz.apache.org/ecommerce/control/main
=
A Product Store has not been defined for this ecommerce site. A Product
Store can be created using the ofbizsetup wizard.

==


Kind Regards,
Deepak Dixit



Re: buildbot failure in on ofbizTrunkFrameworkPlugins

2019-05-26 Thread Jacques Le Roux

OK locally

Le 26/05/2019 à 13:21, 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/822

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

Buildslave for this Build: silvanus_ubuntu

Build Reason: downstream
Build Source Stamp: [branch ofbiz/ofbiz-framework/trunk] 1860051
Blamelist: jleroux

BUILD FAILED: failed shell_4

Sincerely,
  -The Buildbot






Re: buildbot exception in on ofbizTrunkFramework

2019-05-26 Thread Jacques Le Roux

Not a problem

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

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

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

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'onTrunkFrameworkCommit' 
triggered this build
Build Source Stamp: [branch ofbiz/ofbiz-framework/trunk] 1860064
Blamelist: mthl

BUILD FAILED: exception shell_1 upload

Sincerely,
  -The Buildbot






Re: Missing microseconds support in date-time picker

2019-05-25 Thread Jacques Le Roux

Le 25/05/2019 à 14:22, Pawan Verma a écrit :

Hello Devs,

While working on OFBIZ-11022, I have found that current date-time picker
does not have support for microseconds.
In existing demo data for WebSitePathAlias, we have microseconds in it. But
on Edit webSitePathAlias screen date-time picker does not pass microseconds
and due to this system can not find the exact record for update.

Should we add support in date-time picker for microseconds or remove it
from demo data?

Suggestions and thoughts are welcome. Thanks!


Hi Pawan,

I'd be more inclined to remove microseconds from demo data

Thanks

Jacques



Re: svn commit: r1859877 - in /ofbiz/ofbiz-framework/trunk: applications/accounting/servicedef/ applications/content/servicedef/ applications/marketing/servicedef/ applications/order/servicedef/ appli

2019-05-25 Thread Jacques Le Roux

Le 25/05/2019 à 11:01, Mathieu Lirzin a écrit :

Hello,

Jacques Le Roux  writes:


Le 25/05/2019 à 09:07, Jacques Le Roux a écrit :

Le 25/05/2019 à 08:54, Jacques Le Roux a écrit :

You mean when ran isolated, right?

OK, got it, it's a framework only issue

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

Looking at it...

Jacques

This is due to the simple quote in

subject="OFBiz - Your Request is received: '${custRequestName}' 
#CR${custRequestId}"/>

in OrderTypeData.xml

I have yet not idea why the CustomSafePolicy class (based on Slashdot policy) 
rejects it, seems weird to me.

It's also (even more) weird that when the plugins data are loaded the issue 
does not exist

Indeed this is weird, thanks for investigating!
This was a peculiar case that could be generalised to all escapable characters. The general solution is to compare the original value with the 
filtered value unescaped in UtilCodec::checkStringForHtmlSafe.

BTW, weirdly enough StringEscapeUtils::escapeHtml4 does not escape single quote.

Another weirdness is the test was passing with plugins data loaded. This is due to duplicated demo data in scrumTypeData.xml (which is actually not 
only type data)


As ever the scrum component is a mess, that's not new and I always wonder if we should not get rid of it! I guess there are plenty of good tools 
outside...


Jacques



Re: svn commit: r1859877 - in /ofbiz/ofbiz-framework/trunk: applications/accounting/servicedef/ applications/content/servicedef/ applications/marketing/servicedef/ applications/order/servicedef/ appli

2019-05-25 Thread Jacques Le Roux

Le 25/05/2019 à 09:07, Jacques Le Roux a écrit :

Le 25/05/2019 à 08:54, Jacques Le Roux a écrit :
You mean when ran isolated, right? 


OK, got it, it's a framework only issue

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

Looking at it...

Jacques


This is due to the simple quote in

subject="OFBiz - Your Request is received: '${custRequestName}' 
#CR${custRequestId}"/>

in OrderTypeData.xml

I have yet not idea why the CustomSafePolicy class (based on Slashdot policy) 
rejects it, seems weird to me.

It's also (even more) weird that when the plugins data are loaded the issue 
does not exist

Jacques



Re: svn commit: r1859877 - in /ofbiz/ofbiz-framework/trunk: applications/accounting/servicedef/ applications/content/servicedef/ applications/marketing/servicedef/ applications/order/servicedef/ appli

2019-05-25 Thread Jacques Le Roux

Le 25/05/2019 à 08:54, Jacques Le Roux a écrit :
You mean when ran isolated, right? 


OK, got it, it's a framework only issue

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

Looking at it...

Jacques



Re: svn commit: r1859877 - in /ofbiz/ofbiz-framework/trunk: applications/accounting/servicedef/ applications/content/servicedef/ applications/marketing/servicedef/ applications/order/servicedef/ appli

2019-05-25 Thread Jacques Le Roux

Hi Mathieu,

You mean when ran isolated, right?

Because https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins is OK

Thanks

Jacques

Le 24/05/2019 à 23:50, Mathieu Lirzin a écrit :

Hello Jacques,

jler...@apache.org writes:


Author: jleroux
Date: Fri May 24 13:47:08 2019
New Revision: 1859877

URL: http://svn.apache.org/viewvc?rev=1859877=rev
Log:
Fixed: Services allow arbitrary HTML for parameters with allow-html set to 
"safe"
(OFBIZ-5254)

This was reopened after discussion at
https://markmail.org/message/jnaitmwahjcjmdn5

This is a new solution which follows the work done with and OFBIZ-10187
Roughly said, it uses org.owasp.html.PolicyFactory and org.owasp.html.Sanitizers

Thanks: Christoph Neuroth for report

This commit breaks the “custrequesttests” test suite with a vanilla
framework after ‘loadAll’. If the issue can not be solved tomorrow
please revert.

Thanks.



Re: [DISCUSSION] Having to use parent tickets to group tickets

2019-05-21 Thread Jacques Le Roux

Hi Pierre, All,

Actually I mostly use 3 types of parent-children issues relations:

1. Subtasks
2. Part of (and "is  part of")
3. Child of (and "is a parent of)"

The 1st was available with 1st versions of Jira we used. The 2nd came after and 
the later is even more recent.

I use subtasks when the children issues are closely related to the parent one, like a section in a document to image it. I think a subtask can only be 
part of a parent issue (did not check).


I use indifferently "Part of" and "Child of". Maybe they can be related to several parents unlike subtasks? I think they were successively put in by 
the Jira ASF admins, not sure how to differentiate them and even from subtasks.


So I come to the same conclusion than here: 
https://stackoverflow.com/questions/20357372/issue-links-meaning-in-jira

There is also (and reversed relations, like "Is contained by")

 * Contains
 * Incorporates
 * Is required by
 * Is depended upon by

For the 2 last I think meanings are more clear, not sure for the 2 1st :D. They 
could be part of the list of 3 above...

I don't think we need to clearly define the differences since it might still evolve with Jira ASF admins creativity (mostly requests from Jira users), 
as long as we understand what we are doing.


My 2cts

Jacques


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

Hi All,

Some contributors have suggested (in comments in this ML on the above
ticket) that we make more use of the ParentTicket-ChildTicket mechanism
(meaning that BugFix and Improvement tickets are converted to SubTask
tickets) in JIRA to enable parties involved to get a better overview of
what is related.

I seem to remember that this discussion has come before (as side comments
to tickets and in other threads), but can't easily reference a single one
from the past. And IIRW there are both proponents and opponents for the
concept.

What are your thoughts on this? And, can we get a consensus on the subject
and register that in one of our BestPractice pages?

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 17, 2019 at 8:29 AM Suraj Khurana 
wrote:


Hello,

I am inclined with Aditya's thought here.


Furthermore, a parent ticket works well for task and new feature tickets.

And not that well for bug fix and improvement tickets.
IMO, it does. [1]

As a reviewer, I think of all the tickets are bundled together inside a
parent ticket, than it would be better. Yes, there are other ways, but if
we can arrange tickets properly, it is considered a best practice to do so.

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

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

--
Best Regards,
Suraj Khurana
Technical Consultant





On Fri, May 17, 2019 at 12:40 AM Pierre Smits 
wrote:


Hi Aditya, All,

IMO, there are already to many tickets not worked on, but being managed.
And I don't see much progress initiated by the assignees of those tickets
to get the work of the underlying tasks completed. While parent tickets
(and sub tasks) work well for other parties with a more hierarchical and
contractually controlled structure, it does not work that well for an
organisation like the ASF (and projects under its umbrella) where
activities of contributors can't be dictated, nor managed by the assignee
of the parent ticket.

Furthermore, a parent ticket works well for task and new feature tickets.
And not that well for bug fix and improvement tickets.

If you (and others) want to keep track of progress, I believe, there are
ample ways to do that. JIRA provides plenty of tools to get an overview

of

whatever. One of such is



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

and I feel confident that anyone can create a good filter on OFBiz

tickets

that will deliver on specific needs.

An other way to track progress regarding OFBiz Business Intelligence (aka
the BI component) is through the wiki pages associated with the subject,
see e.g.

https://cwiki.apache.org/confluence/display/OFBIZ/Business+Intelligence


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 16, 2019 at 2:45 PM Aditya Sharma 
wrote:


Hi Pierre,
It seems work is related to Business Intelligence[1] work. Thanks for

your

efforts in this direction.

I would suggest that it would be much better if you could have a parent

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.



  1   2   3   4   5   6   7   8   9   10   >