Re: [DISCUSSION] JIRA notifications and reaching contributors

[Michael Brohl]

I fully agree, Scott.

We should also not forget users using mailing list archives. It would be 
a nightmare to follow dev@ discussions on ponymail with all these Jira 
notifications.


I see no evidence that we attract more new contributors through Jira 
notifications, I assume the contrary.


Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 25.04.19 um 21:56 schrieb Scott Gray:

The problem is that jira notification volume far exceeds dev list volume
which has the effect of stifling dev list discussions due to them being
pushed far down the list of recent emails.  The only solution to that is to
filter the jira notifications.  Right now in gmail I can see one week's
worth of jira emails and around 6 weeks worth of dev conversations.  Dev
list discussions are far more important that jira notifications, anything
important happening in jira should already have been discussed in the dev
list.  So we took the opinionated approach that dev list users should not
have to set up a filter in order to avoid being bombarded with low value
notifications.  I would much rather have contributors fully engaged in dev
list discussions than drown them in jira notifications.

Regards
Scott

On Fri, 26 Apr 2019 at 06:43, Pierre Smits  wrote:


We can not prevent those not interested in what is happening to
unsubscribe. And with modern mail clients (or online solutions) anyone not
interested to see posting about specific categories (commits, JIRA
notifications) can set filters there to:

1. have the postings of these categories automatically moved to other
(sub-)folders, or
2. have the posting automatically deleted


This is not about those of the community who do not want to be informed or
want to see/do less, but rather about reaching more (potential)
contributors. The implementation of the result of the vote conveniences
those not interested. If we suppose that all of the PMC members and all of
the committers have subscribed to notifications@, then only 11 out of 574
dev subscribers or out of 926 users@ subscribers see stuff regarding OFBiz
issues.

Michael makes the point that those interested should subscribe, leaving it
to them to show interest. But we should turn it around, as it was before,
in order to attract more. More parties to work with (adpoters) and/or to
contribute to have a better product faster.

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, Apr 25, 2019 at 1:59 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


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

Jacques

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

I am also inline with Michael's comments.


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



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

michael.br...@ecomify.de>

wrote:


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

dev@.

It makes the dev@ discussions a lot better to follow, these would

drown

in the Jira notifications. I suspect that we would make users
unsubscribe dev@ if we would have notifications@ in there also.

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

of

the notifications@ list.

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 25.04.19 um 12:20 schrieb Pierre Smits:

Hi All,

Back in 2016 it was decided that notifications go to the separate

mailing

list notifications@ofbiz.a.o. See [1]. And looking at latest numbers
reported regarding subscriptions to our mailing lists, we have:

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

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

2018-06-20,

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

The numbers indicate that about 14% of our contributor potential

subscribed

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

and

less

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

reached.

And

when we factor in the impact of PMC members and committers (I can

only

guess how many of those have subscribed) on notifications@) the

ratios

are

even worse.

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

that

we

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

and

user@

subscribers, leading to an overload of those working tickets.

Did we take a wrong turn back in 2016? And should we not revert the
resolution of the vote to have notifications go back to dev@ to get

more

contributions (

Re: [DISCUSSION] JIRA notifications and reaching contributors

[Scott Gray]

The problem is that jira notification volume far exceeds dev list volume
which has the effect of stifling dev list discussions due to them being
pushed far down the list of recent emails.  The only solution to that is to
filter the jira notifications.  Right now in gmail I can see one week's
worth of jira emails and around 6 weeks worth of dev conversations.  Dev
list discussions are far more important that jira notifications, anything
important happening in jira should already have been discussed in the dev
list.  So we took the opinionated approach that dev list users should not
have to set up a filter in order to avoid being bombarded with low value
notifications.  I would much rather have contributors fully engaged in dev
list discussions than drown them in jira notifications.

Regards
Scott

On Fri, 26 Apr 2019 at 06:43, Pierre Smits  wrote:

> We can not prevent those not interested in what is happening to
> unsubscribe. And with modern mail clients (or online solutions) anyone not
> interested to see posting about specific categories (commits, JIRA
> notifications) can set filters there to:
>
>1. have the postings of these categories automatically moved to other
>(sub-)folders, or
>2. have the posting automatically deleted
>
>
> This is not about those of the community who do not want to be informed or
> want to see/do less, but rather about reaching more (potential)
> contributors. The implementation of the result of the vote conveniences
> those not interested. If we suppose that all of the PMC members and all of
> the committers have subscribed to notifications@, then only 11 out of 574
> dev subscribers or out of 926 users@ subscribers see stuff regarding OFBiz
> issues.
>
> Michael makes the point that those interested should subscribe, leaving it
> to them to show interest. But we should turn it around, as it was before,
> in order to attract more. More parties to work with (adpoters) and/or to
> contribute to have a better product faster.
>
> 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, Apr 25, 2019 at 1:59 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > I used to have a filter on "(OFBIZ-" to redirect to my OFBiz Jira folder.
> > Having a specific list is easier indeed.
> >
> > Jacques
> >
> > Le 25/04/2019 à 13:39, Swapnil M Mane a écrit :
> > > I am also inline with Michael's comments.
> > >
> > >
> > > - Best Regards,
> > > Swapnil M Mane,
> > > ofbiz.apache.org
> > >
> > >
> > >
> > > On Thu, Apr 25, 2019 at 4:48 PM Michael Brohl <
> michael.br...@ecomify.de>
> > > wrote:
> > >
> > >> I strongly suggest to stay with the split between notifications@ and
> > dev@.
> > >>
> > >> It makes the dev@ discussions a lot better to follow, these would
> drown
> > >> in the Jira notifications. I suspect that we would make users
> > >> unsubscribe dev@ if we would have notifications@ in there also.
> > >>
> > >> If people are interested in getting the notifications, they can
> > >> subscribe anytime. It might be reasonable to encourage people in the
> > >> dev@/user@ lists to subscribe there if we believe they are not aware
> of
> > >> the notifications@ list.
> > >>
> > >> Regards,
> > >>
> > >> Michael Brohl
> > >>
> > >> ecomify GmbH - www.ecomify.de
> > >>
> > >>
> > >> Am 25.04.19 um 12:20 schrieb Pierre Smits:
> > >>> Hi All,
> > >>>
> > >>> Back in 2016 it was decided that notifications go to the separate
> > mailing
> > >>> list notifications@ofbiz.a.o. See [1]. And looking at latest numbers
> > >>> reported regarding subscriptions to our mailing lists, we have:
> > >>>
> > >>>  - user@: 926
> > >>>  - dev@: 574
> > >>>  - commits@: 218
> > >>>  - notifications@: 78
> > >>>
> > >>> The numbers regarding user@, dev@ and notifications@ are from
> > >> 2018-06-20,
> > >>> and the number regarding notifications@ is from 2018-03-20, see [2].
> > >>>
> > >>> The numbers indicate that about 14% of our contributor potential
> > >> subscribed
> > >>> to the dev@ sees these notifications about bugs and improvements,
> and
> > >> less
> > >>> than 9%  of our greater community  (subscribed to user@) are
> reached.
> > >> And
> > >>> when we factor in the impact of PMC members and committers (I can
> only
> > >>> guess how many of those have subscribed) on notifications@) the
> ratios
> > >> are
> > >>> even worse.
> > >>>
> > >>> The effect of the low number of subscriptions to notifications@ is
> > that
> > >> we
> > >>> don't reach our potential and that we don't see the input of dev@
> and
> > >> user@
> > >>> subscribers, leading to an overload of those working tickets.
> > >>>
> > >>> Did we take a wrong turn back in 2016

Re: [DISCUSSION] JIRA notifications and reaching contributors

[Pierre Smits]

We can not prevent those not interested in what is happening to
unsubscribe. And with modern mail clients (or online solutions) anyone not
interested to see posting about specific categories (commits, JIRA
notifications) can set filters there to:

   1. have the postings of these categories automatically moved to other
   (sub-)folders, or
   2. have the posting automatically deleted


This is not about those of the community who do not want to be informed or
want to see/do less, but rather about reaching more (potential)
contributors. The implementation of the result of the vote conveniences
those not interested. If we suppose that all of the PMC members and all of
the committers have subscribed to notifications@, then only 11 out of 574
dev subscribers or out of 926 users@ subscribers see stuff regarding OFBiz
issues.

Michael makes the point that those interested should subscribe, leaving it
to them to show interest. But we should turn it around, as it was before,
in order to attract more. More parties to work with (adpoters) and/or to
contribute to have a better product faster.

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, Apr 25, 2019 at 1:59 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> I used to have a filter on "(OFBIZ-" to redirect to my OFBiz Jira folder.
> Having a specific list is easier indeed.
>
> Jacques
>
> Le 25/04/2019 à 13:39, Swapnil M Mane a écrit :
> > I am also inline with Michael's comments.
> >
> >
> > - Best Regards,
> > Swapnil M Mane,
> > ofbiz.apache.org
> >
> >
> >
> > On Thu, Apr 25, 2019 at 4:48 PM Michael Brohl 
> > wrote:
> >
> >> I strongly suggest to stay with the split between notifications@ and
> dev@.
> >>
> >> It makes the dev@ discussions a lot better to follow, these would drown
> >> in the Jira notifications. I suspect that we would make users
> >> unsubscribe dev@ if we would have notifications@ in there also.
> >>
> >> If people are interested in getting the notifications, they can
> >> subscribe anytime. It might be reasonable to encourage people in the
> >> dev@/user@ lists to subscribe there if we believe they are not aware of
> >> the notifications@ list.
> >>
> >> Regards,
> >>
> >> Michael Brohl
> >>
> >> ecomify GmbH - www.ecomify.de
> >>
> >>
> >> Am 25.04.19 um 12:20 schrieb Pierre Smits:
> >>> Hi All,
> >>>
> >>> Back in 2016 it was decided that notifications go to the separate
> mailing
> >>> list notifications@ofbiz.a.o. See [1]. And looking at latest numbers
> >>> reported regarding subscriptions to our mailing lists, we have:
> >>>
> >>>  - user@: 926
> >>>  - dev@: 574
> >>>  - commits@: 218
> >>>  - notifications@: 78
> >>>
> >>> The numbers regarding user@, dev@ and notifications@ are from
> >> 2018-06-20,
> >>> and the number regarding notifications@ is from 2018-03-20, see [2].
> >>>
> >>> The numbers indicate that about 14% of our contributor potential
> >> subscribed
> >>> to the dev@ sees these notifications about bugs and improvements, and
> >> less
> >>> than 9%  of our greater community  (subscribed to user@) are reached.
> >> And
> >>> when we factor in the impact of PMC members and committers (I can only
> >>> guess how many of those have subscribed) on notifications@) the ratios
> >> are
> >>> even worse.
> >>>
> >>> The effect of the low number of subscriptions to notifications@ is
> that
> >> we
> >>> don't reach our potential and that we don't see the input of dev@ and
> >> user@
> >>> subscribers, leading to an overload of those working tickets.
> >>>
> >>> Did we take a wrong turn back in 2016? And should we not revert the
> >>> resolution of the vote to have notifications go back to dev@ to get
> more
> >>> contributions (potentially leading to more - active - committers that
> >> share
> >>> and lessen the work load?
> >>>
> >>> What do you think?
> >>>
> >>>
> >>> [1] [VOTE] Create a "notifications" mailing list
> >>> <
> >>
> https://ofbiz.markmail.org/message/6hlbap7a6cam3rm2?q=%22%5BVOTE%5D+Create+a+%22notifications%22+mailing+list+%22+list:org%2Eapache%2Eofbiz%2Edev+order:date-forward
> >>>
> >>>
> >>>
> >>> Best regards,
> >>>
> >>> Pierre Smits
> >>>
> >>> *Apache Trafodion , Vice President*
> >>> *Apache Directory , PMC Member*
> >>> Apache Incubator , committer
> >>> *Apache OFBiz , contributor (without
> >> privileges)
> >>> since 2008*
> >>> Apache Steve , committer
> >>>
> >>
>

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

[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&r1=1858093&r2=1858094&view=diff
==
--- 
ofbiz/ofbiz-framework/branches/release18.12/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/RequestHandler.java
 (original)
+++ 
ofbiz/ofbiz-framework/branches/release18.12/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/RequestHandler.java
 Thu Apr 25 08:26:07 2019
@@ -22,6 +22,7 @@ import static org.apache.ofbiz.base.util
  
  import java.io.IOException;

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

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

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

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

This commit is only bypassing the error handling.

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

Thanks.

Re: Reviving the OFBiz community day

[Mathieu Lirzin]

Swapnil M Mane  writes:

> Wow, thoughts travels Pierre!
> I am also working a document for migration of OFBiz from SVN to Git.
> It is at very beginning state, hopefully will share it by this end of week.
> :)

\o/

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

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

[Mathieu Lirzin]

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&r1=1858093&r2=1858094&view=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.

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

Re: [PROPOSAL] DataModel - Improve Internal Fields injection

[Jacques Le Roux]

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

IMO, this is configurable as Jacques pointed, so need to take any action.
In fact, I would suggest showing these fields while searching for any data
from entity-engine in webtools, because they are really helpful while
working in a dev environment for debugging.


This could be configurable indeed (less need in production for instance so 
default would be false)

Jacques



Just my two cents !!!

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






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


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

The entities are defined with no-auto-stamp="false" by default so it's
possible to change this default.

Of course 'createdByUserLogin' and 'lastModifiedByUserLogin' fields are
not concerned, it was just to complete

Jacques


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

Michael,
Thank you for details, all makes sense.

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

Indore,

M.P 452010
Linkedin: *Rishi Solanki*

Direct: +91-9893287847


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


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

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

I am not sure how the selection of entities with these fields was done,
maybe others can add insights.

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 24.04.19 um 12:40 schrieb Pierre Smits:

Thanks Michael,

So we should keep those *TxStamp fields.

But what about the second suggestion about having the

'createdByUserLogin'

and 'lastModifiedByUserLogin'  fields added to the internal fields set?

Best regards,

Pierre Smits

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

privileges)

since 2008*
Apache Steve , committer


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

michael.br...@ecomify.de

wrote:


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

changes

made within an transaction have the same tx timestamp.

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 24.04.19 um 09:48 schrieb Pierre Smits:

Hi All,

Currently our functions inject following internal fields into the

model

of

each entity:

   - createdStamp
   - createdTxStamp
   - lastUpdatedStamp
   - lastUpdatedTxStamp

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

means

that the createdTxStamp is the same as createdStamp  and

lastUpdatedTxStamp

is the same as lastUpdatedStamp.

Should we get rid of the redundant fields?

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

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

these

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

Best regards,

Pierre Smits

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

privileges)

since 2008*
Apache Steve , committer

Re: [PROPOSAL] DataModel - Improve Internal Fields injection

[Suraj Khurana]

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.

Just my two cents !!!

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






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

> A bit out of subject, just to complete the discussion because nobody spoke
> about.
>
> The entities are defined with no-auto-stamp="false" by default so it's
> possible to change this default.
>
> Of course 'createdByUserLogin' and 'lastModifiedByUserLogin' fields are
> not concerned, it was just to complete
>
> Jacques
>
>
> Le 24/04/2019 à 13:36, Rishi Solanki a écrit :
> > Michael,
> > Thank you for details, all makes sense.
> >
> > Best Regards,
> > --
> > *Rishi Solanki* | Sr Manager, Enterprise Software Development
> > HotWax Systems 
> > Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> Indore,
> > M.P 452010
> > Linkedin: *Rishi Solanki*
> > 
> > Direct: +91-9893287847
> >
> >
> > On Wed, Apr 24, 2019 at 4:37 PM Michael Brohl 
> > wrote:
> >
> >> I have not time to elaborate in-depth right now, but just a quick food
> >> for thought:
> >>
> >> Having these fields in every entity *by default* allows detailed
> >> tracking of users which might be unwanted. I know that this is a
> >> sensible topic in companies and affects privacy protection.
> >>
> >> I am not sure how the selection of entities with these fields was done,
> >> maybe others can add insights.
> >>
> >> Regards,
> >>
> >> Michael Brohl
> >>
> >> ecomify GmbH - www.ecomify.de
> >>
> >>
> >> Am 24.04.19 um 12:40 schrieb Pierre Smits:
> >>> Thanks Michael,
> >>>
> >>> So we should keep those *TxStamp fields.
> >>>
> >>> But what about the second suggestion about having the
> >> 'createdByUserLogin'
> >>> and 'lastModifiedByUserLogin'  fields added to the internal fields set?
> >>>
> >>> Best regards,
> >>>
> >>> Pierre Smits
> >>>
> >>> *Apache Trafodion , Vice President*
> >>> *Apache Directory , PMC Member*
> >>> Apache Incubator , committer
> >>> *Apache OFBiz , contributor (without
> >> privileges)
> >>> since 2008*
> >>> Apache Steve , committer
> >>>
> >>>
> >>> On Wed, Apr 24, 2019 at 12:20 PM Michael Brohl <
> michael.br...@ecomify.de
> >>>
> >>> wrote:
> >>>
>  These fields are not the same, they can differ. The TX fields mark the
>  transaction timestamp while the non TX fields mark the "real" update
>  time. You can see it when you watch closely in the database. All
> changes
>  made within an transaction have the same tx timestamp.
> 
>  Regards,
> 
>  Michael Brohl
> 
>  ecomify GmbH - www.ecomify.de
> 
> 
>  Am 24.04.19 um 09:48 schrieb Pierre Smits:
> > Hi All,
> >
> > Currently our functions inject following internal fields into the
> model
>  of
> > each entity:
> >
> >   - createdStamp
> >   - createdTxStamp
> >   - lastUpdatedStamp
> >   - lastUpdatedTxStamp
> >
> > All of the fields above are of the field type definition 'date-time',
> > giving for java: java.sql.Timestamp, and for sql: TIMESTAMP. This
> means
> > that the createdTxStamp is the same as createdStamp  and
>  lastUpdatedTxStamp
> > is the same as lastUpdatedStamp.
> >
> > Should we get rid of the redundant fields?
> >
> > Also, a lot of entity definitions in the various models have the
> > 'createdByUserLogin' and 'lastModifiedByUserLogin' added.
> >
> > Should we have these fields added to the internal fields set so that
>  these
> > are always injected into the model of each entity, and always filled?
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *Apache Trafodion , Vice President*
> > *Apache Directory , PMC Member*
> > Apache Incubator , committer
> > *Apache OFBiz , contributor (without
>  privileges)
> > since 2008*
> > Apache Steve , committer
> >
> >>
>

Re: [DISCUSSION] JIRA notifications and reaching contributors

[Jacques Le Roux]

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

Jacques

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

I am also inline with Michael's comments.


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



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


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

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

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

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 25.04.19 um 12:20 schrieb Pierre Smits:

Hi All,

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

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

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

2018-06-20,

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

The numbers indicate that about 14% of our contributor potential

subscribed

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

less

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

And

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

are

even worse.

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

we

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

user@

subscribers, leading to an overload of those working tickets.

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

share

and lessen the work load?

What do you think?


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

https://ofbiz.markmail.org/message/6hlbap7a6cam3rm2?q=%22%5BVOTE%5D+Create+a+%22notifications%22+mailing+list+%22+list:org%2Eapache%2Eofbiz%2Edev+order:date-forward




Best regards,

Pierre Smits

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

privileges)

since 2008*
Apache Steve , committer

Re: [DISCUSSION] JIRA notifications and reaching contributors

[Swapnil M Mane]

I am also inline with Michael's comments.


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



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

> I strongly suggest to stay with the split between notifications@ and dev@.
>
> It makes the dev@ discussions a lot better to follow, these would drown
> in the Jira notifications. I suspect that we would make users
> unsubscribe dev@ if we would have notifications@ in there also.
>
> If people are interested in getting the notifications, they can
> subscribe anytime. It might be reasonable to encourage people in the
> dev@/user@ lists to subscribe there if we believe they are not aware of
> the notifications@ list.
>
> Regards,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 25.04.19 um 12:20 schrieb Pierre Smits:
> > Hi All,
> >
> > Back in 2016 it was decided that notifications go to the separate mailing
> > list notifications@ofbiz.a.o. See [1]. And looking at latest numbers
> > reported regarding subscriptions to our mailing lists, we have:
> >
> > - user@: 926
> > - dev@: 574
> > - commits@: 218
> > - notifications@: 78
> >
> > The numbers regarding user@, dev@ and notifications@ are from
> 2018-06-20,
> > and the number regarding notifications@ is from 2018-03-20, see [2].
> >
> > The numbers indicate that about 14% of our contributor potential
> subscribed
> > to the dev@ sees these notifications about bugs and improvements, and
> less
> > than 9%  of our greater community  (subscribed to user@) are reached.
> And
> > when we factor in the impact of PMC members and committers (I can only
> > guess how many of those have subscribed) on notifications@) the ratios
> are
> > even worse.
> >
> > The effect of the low number of subscriptions to notifications@ is that
> we
> > don't reach our potential and that we don't see the input of dev@ and
> user@
> > subscribers, leading to an overload of those working tickets.
> >
> > Did we take a wrong turn back in 2016? And should we not revert the
> > resolution of the vote to have notifications go back to dev@ to get more
> > contributions (potentially leading to more - active - committers that
> share
> > and lessen the work load?
> >
> > What do you think?
> >
> >
> > [1] [VOTE] Create a "notifications" mailing list
> > <
> https://ofbiz.markmail.org/message/6hlbap7a6cam3rm2?q=%22%5BVOTE%5D+Create+a+%22notifications%22+mailing+list+%22+list:org%2Eapache%2Eofbiz%2Edev+order:date-forward
> >
> >
> >
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *Apache Trafodion , Vice President*
> > *Apache Directory , PMC Member*
> > Apache Incubator , committer
> > *Apache OFBiz , contributor (without
> privileges)
> > since 2008*
> > Apache Steve , committer
> >
>
>

Re: [DISCUSSION] JIRA notifications and reaching contributors

[Michael Brohl]

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

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


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


Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 25.04.19 um 12:20 schrieb Pierre Smits:

Hi All,

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

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

The numbers regarding user@, dev@ and notifications@ are from 2018-06-20,
and the number regarding notifications@ is from 2018-03-20, see [2].

The numbers indicate that about 14% of our contributor potential subscribed
to the dev@ sees these notifications about bugs and improvements, and less
than 9%  of our greater community  (subscribed to user@) are reached. And
when we factor in the impact of PMC members and committers (I can only
guess how many of those have subscribed) on notifications@) the ratios are
even worse.

The effect of the low number of subscriptions to notifications@ is that we
don't reach our potential and that we don't see the input of dev@ and user@
subscribers, leading to an overload of those working tickets.

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

What do you think?


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




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





smime.p7s
Description: S/MIME Cryptographic Signature

[DISCUSSION] JIRA notifications and reaching contributors

[Pierre Smits]

Hi All,

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

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

The numbers regarding user@, dev@ and notifications@ are from 2018-06-20,
and the number regarding notifications@ is from 2018-03-20, see [2].

The numbers indicate that about 14% of our contributor potential subscribed
to the dev@ sees these notifications about bugs and improvements, and less
than 9%  of our greater community  (subscribed to user@) are reached. And
when we factor in the impact of PMC members and committers (I can only
guess how many of those have subscribed) on notifications@) the ratios are
even worse.

The effect of the low number of subscriptions to notifications@ is that we
don't reach our potential and that we don't see the input of dev@ and user@
subscribers, leading to an overload of those working tickets.

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

What do you think?


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




Best regards,

Pierre Smits

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

Re: Visit/Visitor specific client IPs tracking exclusion

[Giulio Speri - MpStyle Srl]

Hello everyone,

I have created a Jira task for this.

OFBIZ-10957 


Giulio

Il giorno sab 13 apr 2019 alle ore 16:30 Giulio Speri - MpStyle Srl <
giulio.sp...@mpstyle.it> ha scritto:

> Hi Nicolas,
>
> thank you for the suggestion.
> For HaProxy in fact, we prepared a simple request "hacheck" used
> specifically for Health Checks; I tried to set the attributes "track-visit"
> and "track-serverhit" to "false" on the request-map and made some test
> (with the help JMeter) but they affect only "firstvisit" events and the
> tracking of the server hit.
> The problem is that records for Visit and Visitor are created in the
> *ControlServlet#doGet*, before the *RequestHandler#trackVisit* and
> *RequestHandler#trackStats* are executed.
>
> In particular, the trackVisit method, evaluated to check if
> *FIRST_VISIT_EVENTS* should be run, is executed in the
> *RequestHandler#doRequest* method, called in the ControlServlet after the
> setup of some initial request attributes and after these two statements:
>
> *VisitHandler.getVisitor(request, response);*
>
> and
>
> *String visitId = VisitHandler.getVisitId(session);*
>
> If the ip is not filtered before the statements above, the HaProxy that
> requests for its health check page with the track-visit and track-serverhit
> set to "false", will end up to store Visit/Visitor records anyway.
>
> I think that setting those two parameters on the check page should be used
> along with our solution, in order to achieve what we are looking for.
>
>
> @Arun Yes, your summary is accurate.
>
> Thank you and Regards,
> Giulio
>
>
>
>
> Il giorno ven 12 apr 2019 alle ore 09:19 Nicolas Malin <
> nicolas.ma...@nereide.fr> ha scritto:
>
>> Hello,
>>
>> To manage own load balancer we use a dedicate uri like this :
>>
>> > track-visit="false">
>>
>> It would be help to redirect your monitoring traffic.
>>
>> Nicolas
>>
>> On 12/04/2019 08:49, Arun Patidar wrote:
>> > Hello Giulio,
>> >
>> > Thanks for the the detailed and clear message. My understanding with
>> your
>> > proposal is as below:
>> >
>> > 1) We should enable configuration settings to ignore visit entries for
>> > Internal IPs and known requests (like HaProxy/load balancer, monitoring
>> > requests) etc.
>> > 2) For large DB size due to visits and hits, we can use a separate Stats
>> > database for visit entity group.
>> > 3) Also, idea to purge old visits using a scheduled job is good, We can
>> set
>> > number of days configurable as per need.
>> >
>> >
>> >
>> > --
>> > Best Regards,
>> > Arun Patidar
>> > www.hotwax.co
>> >
>> >
>> >
>> > On Fri, Apr 12, 2019 at 5:17 AM Giulio Speri - MpStyle Srl <
>> > giulio.sp...@mpstyle.it> wrote:
>> >
>> >> Hello devs,
>> >>
>> >> I'm writing because I would like to explain a problem my company,
>> MpStyle,
>> >> faced with an OFBiz installation with two active ecommerce sites, for
>> one
>> >> of our customers.
>> >> I am writing this email to the dev mailing list, because I could not
>> find
>> >> any reference in the mailings to the kind of problem we faced, and I
>> think
>> >> that the solution we built, could be an improvement to the OFBiz
>> >> visit/visitor tracking capabilites.
>> >>
>> >> I shortly explain the server architecture on which OFBiz is running:
>> hosted
>> >> by a third party supplier, there are two (virtual) machines where
>> Apache
>> >> OFBiz 13.07.03 is running behind Apache2 web server (so we have two web
>> >> fronts).
>> >> On other two different machines there are the database (MariaDB) and
>> >> HaProxy has a load balancer.
>> >> HaProxy is configured to perform its Health Checks on the backend
>> servers
>> >> with a Http GET on the Home Page of one of the two sites.
>> >> Visit and Visitor tracking are enabled, for BI and analytics purposes,
>> so
>> >> we cannot turn them off.
>> >> These two combined things caused the Visit and Visitor tables to
>> explode in
>> >> dimensions (we counted about 19M records of Visit and about 67M of
>> >> Visitors, with the 86% of those caused by the load balancer), since
>> each
>> >> hit of the HaProxy store a Visit and a Visitor record on the db (plus
>> some
>> >> other record of other entities, like ShoppingList, due to 
>> and
>> >>  events).
>> >> A bad side effect of this situation, on the long run, is an overall
>> >> performance degradation, and an increase in webfront unavailability
>> time
>> >> windows during the day: it's not necessary to say that our customer
>> was not
>> >> so happy about this.
>> >>
>> >> The difficult part of figuring out this problem, was that we did not
>> have
>> >> direct access to HaProxy and DB machines, to check logs.
>> >>
>> >> The solution we thought and implemented, was to exclude from
>> Visit/Visitor
>> >> tracking specific IP addresses (for our case we were interested in
>> HaProxy
>> >> IP).
>> >> The Visit and Visitor records (along with firstvisit and preprocessor
>> >> events) are created mainly in the Con

Re: Reviving the OFBiz community day

[Pierre Smits]

2 minds .

Looking forward to the doc, Swapnil

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, Apr 25, 2019 at 10:55 AM Swapnil M Mane 
wrote:

> Wow, thoughts travels Pierre!
> I am also working a document for migration of OFBiz from SVN to Git.
> It is at very beginning state, hopefully will share it by this end of week.
> :)
>
>
>
> - Best Regards,
> Swapnil M Mane,
> ofbiz.apache.org
>
>
>
> On Thu, Apr 25, 2019 at 2:19 PM Pierre Smits 
> wrote:
>
> > Great initiative.
> >
> > Would love to see such event to help moving the git issue forward. See
> [1]
> >
> > [1] git commit workflow for ofbiz
> > <
> >
> https://ofbiz.markmail.org/message/iojtu6abffow2p43?q=%22git+commit+workflow+for+ofbiz%22+list:org%2Eapache%2Eofbiz%2Edev+order:date-forward
> > >
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *Apache Trafodion , Vice President*
> > *Apache Directory , PMC Member*
> > Apache Incubator , committer
> > *Apache OFBiz , contributor (without
> privileges)
> > since 2008*
> > Apache Steve , committer
> >
> >
> > On Thu, Apr 25, 2019 at 7:24 AM Swapnil M Mane 
> > 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: Reviving the OFBiz community day

[Swapnil M Mane]

Wow, thoughts travels Pierre!
I am also working a document for migration of OFBiz from SVN to Git.
It is at very beginning state, hopefully will share it by this end of week.
:)



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



On Thu, Apr 25, 2019 at 2:19 PM Pierre Smits  wrote:

> Great initiative.
>
> Would love to see such event to help moving the git issue forward. See [1]
>
> [1] git commit workflow for ofbiz
> <
> https://ofbiz.markmail.org/message/iojtu6abffow2p43?q=%22git+commit+workflow+for+ofbiz%22+list:org%2Eapache%2Eofbiz%2Edev+order:date-forward
> >
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion , Vice President*
> *Apache Directory , PMC Member*
> Apache Incubator , committer
> *Apache OFBiz , contributor (without privileges)
> since 2008*
> Apache Steve , committer
>
>
> On Thu, Apr 25, 2019 at 7:24 AM Swapnil M Mane 
> 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: svn commit: r1856609 - in /ofbiz/ofbiz-framework/trunk/applications/order: groovyScripts/test/OrderTests.groovy testdef/data/OrderTestData.xml

[Pierre Smits]

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

Re: Reviving the OFBiz community day

[Pierre Smits]

Great initiative.

Would love to see such event to help moving the git issue forward. See [1]

[1] git commit workflow for ofbiz


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, Apr 25, 2019 at 7:24 AM Swapnil M Mane 
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
>