ofbiz.locale.default in start.properties

[Jacques Le Roux]

Hi,

While explaining to a customer how the default language is picked, I stumbled 
upon ofbiz.locale.default in start.properties.

I still remember the old days where you had to set the user.language system 
property manually from CLI when launching OFBiz to set the default language.

This is no longer true for a while. The language used by default is taken from 
the browser*:

This is done by UtilHttp::getLocale which ultimately uses:

   Locale javax.servlet.ServletRequest.getLocale()

   Returns the preferred Locale that the client will accept content in, based 
on the Accept-Language header.
   If the client request doesn't provide an Accept-Language header, this method 
returns the default locale for the server.
   Returns: the preferred Locale for the client

We also use initialLocaleComplete in the screens for JavaScript part.

I see no reasons to keep ofbiz.locale.default in start.properties and the 
related Config::getDefaultLocale
Also locale.properties.fallback in general.properties have no effects.

If you want to give a try: I use French by default, if I set ofbiz.locale.default=de_DE and locale.properties.fallback=ar: no effects**. I still have 
French labels showing.


I thought about removing them for clarity sake. But the point ** below makes me rather think that we should simply change the properties 
documentation. I'll do so in a week if nobody see a better solution


Also it should be noted that you can force the language by store using the Default Locale String, eg [1]. THis is only for frontends (ecommerce, 
webpos, etc.)


I hope this will useful for everybody, it was not quite clear to me :)

Jacques

* If no one has forced the value using the changing language feature, done by 
setSessionLocale which also sets lastLocale to remind.
** Apart things like this due to jobs pending that run before any UI 
interactions. There are most often because of demo data:
2020-08-09 11:13:49,349 |OFBiz-JobQueue-0 |UtilProperties    |I| ResourceBundle ServiceErrorUiLabels (de_DE) created in 0.048s with 6 
properties
2020-08-09 11:13:49,349 |OFBiz-JobQueue-0 |UtilProperties    |W| ServicePermissionErrorDefinitionProblem is missing in 
ServiceErrorUiLabels for locale de_DE

2020-08-09 11:13:49,349 |OFBiz-JobQueue-0 |ServiceUtil   |E| 
{errorMessage=ServicePermissionErrorDefinitionProblem, responseMessage=error}
2020-08-09 11:13:49,349 |OFBiz-JobQueue-0 |UtilProperties    |W| 
ServicePermissionError is missing in ServiceErrorUiLabels for locale de_DE
2020-08-09 11:13:49,349 |OFBiz-JobQueue-0 |ServiceDispatcher |T| [[Sync service failed...- total:0.0,since last(Begin):0.0]] - 'default / 
createMaintsFromTimeInterval'

2020-08-09 11:13:49,350 |OFBiz-JobQueue-0 |TransactionUtil   |W| 
Transaction rollback only not set, status is STATUS_NO_TRANSACTION
2020-08-09 11:13:49,351 |OFBiz-JobQueue-0 |GenericServiceJob |E| 
Async-Service failed.

https://demo-trunk.ofbiz.apache.org/catalog/control/EditProductStore?productStoreId=9000
 (Localization block)

Re: Ordering Decimals

[Jacques Le Roux]

Hi,

I was wrong. It's not due to Boostrap. I could not understand how a theming 
feature could do that.
So I searched and found the reason of this regression. It's due to
https://gitbox.apache.org/repos/asf?p=ofbiz-plugins.git;h=a802ae0


With 88224620  I reverted Suraj's workaround and the change in 
ConfigProductDetail.ftl by
commit a802ae0. I'll ask James to fix the root of the issue in OFBIZ-11706.

I hope there are no other types or regressions...

Jacques

Le 07/08/2020 à 11:20, Jacques Le Roux a écrit :

Hi All,

I believe OFBIZ-11899 is due to a mismatch in the Boostrap "recent" changes 
(also in R18, R17 OK).

The browser log says: "TypeError: document.addform.quantity is undefined"

Here is the generated code:

https://localhost:8443/ecomseo/additem/product; name="addform">value="ENCHILADAS">id="add_amount" class="hidden">Amountclass="input-group">href="javascript:addItem()" class="btn btn-outline-secondary btn-sm">Add to Cart Though it seems OK in ecommerce 
ConfigProductDetail.ftl, addform form is closed before enclosing add_amount and quantity fields, As I have no competencies in Boostrap, and don't 
want to have, could somebody competent have a look? I need that before fixing OFBIZ-11916. TIA Jacques


Le 25/07/2020 à 12:05, Jacques Le Roux a écrit :

I created OFBIZ-11916 for that

Le 20/07/2020 à 19:17, Jacques Le Roux a écrit :

Hi,

In OFBiz, OOTB you can order decimals of products. For instance you may want to sell half pizza. That is an user decision. The user may want to 
allow decimals by store or by product as shown in


https://github.com/apache/ofbiz-framework/blob/trunk/applications/product/src/main/java/org/apache/ofbiz/product/product/ProductWorker.java#L1204

We though should not be able to order a part of finished product like "Tiny Chrome Widget" (try 3.5 as mini is 3). You may notice that we have an 
issue in trunk and R18: see OFBIZ-11899. It works in stable demo and R17 locally.


We should set orderDecimalQuantity to false for all products data of FINISHED_GOOD, SERVICE, AGGREGATED, MARKETING_PKG_AUTO, DIGITAL_GOOD, 
ASSET_USAGE, etc. as can be seen in ProductSeedData.xml. Anyway it should be set on a product basis.


I think it's worth to do. Because it's demo data and would show to correctly set things. For a store which sells only not splittable products 
(which I guess is most of the time when using OFBiz ecommerce) then it's possible to set the same at the store level.


What do you think?

Jacques

Re: Ordering Decimals

[Jacques Le Roux]

Hi All,

I believe OFBIZ-11899 is due to a mismatch in the Boostrap "recent" changes 
(also in R18, R17 OK).

The browser log says: "TypeError: document.addform.quantity is undefined"

Here is the generated code:

https://localhost:8443/ecomseo/additem/product; name="addform">value="ENCHILADAS">id="add_amount" class="hidden">Amountclass="input-group">href="javascript:addItem()" class="btn btn-outline-secondary btn-sm">Add to Cart Though it seems OK in ecommerce 
ConfigProductDetail.ftl, addform form is closed before enclosing add_amount and quantity fields, As I have no competencies in Boostrap, and don't want 
to have, could somebody competent have a look? I need that before fixing OFBIZ-11916. TIA Jacques


Le 25/07/2020 à 12:05, Jacques Le Roux a écrit :

I created OFBIZ-11916 for that

Le 20/07/2020 à 19:17, Jacques Le Roux a écrit :

Hi,

In OFBiz, OOTB you can order decimals of products. For instance you may want to sell half pizza. That is an user decision. The user may want to 
allow decimals by store or by product as shown in


https://github.com/apache/ofbiz-framework/blob/trunk/applications/product/src/main/java/org/apache/ofbiz/product/product/ProductWorker.java#L1204

We though should not be able to order a part of finished product like "Tiny Chrome Widget" (try 3.5 as mini is 3). You may notice that we have an 
issue in trunk and R18: see OFBIZ-11899. It works in stable demo and R17 locally.


We should set orderDecimalQuantity to false for all products data of FINISHED_GOOD, SERVICE, AGGREGATED, MARKETING_PKG_AUTO, DIGITAL_GOOD, 
ASSET_USAGE, etc. as can be seen in ProductSeedData.xml. Anyway it should be set on a product basis.


I think it's worth to do. Because it's demo data and would show to correctly set things. For a store which sells only not splittable products 
(which I guess is most of the time when using OFBiz ecommerce) then it's possible to set the same at the store level.


What do you think?

Jacques

Re: buildbot exception in on ofbizTrunkFrameworkPlugins

[Jacques Le Roux]

Works here too

Le 03/08/2020 à 07:32, Suraj Khurana a écrit :

All good on the local machine.

--

Best Regards,
Suraj Khurana
Senior Technical Consultant


On Mon, Aug 3, 2020 at 10:15 AM  wrote:


The Buildbot has detected a build exception on builder
ofbizTrunkFrameworkPlugins while building ofbiz-plugins. Full details are
available at:
 https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1581

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

Buildslave for this Build: asf945_ubuntu

Build Reason: The AnyBranchScheduler scheduler named
'onTrunkPluginsCommit' triggered this build
Build Source Stamp: [branch trunk] b65d9c94df18ab57357111ee6365287f40fd1282
Blamelist: Suraj Khurana 

BUILD FAILED: exception build upload test-results part 1

Sincerely,
  -The Buildbot

Re: REST implementation

[Jacques Le Roux]

At https://localhost:8443/rest/ I get a 404 and in log

javax.ws.rs.NotFoundException: HTTP 404 Not Found
    at 
org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:250)
    at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
    at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
    at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
    at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
    at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
    at 
org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:265)
    at 
org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:232)
    at 
org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:680)
    at 
org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:394)
    at 
org.glassfish.jersey.servlet.ServletContainer.serviceImpl(ServletContainer.java:386)
    at 
org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:561)
    at 
org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:502)
    at 
org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:439)
    at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
    at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
    at 
org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:71)
    at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
    at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
    at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
    at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
    at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
    at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
    at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
    at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
    at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690)
    at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
    at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:373)
    at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
    at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
    at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1589)
    at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
    at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.lang.Thread.run(Thread.java:748)

Normal?

Le 02/08/2020 à 11:14, Jacques Le Roux a écrit :

I get that we have this information at

https://localhost:8443/docs/swagger-ui.html

like with

https://localhost:8443/docs/swagger-ui.html#/Exported%20Services/findProductById

So I guess we can put a link to that, rigth?

Also there is no of...@apache.org (at OpenApiResource::buildOpenApiContact) I'd 
suggest dev@ofbiz.apache.org

For "Terms of service" I suggest a link to ASL2 and to remove the below direct 
link to it.

BTW thanks Girish, this is really a great step forward :)

Jacques


Le 02/08/2020 à 09:40, Jacques Le Roux a écrit :

Hi Girish,

I'm just starting to review so I may miss things. Just a question for now. We 
have an option at

https://demo-trunk.ofbiz.apache.org/webtools/control/ServiceList?sel_service_name=testScv

to  (Show wsdl 
<https://demo-trunk.ofbiz.apache.org:443/webtools/control/ServiceList?sel_service_name=testScv_wsdl=true>)

Would it be possible to have the same for REST?

Thanks

Jacques

Le 31/07/2020 à 10:32, Girish Vasmatkar a écrit :

Greetings!

I have created a PR to add a REST component -
https://github.com/apache/ofbiz-plugins/pull/35 . Please take a look
and let me know what you think and let me know if you face any issues. I
intend to merge it in a week from now.

With the PR (https://github.com/apache/ofbiz-framework/pull/214) to add
"action" attribute to the service definition now merged, this above
component should be able to expose exportable (export=true) and
actionable(action=GET|POST) services via REST.

Once the changes for nested attributes (OFBIZ-11902
<h

Re: REST implementation

[Jacques Le Roux]

I get that we have this information at

https://localhost:8443/docs/swagger-ui.html

like with

https://localhost:8443/docs/swagger-ui.html#/Exported%20Services/findProductById

So I guess we can put a link to that, rigth?

Also there is no of...@apache.org (at OpenApiResource::buildOpenApiContact) I'd 
suggest dev@ofbiz.apache.org

For "Terms of service" I suggest a link to ASL2 and to remove the below direct 
link to it.

BTW thanks Girish, this is really a great step forward :)

Jacques


Le 02/08/2020 à 09:40, Jacques Le Roux a écrit :

Hi Girish,

I'm just starting to review so I may miss things. Just a question for now. We 
have an option at

https://demo-trunk.ofbiz.apache.org/webtools/control/ServiceList?sel_service_name=testScv

to  (Show wsdl 
<https://demo-trunk.ofbiz.apache.org:443/webtools/control/ServiceList?sel_service_name=testScv_wsdl=true>)

Would it be possible to have the same for REST?

Thanks

Jacques

Le 31/07/2020 à 10:32, Girish Vasmatkar a écrit :

Greetings!

I have created a PR to add a REST component -
https://github.com/apache/ofbiz-plugins/pull/35 . Please take a look
and let me know what you think and let me know if you face any issues. I
intend to merge it in a week from now.

With the PR (https://github.com/apache/ofbiz-framework/pull/214) to add
"action" attribute to the service definition now merged, this above
component should be able to expose exportable (export=true) and
actionable(action=GET|POST) services via REST.

Once the changes for nested attributes (OFBIZ-11902
<https://issues.apache.org/jira/browse/OFBIZ-11902>) are done, I will also
be making corresponding changes in the GraphQL plugin to account for nested
attributes. OFBIZ-11902
<https://issues.apache.org/jira/browse/OFBIZ-11902> will
help in defining complex GraphQL mutations.

I am parallelly also working on designing an XML DSL for REST that should
allow tying up REST resources with OFBiz services.

Best,
Girish



On Thu, Jul 9, 2020 at 6:27 PM Shi Jinghai  wrote:


Hi Girish,

Yes, you got it.

Web browser will popup a login dialog when response code is 401:
setResponseHeader("WWW-Authenticate", "Bearer realm=\"authentication
required\"");

The popup is skipped and then react/vue/angular can handle the response:
setResponseHeader("WWW-Authenticate", "OFBiz realm=\"authentication
required\"");


发件人: Girish Vasmatkar<mailto:girish.vasmat...@hotwaxsystems.com>
发送时间: 2020年7月9日 14:54
收件人: dev@ofbiz.apache.org<mailto:dev@ofbiz.apache.org>
主题: Re: REST implementation

Hi Shi

Thanks for taking a look at it. I have a question on "WWW-Authenticate"
header so please clarify and I can make appropriate changes accordingly -

All I am finding is that to prevent the pop-up, either return 403 (which I
do not want to do) or not include "WWW-Authenticate" header at all (not
inclined to do this as well because then we would be violating the spec).
Do you mean to NOT start the value of the header with "Bearer" ?
so instead of below

*WWW-Authenticate: Bearer realm="Access to OFBiz", charset="UTF-8"*

should we change it to

*WWW-Authenticate: xBearer realm="Access to OFBiz", charset="UTF-8"*

I did not test it, but I can just change it like this without testing if
you can please confirm it will prevent the browser dialog.

Thanks again for the review.

Best,
Girish

On Wed, Jul 8, 2020 at 8:45 PM Shi Jinghai  wrote:


Hi Girish,

Excellent.

Only one suggestion from my quick view, when response code is 401, the
"WWW-Authenticate" header should be set to start with a word NOT “Bearer
…”, this can prevent web browser from popping up a login dialog.

Kind Regards,

Shi Jinghai

发件人: Girish Vasmatkar<mailto:girish.vasmat...@hotwaxsystems.com>
发送时间: 2020年7月8日 20:47
收件人: dev@ofbiz.apache.org<mailto:dev@ofbiz.apache.org>
主题: Re: REST implementation

Hi Folks

I have added support for OpenApi Integration. The updated code can be

found

here : https://github.com/girishvasmatkar/ofbiz-rest-impl. Please go
through the changes and test at your end and let me know your thoughts.

I am planning to do some refactoring and then raise initial PR for the
plug-in if the changes look good to everyone.

Best,
Girish


On Wed, Jun 17, 2020 at 4:54 PM Carsten Schinzer <
cars...@dcs-verkaufssysteme.de> wrote:


Hi Girish,

Thanks to clarify :)
What caught me on the OpenAPI integration is the snippet quoted below

and

I realize I should have read it in context. Actually then it is aligned
with my view.

Warm regards

Carsten


Initial implementation does not contain OpenApi integration yet.

And

Re: REST implementation

[Jacques Le Roux]

Not a big deal, saw that when applying as a patch:

git apply 35.patch
35.patch:364: trailing whitespace.
* GET /rest/services/{serviceName}?inParams=
35.patch:765: trailing whitespace.
    xmlns:xl="http://www.w3.org/1999/xlink;
35.patch:2813: trailing whitespace.

35.patch:486: new blank line at EOF.
+
35.patch:772: new blank line at EOF.
+
warning: 5 lines add whitespace errors.

Jacques

Le 02/08/2020 à 09:40, Jacques Le Roux a écrit :

Hi Girish,

I'm just starting to review so I may miss things. Just a question for now. We 
have an option at

https://demo-trunk.ofbiz.apache.org/webtools/control/ServiceList?sel_service_name=testScv

to  (Show wsdl 
<https://demo-trunk.ofbiz.apache.org:443/webtools/control/ServiceList?sel_service_name=testScv_wsdl=true>)

Would it be possible to have the same for REST?

Thanks

Jacques

Le 31/07/2020 à 10:32, Girish Vasmatkar a écrit :

Greetings!

I have created a PR to add a REST component -
https://github.com/apache/ofbiz-plugins/pull/35 . Please take a look
and let me know what you think and let me know if you face any issues. I
intend to merge it in a week from now.

With the PR (https://github.com/apache/ofbiz-framework/pull/214) to add
"action" attribute to the service definition now merged, this above
component should be able to expose exportable (export=true) and
actionable(action=GET|POST) services via REST.

Once the changes for nested attributes (OFBIZ-11902
<https://issues.apache.org/jira/browse/OFBIZ-11902>) are done, I will also
be making corresponding changes in the GraphQL plugin to account for nested
attributes. OFBIZ-11902
<https://issues.apache.org/jira/browse/OFBIZ-11902> will
help in defining complex GraphQL mutations.

I am parallelly also working on designing an XML DSL for REST that should
allow tying up REST resources with OFBiz services.

Best,
Girish



On Thu, Jul 9, 2020 at 6:27 PM Shi Jinghai  wrote:


Hi Girish,

Yes, you got it.

Web browser will popup a login dialog when response code is 401:
setResponseHeader("WWW-Authenticate", "Bearer realm=\"authentication
required\"");

The popup is skipped and then react/vue/angular can handle the response:
setResponseHeader("WWW-Authenticate", "OFBiz realm=\"authentication
required\"");


发件人: Girish Vasmatkar<mailto:girish.vasmat...@hotwaxsystems.com>
发送时间: 2020年7月9日 14:54
收件人: dev@ofbiz.apache.org<mailto:dev@ofbiz.apache.org>
主题: Re: REST implementation

Hi Shi

Thanks for taking a look at it. I have a question on "WWW-Authenticate"
header so please clarify and I can make appropriate changes accordingly -

All I am finding is that to prevent the pop-up, either return 403 (which I
do not want to do) or not include "WWW-Authenticate" header at all (not
inclined to do this as well because then we would be violating the spec).
Do you mean to NOT start the value of the header with "Bearer" ?
so instead of below

*WWW-Authenticate: Bearer realm="Access to OFBiz", charset="UTF-8"*

should we change it to

*WWW-Authenticate: xBearer realm="Access to OFBiz", charset="UTF-8"*

I did not test it, but I can just change it like this without testing if
you can please confirm it will prevent the browser dialog.

Thanks again for the review.

Best,
Girish

On Wed, Jul 8, 2020 at 8:45 PM Shi Jinghai  wrote:


Hi Girish,

Excellent.

Only one suggestion from my quick view, when response code is 401, the
"WWW-Authenticate" header should be set to start with a word NOT “Bearer
…”, this can prevent web browser from popping up a login dialog.

Kind Regards,

Shi Jinghai

发件人: Girish Vasmatkar<mailto:girish.vasmat...@hotwaxsystems.com>
发送时间: 2020年7月8日 20:47
收件人: dev@ofbiz.apache.org<mailto:dev@ofbiz.apache.org>
主题: Re: REST implementation

Hi Folks

I have added support for OpenApi Integration. The updated code can be

found

here : https://github.com/girishvasmatkar/ofbiz-rest-impl. Please go
through the changes and test at your end and let me know your thoughts.

I am planning to do some refactoring and then raise initial PR for the
plug-in if the changes look good to everyone.

Best,
Girish


On Wed, Jun 17, 2020 at 4:54 PM Carsten Schinzer <
cars...@dcs-verkaufssysteme.de> wrote:


Hi Girish,

Thanks to clarify :)
What caught me on the OpenAPI integration is the snippet quoted below

and

I realize I should have read it in context. Actually then it is aligned
with my view.

Warm regards

Carsten


Initial implementation does not contain OpenApi integration yet.

And

Re: REST implementation

[Jacques Le Roux]

Hi Girish,

I'm just starting to review so I may miss things. Just a question for now. We 
have an option at

https://demo-trunk.ofbiz.apache.org/webtools/control/ServiceList?sel_service_name=testScv

to  (Show wsdl 
)

Would it be possible to have the same for REST?

Thanks

Jacques

Le 31/07/2020 à 10:32, Girish Vasmatkar a écrit :

Greetings!

I have created a PR to add a REST component -
https://github.com/apache/ofbiz-plugins/pull/35 . Please take a look
and let me know what you think and let me know if you face any issues. I
intend to merge it in a week from now.

With the PR (https://github.com/apache/ofbiz-framework/pull/214) to add
"action" attribute to the service definition now merged, this above
component should be able to expose exportable (export=true) and
actionable(action=GET|POST) services via REST.

Once the changes for nested attributes (OFBIZ-11902
) are done, I will also
be making corresponding changes in the GraphQL plugin to account for nested
attributes. OFBIZ-11902
 will
help in defining complex GraphQL mutations.

I am parallelly also working on designing an XML DSL for REST that should
allow tying up REST resources with OFBiz services.

Best,
Girish



On Thu, Jul 9, 2020 at 6:27 PM Shi Jinghai  wrote:


Hi Girish,

Yes, you got it.

Web browser will popup a login dialog when response code is 401:
setResponseHeader("WWW-Authenticate", "Bearer realm=\"authentication
required\"");

The popup is skipped and then react/vue/angular can handle the response:
setResponseHeader("WWW-Authenticate", "OFBiz realm=\"authentication
required\"");


发件人: Girish Vasmatkar
发送时间: 2020年7月9日 14:54
收件人: dev@ofbiz.apache.org
主题: Re: REST implementation

Hi Shi

Thanks for taking a look at it. I have a question on "WWW-Authenticate"
header so please clarify and I can make appropriate changes accordingly -

All I am finding is that to prevent the pop-up, either return 403 (which I
do not want to do) or not include "WWW-Authenticate" header at all (not
inclined to do this as well because then we would be violating the spec).
Do you mean to NOT start the value of the header with "Bearer" ?
so instead of below

*WWW-Authenticate: Bearer realm="Access to OFBiz", charset="UTF-8"*

should we change it to

*WWW-Authenticate: xBearer realm="Access to OFBiz", charset="UTF-8"*

I did not test it, but I can just change it like this without testing if
you can please confirm it will prevent the browser dialog.

Thanks again for the review.

Best,
Girish

On Wed, Jul 8, 2020 at 8:45 PM Shi Jinghai  wrote:


Hi Girish,

Excellent.

Only one suggestion from my quick view, when response code is 401, the
"WWW-Authenticate" header should be set to start with a word NOT “Bearer
…”, this can prevent web browser from popping up a login dialog.

Kind Regards,

Shi Jinghai

发件人: Girish Vasmatkar
发送时间: 2020年7月8日 20:47
收件人: dev@ofbiz.apache.org
主题: Re: REST implementation

Hi Folks

I have added support for OpenApi Integration. The updated code can be

found

here : https://github.com/girishvasmatkar/ofbiz-rest-impl. Please go
through the changes and test at your end and let me know your thoughts.

I am planning to do some refactoring and then raise initial PR for the
plug-in if the changes look good to everyone.

Best,
Girish


On Wed, Jun 17, 2020 at 4:54 PM Carsten Schinzer <
cars...@dcs-verkaufssysteme.de> wrote:


Hi Girish,

Thanks to clarify :)
What caught me on the OpenAPI integration is the snippet quoted below

and

I realize I should have read it in context. Actually then it is aligned
with my view.

Warm regards

Carsten


Initial implementation does not contain OpenApi integration yet.

And

Re: Reverse bounty idea

[Jacques Le Roux]

And GH did better 
https://docs.github.com/en/github/supporting-the-open-source-community-with-github-sponsors/about-github-sponsors

Jacques

Le 10/12/2013 à 11:47, Jacques Le Roux a écrit :

Someone did it http://www.indiegogo.com/projects/a-month-of-apache-tapestry-5

Jacques

On Saturday, November 29, 2008 9:16 AM Jacques Le Roux 
 wrote:

While working on https://issues.apache.org/jira/browse/OFBIZ-2058 I had also an 
idea about how to deal with OFBiz requirements
from a community POV.

In Open source world there is the well known notion of bounty for feature.

 From time to time (rarely) someone offers to pay for a feature he/she needs.

But this is not used in an official way in OFBiz yet (there are no arranged 
place for that maybe because there are too few needs).

Actually the idea I had is a reversed bounty concept. It will not be a person 
or organisation that will make a pledge for a
feature but a person or organisation that will submit a quote for a new feature 
to be commited in OFBiz.

This came to my mind while working on a quote for a VAT stuff.
Let me explain : a lot of people need VAT/GST (I guess most countries but USA). 
I have open a Jira issue to centralise efforts
OFBIZ-366.
David Garett (OFBIZ-416) and Marco Risaliti (OFBIZ-1262) contributed big 
patches in the past and I wanted to review them but did
not find the time to do so seriously and was not sure it was the right way to 
go at this time.
Also one thing that discouraged me was that both David and Marco was seeing 
their patches as not ready to be commited. They are
now partially unmergeable but I'm sure with still some interesting ideas/code 
in them.
There is also an interesting recent thread 
http://markmail.org/message/bkqmwwvswzlgzbfr and an even more recent wiki page
http://docs.ofbiz.org/display/OFBIZ/VAT (actually these informations are 
referenced at OFBIZ-366 bottom).

The reversed bounty concept is applicable for "feature" like VAT which actually 
may cover a lot of things (which are not obvious
at 1st sight).

How I see it : one person, a team or an organisation propose to develop a new 
feature that has proven in the past to interest a
lot of people but has not been developed in OFBiz because being an huge work or 
not well enough defined
Actually by "propose" I mean detailled requirements to be freely discussed in 
dev ML. Could be also direct estimates like in
http://docs.ofbiz.org/display/OFBIZ/CRM+Sales+Force+Automation+Plan

For instance, for VAT we know there have been some "proprietary" 
implementations.
I guess mostly because it seems difficult to coordinate efforts on things  that 
at 1st sight appears to be countries or
organisations specific.

But, from the links above, we know also that there are some commons features:
* periodic Tax Authority VAT report (input minus input) : by Tax Authority
* affect GL accounts (by Tax Authority) default being  VAT Purchases/Sales 
respectively linked to Assets and Liabilities GL
accounts
* show prices VAT inclusive everywhere it's needed (some issues : OFBIZ-1086)
* how to apply VAT on discount (some categories, not so much)
* etc. (more details in VAT wiki page)

Sorry for the long and disorganised post. I'm trying to find a new way to earn 
a living (crisis effect ?). Reverse bounties could
be shared of course...

Jacques
PS : I was not the 1st to have this idea. Curious I just found that a Drupal 
developer has already suggested a such thing

Re: Update Gradle in trunk

[Jacques Le Roux]

Thanks Nicolas,

I'll try again and get back to you if I can't

Jacques

Le 31/07/2020 à 15:08, Nicolas Malin a écrit :

Hello Jacques,

I tried to load a new gradle wapper version on bintray without problem.

Maybe we can realize it together to be sure we talk on the same subject.

Nicolas

On 23/07/2020 10:29, Jacques Le Roux wrote:

Thanks Nicolas!

Le 21/07/2020 à 14:20, Nicolas Malin a écrit :

Hi Jacques,

Thanks for your alert, I will take some time to check the new UI dans
correct the process.

Nicolas

On 21/07/2020 10:15, Jacques Le Roux wrote:

Hi Nicolas, All,

I tried to update Gradle in trunk following
https://cwiki.apache.org/confluence/display/OFBIZ/Load+new+gradle+wrapper+version+on+bintray

rather than doing it by hand, mostly to test the process by my own.

But the UI has changed. There is no longer an "*Upload* link, hidden
on the header bar". I see only a Link button and it does not seem to
be the same thing.

Any idea?

TIA

Jacques

Re: buildbot failure in on ofbizTrunkFramework

[Jacques Le Roux]

I confirm it's OK

Le 31/07/2020 à 09:48, Jacques Le Roux a écrit :

I guess it's only an unrelated data load issue:


loadQuoteTestData 
<https://ci.apache.org/24_quotetests.html#loadQuoteTestData> Error A 
transaction error occurred reading data

|org.xml.sax.SAXException: A transaction error occurred reading data
org.apache.ofbiz.entity.GenericEntityException: 
org.apache.ofbiz.entity.GenericEntityException: |

I check locally...

Le 31/07/2020 à 09:18, build...@apache.org a écrit :

The Buildbot has detected a new failure on builder ofbizTrunkFramework while 
building ofbiz-framework. Full details are available at:
https://ci.apache.org/builders/ofbizTrunkFramework/builds/1750

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

Buildslave for this Build: asf947_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'onTrunkFrameworkCommit' 
triggered this build
Build Source Stamp: [branch trunk] d962777c771285683737795a0c6db9c55e9d7823
Blamelist: Pawan Verma 

BUILD FAILED: failed testIntegration

Sincerely,
  -The Buildbot

Re: Open Source - Vertical Applications

[Jacques Le Roux]

Hi Neetan,

Your message has been moderated, else it would not have reached this Mailing 
List.

Please subscribe to the user ML for such questions and then use your email 
client.
See why here http://ofbiz.apache.org/mailing-lists.html.

You will get a better support, people can answer you on the ML.
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

This said Nicolas answered you on the user ML, please check 
https://markmail.org/message/wapyrrohrnlx62su

Jacques

Le 30/07/2020 à 22:05, Neetan Chopra a écrit :

Hi there

This is Neetan. I am a Group CTO working in Dubai.
Having worked in the Airline industry for 23 years (with Emirates) I have
been thinking about open sourcing one of the core aviation applications.
However there does not seem to be any example of a vertical OSS
application which has made an impact.

I just wanted to reach out to you to seek your advice on how the journey
with ofbiz has been and the lessons learnt for other open source enterprise
software endeavours.
Thank you and would be most grateful for any advice you can offer.

warm regards
Neetan Chopra

Re: buildbot failure in on ofbizTrunkFramework

[Jacques Le Roux]

I guess it's only an unrelated data load issue:


loadQuoteTestData 
Error   A 
transaction error occurred reading data

|org.xml.sax.SAXException: A transaction error occurred reading data
org.apache.ofbiz.entity.GenericEntityException: 
org.apache.ofbiz.entity.GenericEntityException: |

I check locally...

Le 31/07/2020 à 09:18, build...@apache.org a écrit :

The Buildbot has detected a new failure on builder ofbizTrunkFramework while 
building ofbiz-framework. Full details are available at:
 https://ci.apache.org/builders/ofbizTrunkFramework/builds/1750

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

Buildslave for this Build: asf947_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'onTrunkFrameworkCommit' 
triggered this build
Build Source Stamp: [branch trunk] d962777c771285683737795a0c6db9c55e9d7823
Blamelist: Pawan Verma 

BUILD FAILED: failed testIntegration

Sincerely,
  -The Buildbot

Re: Organize OFBiz Wiki

[Jacques Le Roux]

Hi Devanshu,

Please see my answer to Priya today in "Update 'How-to articles' wiki page" 
thread

HTH

Jacques

Le 30/07/2020 à 07:16, Devanshu Vyas a écrit :

Hello Devs,

We have discussed the need to clean our Wiki for a long time and we did
some work as well. But, with recent opinion shared on the user list, I feel
we should make our priority to clear the haystack of documentation
specially for the need of new OFBiz adaptors.

I would suggest aligning the documentation in such a way that a new person
visiting/exploring OFBiz has a seamless experience in identifying and
learning the traits of OFBiz.

@Jacques, It would be great if you could share more thoughts on the
concern, as you have been very vocal on this effort.

Wating for your thoughts.

Thanks & Regards,
Devanshu Vyas.

Re: Update 'How-to articles' wiki page

[Jacques Le Roux]

Hi Priya,

This page has been moved to Attic. But it still referenced by OFBiz End User Guide - WIP 
: 
https://cwiki.apache.org/confluence/pages/viewinfo.action?pageId=70258169


There is no way in Confluence to know who, when and why it was done: 
https://jira.atlassian.com/browse/CONFSERVER-5231

Actually I know, I did it: https://markmail.org/message/pzwa7ffoj7srjbsr, but 
forgot about the in and out links...

The problem with the documentation in the wiki is to keep things up to date, 
notably with in and out links.
That's why we (I don't think it's me only ;)) want to move all but very generic 
things not related to a version into AsciiDoc.
And refer to https://ci.apache.org/projects/ofbiz/site/ for and up to date 
documentation limited to 3 versions which is already ambitious but possible...

Jacques

Le 31/07/2020 à 07:39, Priya Sharma a écrit :

Hello All,

I recently stumbled upon this wiki page
https://cwiki.apache.org/confluence/display/OFBIZ/How+to+Install+OFBiz+without+the+Demo+Datand
it still refers to release 16.11 while
https://cwiki.apache.org/confluence/display/OFBIZ/How+to+install+OFBiz+with+the+Demo+Data
has been updated as per 17.12.

Was it intentional or should we update it?

Best Regards,
Priya

Re: Repository Management For Third-Party Plugins

[Jacques Le Roux]

Hi,

Like Mridul, I also suggested  the 2nd approach. I eventually tend to agree with Mridul. Having clearly separated packages, even with a bit of 
redundancy, simplifies and consolidate things.


Jacques

Le 30/07/2020 à 17:37, Mridul Pathak a écrit :

Hi Pawan,

Though few years ago I was advocate of the approach #2 that you have suggested 
here, now I think that #1 is the best approach. In real time implementations 
the idea of plugins is to be able to use only what you need. Like for payment 
integrations you selectively use the gateways, mostly one. So it should be as 
easy to drop the plugin for your preferred gateway and use it, you shouldn’t 
need to unnecessarily have to code of all other payment integrations that you 
don’t need. Also, from maintenance perspective even though some of these third 
party integrations could be categorised but still each of them have their own 
API specification, configurations and they need to be maintained separately. 
So, my vote would be to #1 that is to create separate plugins for each third 
party integration.

Thanks.
--
Mridul Pathak



On 30-Jul-2020, at 8:34 PM, Pawan Verma  wrote:

Hi Pritam,

I am also more inclined to not create a different repository for
third-party-plugins. As we can have any number of plugins in OFBiz and
Users can set up required plugins as per their need.

I would suggest creating separate plugins for each third-party integration
like ups, firstdatapaymentgateway, etc that way if the user wants only a
specific gateway or plugins can have only that one.

I suggest two approaches:
#1: Create a separate plugin for each integration and put them into the
plugins directory.

#2: Club all the related plugins into one directory and can add that parent
directory in base/config/component-load.xml. The benefit of this approach
is we can have all payment or other gateways in one place and also don't
need to create a separate repository for the third-party-plugins.
Example for shipping gateways:

   1. Club all shipping gateways into the plugins/shipping-gateway directory
   2. Add this shipping-gateway into base/config/component-load.xml
   as 

If we follow the #2 approach we may need to improve our plugin setup Gradle
target i.e. pullPluginSource.

Please let me know your thoughts and I can provide more detail if needed.

Best
Pawan

Re: ParameterNumber checkstyle rule

[Jacques Le Roux]

10?

Le 29/07/2020 à 17:53, Suraj Khurana a écrit :

Hello team,

Currently there are around 175 issues due parameter count in java methods

Its default value is 7 [1], we should decide this configuration for
checkstyle. In current code, there are some methods having around 20
parameters (addOrIncreaseItem).

[1]:
https://checkstyle.sourceforge.io/apidocs/com/puppycrawl/tools/checkstyle/checks/sizes/ParameterNumberCheck.html

Please share your thoughts on this.

--
Best Regards,
Suraj Khurana
Senior Technical Consultant

Re: MethodLength checkstyle rule

[Jacques Le Roux]

Hi Suraj,

Has I had no ideas about the best length, I was to suggest to add the 2 number 
(150+945) and to divide the total by 2.

This gives us around 550, I'd have suggested 500, but 450 is fine with me.

Thanks

Jacques

Le 29/07/2020 à 19:47, Suraj Khurana a écrit :

Hello team,

Any thoughts on this, IMO we can make it to 450 or something, it's quite
readable by then.
Please suggest.

--

Best Regards,
Suraj Khurana
Senior Technical Consultant


On Sun, Jul 26, 2020 at 9:12 PM Suraj Khurana 
wrote:


Hello team,

Currently there are around 200 issues due method length.

Its default value is 150, we need to decide this configuration. In current
code, maximum method length I noticed is of 945 lines
(createOrder#OrderServices.java)

I have created OFBIZ-11915 for this, we can continue this effort as per
conclusions drawn in this thread.

Please share your thoughts on this.
--
Best Regards,
Suraj Khurana
SENIOR TECHNICAL CONSULTANT
mobile: +91 9669750002
email: suraj.khur...@hotwax.co
*www.hotwax.co *

Re: Is the HTML renderer still used?

[Jacques Le Roux]

Hi Daniel,

I indeed see only imports of org.apache.ofbiz.widget.renderer.html under
framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/html

HtmlMenuWrapper, which uses HtmlMenuRenderer, is used in MenuWrapTransform
But I don't see any use of MenuWrapTransform OOTB through

   menuWrap=org.apache.ofbiz.widget.renderer.MenuWrapTransform

I'd go with your WidgetWorker changes if they are trivial in the package ;)


If the HTML Render package is no longer in use can we remove it?

I think it's a good question you asked, it needs more attention.
It could be used by (old) custom projects. We can't be dragged down by them 
eternally...

HTH

Jacques

Le 25/07/2020 à 10:58, Daniel Watford a écrit :

Hello,

While working on OFBIZ-11907 (
https://github.com/apache/ofbiz-framework/pull/217) I needed to alter the
various callers to WidgetWorker's methods for creating URLs, links and
hidden forms.

For most of the callers I was able to find examples of their use and
therefore (manually) check that current behaviour was maintained after the
WidgetWorker changes. However I couldn't find any places where
HtmlMenuRenderer and HtmlTreeRenderer were used.

I've made minimal changes to HtmlMenuRenderer and HtmlTreeRenderer so they
can continue to use WidgetWorker, but without concrete examples of usage I
am unable to prove they still work.

Is the HTML Renderer package (org.apache.ofbiz.widget.renderer.html) still
in use or was it replaced by the Macro Renderer package?

If HTML Renderer is still used please please point me at the relevant
screens in Ofbiz so I can confirm they have not been broken by the
WidgetWorker changes.

If the HTML Render package is no longer in use can we remove it?

Thanks,

Dan.

Welcome Pawan Verma as new PMC member

[Jacques Le Roux]

The OFBiz PMC has invited Pawan Verma to become member of the committee and we 
are glad to announce that he has accepted the nomination.

On behalf of the OFBiz PMC, welcome on board Pawan!

Re: JavaScript Source Maps

[Jacques Le Roux]

Hi Aditya,

Maybe it will be easier to indeed use the node Gradle plugin.

Though I'm not much versed in node, then I guess following the steps I put in 
the alert at

https://cwiki.apache.org/confluence/display/OFBIZ/About+retire.js

Would be easier? Notably
https://github.com/mozilla/source-map
https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Use_a_source_map

Thanks

Jacques

Le 27/07/2020 à 09:48, Aditya Sharma a écrit :

Hi Jacques,

We should definitely care about JavaScript source maps as it is a great
addon to debugging.

I think gradle-js-plugin is indeed a great tool but due to a dead
community, it always made me reluctant to use it. Thanks for your efforts
towards its update. I still want to understand how it will be further
maintained.

As I get some time I will try to come up with some solution using the
requirejs, node, etc to ease these things.
https://plugins.gradle.org/plugin/com.github.node-gradle.node


So I want to change it to "org.apache.ofbiz" to be able to publish. I

guess I also need to change the package names (not yet sure about that)
I think we will only have to change the id I guess and we have the option
to configure the implementationClass

https://guides.gradle.org/publishing-plugins-to-gradle-plugin-portal/#configure_the_plugin_publishing_plugin


Now we also know (thanks to Suraj) that "We will get source map URL in

most of the libraries except jQuery, we will have to manually add it"[8]
Aditya :D


Thanks and regards,
Aditya Sharma


On Sun, Jul 26, 2020 at 8:48 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Le 26/07/2020 à 11:44, Jacques Le Roux a écrit :

There was a good old time when this was available[1]. But with Gradle

upgrades these plugins were slowly abandoned by their creator, eg[2]

Some forks where done, eg[3][4]. Seems that their creators could not get

PRs merged. So I don't know how/if they are published and used.

I somehow actually answered to myself with


[2] https://github.com/eriwen/gradle-css-plugin/issues/58

I read it there and forgot:

 /<>/

So that's how people are poorly handling it :/

Jacques

Re: JavaScript Source Maps

[Jacques Le Roux]

Le 26/07/2020 à 11:44, Jacques Le Roux a écrit :

There was a good old time when this was available[1]. But with Gradle upgrades 
these plugins were slowly abandoned by their creator, eg[2]

Some forks where done, eg[3][4]. Seems that their creators could not get PRs 
merged. So I don't know how/if they are published and used.


I somehow actually answered to myself with

[2] https://github.com/eriwen/gradle-css-plugin/issues/58 


I read it there and forgot:

   /<>/

So that's how people are poorly handling it :/

Jacques

Re: JavaScript Source Maps

[Jacques Le Roux]

Hi Guys,

I have a problem with that. Sorry for the long coming text :)

Initially the gradle-js-plugin was created and published as a Gradle plugin by  Eric Wendelin at https://github.com/eriwen/gradle-js-plugin. There is 
also https://github.com/eriwen/gradle-css-plugin


There was a good old time when this was available[1]. But with Gradle upgrades 
these plugins were slowly abandoned by their creator, eg[2]

Some forks where done, eg[3][4]. Seems that their creators could not get PRs 
merged. So I don't know how/if they are published and used.

My concern is that if you want to publish using the "plugin publishing plugin"[5] you need to use a 
so called "'group" which is initially "com.eriwen".

The Groovy code is "Licensed under the Apache License, Version 2.0" but also 
"Copyright[ed in] 2012 [by] Eric Wendelin"[6]

That would not be a problem I guess, ASL2 should prevail. The concern is about the so called 
"'group" to publish to (initially "com.eriwen").

Since Eric Wendelin don't care anymore about PRs, it seems he is blocking publishs on 
"com.eriwen".

So I want to change it to "org.apache.ofbiz" to be able to publish. I guess I 
also need to change the package names (not yet sure about that)

What I see for other forks is they still use "com.eriwen" in package, eg[7]. So I guess they are not officially published. I'm still unsure I don't 
miss anything.


The JavaScript Source Map is a cool thing when you need to get into other minified libs. I must say I never got blocked by not being able to do that. 
But I'd have liked to be able to do so few times.


Now we also know (thanks to Suraj) that "We will get source map URL in most of the 
libraries except jQuery, we will have to manually add it"[8]

I put an alert about that at 
https://cwiki.apache.org/confluence/display/OFBIZ/About+retire.js

My questions are:

1. Should we care about JavaScript source maps (I think we should)?
2. Should we care about gradle-js-plugin?
3. If we don't, is my alert in wiki enough (using js tools is uneasy to me)?

Thanks to get to this point ;)

Jacques

[1] https://dzone.com/articles/javascript-webapps-gradle
[2] https://github.com/eriwen/gradle-css-plugin/issues/58
[3] https://github.com/twwwt/gradle-js-plugin
[4] https://github.com/tbutter/gradle-js-plugin/
[5] https://plugins.gradle.org/docs/submit
[6] 
https://github.com/eriwen/gradle-js-plugin/blob/master/src/main/groovy/com/eriwen/gradle/js/tasks/CombineJsTask.groovy
[7] 
https://github.com/twwwt/gradle-js-plugin/blob/master/src/main/groovy/com/eriwen/gradle/js/tasks/CombineJsTask.groovy
[8] https://github.com/jquery/jquery/issues/4166

Le 24/07/2020 à 15:39, Jacques Le Roux a écrit :

Thanks Aditya,

It works only with 5.1 mine works with 6.3. I want to publish it as org.apache.ofbiz.gradle-js-plugin or maybe simply org.apache.ofbiz.js-plugin. 
Still have to complete that (one point is confusing)


Jacques


Le 24/07/2020 à 13:47, Aditya Sharma a écrit :

That's great Jacques.

Just for reference, another fork of gradle js plugin which was updated in
May 2019.
https://plugins.gradle.org/plugin/eu.butter.gradle.js
https://github.com/tbutter/gradle-js-plugin/

Thanks and regards,

Aditya Sharma

On Thu, Jul 23, 2020 at 2:00 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi All,

Backport done, I have created a fork of gradle-js-plugin and it works with
Gradle 6.3. I'll tell you more when I'll get a chance :)

Jacques

Le 19/07/2020 à 16:08, Jacques Le Roux a écrit :

Thanks Aditya,

@All, without more answers I'll exceptionally use a lazy consensus to

backport changes in minified and add of maps files down to R17 in a week
from

"16/07/2020 à 15:01"

This because, even if the Jiras are registered as improvements and we

can't see anything in UI and OFBiz logs, there are 404 and lack of help in

browser log.

Thanks to Alex for the help!

Jacques

Le 17/07/2020 à 14:41, Aditya Sharma a écrit :

Thank you, Jacques and Alex, for bringing this up. I think source maps

can

be a great aid for debugging. I am willing to give a hand.

Thanks and regards,
Aditya Sharma

On Thu, Jul 16, 2020 at 8:36 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Le 16/07/2020 à 15:01, Jacques Le Roux a écrit :

https://issues.apache.org/jira/issues/?jql=project %3D OFBIZ AND

text ~

"map alex"
This url is easier to use: https://s.apache.org/xzdtx

Re: buildbot exception in on ofbizTrunkFrameworkPlugins

[Jacques Le Roux]

Thanks Suraj,

All should be cured now :)

Jacques

Le 25/07/2020 à 19:47, Suraj Khurana a écrit :

Hey Jacques,

I have attached a patch for this existing issue on OFBIZ-11553, it works
for me. Please check and go ahead if it looks good to you as well.

HTH.
--
Best Regards,
Suraj Khurana
Senior Technical Consultant


On Sat, Jul 25, 2020 at 7:59 PM Suraj Khurana 
wrote:


On my local, I am facing same one test failure
(testCreateOrderServiceProduct) and as you mentioned in OFBIZ-11553, it
is working fine with ofbiz -test component=order --test
suitename=shoppingcarttests --test case=configurableServiceOrder-test.

--
Best Regards,
Suraj Khurana
Senior Technical Consultant


On Sat, Jul 25, 2020 at 7:40 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Ha no, we get the same 3 new errors than I locally:

I reverted push from OFBIZ-11487 before it becomes confusing...

Thanks to Pawan's comment in OFBIZ-11553 I'm considering to look again at
the remaining failure. Things get confusing when errors/failures mix...

Jacques

Le 25/07/2020 à 14:41, Suraj Khurana a écrit :

Thanks Jacques for confirming.

--
Best Regards,
Suraj Khurana
Senior Technical Consultant


On Sat, Jul 25, 2020 at 5:40 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Suraj,

It's only about (not) uploading the result file. I tested locally, we

have

still the pending failure error from OFBIZ-11553.
I got 3 others errors I believe are only Windows related (slow files
handling there)

So it's OK, we will see with my next push...

Jacques

Le 25/07/2020 à 12:26, Suraj Khurana a écrit :

Hello team,

Everything looks ok on the local machine with testIntegration.
I checked with "./gradlew cleanAll loadAll testIntegration".

--
Best Regards,
Suraj Khurana
Senior Technical Consultant


On Sat, Jul 25, 2020 at 2:06 PM  wrote:


The Buildbot has detected a build exception on builder
ofbizTrunkFrameworkPlugins while building ofbiz-plugins. Full details

are

available at:


https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1567

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

Buildslave for this Build: asf945_ubuntu

Build Reason: The AnyBranchScheduler scheduler named
'onTrunkPluginsCommit' triggered this build
Build Source Stamp: [branch trunk]

4b88493e1bfd1a0e33bc1a1568ed1e1ba34a254a

Blamelist: Suraj Khurana 

BUILD FAILED: exception javadoc upload test-results part 1

Sincerely,
-The Buildbot

Re: buildbot exception in on ofbizTrunkFrameworkPlugins

[Jacques Le Roux]

Ha no, we get the same 3 new errors than I locally:

I reverted push from OFBIZ-11487 before it becomes confusing...

Thanks to Pawan's comment in OFBIZ-11553 I'm considering to look again at the 
remaining failure. Things get confusing when errors/failures mix...

Jacques

Le 25/07/2020 à 14:41, Suraj Khurana a écrit :

Thanks Jacques for confirming.

--
Best Regards,
Suraj Khurana
Senior Technical Consultant


On Sat, Jul 25, 2020 at 5:40 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Suraj,

It's only about (not) uploading the result file. I tested locally, we have
still the pending failure error from OFBIZ-11553.
I got 3 others errors I believe are only Windows related (slow files
handling there)

So it's OK, we will see with my next push...

Jacques

Le 25/07/2020 à 12:26, Suraj Khurana a écrit :

Hello team,

Everything looks ok on the local machine with testIntegration.
I checked with "./gradlew cleanAll loadAll testIntegration".

--
Best Regards,
Suraj Khurana
Senior Technical Consultant


On Sat, Jul 25, 2020 at 2:06 PM  wrote:


The Buildbot has detected a build exception on builder
ofbizTrunkFrameworkPlugins while building ofbiz-plugins. Full details

are

available at:


https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1567

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

Buildslave for this Build: asf945_ubuntu

Build Reason: The AnyBranchScheduler scheduler named
'onTrunkPluginsCommit' triggered this build
Build Source Stamp: [branch trunk]

4b88493e1bfd1a0e33bc1a1568ed1e1ba34a254a

Blamelist: Suraj Khurana 

BUILD FAILED: exception javadoc upload test-results part 1

Sincerely,
   -The Buildbot

Re: buildbot exception in on ofbizTrunkFrameworkPlugins

[Jacques Le Roux]

Hi Suraj,

It's only about (not) uploading the result file. I tested locally, we have 
still the pending failure error from OFBIZ-11553.
I got 3 others errors I believe are only Windows related (slow files handling 
there)

So it's OK, we will see with my next push...

Jacques

Le 25/07/2020 à 12:26, Suraj Khurana a écrit :

Hello team,

Everything looks ok on the local machine with testIntegration.
I checked with "./gradlew cleanAll loadAll testIntegration".

--
Best Regards,
Suraj Khurana
Senior Technical Consultant


On Sat, Jul 25, 2020 at 2:06 PM  wrote:


The Buildbot has detected a build exception on builder
ofbizTrunkFrameworkPlugins while building ofbiz-plugins. Full details are
available at:
 https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1567

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

Buildslave for this Build: asf945_ubuntu

Build Reason: The AnyBranchScheduler scheduler named
'onTrunkPluginsCommit' triggered this build
Build Source Stamp: [branch trunk] 4b88493e1bfd1a0e33bc1a1568ed1e1ba34a254a
Blamelist: Suraj Khurana 

BUILD FAILED: exception javadoc upload test-results part 1

Sincerely,
  -The Buildbot

Re: Ordering Decimals

[Jacques Le Roux]

I created OFBIZ-11916 for that

Le 20/07/2020 à 19:17, Jacques Le Roux a écrit :

Hi,

In OFBiz, OOTB you can order decimals of products. For instance you may want to sell half pizza. That is an user decision. The user may want to 
allow decimals by store or by product as shown in


https://github.com/apache/ofbiz-framework/blob/trunk/applications/product/src/main/java/org/apache/ofbiz/product/product/ProductWorker.java#L1204

We though should not be able to order a part of finished product like "Tiny Chrome Widget" (try 3.5 as mini is 3). You may notice that we have an 
issue in trunk and R18: see OFBIZ-11899. It works in stable demo and R17 locally.


We should set orderDecimalQuantity to false for all products data of FINISHED_GOOD, SERVICE, AGGREGATED, MARKETING_PKG_AUTO, DIGITAL_GOOD, 
ASSET_USAGE, etc. as can be seen in ProductSeedData.xml. Anyway it should be set on a product basis.


I think it's worth to do. Because it's demo data and would show to correctly set things. For a store which sells only not splittable products (which 
I guess is most of the time when using OFBiz ecommerce) then it's possible to set the same at the store level.


What do you think?

Jacques

Re: JavaScript Source Maps

[Jacques Le Roux]

Thanks Aditya,

It works only with 5.1 mine works with 6.3. I want to publish it as org.apache.ofbiz.gradle-js-plugin or maybe simply org.apache.ofbiz.js-plugin. 
Still have to complete that (one point is confusing)


Jacques


Le 24/07/2020 à 13:47, Aditya Sharma a écrit :

That's great Jacques.

Just for reference, another fork of gradle js plugin which was updated in
May 2019.
https://plugins.gradle.org/plugin/eu.butter.gradle.js
https://github.com/tbutter/gradle-js-plugin/

Thanks and regards,

Aditya Sharma

On Thu, Jul 23, 2020 at 2:00 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi All,

Backport done, I have created a fork of gradle-js-plugin and it works with
Gradle 6.3. I'll tell you more when I'll get a chance :)

Jacques

Le 19/07/2020 à 16:08, Jacques Le Roux a écrit :

Thanks Aditya,

@All, without more answers I'll exceptionally use a lazy consensus to

backport changes in minified and add of maps files down to R17 in a week
from

"16/07/2020 à 15:01"

This because, even if the Jiras are registered as improvements and we

can't see anything in UI and OFBiz logs, there are 404 and lack of help in

browser log.

Thanks to Alex for the help!

Jacques

Le 17/07/2020 à 14:41, Aditya Sharma a écrit :

Thank you, Jacques and Alex, for bringing this up. I think source maps

can

be a great aid for debugging. I am willing to give a hand.

Thanks and regards,
Aditya Sharma

On Thu, Jul 16, 2020 at 8:36 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Le 16/07/2020 à 15:01, Jacques Le Roux a écrit :

https://issues.apache.org/jira/issues/?jql=project %3D OFBIZ AND

text ~

"map alex"
This url is easier to use: https://s.apache.org/xzdtx

Re: JavaScript Source Maps

[Jacques Le Roux]

Hi All,

Backport done, I have created a fork of gradle-js-plugin and it works with 
Gradle 6.3. I'll tell you more when I'll get a chance :)

Jacques

Le 19/07/2020 à 16:08, Jacques Le Roux a écrit :

Thanks Aditya,

@All, without more answers I'll exceptionally use a lazy consensus to backport changes in minified and add of maps files down to R17 in a week from 
"16/07/2020 à 15:01"


This because, even if the Jiras are registered as improvements and we can't see anything in UI and OFBiz logs, there are 404 and lack of help in 
browser log.


Thanks to Alex for the help!

Jacques

Le 17/07/2020 à 14:41, Aditya Sharma a écrit :

Thank you, Jacques and Alex, for bringing this up. I think source maps can
be a great aid for debugging. I am willing to give a hand.

Thanks and regards,
Aditya Sharma

On Thu, Jul 16, 2020 at 8:36 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Le 16/07/2020 à 15:01, Jacques Le Roux a écrit :

https://issues.apache.org/jira/issues/?jql=project %3D OFBIZ AND text ~

"map alex"
This url is easier to use: https://s.apache.org/xzdtx

Re: Update Gradle in trunk

[Jacques Le Roux]

Thanks Nicolas!

Le 21/07/2020 à 14:20, Nicolas Malin a écrit :

Hi Jacques,

Thanks for your alert, I will take some time to check the new UI dans
correct the process.

Nicolas

On 21/07/2020 10:15, Jacques Le Roux wrote:

Hi Nicolas, All,

I tried to update Gradle in trunk following
https://cwiki.apache.org/confluence/display/OFBIZ/Load+new+gradle+wrapper+version+on+bintray
rather than doing it by hand, mostly to test the process by my own.

But the UI has changed. There is no longer an "*Upload* link, hidden
on the header bar". I see only a Link button and it does not seem to
be the same thing.

Any idea?

TIA

Jacques

Re: Checkstyle line wrapping Indentation

[Jacques Le Roux]

It works as expected in 4.2 when using our formatter in Eclipse.
Since the checkstyle was based on the formatter, that should not be changed

Jacques

Le 22/07/2020 à 14:16, Jacques Le Roux a écrit :

I had a doubt too, this is always confusing.

I'll test formatting in Eclipse...

Jacques

Le 22/07/2020 à 12:56, Suraj Khurana a écrit :

Hello team,

I further checked oracle docs [1] and maybe this is the reason for this.
See 4.2 in this pdf.

[1]: https://www.oracle.com/technetwork/java/codeconventions-150003.pdf

--
Best Regards,
Suraj Khurana
Senior Technical Consultant


On Tue, Jul 21, 2020 at 10:52 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


+1 reading the link

Thanks Suraj!

Le 21/07/2020 à 14:21, Pritam Kute a écrit :

Good catch Suraj. +1 for having it as 4 instead of 8.

Kind Regards,
--
Pritam Kute


On Tue, Jul 21, 2020 at 5:26 PM Suraj Khurana 
wrote:


Hello folks,

In checkstyle.xml, we have set lineWrappingIndentation value to 8. I
Propose we should make it 4 instead which is default. [1]

Is there any specific reason for setting it to 8? Please advise.

[1]:



https://checkstyle.sourceforge.io/apidocs/com/puppycrawl/tools/checkstyle/checks/indentation/IndentationCheck.html

--
Best Regards,
Suraj Khurana
Senior Technical Consultant

Re: Checkstyle line wrapping Indentation

[Jacques Le Roux]

I had a doubt too, this is always confusing.

I'll test formatting in Eclipse...

Jacques

Le 22/07/2020 à 12:56, Suraj Khurana a écrit :

Hello team,

I further checked oracle docs [1] and maybe this is the reason for this.
See 4.2 in this pdf.

[1]: https://www.oracle.com/technetwork/java/codeconventions-150003.pdf

--
Best Regards,
Suraj Khurana
Senior Technical Consultant


On Tue, Jul 21, 2020 at 10:52 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


+1 reading the link

Thanks Suraj!

Le 21/07/2020 à 14:21, Pritam Kute a écrit :

Good catch Suraj. +1 for having it as 4 instead of 8.

Kind Regards,
--
Pritam Kute


On Tue, Jul 21, 2020 at 5:26 PM Suraj Khurana 
wrote:


Hello folks,

In checkstyle.xml, we have set lineWrappingIndentation value to 8. I
Propose we should make it 4 instead which is default. [1]

Is there any specific reason for setting it to 8? Please advise.

[1]:



https://checkstyle.sourceforge.io/apidocs/com/puppycrawl/tools/checkstyle/checks/indentation/IndentationCheck.html

--
Best Regards,
Suraj Khurana
Senior Technical Consultant

Re: Checkstyle line wrapping Indentation

[Jacques Le Roux]

+1 reading the link

Thanks Suraj!

Le 21/07/2020 à 14:21, Pritam Kute a écrit :

Good catch Suraj. +1 for having it as 4 instead of 8.

Kind Regards,
--
Pritam Kute


On Tue, Jul 21, 2020 at 5:26 PM Suraj Khurana 
wrote:


Hello folks,

In checkstyle.xml, we have set lineWrappingIndentation value to 8. I
Propose we should make it 4 instead which is default. [1]

Is there any specific reason for setting it to 8? Please advise.

[1]:

https://checkstyle.sourceforge.io/apidocs/com/puppycrawl/tools/checkstyle/checks/indentation/IndentationCheck.html

--
Best Regards,
Suraj Khurana
Senior Technical Consultant

Update Gradle in trunk

[Jacques Le Roux]

Hi Nicolas, All,

I tried to update Gradle in trunk following https://cwiki.apache.org/confluence/display/OFBIZ/Load+new+gradle+wrapper+version+on+bintray rather than 
doing it by hand, mostly to test the process by my own.


But the UI has changed. There is no longer an "*Upload* link, hidden on the header bar". I see only a Link button and it does not seem to be the same 
thing.


Any idea?

TIA

Jacques

Re: Ordering Decimals

[Jacques Le Roux]

Le 21/07/2020 à 09:29, Suraj Khurana a écrit :

Also, if we agree for product store level configuration, it should be
entertaining in a similar manner as we have done for requireInventory
(Check service isStoreInventoryRequiredInline).
Means, giving priority to product level configuration and then store level.


+1

Jacques

Re: Ordering Decimals

[Jacques Le Roux]

Hi Pritam,

Le 21/07/2020 à 08:13, Pritam Kute a écrit :

I think its a good idea to have orderDecimalQuantity set to N for the
products in demo data. What I have noticed in demo data is there is no
practical product data available for which we can set this flag to Y. IMO,
we can add one or two demo products that can be ordered in
decimal quantities.


I'd advocate that products like pizza, ie Configurable Foods products, can be 
sell as parts.



For the product store level flag, we can modify the field description in
entity definition to convey the message to the user to set the flag to Y
for a global setting. If it is set to Y then the user may not need to set
the flag at each product level.


+1

Jacques



Kind Regards,
--
Pritam Kute


On Mon, Jul 20, 2020 at 10:48 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi,

In OFBiz, OOTB you can order decimals of products. For instance you may
want to sell half pizza. That is an user decision. The user may want to
allow
decimals by store or by product as shown in


https://github.com/apache/ofbiz-framework/blob/trunk/applications/product/src/main/java/org/apache/ofbiz/product/product/ProductWorker.java#L1204

We though should not be able to order a part of finished product like
"Tiny Chrome Widget" (try 3.5 as mini is 3). You may notice that we have an
issue in trunk and R18: see OFBIZ-11899. It works in stable demo and R17
locally.

We should set orderDecimalQuantity to false for all products data of
FINISHED_GOOD, SERVICE, AGGREGATED, MARKETING_PKG_AUTO, DIGITAL_GOOD,
ASSET_USAGE, etc. as can be seen in ProductSeedData.xml. Anyway it should
be set on a product basis.

I think it's worth to do. Because it's demo data and would show to
correctly set things. For a store which sells only not splittable products
(which I
guess is most of the time when using OFBiz ecommerce) then it's possible
to set the same at the store level.

What do you think?

Jacques

Re: Documentation "issues"

[Jacques Le Roux]

Hi Eugen,

Inline...

Le 20/07/2020 à 12:34, Eugen Stan a écrit :

Hi,

I think it's great that you are migration your docs to AsciiDoc.

What are you using to publish them?


Buildbot launches Gradle AsciiDoc tasks.

https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/ofbiz.conf
 (only access to ASF committers)




We've been working on doing a similar process in Apache James.

We decided to use Antora for publishing the content which is pretty great so 
far.


Yes the result sounds good indeed. Olivier has advocated JBake for the same. You can see what he came to at 
https://ofbizextra.org/ofbiz_adocs/docs/asciidoc/README.html





We haven't finished our process.

I've managed to make the automated build and the next goal is to work on the 
content and structure.

If you are interested, here are some links:

* https://github.com/apache/james-site/ - repo to build the documentation 
website - includes gradle tasks to build the theme and run antora.

* Jenkinsfile is used to publish the staged website to 
https://james.staged.apache.org/main/3.5/index.html

* https://issues.apache.org/jira/browse/JAMES-3226 Jira issue to track the 
progress


I'll have a look when I'll get a chance. I don't think we will move out of 
Buildbot.

Thanks

Jacques




La 20.07.2020 11:54, Olivier Heintz a scris:

Thanks Jacques, for this list,

I will finish the plugins docbook migration to asciidoc
and I will continue with these JIRA, with a first step to be sure to migrate 
all old format to the new one.

This list is a good road to clean before doing some new doc.

Thanks

Olivier

Le 17/07/2020 à 09:46, Jacques Le Roux a écrit :

Hi All, Olivier,

Again Olivier, I must say I'm so glad that you took the documentation challenge 
in hands. That's very promising for the future of the project. Thanks
for your work!

At this stage I'd like to clean the situation as much as possible. It's not about your work, but about all that we have left behind us. It's 
difficult

to figure out what the situation really is.

There are few minor things and some others more systemic. What are your thought 
about them? Take your time ;)

Among the minor issues:


I think we should begin to close issues like:

OFBIZ-6644:
This is deprecated with its sub-tasks

OFBIZ-11893:
Trivial issues I collected before forgetting them. You might found more.

https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML:
This is now broken. I guess after you removed some files referenced by 
documents in /plugins/cmssite/documents
Related with OFBIZ-11364 I guess.
OFBIZ-9926 should be closed.

OFBIZ-6243:
Should we take the burden of migrating the existing README.md?
I don't think so. I'd like to remove them with the related wiki pages, like:
https://cwiki.apache.org/confluence/display/OFBENDUSER/Financial+Accounting+and+Reporting
All that is mostly deprecated and redundant.

Among the more serious ones:
=

OFBIZ-10285:
What are your thoughts about this one (sorry not enough time to dig in)?
It's clearly time to prune the sub-tasks, I mean close them if possible, like:
OFBIZ-10251
OFBIZ-10255
OFBIZ-11364
etc.

Also we need to update, actually  mainly prune, the wiki, there is too much 
deprecated and MISLEADING documentation there!

A bit of pontification :):

One thing I learned is that it's hard to maintain a documentation. Because 
things evolve and are not always related to each other (like code).
So we should restrain ourselves to refer to things that may disappear or change 
in the future. If not possible we need to generalise them as much as
possible.
An example is OFBIZ-6243.

Jacques

Re: Nested attributes for Collection Types

[Jacques Le Roux]

Thanks Mridul,

I agree about enhancing existing service definitions

Jacques

Le 20/07/2020 à 10:37, Mridul Pathak a écrit :

Hi Girish,

I think this would be a good improvement to service definition. While it makes 
more sense that it would enable creating JSON like schema definitions it would 
make service definitions more predictable in general. This improvement could 
also be applied to existing service definitions to be able to expose them as an 
API in a more sensible way.

Thanks.
--
Mridul Pathak



On 16-Jul-2020, at 5:20 PM, Girish Vasmatkar 
 wrote:

Hey Guys,

While working on OpenApi integration as well as GraphQL implementation, I
faced issues on how to automatically document request/response JSON
structure for service attributes that were of Collection types (Map, List
etc).

For simple types, it is just plain easy but when it comes to Map/Lists, you
have to know what exactly is inside them to be able to convey properly in
the OpenApi schema.

I was thinking to may be try to introduce nested attributes in service
definition such that if the attribute type is Map/List, you can actually
specify what goes inside that attribute -











With this change, it becomes possible to generate the schema for the
service attribute, Where as if we don't have this option, we can't possibly
indicate what the structure of the "header" key is going to be if it was
represented in JSON format.

Of course, this change will only help documentation and GraphQL
implementation and that there is very little case for it to benefit a
general OFBiz service call.

Any thoughts or comments on this? Is this too big of a change (impact wise
and not coding perspective) to avoid it and consider something else? Has
this been discussed before?

Best,
Girish

Ordering Decimals

[Jacques Le Roux]

Hi,

In OFBiz, OOTB you can order decimals of products. For instance you may want to sell half pizza. That is an user decision. The user may want to allow 
decimals by store or by product as shown in


https://github.com/apache/ofbiz-framework/blob/trunk/applications/product/src/main/java/org/apache/ofbiz/product/product/ProductWorker.java#L1204

We though should not be able to order a part of finished product like "Tiny Chrome Widget" (try 3.5 as mini is 3). You may notice that we have an 
issue in trunk and R18: see OFBIZ-11899. It works in stable demo and R17 locally.


We should set orderDecimalQuantity to false for all products data of FINISHED_GOOD, SERVICE, AGGREGATED, MARKETING_PKG_AUTO, DIGITAL_GOOD, 
ASSET_USAGE, etc. as can be seen in ProductSeedData.xml. Anyway it should be set on a product basis.


I think it's worth to do. Because it's demo data and would show to correctly set things. For a store which sells only not splittable products (which I 
guess is most of the time when using OFBiz ecommerce) then it's possible to set the same at the store level.


What do you think?

Jacques

Re: EntityBatchIterator for large data set queries

[Jacques Le Roux]

Thanks Prakhar for this information.

Jacques

Le 20/07/2020 à 10:12, Prakhar Kumar a écrit :

Hello Pawan,

We were getting a hard time dealing with large datasets in our client
project. We were streaming data from MySQL using the FetchSize and
EntityListIterator, which helped us up to some point, but ultimately
struggled with the further increase in data. This is where the batch
processing implementation came to rescue. We incorporated it into our
project and were able to process the data with ease. This implementation
seems to be quite scalable and faster in performance as compared to
streaming. Batch processing was the need of the hour and there we have it
in OFBiz. Thanks, Pawan for your valuable contribution.

On Wed, Jul 1, 2020 at 4:06 PM Pawan Verma 
wrote:


Hi Chandan, Jacques

Thanks, for your feedback.

Yes, To solve the problem of heavy entity operations which consumes all the
system memory, we have implemented EntityBatchIterator. Originally designed
for the heavy entity operations.
--
Thanks & Regards
Pawan Verma
Technical Consultant
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com


On Sun, Jun 28, 2020 at 10:16 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi,

I have not looked into any details but Chandan's advice sounds like a

wise

one to me

Jacques

Le 27/06/2020 à 13:43, Chandan Khandelwal a écrit :

Hello Pawan,

Approach looks good, my only suggestion is to use batch processing only
when we are dealing with large data set, as this method takes a longer

time

compared to the normal method specially on a distributed environment,

which

may negatively impact the performance.

Kind Regards,
Chandan Khandelwal
Senior Manager, Enterprise Software Development

*HotWax Systems*
*Enterprise open source experts*
cell: +91-98934-81076
office: 0731-409-3684
http://www.hotwaxsystems.com


On Fri, Jun 5, 2020 at 4:07 PM Pawan Verma <

pawan.ve...@hotwaxsystems.com>

wrote:


Thanks, Pritam and Scott for the discussion.

I've created Jira OFBIZ-11789 for this improvement and also created a

PR

with the proposed changes.

I request everyone to review the PR and suggest your thought on this.
Thanks!
--
Thanks & Regards
Pawan Verma
Technical Consultant
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com


On Mon, Jun 1, 2020 at 12:36 PM Pritam Kute <

pritam.k...@hotwaxsystems.com

wrote:


Thanks Scott for your detailed explanation.

The solution looks good to me too. My confusion was with why we are

going

to implement new method if we can achieve that using the current
EntityQuery methods.

+1 for adding queryBatchIterator() to EntityQuery.

Kind Regards,
--
Pritam Kute


On Thu, May 28, 2020 at 6:32 AM Scott Gray <

scott.g...@hotwaxsystems.com

wrote:


Hi Pritam,

I'm not sure about PostgreSQL or Derby but I know with MySQL that

using a

cursor doesn't really work.  You have to set the result set to
TYPE_FORWARD_ONLY and CONCUR_READ_ONLY and also set the fetch size

to

INTEGER.MIN_VALUE.  Only then will the driver stream the results and

even

then, you may not execute any other SQL commands on the connection

until

you have fully read or closed the resultset.

So if an EntityListIterator doesn't really conserve memory, then you

need

to take a paging query approach such as this:
EntityQuery query =

EntityQuery.use(delegator).from("SomeTable").limit(100)

List results = null
while (!(results = query.queryList()).isEmpty()) {
   for (value : results) {
// do something with each value
   }
   query.offset(query.getOffset() + query.getLimit())
}

Or with the proposed EntityBatchIterator:
Iterator query =



EntityQuery.use(delegator).from("SomeTable").limit(100).queryBatchIterator()

while (iterator.hasNext()) {
   result = iterator.next()
   // do something with each value
}

I guess an alternative approach would be to implement something

similar

within the EntityListIterator and perhaps a flag to turn it off or

on

depending on which database is being used and how well it supports
iterating over results without loading the entire resultset into

memory.

Regards
Scott



On Sat, 23 May 2020 at 20:59, Pritam Kute <

pritam.k...@hotwaxsystems.com

wrote:


Hello Pawan,

I just had a look into the EntityQuery.queryIterator() method and

looks

like we can achieve that by using fetchSize(), fowardOnly(),
cursorScrollInsensitive(), cursorScrollSensitive() and offset()

methods

in

EntityQuery class. Let me know if I am missing anything.

It will be good if you can post a pseudo code or something here so

that

we

could get an understanding of the exact design which you have in

your

mind.

Kind Regards,
--
Pritam Kute


On Thu, May 21, 2020 at 7:41 PM Pawan Verma <

pawan.ve...@hotwaxsystems.com

wrote:


Hello Devs,

While working on the large database we have figured out that very

large

queries consume all memory and crash ofbiz(because queryIter

Re: JavaScript Source Maps

[Jacques Le Roux]

Thanks Aditya,

@All, without more answers I'll exceptionally use a lazy consensus to backport changes in minified and add of maps files down to R17 in a week from 
"16/07/2020 à 15:01"


This because, even if the Jiras are registered as improvements and we can't see anything in UI and OFBiz logs, there are 404 and lack of help in 
browser log.


Thanks to Alex for the help!

Jacques

Le 17/07/2020 à 14:41, Aditya Sharma a écrit :

Thank you, Jacques and Alex, for bringing this up. I think source maps can
be a great aid for debugging. I am willing to give a hand.

Thanks and regards,
Aditya Sharma

On Thu, Jul 16, 2020 at 8:36 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Le 16/07/2020 à 15:01, Jacques Le Roux a écrit :

https://issues.apache.org/jira/issues/?jql=project %3D OFBIZ AND text ~

"map alex"
This url is easier to use: https://s.apache.org/xzdtx

Re: checkNewPassword and ignoreCurrentPassword

[Jacques Le Roux]

Le 18/07/2020 à 11:34, Jacques Le Roux a écrit :

Le 13/07/2020 à 14:50, Jacques Le Roux a écrit :

Something related I already shared in the security ML:

I guess we don't want to change (I don't mean the NOTE but the feature).

   // NOTE: must check permission first so that admin users can set own 
password without specifying old password


I think it's OK as is and with the lazy consensus I will told the reporter so



I also have a question to you Jacopo:

I'm not quite sure you meant with (https://s.apache.org/04dt9)

   // TODO: change this security group because we can't use permission groups 
defined in the applications from the framework.

Which security group is it about? 

I guess it's the PARTYMGR security group and anyway it's unrelated, forget it

Jacques


TO add to this and thanks to James reference to

https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/09-Testing_for_Weak_Password_Change_or_Reset_Functionalities

They say there:

 *

   Is the old password requested to complete the change?

   The most insecure scenario here is if the application permits the change of 
the password without requesting the current password. Indeed if an
   attacker is able to take control of a valid session they could easily change 
the victim’s password.

Anyway in case of an admin, if a valid session is in the hand of an attacker 
it's too late to do anything, all is open!

Jacques

Re: checkNewPassword and ignoreCurrentPassword

[Jacques Le Roux]

Le 13/07/2020 à 14:50, Jacques Le Roux a écrit :

Something related I already shared in the security ML:

I guess we don't want to change (I don't mean the NOTE but the feature).

   // NOTE: must check permission first so that admin users can set own 
password without specifying old password


I think it's OK as is and with the lazy consensus I will told the reporter so



I also have a question to you Jacopo:

I'm not quite sure you meant with (https://s.apache.org/04dt9)

   // TODO: change this security group because we can't use permission groups 
defined in the applications from the framework.

Which security group is it about? 

I guess it's the PARTYMGR security group and anyway it's unrelated, forget it

Jacques

Re: Error.ftl everywhere

[Jacques Le Roux]

Le 16/07/2020 à 17:20, Jacques Le Roux a écrit :


Then it makes sense to remove RequestHandler::getDefaultErrorPage and its only reference in ControlServlet::handle (since nothing exists in web.xml 
files) 


I rather made error.ftl the new default

Done

Jacques

Re: Single line statements - checkstyle

[Jacques Le Roux]

Le 14/07/2020 à 10:15, Jacques Le Roux a écrit :

My conclusion is that could be discussed again and I for one I'm not against 
changing this rule for 2 reasons:

1.      We can't use our current formatter to do it right
2.      With a single line statement there are less chances to confuse and fall 
in the error-prone form mentioned above

Another option would be to find a way to improve our formatter to do the right thing (ie add braces when splitting). 


We discussed the point 1 with Suraj in Slack. It's actually possible in both 
IntelliJ

https://www.jetbrains.com/help/resharper/Braces_for_Single_Line_Statements.html
https://stackoverflow.com/questions/55248370/intellij-checkstyle-plugin-reformat

and Eclipse

https://stackoverflow.com/questions/3704308/how-to-make-eclipse-automatically-add-braces-to-an-if-statement

I don't know for IntelliJ, but in Eclipse it's not a formatting option but a 
clean-up option.
And when you clean-up you can't select a block of code, it's all the file or 
nothing.
There are then more changes and some are unwanted.

So I agree with Suraj and Pritam, let's do that. There would be anyway so much 
changes to do by hand that it's not rational!

Jacques

Re: Nested attributes for Collection Types

[Jacques Le Roux]

Hi Girish,

I don't remember this having been discussed before. I like the idea and the proposed 
"implementation".
I don't think it's a too big change, it's an improvement for me.

About Pritam's remark for GenericValue, if it may help: those are Maps 
[Map] and considered  as such in SOAP.

Thanks

Jacques

Le 17/07/2020 à 07:21, Pritam Kute a écrit :

Hello Girish,

IMO, the option which you have suggested looks good in case if we want to
leverage upon the existing service definitions for creating the API
documentation. I also think that this could be a good addition to OFBiz in
the developer perspective, as right now, it is very difficult to guess the
content of the Map/List attributes seeing at service definition. For the
attribute type GenericValue, we can skip the nested structure.

Kind Regards,
--
Pritam Kute


On Thu, Jul 16, 2020 at 5:21 PM Girish Vasmatkar <
girish.vasmat...@hotwaxsystems.com> wrote:


Hey Guys,

While working on OpenApi integration as well as GraphQL implementation, I
faced issues on how to automatically document request/response JSON
structure for service attributes that were of Collection types (Map, List
etc).

For simple types, it is just plain easy but when it comes to Map/Lists, you
have to know what exactly is inside them to be able to convey properly in
the OpenApi schema.

I was thinking to may be try to introduce nested attributes in service
definition such that if the attribute type is Map/List, you can actually
specify what goes inside that attribute -



 

 





With this change, it becomes possible to generate the schema for the
service attribute, Where as if we don't have this option, we can't possibly
indicate what the structure of the "header" key is going to be if it was
represented in JSON format.

Of course, this change will only help documentation and GraphQL
implementation and that there is very little case for it to benefit a
general OFBiz service call.

Any thoughts or comments on this? Is this too big of a change (impact wise
and not coding perspective) to avoid it and consider something else? Has
this been discussed before?

Best,
Girish

Documentation "issues"

[Jacques Le Roux]

Hi All, Olivier,

Again Olivier, I must say I'm so glad that you took the documentation challenge in hands. That's very promising for the future of the project. Thanks 
for your work!


At this stage I'd like to clean the situation as much as possible. It's not about your work, but about all that we have left behind us. It's difficult 
to figure out what the situation really is.


There are few minor things and some others more systemic. What are your thought 
about them? Take your time ;)

Among the minor issues:


I think we should begin to close issues like:

OFBIZ-6644:
This is deprecated with its sub-tasks

OFBIZ-11893:
Trivial issues I collected before forgetting them. You might found more.

https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML:
This is now broken. I guess after you removed some files referenced by 
documents in /plugins/cmssite/documents
Related with OFBIZ-11364 I guess.
OFBIZ-9926 should be closed.

OFBIZ-6243:
Should we take the burden of migrating the existing README.md?
I don't think so. I'd like to remove them with the related wiki pages, like:
https://cwiki.apache.org/confluence/display/OFBENDUSER/Financial+Accounting+and+Reporting
All that is mostly deprecated and redundant.

Among the more serious ones:
=

OFBIZ-10285:
What are your thoughts about this one (sorry not enough time to dig in)?
It's clearly time to prune the sub-tasks, I mean close them if possible, like:
OFBIZ-10251
OFBIZ-10255
OFBIZ-11364
etc.

Also we need to update, actually  mainly prune, the wiki, there is too much 
deprecated and MISLEADING documentation there!

A bit of pontification :):

One thing I learned is that it's hard to maintain a documentation. Because 
things evolve and are not always related to each other (like code).
So we should restrain ourselves to refer to things that may disappear or change in the future. If not possible we need to generalise them as much as 
possible.

An example is OFBIZ-6243.

Jacques

Re: Plugins documentation and framework

[Jacques Le Roux]

Hi Olivier,

First I must thank all your work on documentation and this proposition

With documentation maintenance in mind, I think it's best to clearly split 
between framework and plugins, so solution 3 seems better to me.

Jacques

Le 15/07/2020 à 11:00, Olivier Heintz a écrit :

My point of view about my question ;-)

On a Documentation, point of view, I prefer the solution 2, (with a clear flag 
to say it's a with the plugin )

On a technical point of view to have minimum dependency between framework and 
plugins, solution 3 is the better one

Le 15/07/2020 à 10:53, Olivier Heintz a écrit :

Hi Community,

I start migrate plugins docbook for ofbiz-plugins and I have a question about
How to manage plugins documentation, in the structure of user-documentation and 
developper-manual ?

I see 3 possible solutions
1) Current solution: one document per plugin, and link to its in the correct 
chapter
example: plugins ldap, doc SingleSignOn : it is generated as
https://ci.apache.org/projects/ofbiz/site/trunk/pluginsdoc/ldap/html5/SingleSignOn.html
 in developper-manual, put a link to this doc in the Deployment 
chapter

2) add a "include::" in the correct chapter (created a dependency between 
framework and plugins)
example: currently in Deployment chapter there is the "11.2. OFBiz Single Sign 
On using CAS and LDAP" as sub-chapter

3) add a "include::" to a doc/asciidoc/plugins-user-documentation in 
user-ddocumentation
   and one to doc/asciidoc/plugins-developper-manual in 
developper-manual
In each file there will be all the include to tha appropriate plugins.

Re: Error.ftl everywhere

[Jacques Le Roux]

Hi Nicolas, All,

Last effort: I think we should now get rid of all error.jsp, error403.jsp and 
error404.jsp files and all references to these.

It's easy to remove commented out  references from 3 web.xml files 
(marketing, partymgr and workeffort). We are sure they are not used.

Then it makes sense to remove RequestHandler::getDefaultErrorPage and its only 
reference in ControlServlet::handle (since nothing exists in web.xml files)

Same for

   <<[tempName:'error.jsp', newName:'error.jsp', 
location:"webapp/${webappName}/error"],>>

in build.gradle.

Do I miss anything?

Thanks

Jacques

Le 16/07/2020 à 11:55, Nicolas Malin a écrit :

Thanks Jacques,

You finished the work to remove the jsp error :)

Nicolas

On 15/07/2020 21:09, Jacques Le Roux wrote:

Le 05/07/2020 à 16:50, Jacques Le Roux a écrit :

Hi,

While working on OFBIZ-11840 I thought about the solution I used for
"[CVE-2020-1943] Apache OFBiz XSS Vulnerability"

So I tried that:

diff --git framework/common/webcommon/WEB-INF/common-controller.xml
framework/common/webcommon/WEB-INF/common-controller.xml
index e6f9394cd4..9291cdbece 100644
--- framework/common/webcommon/WEB-INF/common-controller.xml
+++ framework/common/webcommon/WEB-INF/common-controller.xml
@@ -338,7 +338,7 @@ under the License.
  

  
-    
+    
  
  
  
diff --git framework/common/webcommon/WEB-INF/handlers-controller.xml
framework/common/webcommon/WEB-INF/handlers-controller.xml
index be21b19fd9..1622d10ead 100644
--- framework/common/webcommon/WEB-INF/handlers-controller.xml
+++ framework/common/webcommon/WEB-INF/handlers-controller.xml
@@ -42,4 +42,5 @@ under the License.
  
  
  
+    
  

It does not fix the OFBIZ-11840 issue but it works. I mean it
correctly replaces error.jsp by error.ftl.

Few questions:

1. Why having the ftl handlers only in webtools controller? BTW it
makes the XSD documentation awkward because it speaks about the ftl
handlers being
    in handlers-controller.xml
2. Why not using error.ftl in common-controller.xml instead of
error.jsp?
3. Same question for plugins.

I believe we could change all that and definitely get rid of
error.jsp (error.ftl is already in all supported releases branches)

What do you think?

Jacques


Done with OFBIZ-11890

Jacques

Re: JavaScript Source Maps

[Jacques Le Roux]

Le 16/07/2020 à 15:01, Jacques Le Roux a écrit :

https://issues.apache.org/jira/issues/?jql=project %3D OFBIZ AND text ~ "map 
alex"

This url is easier to use: https://s.apache.org/xzdtx

JavaScript Source Maps

[Jacques Le Roux]

Hi,

Alex Bodnaru has started an effort to fix issues with javascript minification 
and javaScript source maps[1]:

https://issues.apache.org/jira/issues/?jql=project %3D OFBIZ AND text ~ "map 
alex"

For now he is working on R17. I see no pb to backport JavaScript Source Maps 
adds and changes down to R17.

What do you think about that?

[1] https://www.html5rocks.com/en/tutorials/developertools/sourcemaps/

Thanks

Jacques

Re: API Reference on OFBiz site

[Jacques Le Roux]

Hi Pawan,

That looks good but we have a problem with the menu Documentation/API Reference

Jacques

Le 16/07/2020 à 14:12, Pritam Kute a écrit :

Thanks, Pawan. Looks good to me.

Kind Regards,
--
Pritam Kute


On Thu, Jul 16, 2020 at 5:24 PM Devanshu Vyas 
wrote:


Looks good to me.

Thanks & Regards,
Devanshu Vyas.


On Thu, Jul 16, 2020 at 4:42 PM Pawan Verma 
Changes are live now, please have a look at
https://ofbiz.apache.org/developers.html#DevDocs

If we are good here the ticket can be closed now.
--
Thanks & Regards
Pawan Verma
Technical Consultant
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com


On Thu, Jul 16, 2020 at 3:26 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


+1

Jacques

Le 16/07/2020 à 11:43, Pawan Verma a écrit :

Thanks, Jacques, All for the response.

Yes, Makes sense. So, It will look something like this, if this looks

good,

I'll make the required changes.

The layout of API Reference on the Site:
*OFBiz API Reference*

 - *Trunk API Reference*
 - *Release 17.12 API Reference*
 - *Next Release API Reference*

Re: API Reference on OFBiz site

[Jacques Le Roux]

+1

Jacques

Le 16/07/2020 à 11:43, Pawan Verma a écrit :

Thanks, Jacques, All for the response.

Yes, Makes sense. So, It will look something like this, if this looks good,
I'll make the required changes.

The layout of API Reference on the Site:
*OFBiz API Reference*

- *Trunk API Reference*
- *Release 17.12 API Reference*
- *Next Release API Reference*

Re: API Reference on OFBiz site

[Jacques Le Roux]

Hi Pawan,

Indeed, next is for now more an internal concept.

But, like it's now clear for stable - thanks to the demo, we could explain this concept to users. It's simple: the next branch to be released. This 
would prevent to have to modify (and often forget) the real reference, ie R18 for now.


Jacques

Le 16/07/2020 à 09:49, Pawan Verma a écrit :

Hi Jacques,

Yes, seems like a good idea to expose the next API too. But I am not fully
aware of the next API and curious about the label means Next API Reference,
wouldn't it be confusing for the user?

Re: Error.ftl everywhere

[Jacques Le Roux]

Le 05/07/2020 à 16:50, Jacques Le Roux a écrit :

Hi,

While working on OFBIZ-11840 I thought about the solution I used for 
"[CVE-2020-1943] Apache OFBiz XSS Vulnerability"

So I tried that:

diff --git framework/common/webcommon/WEB-INF/common-controller.xml 
framework/common/webcommon/WEB-INF/common-controller.xml
index e6f9394cd4..9291cdbece 100644
--- framework/common/webcommon/WEB-INF/common-controller.xml
+++ framework/common/webcommon/WEB-INF/common-controller.xml
@@ -338,7 +338,7 @@ under the License.
 

 
-    
+    
 
 
 
diff --git framework/common/webcommon/WEB-INF/handlers-controller.xml 
framework/common/webcommon/WEB-INF/handlers-controller.xml
index be21b19fd9..1622d10ead 100644
--- framework/common/webcommon/WEB-INF/handlers-controller.xml
+++ framework/common/webcommon/WEB-INF/handlers-controller.xml
@@ -42,4 +42,5 @@ under the License.
 
 
 
+    
 

It does not fix the OFBIZ-11840 issue but it works. I mean it correctly 
replaces error.jsp by error.ftl.

Few questions:

1. Why having the ftl handlers only in webtools controller? BTW it makes the 
XSD documentation awkward because it speaks about the ftl handlers being
   in handlers-controller.xml
2. Why not using error.ftl in common-controller.xml instead of error.jsp?
3. Same question for plugins.

I believe we could change all that and definitely get rid of error.jsp 
(error.ftl is already in all supported releases branches)

What do you think?

Jacques


Done with OFBIZ-11890

Jacques

[CVE-2020-9496] Apache OFBiz XML-RPC requests vulnerable without authentication

[Jacques Le Roux]

Severity:
Important

Vendor:
The Apache Software Foundation

Versions Affected:
OFBiz 17.12.03

Description:
Apache OFBiz XML-RPC request are  vulnerable to unsafe deserialization and 
Cross-Site Scripting issues.

Mitigation:
Upgrade to 17.12.04 or manually apply the commit at OFBIZ-11716


Credit:
Alvaro Munoz from  GitHub Security Lab team 

References:
https://ofbiz.apache.org/security.html

[CVE-2020-13923] IDOR in Apache OFBiz

[Jacques Le Roux]

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
All versions < 17.12.04

Description:
IDOR vulnerability in the order processing feature from ecommerce component.

Mitigation:
Upgrade to 17.12.04 or manually apply the commit at OFBIZ-11836


Credit:
Harshit Shukla 

References:
https://ofbiz.apache.org/security.html

Re: API Reference on OFBiz site

[Jacques Le Roux]

After thought: why not expose the next API too?

Jacques

Le 15/07/2020 à 10:19, Olivier Heintz a écrit :

+1 to the 2nd option

Le 15/07/2020 à 09:58, Devanshu Vyas a écrit :

+1 to the 2nd option.

Thanks & Regards,
Devanshu Vyas.


On Wed, Jul 15, 2020 at 10:56 AM Pritam Kute 
wrote:


I am also inclined to 2nd option.

Thanks, Pawan for pointing this.

Kind Regards,
--
Pritam Kute


On Wed, Jul 15, 2020 at 1:24 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Thanks Pawan,

The 2nd options looks like a good idea to me.

Jacques

Le 14/07/2020 à 15:38, Pawan Verma a écrit :

Hello Devs,

Since Oliver has refactored documentation with new directories

structure

with the trunk, next and stable API Reference link becomes stale.

Question: What should be the API Reference link on the site?

Possible Solutions:
#1: We can use the link for stable APIs for Site as suggested by

Jacques

on

Jira OFBIZ-11888.

#2: We can show the link for both trunk and stable release like Build

and

Run section.
Example:
* OFBiz API Reference*

 - *Trunk API Reference*
 - *Release 17.12 API Reference*

Please share your thoughts on this. TIA!

Re: API Reference on OFBiz site

[Jacques Le Roux]

Thanks Pawan,

The 2nd options looks like a good idea to me.

Jacques

Le 14/07/2020 à 15:38, Pawan Verma a écrit :

Hello Devs,

Since Oliver has refactored documentation with new directories structure
with the trunk, next and stable API Reference link becomes stale.

Question: What should be the API Reference link on the site?

Possible Solutions:
#1: We can use the link for stable APIs for Site as suggested by Jacques on
Jira OFBIZ-11888.

#2: We can show the link for both trunk and stable release like Build and
Run section.
Example:
* OFBiz API Reference*

- *Trunk API Reference*
- *Release 17.12 API Reference*

Please share your thoughts on this. TIA!

Re: [ofbiz-site] branch master updated: Added Aditya, Arun and Suraj as PMC

[Jacques Le Roux]

Thanks Pawan!

Le 14/07/2020 à 14:22, pa...@apache.org a écrit :

This is an automated email from the ASF dual-hosted git repository.

pawan pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/ofbiz-site.git


The following commit(s) were added to refs/heads/master by this push:
  new c71384c  Added Aditya, Arun and Suraj as PMC
c71384c is described below

commit c71384c0dcc8fde3c4bf0f66a1130934a1473874
Author: Pawan Verma 
AuthorDate: Tue Jul 14 17:51:47 2020 +0530

 Added Aditya, Arun and Suraj as PMC
---
  pmc/ofbiz.rdf | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/pmc/ofbiz.rdf b/pmc/ofbiz.rdf
index b7c35df..ccf6bed 100644
--- a/pmc/ofbiz.rdf
+++ b/pmc/ofbiz.rdf
@@ -40,13 +40,16 @@ Apache OFBiz provides a foundation and starting point for 
reliable, secure and s
  Adam 
Heath
  Bilgin 
Ibryam
  David E. 
Jones
+Suraj 
Khurana
  Jacques Le 
Roux
  Nicolas 
Malin
  Swapnil M 
Mane
  Pranay 
Pandey
  Anil 
Patel
+Arun 
Patidar
  Gil 
Portenseigne
  Yoav 
Shapira
+Aditya 
Sharma
  Ashish 
Vijaywargiya
  David 
Welton
  James 
Yong

Re: Single line statements - checkstyle

[Jacques Le Roux]

Hi Suraj,

We discussed this in the past (I can't find it yet) and we concluded that we 
should not allow that.

It's in contradiction with "Code Conventions for the Java^TM Programming 
Language":
https://www.oracle.com/java/technologies/javase/codeconventions-statements.html#449

Hence with our recommended conventions as in
https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions
and
https://gitbox.apache.org/repos/asf?p=ofbiz-tools.git;a=blob_plain;f=wiki-files/OFBizJavaFormatter.xml

BTW, I was looking at LoginServices::checkNewPassword. Its signature was 
outrageous long (234 chars!), I splitted it by hand.
I wanted to commit it as is but while at it I decided to try to format the 
whole class with Eclipse.
I just putt the result as 
OFBIZ-11886-format-LoginServices-checkNewPassword.patch under OFBIZ-11886.

I then noticed that Eclipse rightly splits "if single line statements" but does 
not add braces, {}. It's not good as it does not follow Sun convention:

   Note: if statements always use braces, {}. Avoid the following error-prone 
form:
   if (condition) //AVOID! THIS OMITS THE BRACES {}!
    statement;

With all this said.

 *      We have tons of single line statements in OFBiz.
 *      It's certainly part of much of errors reported by checkstyle.
 *      I don't remember clearly but it seems to me that when we discussed it 
last time it was a moot point. Like with return on the same line.


My conclusion is that could be discussed again and I for one I'm not against 
changing this rule for 2 reasons:

1.      We can't use our current formatter to do it right
2.      With a single line statement there are less chances to confuse and fall 
in the error-prone form mentioned above

Another option would be to find a way to improve our formatter to do the right 
thing (ie add braces when splitting).

My 2 cts

Jacques


||

Le 14/07/2020 à 07:30, Pritam Kute a écrit :

Looks good to me.

Kind Regards,
--
Pritam Kute


On Mon, Jul 13, 2020 at 9:04 PM Suraj Khurana 
wrote:


Hello team,

I have created a ticket https://issues.apache.org/jira/browse/OFBIZ-11886
to allow single line statements during checkstyle, I hope we are fine with
this.

For this, we need to add a module to allow single line statements:
==

 

==

Let me know your thoughts on this.

--
Best Regards,
Suraj Khurana
Senior Technical Consultant

Re: checkNewPassword and ignoreCurrentPassword

[Jacques Le Roux]

Hi James,

Inline...

Le 13/07/2020 à 08:36, James Yong a écrit :

Hi Jacques,

There is a number of reports relating to CSRF.
To reduce the number of false positive security alerts, I think the CSRF 
defense should be turned on in the demo.


The OFBiz specific CSRF defense exists only in trunk because it was hard to backport. The vulnerability reports are always done against our stable 
version.

Anyway, all our supported versions (including trunk) have the cookie same 
attribute in place. So we have a solid indisputable CSRF defense in place.
As explained in security properties we don't need to activate the OFBiz 
specific CSRF defense except in 2 cases:

   # -- CSRF defense strategy.
   # -- Because OOTB OFBiz  also sets the SameSite attribute to 'strict' for 
all cookies,
   # -- which is an effective CSRF defense,
   # -- default is org.apache.ofbiz.security.NoCsrfDefenseStrategy if not 
specified.
   # -- Use org.apache.ofbiz.security.CsrfDefenseStrategy
   # -- if you need to use a 'lax' for SameSiteCookieAttribute.
   # --
   # -- Or if you, or your users, use, or may use, a browser version that
   # -- is not supporting the SameSite cookie attribute
   # -- You may refer to https://caniuse.com/#feat=same-site-cookie-attribute


I feel there should be additional verification like checking current password 
when the user is doing password change.
Please see the section on "Test Password Change" at
https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/09-Testing_for_Weak_Password_Change_or_Reset_Functionalities


I did not read the article yet, but checking current password  is done but not when the user is an admin or "system" user (see 
LoginServices::updatePassword). The question is: should we do the same when the user an admin or "system" user?


Thanks

Jacques



Regards,
James

On 2020/07/12 11:07:59, Jacques Le Roux  wrote:

Hi team,

We recently got a security report about checkNewPassword where it was claimed a 
CSRF vulnerability because of ignoreCurrentPassword but I rejected it.

I have though added a comment in trunk to allow users to adds OFBiz specific 
CSRF defense in case it would be needed (peculiar browsers):
https://github.com/apache/ofbiz-framework/commit/16c2d3521990caf5e8703cbb323ce1146c93b9ce/

The reporter then wrote

 "Even if this is not a CSRF vulnerability, I still think it is an insecure 
measure to not verify the current password when changing the password
 of the system account. What do you think?"

His report was initially roughly :

 *If it is a system account, current password would not be checked*
 *
 *
 public static void checkNewPassword(GenericValue userLogin, String 
currentPassword, String newPassword, String newPasswordVerify, String
 passwordHint, List errorMessageList, boolean 
ignoreCurrentPassword, Locale locale) {
          Delegator delegator = userLogin.getDelegator();
          boolean useEncryption = 
"true".equals(EntityUtilProperties.getPropertyValue("security", 
"password.encrypt", delegator));

          String errMsg = null;

          if (!ignoreCurrentPassword) {
              // if the password.accept.encrypted.and.plain property in 
security is set to true allow plain or encrypted passwords
              // if this is a system account don't bother checking the 
passwords
              boolean passwordMatches = 
checkPassword(userLogin.getString("currentPassword"), useEncryption, 
currentPassword);
              if ((currentPassword == null) || (!passwordMatches)) {
                  errMsg = 
UtilProperties.getMessage(resource,"loginservices.old_password_not_correct_reenter",
 locale);
                  errorMessageList.add(errMsg);
              }
              if (checkPassword(userLogin.getString("currentPassword"), 
useEncryption, newPassword)) {
                  errMsg = 
UtilProperties.getMessage(resource,"loginservices.new_password_is_equal_to_old_password",
 locale);
                  errorMessageList.add(errMsg);
              }

          }

The code and related calling code is easy to check and I don't really see an 
issue with it.

@Jacopo, you put it in with 
http://svn.apache.org/viewvc?view=revision=739738 what is your opinion 
about that?

And what is the team's opinion?

Thanks

Jacques

Re: [VOTE] [RESULT] Apache OFBiz 17.12.04 - Second Attempt

[Jacques Le Roux]

Great news, thanks Jacopo,

I had a doubt we had enough binding vote, which is a pity I must say!

Jacques

Le 13/07/2020 à 10:44, Jacopo Cappellato a écrit :

The vote is successful with 4 positive votes (of which 3 binding).
The new release is going to be published and announced in a few days from
now.

Jacopo



This is the vote thread (second attempt) to publish a new bug fix release
from the "release17.12" branch. This new release, "Apache OFBiz 17.12.04",
will supersede all the previous releases from the same branch.
The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-17.12.04.zip
* KEYS: text file with keys
* apache-ofbiz-17.12.04.zip.asc: the detached signature file
* apache-ofbiz-17.12.04.zip.sha512: checksum file
Please download and test the zip file and its signatures (for instructions
on testing the signatures see http://www.apache.org/info/verification.html
).
Vote:
[ +1] release as Apache OFBiz 17.12.04
[ -1] do not release
This vote will be open for 5 days.
For more details about this process please read
http://www.apache.org/foundation/voting.html

Re: checkNewPassword and ignoreCurrentPassword

[Jacques Le Roux]

Le 12/07/2020 à 13:07, Jacques Le Roux a écrit :

Hi team,

We recently got a security report about checkNewPassword where it was claimed a 
CSRF vulnerability because of ignoreCurrentPassword but I rejected it.

I have though added a comment in trunk to allow users to adds OFBiz specific 
CSRF defense in case it would be needed (peculiar browsers):
https://github.com/apache/ofbiz-framework/commit/16c2d3521990caf5e8703cbb323ce1146c93b9ce/

The reporter then wrote

   "Even if this is not a CSRF vulnerability, I still think it is an insecure 
measure to not verify the current password when changing the password
   of the system account. What do you think?"

His report was initially roughly :

   *If it is a system account, current password would not be checked*
   *
   *
   public static void checkNewPassword(GenericValue userLogin, String 
currentPassword, String newPassword, String newPasswordVerify, String
   passwordHint, List errorMessageList, boolean ignoreCurrentPassword, 
Locale locale) {
            Delegator delegator = userLogin.getDelegator();
            boolean useEncryption = 
"true".equals(EntityUtilProperties.getPropertyValue("security", 
"password.encrypt", delegator));

            String errMsg = null;

            if (!ignoreCurrentPassword) {
                // if the password.accept.encrypted.and.plain property in 
security is set to true allow plain or encrypted passwords
                // if this is a system account don't bother checking the 
passwords
                boolean passwordMatches = 
checkPassword(userLogin.getString("currentPassword"), useEncryption, 
currentPassword);
                if ((currentPassword == null) || (!passwordMatches)) {
                    errMsg = 
UtilProperties.getMessage(resource,"loginservices.old_password_not_correct_reenter",
 locale);
                    errorMessageList.add(errMsg);
                }
                if (checkPassword(userLogin.getString("currentPassword"), 
useEncryption, newPassword)) {
                    errMsg = 
UtilProperties.getMessage(resource,"loginservices.new_password_is_equal_to_old_password",
 locale);
                    errorMessageList.add(errMsg);
                }

            }

The code and related calling code is easy to check and I don't really see an 
issue with it.

@Jacopo, you put it in with 
http://svn.apache.org/viewvc?view=revision=739738 what is your opinion 
about that?

And what is the team's opinion?

Thanks

Jacques


Something related I already shared in the security ML:

I guess we don't want to change (I don't mean the NOTE but the feature).

   // NOTE: must check permission first so that admin users can set own 
password without specifying old password

I also have a question to you Jacopo:

I'm not quite sure you meant with (https://s.apache.org/04dt9)

   // TODO: change this security group because we can't use permission groups 
defined in the applications from the framework.

Which security group is it about?

Thanks

Jacques

Re: checkNewPassword and ignoreCurrentPassword

[Jacques Le Roux]

Hi Girish,

Le 13/07/2020 à 05:48, Girish Vasmatkar a écrit :

Hi Jacques

I think the vulnerability does not exist if the CSRF defence is in place.


Yes I already answered the same to the reporter and he agreed.


If there is no defence in place, there is a possibility of using system
account session to change the admin password.


All our supported versions have the cookie same attribute in place, so no 
worries


As for bypassing current password check if the user is admin, it won't hurt
if the check was in place for system account as well to check the current
password. I could be wrong so we need others opinion as well. My 2 cents.


Yes, my thoughts too

Thanks

Jacques



Best Regards,
Girish

On Sun, Jul 12, 2020 at 4:38 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi team,

We recently got a security report about checkNewPassword where it was
claimed a CSRF vulnerability because of ignoreCurrentPassword but I
rejected it.

I have though added a comment in trunk to allow users to adds OFBiz
specific CSRF defense in case it would be needed (peculiar browsers):

https://github.com/apache/ofbiz-framework/commit/16c2d3521990caf5e8703cbb323ce1146c93b9ce/

The reporter then wrote

 "Even if this is not a CSRF vulnerability, I still think it is an
insecure measure to not verify the current password when changing the
password
 of the system account. What do you think?"

His report was initially roughly :

 *If it is a system account, current password would not be checked*
 *
 *
 public static void checkNewPassword(GenericValue userLogin, String
currentPassword, String newPassword, String newPasswordVerify, String
 passwordHint, List errorMessageList, boolean
ignoreCurrentPassword, Locale locale) {
  Delegator delegator = userLogin.getDelegator();
  boolean useEncryption =
"true".equals(EntityUtilProperties.getPropertyValue("security",
"password.encrypt", delegator));

  String errMsg = null;

  if (!ignoreCurrentPassword) {
  // if the password.accept.encrypted.and.plain property in
security is set to true allow plain or encrypted passwords
  // if this is a system account don't bother checking the
passwords
  boolean passwordMatches =
checkPassword(userLogin.getString("currentPassword"), useEncryption,
currentPassword);
  if ((currentPassword == null) || (!passwordMatches)) {
  errMsg =
UtilProperties.getMessage(resource,"loginservices.old_password_not_correct_reenter",
locale);
  errorMessageList.add(errMsg);
  }
  if (checkPassword(userLogin.getString("currentPassword"),
useEncryption, newPassword)) {
  errMsg =
UtilProperties.getMessage(resource,"loginservices.new_password_is_equal_to_old_password",
locale);
  errorMessageList.add(errMsg);
  }

  }

The code and related calling code is easy to check and I don't really see
an issue with it.

@Jacopo, you put it in with
http://svn.apache.org/viewvc?view=revision=739738 what is your
opinion about that?

And what is the team's opinion?

Thanks

Jacques

checkNewPassword and ignoreCurrentPassword

[Jacques Le Roux]

Hi team,

We recently got a security report about checkNewPassword where it was claimed a 
CSRF vulnerability because of ignoreCurrentPassword but I rejected it.

I have though added a comment in trunk to allow users to adds OFBiz specific 
CSRF defense in case it would be needed (peculiar browsers):
https://github.com/apache/ofbiz-framework/commit/16c2d3521990caf5e8703cbb323ce1146c93b9ce/

The reporter then wrote

   "Even if this is not a CSRF vulnerability, I still think it is an insecure 
measure to not verify the current password when changing the password
   of the system account. What do you think?"

His report was initially roughly :

   *If it is a system account, current password would not be checked*
   *
   *
   public static void checkNewPassword(GenericValue userLogin, String 
currentPassword, String newPassword, String newPasswordVerify, String
   passwordHint, List errorMessageList, boolean ignoreCurrentPassword, 
Locale locale) {
        Delegator delegator = userLogin.getDelegator();
        boolean useEncryption = 
"true".equals(EntityUtilProperties.getPropertyValue("security", 
"password.encrypt", delegator));

        String errMsg = null;

        if (!ignoreCurrentPassword) {
            // if the password.accept.encrypted.and.plain property in 
security is set to true allow plain or encrypted passwords
            // if this is a system account don't bother checking the 
passwords
            boolean passwordMatches = 
checkPassword(userLogin.getString("currentPassword"), useEncryption, 
currentPassword);
            if ((currentPassword == null) || (!passwordMatches)) {
                errMsg = 
UtilProperties.getMessage(resource,"loginservices.old_password_not_correct_reenter",
 locale);
                errorMessageList.add(errMsg);
            }
            if (checkPassword(userLogin.getString("currentPassword"), 
useEncryption, newPassword)) {
                errMsg = 
UtilProperties.getMessage(resource,"loginservices.new_password_is_equal_to_old_password",
 locale);
                errorMessageList.add(errMsg);
            }

        }

The code and related calling code is easy to check and I don't really see an 
issue with it.

@Jacopo, you put it in with 
http://svn.apache.org/viewvc?view=revision=739738 what is your opinion 
about that?

And what is the team's opinion?

Thanks

Jacques

Re: svn commit: r1828857 - in /ofbiz/ofbiz-framework/trunk/docs/asciidoc: documentation_guidelines.adoc resource/ resource/article.adoc resource/source.java

[Jacques Le Roux]

Ah, thanks Michael,

OK then, they should stay

Jacques

Le 11/07/2020 à 17:48, Michael Brohl a écrit :

Sorry Jacques,

I missed your previous message.

Those files are referenced in the documentation_guidelines.adoc file to show how to include/reference external files. The guidelines are still valid 
and IMO useful for new contributors starting to work on documentation with asciidoc.


What are the reasons to remove those files?

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 11.07.20 um 17:04 schrieb Jacques Le Roux:
Reading https://www.vogella.com/tutorials/AsciiDoc/article.html I understand that this file were used to start the work or possibly show how to use 
AsciiDoc.


I believe they are now useless and we should get rid of them with the resource 
dir. I'll do so in a week if nobody is against.

Jacques

Le 09/07/2020 à 10:00, Jacques Le Roux a écrit :

Hi Michael,

I just stumbled upon the article.adoc and source.java files. What are those 
files used for?

Thanks

Jacques

Le 10/04/2018 à 23:24, mbr...@apache.org a écrit :

Author: mbrohl
Date: Tue Apr 10 21:24:31 2018
New Revision: 1828857

URL: http://svn.apache.org/viewvc?rev=1828857=rev
Log:
Improved: added the first draft of the documentation guidelines.

Added:
ofbiz/ofbiz-framework/trunk/docs/asciidoc/documentation_guidelines.adoc
 ofbiz/ofbiz-framework/trunk/docs/asciidoc/resource/
ofbiz/ofbiz-framework/trunk/docs/asciidoc/resource/article.adoc
ofbiz/ofbiz-framework/trunk/docs/asciidoc/resource/source.java (with props)

Added: ofbiz/ofbiz-framework/trunk/docs/asciidoc/documentation_guidelines.adoc
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/docs/asciidoc/documentation_guidelines.adoc?rev=1828857=auto
==
--- ofbiz/ofbiz-framework/trunk/docs/asciidoc/documentation_guidelines.adoc 
(added)
+++ ofbiz/ofbiz-framework/trunk/docs/asciidoc/documentation_guidelines.adoc Tue 
Apr 10 21:24:31 2018
@@ -0,0 +1,627 @@
+
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+
+= Apache OFBiz Documentation Guidelines
+The Apache OFBiz Project
+Release 17.12
+:imagesdir: ./images
+ifdef::backend-pdf[]
+:title-logo-image: image::OFBiz-Logo.svg[Apache OFBiz Logo, pdfwidth=4.25in, 
align=center]
+:source-highlighter: rouge
+endif::[]
+
+== Intro
+
+This guideline serves as a general styleguide and collection of examples of 
how we are documenting the project.
+This intentionally is not a complete user manual but lists the subset of 
functionality and formatting options we
+want to use.
+
+For further reference and more examples see
+
+* Official Asciidoc User Guide
+footnote:[http://asciidoc.org/userguide.html]
+* Asciidoc Writers Guide
+footnote:[https://asciidoctor.org/docs/asciidoc-writers-guide/].
+* Asciidoc Quick Reference
+footnote:[https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/]
+* Asciidoc Recommended Practices
+footnote:[https://asciidoctor.org/docs/asciidoc-recommended-practices/]
+
+If you want to help with the documentation of the project, see wiki page
+footnote:[https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Documentation+Team]
 for further information and
+how we are organised.
+
+== General rules
+
+=== Document configuration
+
+Documents who will be published standalone (e.g. developer manual, user 
manual) should contain a common configuration
+so that the output ist generated in the same way for all documents.
+
+[NOTE]
+This is not necessary for documents which will only be included in parent 
documents. These documents will inherit the
+configuration from the parent.
+
+This ist the proposed configuration:
+
+
+The Apache OFBiz Project // <1>
+Release 17.12 // <2>
+:imagesdir: ./images // <3>
+ifdef::backend-pdf[] // <4>
+:title-logo-image: image::OFBiz-Logo.svg[Apache OFBiz Logo, pdfwidth=4.25in, 
align=center] // <5>
+:source-highlighter: rouge // <6>
+endif::[] // <7>
+
+<1> author
+<2> target release, indicates for which release this documentation is valid
+<3> global definition of the image directory
+<4> begin block of configurations only for pdf rendering
+<5> define the title

Re: svn commit: r1828857 - in /ofbiz/ofbiz-framework/trunk/docs/asciidoc: documentation_guidelines.adoc resource/ resource/article.adoc resource/source.java

[Jacques Le Roux]

Reading https://www.vogella.com/tutorials/AsciiDoc/article.html I understand that this file were used to start the work or possibly show how to use 
AsciiDoc.


I believe they are now useless and we should get rid of them with the resource 
dir. I'll do so in a week if nobody is against.

Jacques

Le 09/07/2020 à 10:00, Jacques Le Roux a écrit :

Hi Michael,

I just stumbled upon the article.adoc and source.java files. What are those 
files used for?

Thanks

Jacques

Le 10/04/2018 à 23:24, mbr...@apache.org a écrit :

Author: mbrohl
Date: Tue Apr 10 21:24:31 2018
New Revision: 1828857

URL: http://svn.apache.org/viewvc?rev=1828857=rev
Log:
Improved: added the first draft of the documentation guidelines.

Added:
ofbiz/ofbiz-framework/trunk/docs/asciidoc/documentation_guidelines.adoc
 ofbiz/ofbiz-framework/trunk/docs/asciidoc/resource/
ofbiz/ofbiz-framework/trunk/docs/asciidoc/resource/article.adoc
ofbiz/ofbiz-framework/trunk/docs/asciidoc/resource/source.java (with props)

Added: ofbiz/ofbiz-framework/trunk/docs/asciidoc/documentation_guidelines.adoc
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/docs/asciidoc/documentation_guidelines.adoc?rev=1828857=auto
==
--- ofbiz/ofbiz-framework/trunk/docs/asciidoc/documentation_guidelines.adoc 
(added)
+++ ofbiz/ofbiz-framework/trunk/docs/asciidoc/documentation_guidelines.adoc Tue 
Apr 10 21:24:31 2018
@@ -0,0 +1,627 @@
+
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+
+= Apache OFBiz Documentation Guidelines
+The Apache OFBiz Project
+Release 17.12
+:imagesdir: ./images
+ifdef::backend-pdf[]
+:title-logo-image: image::OFBiz-Logo.svg[Apache OFBiz Logo, pdfwidth=4.25in, 
align=center]
+:source-highlighter: rouge
+endif::[]
+
+== Intro
+
+This guideline serves as a general styleguide and collection of examples of 
how we are documenting the project.
+This intentionally is not a complete user manual but lists the subset of 
functionality and formatting options we
+want to use.
+
+For further reference and more examples see
+
+* Official Asciidoc User Guide
+footnote:[http://asciidoc.org/userguide.html]
+* Asciidoc Writers Guide
+footnote:[https://asciidoctor.org/docs/asciidoc-writers-guide/].
+* Asciidoc Quick Reference
+footnote:[https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/]
+* Asciidoc Recommended Practices
+footnote:[https://asciidoctor.org/docs/asciidoc-recommended-practices/]
+
+If you want to help with the documentation of the project, see wiki page
+footnote:[https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Documentation+Team]
 for further information and
+how we are organised.
+
+== General rules
+
+=== Document configuration
+
+Documents who will be published standalone (e.g. developer manual, user 
manual) should contain a common configuration
+so that the output ist generated in the same way for all documents.
+
+[NOTE]
+This is not necessary for documents which will only be included in parent 
documents. These documents will inherit the
+configuration from the parent.
+
+This ist the proposed configuration:
+
+
+The Apache OFBiz Project // <1>
+Release 17.12 // <2>
+:imagesdir: ./images // <3>
+ifdef::backend-pdf[] // <4>
+:title-logo-image: image::OFBiz-Logo.svg[Apache OFBiz Logo, pdfwidth=4.25in, 
align=center] // <5>
+:source-highlighter: rouge // <6>
+endif::[] // <7>
+
+<1> author
+<2> target release, indicates for which release this documentation is valid
+<3> global definition of the image directory
+<4> begin block of configurations only for pdf rendering
+<5> define the title logo image
+<6> use the Rouge source code highlighter
+<7> end block of configurations only for PDF rendering
+
+The following configuration options are set globally in the Gradle build file.
+They are not configured in the document itself and are listed for reference 
only:
+
+.build.gradle
+
+'doctype': 'book', // <1>
+'experimental': '', // <2>
+'icons': 'font', // <3>
+'sectnums': '', // <4>
+'chapter-label': '', // <5>
+'toc': '', // <6>
+'toclevels': '5' // <7>
+
+

OFBIZ-11879 and README files under web site

[Jacques Le Roux]

Hi,

I have always found annoying to read README.adoc when it's suite fine as a HTML 
file with a TOC.
I also found that few users are not reading it maybe because it's uneasy.

Anyway instead of AsciiDoc files under main repos we can now refer to HTML or 
PDF files under https://ci.apache.org/projects/ofbiz/site/

eg for README

 * https://ci.apache.org/projects/ofbiz/site/trunk/readme/html5/README.html
 * https://ci.apache.org/projects/ofbiz/site/next/readme/html5/README.html
 * https://ci.apache.org/projects/ofbiz/site/stable/readme/html5/README.html

Jacques

Re: svn commit: r1828857 - in /ofbiz/ofbiz-framework/trunk/docs/asciidoc: documentation_guidelines.adoc resource/ resource/article.adoc resource/source.java

[Jacques Le Roux]

Hi Michael,

I just stumbled upon the article.adoc and source.java files. What are those 
files used for?

Thanks

Jacques

Le 10/04/2018 à 23:24, mbr...@apache.org a écrit :

Author: mbrohl
Date: Tue Apr 10 21:24:31 2018
New Revision: 1828857

URL: http://svn.apache.org/viewvc?rev=1828857=rev
Log:
Improved: added the first draft of the documentation guidelines.

Added:
 ofbiz/ofbiz-framework/trunk/docs/asciidoc/documentation_guidelines.adoc
 ofbiz/ofbiz-framework/trunk/docs/asciidoc/resource/
 ofbiz/ofbiz-framework/trunk/docs/asciidoc/resource/article.adoc
 ofbiz/ofbiz-framework/trunk/docs/asciidoc/resource/source.java   (with 
props)

Added: ofbiz/ofbiz-framework/trunk/docs/asciidoc/documentation_guidelines.adoc
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/docs/asciidoc/documentation_guidelines.adoc?rev=1828857=auto
==
--- ofbiz/ofbiz-framework/trunk/docs/asciidoc/documentation_guidelines.adoc 
(added)
+++ ofbiz/ofbiz-framework/trunk/docs/asciidoc/documentation_guidelines.adoc Tue 
Apr 10 21:24:31 2018
@@ -0,0 +1,627 @@
+
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+
+= Apache OFBiz Documentation Guidelines
+The Apache OFBiz Project
+Release 17.12
+:imagesdir: ./images
+ifdef::backend-pdf[]
+:title-logo-image: image::OFBiz-Logo.svg[Apache OFBiz Logo, pdfwidth=4.25in, 
align=center]
+:source-highlighter: rouge
+endif::[]
+
+== Intro
+
+This guideline serves as a general styleguide and collection of examples of 
how we are documenting the project.
+This intentionally is not a complete user manual but lists the subset of 
functionality and formatting options we
+want to use.
+
+For further reference and more examples see
+
+* Official Asciidoc User Guide
+footnote:[http://asciidoc.org/userguide.html]
+* Asciidoc Writers Guide
+footnote:[https://asciidoctor.org/docs/asciidoc-writers-guide/].
+* Asciidoc Quick Reference
+footnote:[https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/]
+* Asciidoc Recommended Practices
+footnote:[https://asciidoctor.org/docs/asciidoc-recommended-practices/]
+
+If you want to help with the documentation of the project, see wiki page
+footnote:[https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Documentation+Team]
 for further information and
+how we are organised.
+
+== General rules
+
+=== Document configuration
+
+Documents who will be published standalone (e.g. developer manual, user 
manual) should contain a common configuration
+so that the output ist generated in the same way for all documents.
+
+[NOTE]
+This is not necessary for documents which will only be included in parent 
documents. These documents will inherit the
+configuration from the parent.
+
+This ist the proposed configuration:
+
+
+The Apache OFBiz Project // <1>
+Release 17.12 // <2>
+:imagesdir: ./images // <3>
+ifdef::backend-pdf[] // <4>
+:title-logo-image: image::OFBiz-Logo.svg[Apache OFBiz Logo, pdfwidth=4.25in, 
align=center] // <5>
+:source-highlighter: rouge // <6>
+endif::[] // <7>
+
+<1> author
+<2> target release, indicates for which release this documentation is valid
+<3> global definition of the image directory
+<4> begin block of configurations only for pdf rendering
+<5> define the title logo image
+<6> use the Rouge source code highlighter
+<7> end block of configurations only for PDF rendering
+
+The following configuration options are set globally in the Gradle build file.
+They are not configured in the document itself and are listed for reference 
only:
+
+.build.gradle
+
+'doctype': 'book', // <1>
+'experimental': '', // <2>
+'icons': 'font', // <3>
+'sectnums': '', // <4>
+'chapter-label': '', // <5>
+'toc': '', // <6>
+'toclevels': '5' // <7>
+
+<1> doctype book
+<2> allow experimental features like keyboard shortcuts
+<3> make font awesome icons available
+<4> number chapters and sections automatically
+<5> do not prefix the chapters
+<6> insert a table of contents
+<7> max levels to show in the table of contents
+
+=== Apache License Header
+
+Each .adoc file must contain the Apache license header (put between " 
license... "). You can just copy the
+following block:
+
+
+Licensed to the Apache Software 

Re: Change "build and install" section on the website

[Jacques Le Roux]

Done

Le 08/07/2020 à 09:29, Jacques Le Roux a écrit :
hen I will modify the “Build and running OFBiz” section on the website to refer to the INSTALL file 

Re: JUnit 5?

[Jacques Le Roux]

Thank you Girish for copying in OFBIZ-11870,

I still not had the time to think at your question :)

Jacques

Le 06/07/2020 à 07:39, Girish Vasmatkar a écrit :

Hi All

OFBiz integration tests are based on classes extending the TestCase class.
Should we not allow for a hybrid way of writing integration test cases
based on classes that do not extend TestCase while also allowing old ways
(extending TestCase and test methods starting with test) of writing test
cases?

Is there any particular reason why we are still using TestCase class?

Best
Girish




On Sun, Jul 5, 2020 at 1:44 PM Jacques Le Roux 
wrote:


Thanks Eugen,

That's quite interesting, could you please put your comment in the Jira?

TIA

Jacques

Le 05/07/2020 à 09:36, Eugen Stan a écrit :

Hello Jacques,

I think it makes sense to make the transition.

In James we do have it ongoing.

Junit5 people have documented the upgrade process and you can make it
gradually and have both.

Use ` git grep org.junit.Test | wc -l `to count the non-migrated tests.

This is what we have based on the migration samples
https://github.com/junit-team/junit5-samples#gradle-migration-



https://github.com/junit-team/junit5-samples/blob/main/junit5-migration-gradle/build.gradle


https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4



  testImplementation 'org.junit.jupiter:junit-jupiter-api:5.5.1'
  testImplementation 'org.junit.jupiter:junit-jupiter-params:5.5.1'
  testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.5.1'
  testCompileOnly 'junit:junit:4.13'
  testRuntimeOnly 'org.junit.vintage:junit-vintage-engine:5.5.1'
}

test {
  useJUnitPlatform()
}




La 05.07.2020 10:01, Jacques Le Roux a scris:

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

Jacques

Le 04/09/2018 à 09:15, Jacques Le Roux a écrit :

Hi,

I stumbled upon this tweet

  https://twitter.com/junitteam/status/1036707906706698243

Had a quick look at

  https://junit.org/junit5/docs/5.3.0/release-notes/

  https://www.baeldung.com/junit-5-migration

I did not rememberf, so searched if we discussed moving from JUnit 4
to JUnit 5, but did not find anything.

Did we discuss it, if so what were the conclusions? If not, should we
not discuss it?

Thanks


https://twitter.com/junitteam/status/1036707906706698243witter.com/junitteam/status/1036707906706698243

Jacques

Re: Change "build and install" section on the website

[Jacques Le Roux]

Hi All,

After trying to update it, I have finally moved
https://cwiki.apache.org/confluence/display/OFBIZ/How+to+install+OFBiz+with+the+Demo+Data
to the wiki Attic, with another older one from 2008.

I'll do the same for
https://cwiki.apache.org/confluence/display/OFBENDUSER/How+to+Install+OFBiz+without+the+Demo+Data
I'll document that in the INSTALL before

Then I will modify the “Build and running OFBiz” section on the website to 
refer to the INSTALL file

There are maybe other deprecated install or load data or what-not related to 
install and load data pages that you are aware of.
Then please either move them to Wiki Attic or let us know here that we check, 
TIA

Jacques

Le 02/07/2020 à 07:50, Jacques Le Roux a écrit :

Hi Michael,

That sounds like a pragmatic idea to me

Jacques

Le 01/07/2020 à 18:47, Michael Brohl a écrit :

Hi all,

The description in https://ofbiz.apache.org/business-users.html#UsrInstall  is 
not correct for the 17.12 download at the moment.

I think we should get rid of the “Build and running OFBiz” section on the website and just refer to the INSTALL/README in the downloaded package to 
avoid confusion.


It will be easier to maintain also.

What do you think?

Michael Brohl

ecomify GmbH - www.ecomify.de

Welcome Arun Patidar as new PMC member

[Jacques Le Roux]

The OFBiz PMC has invited Arun Patidar to become member of the committee and we 
are glad to announce that he has accepted the nomination.

On behalf of the OFBiz PMC, welcome on board Arun!

Welcome Aditya Sharma as new PMC member

[Jacques Le Roux]

The OFBiz PMC has invited Aditya Sharma to become member of the committee and 
we are glad to announce that he has accepted the nomination.

On behalf of the OFBiz PMC, welcome on board Aditya!

Error.ftl everywhere

[Jacques Le Roux]

Hi,

While working on OFBIZ-11840 I thought about the solution I used for 
"[CVE-2020-1943] Apache OFBiz XSS Vulnerability"

So I tried that:

diff --git framework/common/webcommon/WEB-INF/common-controller.xml 
framework/common/webcommon/WEB-INF/common-controller.xml
index e6f9394cd4..9291cdbece 100644
--- framework/common/webcommon/WEB-INF/common-controller.xml
+++ framework/common/webcommon/WEB-INF/common-controller.xml
@@ -338,7 +338,7 @@ under the License.
 

 
-    
+    
 
 
 
diff --git framework/common/webcommon/WEB-INF/handlers-controller.xml 
framework/common/webcommon/WEB-INF/handlers-controller.xml
index be21b19fd9..1622d10ead 100644
--- framework/common/webcommon/WEB-INF/handlers-controller.xml
+++ framework/common/webcommon/WEB-INF/handlers-controller.xml
@@ -42,4 +42,5 @@ under the License.
 
 
 
+    
 

It does not fix the OFBIZ-11840 issue but it works. I mean it correctly 
replaces error.jsp by error.ftl.

Few questions:

1. Why having the ftl handlers only in webtools controller? BTW it makes the 
XSD documentation awkward because it speaks about the ftl handlers being
   in handlers-controller.xml
2. Why not using error.ftl in common-controller.xml instead of error.jsp?
3. Same question for plugins.

I believe we could change all that and definitely get rid of error.jsp 
(error.ftl is already in all supported releases branches)

What do you think?

Jacques

Re: [VOTE] [RELEASE] Apache OFBiz 17.12.04 - Second Attempt

[Jacques Le Roux]

Thanks Girish,

A Git-bash quirk in Windows I guess, OK with me also in my Ubuntu VM

+1 to release

Jacques

Le 05/07/2020 à 14:38, Girish Vasmatkar a écrit :

Looks fine at my end -

  girish$ ./verify-ofbiz-release.sh apache-ofbiz-17.12.04.zip

sha check of file: apache-ofbiz-17.12.04.zip

Using sha file: apache-ofbiz-17.12.04.zip.sha512

apache-ofbiz-17.12.04.zip: 87FC62B2 8005BE59 FBB5AA69 6F0317C1 72273F02
EB39DD82 9738761C 694D644B F004C3A6 12E8DB41 512C726A 4F5E991F D80A6A84
4AADE640 7B726DC1 8E4182A8

apache-ofbiz-17.12.04.zip: 87FC62B2 8005BE59 FBB5AA69 6F0317C1 72273F02
EB39DD82 9738761C 694D644B F004C3A6 12E8DB41 512C726A 4F5E991F D80A6A84
4AADE640 7B726DC1 8E4182A8

sha checksum OK


GPG verification output

gpg: Signature made Sun Jul  5 13:38:45 2020 IST

gpg:using RSA key 7A580908847AF9E0

gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY) <
jaco...@apache.org>" [unknown]

gpg: WARNING: This key is not certified with a trusted signature!

gpg:  There is no indication that the signature belongs to the
owner.

Primary key fingerprint: 3545 C5E3 1CC2 D029 B2CC  AD06 7A58 0908 847A F9E0

Best,
Girish


On Sun, Jul 5, 2020 at 3:24 PM Jacques Le Roux 
wrote:


Hi Jacopo,

Something is wrong, I get that (dowloaded twice, except the package which
opens normally):

$ ./verify-ofbiz-release.sh apache-ofbiz-17.12.04.zip
sha check of file: apache-ofbiz-17.12.04.zip
Using sha file: apache-ofbiz-17.12.04.zip.sha512
apache-ofbiz-17.12.04.zip: 87FC62B2 8005BE59 FBB5AA69 6F0317C1 72273F02
EB39DD82 9738761C 694D644B F004C3A6 12E8DB41 512C726A 4F5E991F D80A6A84
4AADE640 7B726DC1 8E4182A8
apache-ofbiz-17.12.04.zip: 74F79D42 2746A409 9C0F2E0D 5F96C070 78C73D7B
4C681452 EB974F18 33E2E391 3E1C7D1F 2F0E8A44 C18AC8FF A9F86094 4C9F5D4D
5DDA3AB9 E2DC2057 CA0F2E33
sha sums mismatch!

GPG verification output
gpg: Signature made Fri Jul  3 16:04:40 2020
gpg:using RSA key 7A580908847AF9E0
gpg: BAD signature from "Jacopo Cappellato (CODE SIGNING KEY) <
jaco...@apache.org>"

Could it be on my side? Anyone reproduce?

Jacques

Le 05/07/2020 à 10:23, Jacopo Cappellato a écrit :

This is the vote thread (second attempt) to publish a new bug fix release
from the "release17.12" branch. This new release, "Apache OFBiz

17.12.04",

will supersede all the previous releases from the same branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-17.12.04.zip
* KEYS: text file with keys
* apache-ofbiz-17.12.04.zip.asc: the detached signature file
* apache-ofbiz-17.12.04.zip.sha512: checksum file

Please download and test the zip file and its signatures (for

instructions

on testing the signatures see

http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 17.12.04
[ -1] do not release

This vote will be open for 5 days.

For more details about this process please read
http://www.apache.org/foundation/voting.html

Re: [VOTE] [RELEASE] Apache OFBiz 17.12.04 - Second Attempt

[Jacques Le Roux]

Hi Jacopo,

Something is wrong, I get that (dowloaded twice, except the package which opens 
normally):

$ ./verify-ofbiz-release.sh apache-ofbiz-17.12.04.zip
sha check of file: apache-ofbiz-17.12.04.zip
Using sha file: apache-ofbiz-17.12.04.zip.sha512
apache-ofbiz-17.12.04.zip: 87FC62B2 8005BE59 FBB5AA69 6F0317C1 72273F02 EB39DD82 9738761C 694D644B F004C3A6 12E8DB41 512C726A 4F5E991F D80A6A84 
4AADE640 7B726DC1 8E4182A8
apache-ofbiz-17.12.04.zip: 74F79D42 2746A409 9C0F2E0D 5F96C070 78C73D7B 4C681452 EB974F18 33E2E391 3E1C7D1F 2F0E8A44 C18AC8FF A9F86094 4C9F5D4D 
5DDA3AB9 E2DC2057 CA0F2E33

sha sums mismatch!

GPG verification output
gpg: Signature made Fri Jul  3 16:04:40 2020
gpg:    using RSA key 7A580908847AF9E0
gpg: BAD signature from "Jacopo Cappellato (CODE SIGNING KEY) 
"

Could it be on my side? Anyone reproduce?

Jacques

Le 05/07/2020 à 10:23, Jacopo Cappellato a écrit :

This is the vote thread (second attempt) to publish a new bug fix release
from the "release17.12" branch. This new release, "Apache OFBiz 17.12.04",
will supersede all the previous releases from the same branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-17.12.04.zip
* KEYS: text file with keys
* apache-ofbiz-17.12.04.zip.asc: the detached signature file
* apache-ofbiz-17.12.04.zip.sha512: checksum file

Please download and test the zip file and its signatures (for instructions
on testing the signatures see http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 17.12.04
[ -1] do not release

This vote will be open for 5 days.

For more details about this process please read
http://www.apache.org/foundation/voting.html

Re: JUnit 5?

[Jacques Le Roux]

Thanks Eugen,

That's quite interesting, could you please put your comment in the Jira?

TIA

Jacques

Le 05/07/2020 à 09:36, Eugen Stan a écrit :

Hello Jacques,

I think it makes sense to make the transition.

In James we do have it ongoing.

Junit5 people have documented the upgrade process and you can make it
gradually and have both.

Use ` git grep org.junit.Test | wc -l `to count the non-migrated tests.

This is what we have based on the migration samples
https://github.com/junit-team/junit5-samples#gradle-migration-

https://github.com/junit-team/junit5-samples/blob/main/junit5-migration-gradle/build.gradle


https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4



     testImplementation 'org.junit.jupiter:junit-jupiter-api:5.5.1'
     testImplementation 'org.junit.jupiter:junit-jupiter-params:5.5.1'
     testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.5.1'
     testCompileOnly 'junit:junit:4.13'
     testRuntimeOnly 'org.junit.vintage:junit-vintage-engine:5.5.1'
}

test {
     useJUnitPlatform()
}




La 05.07.2020 10:01, Jacques Le Roux a scris:

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

Jacques

Le 04/09/2018 à 09:15, Jacques Le Roux a écrit :

Hi,

I stumbled upon this tweet

     https://twitter.com/junitteam/status/1036707906706698243

Had a quick look at

     https://junit.org/junit5/docs/5.3.0/release-notes/

     https://www.baeldung.com/junit-5-migration

I did not rememberf, so searched if we discussed moving from JUnit 4
to JUnit 5, but did not find anything.

Did we discuss it, if so what were the conclusions? If not, should we
not discuss it?

Thanks

https://twitter.com/junitteam/status/1036707906706698243witter.com/junitteam/status/1036707906706698243

Jacques

Re: JUnit 5?

[Jacques Le Roux]

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

Jacques

Le 04/09/2018 à 09:15, Jacques Le Roux a écrit :

Hi,

I stumbled upon this tweet

    https://twitter.com/junitteam/status/1036707906706698243

Had a quick look at

    https://junit.org/junit5/docs/5.3.0/release-notes/

    https://www.baeldung.com/junit-5-migration

I did not rememberf, so searched if we discussed moving from JUnit 4 to JUnit 
5, but did not find anything.

Did we discuss it, if so what were the conclusions? If not, should we not 
discuss it?

Thanks

https://twitter.com/junitteam/status/1036707906706698243witter.com/junitteam/status/1036707906706698243

Jacques

Welcome Suraj Khurana as new PMC member

[Jacques Le Roux]

The OFBiz PMC has invited Suraj Khurana to become member of the committee and 
we are glad to announce that he has accepted the nomination.

On behalf of the OFBiz PMC, welcome on board Suraj!

Re: [VOTE] [RELEASE] Apache OFBiz 17.12.04

[Jacques Le Roux]

Le 03/07/2020 à 19:31, Jacques Le Roux a écrit :

I see another issue locally, that exists also on R17 demo:

2020-07-03 03:10:02,911 |OFBiz-batch-2 |DatabaseUtil  |E| Column [ACCOMMODATION_CLASS_ID] of table [OFBIZ.ACCOMMODATION_CLASS] of 
entity [AccommodationClass] IS NOT a primary key in the database, but IS a primary key in the entity definition. The primary key for this table 
needs to be re-created or modified to add this column to the primary key. Note that data may need to be added first as a primary key column cannot 
have an null values.

[...]
2020-07-03 03:10:03,092 |OFBiz-batch-2 |DatabaseUtil  |E| Column [CITY] of table [OFBIZ.ZIP_SALES_TAX_LOOKUP] of entity 
[ZipSalesTaxLookup] IS NOT a primary key in the database, but IS a primary key in the entity definition. The primary key for this table needs to be 
re-created or modified to add this column to the primary key. Note that data may need to be added first as a primary key column cannot have an null 
values.


This does not exist in trunk, did not check R18.

Weirdly it does not exist in Buildbot either for R17. Even before Michael's 
last fix for AJP. Anyway I don't use AJP locally nor does Buildbot.

And finally it does not prevent the tests to pass. 


This is no longer a problem. I fixed it in OFBIZ-11312. I wrongly removed a 
line when backporting by hand in R17

I see now no reasons to create a new "Tentative release files for Apache OFBiz 
17.12.04"

Thanks

Jacques

Re: [VOTE] [RELEASE] Apache OFBiz 17.12.04

[Jacques Le Roux]

Le 03/07/2020 à 19:37, Jacques Le Roux a écrit :

Le 03/07/2020 à 19:31, Jacques Le Roux a écrit :

I think we should mention that this is not a real issue referring to the 
corresponding Jiras.

Forgot to mention it's OFBIZ-6807  and related

I just fixed a miss in OFBIZ-6993, should not be a worry anymore

Jacques

Re: [VOTE] [RELEASE] Apache OFBiz 17.12.04

[Jacques Le Roux]

Le 03/07/2020 à 19:31, Jacques Le Roux a écrit :

I think we should mention that this is not a real issue referring to the 
corresponding Jiras.

Forgot to mention it's OFBIZ-6807  and related

Jacques

Re: [VOTE] [RELEASE] Apache OFBiz 17.12.04

[Jacques Le Roux]

-1 for now.

check OK:

$ ./verify-ofbiz-release.sh apache-ofbiz-17.12.04.zip
sha check of file: apache-ofbiz-17.12.04.zip
Using sha file: apache-ofbiz-17.12.04.zip.sha512
apache-ofbiz-17.12.04.zip: 74F79D42 2746A409 9C0F2E0D 5F96C070 78C73D7B 4C681452 EB974F18 33E2E391 3E1C7D1F 2F0E8A44 C18AC8FF A9F86094 4C9F5D4D 
5DDA3AB9 E2DC2057 CA0F2E33
apache-ofbiz-17.12.04.zip: 74F79D42 2746A409 9C0F2E0D 5F96C070 78C73D7B 4C681452 EB974F18 33E2E391 3E1C7D1F 2F0E8A44 C18AC8FF A9F86094 4C9F5D4D 
5DDA3AB9 E2DC2057 CA0F2E33

sha checksum OK

GPG verification output
gpg: Signature made Fri Jul  3 16:04:40 2020
gpg:    using RSA key 7A580908847AF9E0
gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY) 
"


Running OFBiz (gradlew loadAll ofbiz) is OK but I initially get:

2020-07-03 16:56:13,607 |catalina-startup-6 |CatalinaContainer |I| 
host[StandardEngine[default-server].StandardHost[0.0.0.0]].addChild(StandardEngine[default-server].StandardHost[0.0.0.0].Standa

rdContext[/ecommerce])
Jul 03, 2020 4:56:13 PM org.apache.tomcat.util.digester.Digester error
SEVERE: Parse error at line [20] column [24]
org.xml.sax.SAXParseException; systemId: 
file:///C:/projectsASF/Git/ofbiz-framework/tools/apache-ofbiz-17.12.04/applications/commonext/webapp/ordermgr-js/WEB-INF/web.xml; lineNumber: 20; 
columnNumber: 24; cvc

-elt.1: Cannot find the declaration of element 'web-app'.
    at 
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown 
Source)

I think we should mention that this is not a real issue referring to the 
corresponding Jiras. The same reappears when running testIntegration.


I see another issue locally, that exists also on R17 demo:

2020-07-03 03:10:02,911 |OFBiz-batch-2 |DatabaseUtil  |E| Column [ACCOMMODATION_CLASS_ID] of table [OFBIZ.ACCOMMODATION_CLASS] of 
entity [AccommodationClass] IS NOT a primary key in the database, but IS a primary key in the entity definition. The primary key for this table needs 
to be re-created or modified to add this column to the primary key. Note that data may need to be added first as a primary key column cannot have an 
null values.

[...]
2020-07-03 03:10:03,092 |OFBiz-batch-2 |DatabaseUtil  |E| Column [CITY] of table [OFBIZ.ZIP_SALES_TAX_LOOKUP] of entity 
[ZipSalesTaxLookup] IS NOT a primary key in the database, but IS a primary key in the entity definition. The primary key for this table needs to be 
re-created or modified to add this column to the primary key. Note that data may need to be added first as a primary key column cannot have an null 
values.


This does not exist in trunk, did not check R18.

Weirdly it does not exist in Buildbot either for R17. Even before Michael's 
last fix for AJP. Anyway I don't use AJP locally nor does Buildbot.

And finally it does not prevent the tests to pass.

I'm not sure what this is or if  it's random. But it would certainly not look 
good to users's views. We need to understand what's the problem is.

I also found a bug in scrum/template/AcceptedBacklogNotification.ftl but that 
can wait.

Jacques

Le 03/07/2020 à 16:23, Jacopo Cappellato a écrit :

  This is the vote thread to publish a new bug fix release from the
"release17.12" branch. This new release, "Apache OFBiz 17.12.04", will
supersede all the previous releases from the same branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-17.12.04.zip
* KEYS: text file with keys
* apache-ofbiz-17.12.04.zip.asc: the detached signature file
* apache-ofbiz-17.12.04.zip.sha512: checksum file

Please download and test the zip file and its signatures (for instructions
on testing the signatures see http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 17.12.04
[ -1] do not release

This vote will be open for 5 days.

For more details about this process please read
http://www.apache.org/foundation/voting.html

Re: [Presentation] Slides for empower screen engine

[Jacques Le Roux]

Thanks Nicolas and the Nereide team,

Sounds like it's ready to be used :)

Very nice!

Jacques

Le 03/07/2020 à 12:40, Eugen Stan a écrit :

I'm a begginer in OFBiz and looking forward to see the new theme.

Very nice presentation.

The sound volume in the second video is very low.

Once you merge this, it would be nice to publish the videos on Apache
OFBiz youtube channel.


Regards,

Eugen

La 03.07.2020 11:14, Nicolas Malin a scris:

Hello all,

To finalize our current work presentation to homogenize and empower
the screen engine, we realized some slides [1] to summarize it.

We opened an issue to prepare to load of it in trunk (OFBIZ-11808 [2])
with the idea to not introduce any regression on old theme and screen.

So to continue to move forward, we appreciate to have any remark,
suggest or feeling about that, your welcome !

Cheers,

Nicolas

[1] https://s.apache.org/EmpowerOFBizScreen
[2] https://issues.apache.org/jira/browse/OFBIZ-11808

--
logoNrd 
Nicolas Malin
The apache way  : *Charity* Apache’s mission
is providing software for the public good.
informat...@nereide.fr
8 rue des Déportés 37000 TOURS, 02 47 50 30 54

Apache OFBiz |The Apache Way
|réseau LE 

Re: Change "build and install" section on the website

[Jacques Le Roux]

Hi Michael,

That sounds like a pragmatic idea to me

Jacques

Le 01/07/2020 à 18:47, Michael Brohl a écrit :

Hi all,

The description in https://ofbiz.apache.org/business-users.html#UsrInstall  is 
not correct for the 17.12 download at the moment.

I think we should get rid of the “Build and running OFBiz” section on the website and just refer to the INSTALL/README in the downloaded package to 
avoid confusion.


It will be easier to maintain also.

What do you think?

Michael Brohl

ecomify GmbH - www.ecomify.de

Re: buildbot failure in on ofbizTrunkFramework

[Jacques Le Roux]

Fixed, was an issue in the Buildbot config file

Le 29/06/2020 à 12:31, Jacques Le Roux a écrit :

For a reason, the results at 
https://ci.apache.org/projects/ofbiz/logs/trunk/plugins/html/ stopped to update 
3 days ago

I'll try to check why...

The Buildbot config changed 4 days ago, but I can't see a relation. I only changed 
"upload checkstyle" steps titles which are OK.

Also there are no failure uploading the failing test results:
https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1535

Le 29/06/2020 à 11:18, Jacques Le Roux a écrit :

It works, I commented out the data loading.

Still the other unrelated failure, looking at it...

Jacques

Le 29/06/2020 à 11:05, Pritam Kute a écrit :

Thanks, Jacques for confirming the same.

IMO, commenting it for now is better option. We should not move it to
applications. Soon or later we are going to move all 3rd party payment
gateway code outside applications may be as a separate 3rd party
integration plugins.

I am working on modifying the plugin further to support token-based
transactions and I will take care of documentation with that work.

Kind Regards,
--
Pritam Kute


On Mon, Jun 29, 2020 at 2:22 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Thanks Pritam,

Trying to comment them out.

If it works, maybe we could move them to
applications/commonext/data/OfbizSetupProductStoreData.xml or simply let
them commented out and documenting it?

Let's see...

Jacques

Le 29/06/2020 à 10:04, Pritam Kute a écrit :

Hello Jacques,

Should we remove the product store association in demo data for the first
data integration? I think it is causing this issue.

Kind Regards,
--
Pritam Kute

On Mon, Jun 29, 2020 at 1:16 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Weird again, running

"ofbiz --test component=accounting --test suitename=accountingtests

--test

case=auto-accounting-transaction-tests-sales"

Maybe a data issue when running integration tests, maybe in both case,

ie

for auto-accounting-transaction-tests-sales and
configurableServiceOrder-test

I continue...

Le 28/06/2020 à 12:52, Jacques Le Roux a écrit :

Actually that was it, had to clean and reload data.

Le 28/06/2020 à 12:25, Jacques Le Roux a écrit :

Le 28/06/2020 à 12:01, Jacques Le Roux a écrit :

There is also an issue with auto-accounting-transaction-tests-sales

I'm chasing

It seems due to

https://gitbox.apache.org/repos/asf?p=ofbiz-plugins.git;h=df753f8

2020-06-28 11:59:36,699 |main |TransactionUtil   |W| Not

committing transaction, status is No Transaction (6)

2020-06-28 11:59:36,699 |main |PaymentGatewayServices    |E| Error

occurred on: firstDataCCAuth, Order ID is: [DEMO10090]

org.apache.ofbiz.service.GenericServiceException: Service

[firstDataCCAuth] target threw an unexpected exception (Illegal

character

in path at

index 0: [TransactionUrl]/payments)

but reverting the commit does not fix it. So maybe another mixed stuff

Jacques

Re: [PROPOSAL] Change implementation/runtimeOnly in build.gradle to comma separated style?

[Jacques Le Roux]

Hi Jinghai,

Actually I prefer the current version. I find it easier to maintain: eg when you add a line you simply copy the line above and don't need to worry 
about the comma.


I can't remember the number of cases I forgot a comma in the Buildbot config 
file :)

Jacques

Le 30/06/2020 à 11:19, Shi Jinghai a écrit :

Hi Eugen,

I agree this proposal is mild cosmetic :)


发件人: Eugen Stan
发送时间: 2020年6月30日 17:07
收件人: dev@ofbiz.apache.org; Shi 
Jinghai
主题: Re: [PROPOSAL] Change implementation/runtimeOnly in build.gradle to comma 
separated style?

Hi Shi Jinghai,

What are the benefits?

Why do all this work?

It seems to me they are only mild cosmetic improvements (arguably an
improvement).

In my apps I usually copy dependencies from maven (the copy button) and
they include the 'implementation' word, as most similar sites do.

Example:
https://search.maven.org/artifact/org.huihoo/ofbiz-smart-framework/0.9.5/jar



La 30.06.2020 06:05, Shi Jinghai a scris:

Hi there,

While typing implementation, runtimeOnly and etc. in build.gradle, I find they 
can be changed to comma separated style, as the build.gradle is a groovy file, 
for example:

implementation 'xerces:xercesImpl:2.11.0'
implementation 'com.google.zxing:core:3.4.0'
implementation 
'com.googlecode.concurrentlinkedhashmap:concurrentlinkedhashmap-lru:1.4.2'
implementation 'com.googlecode.ez-vcard:ez-vcard:0.9.10'
implementation 
'com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:1.1'

EQUALS to

implementation 'xerces:xercesImpl:2.11.0',
'com.google.zxing:core:3.4.0',

'com.googlecode.concurrentlinkedhashmap:concurrentlinkedhashmap-lru:1.4.2',
'com.googlecode.ez-vcard:ez-vcard:0.9.10',

'com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:1.1'

Just the same as
   int a, b
equals to
   int a
   int b

What do you think?

Kind Regards,

Shi Jinghai



--
Eugen Stan
+40720 898 747 / netdava.com

Re: buildbot failure in on ofbizTrunkFramework

[Jacques Le Roux]

For a reason, the results at 
https://ci.apache.org/projects/ofbiz/logs/trunk/plugins/html/ stopped to update 
3 days ago

I'll try to check why...

The Buildbot config changed 4 days ago, but I can't see a relation. I only changed 
"upload checkstyle" steps titles which are OK.

Also there are no failure uploading the failing test results:
https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1535

Le 29/06/2020 à 11:18, Jacques Le Roux a écrit :

It works, I commented out the data loading.

Still the other unrelated failure, looking at it...

Jacques

Le 29/06/2020 à 11:05, Pritam Kute a écrit :

Thanks, Jacques for confirming the same.

IMO, commenting it for now is better option. We should not move it to
applications. Soon or later we are going to move all 3rd party payment
gateway code outside applications may be as a separate 3rd party
integration plugins.

I am working on modifying the plugin further to support token-based
transactions and I will take care of documentation with that work.

Kind Regards,
--
Pritam Kute


On Mon, Jun 29, 2020 at 2:22 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Thanks Pritam,

Trying to comment them out.

If it works, maybe we could move them to
applications/commonext/data/OfbizSetupProductStoreData.xml or simply let
them commented out and documenting it?

Let's see...

Jacques

Le 29/06/2020 à 10:04, Pritam Kute a écrit :

Hello Jacques,

Should we remove the product store association in demo data for the first
data integration? I think it is causing this issue.

Kind Regards,
--
Pritam Kute

On Mon, Jun 29, 2020 at 1:16 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Weird again, running

"ofbiz --test component=accounting --test suitename=accountingtests

--test

case=auto-accounting-transaction-tests-sales"

Maybe a data issue when running integration tests, maybe in both case,

ie

for auto-accounting-transaction-tests-sales and
configurableServiceOrder-test

I continue...

Le 28/06/2020 à 12:52, Jacques Le Roux a écrit :

Actually that was it, had to clean and reload data.

Le 28/06/2020 à 12:25, Jacques Le Roux a écrit :

Le 28/06/2020 à 12:01, Jacques Le Roux a écrit :

There is also an issue with auto-accounting-transaction-tests-sales

I'm chasing

It seems due to

https://gitbox.apache.org/repos/asf?p=ofbiz-plugins.git;h=df753f8

2020-06-28 11:59:36,699 |main |TransactionUtil   |W| Not

committing transaction, status is No Transaction (6)

2020-06-28 11:59:36,699 |main |PaymentGatewayServices    |E| Error

occurred on: firstDataCCAuth, Order ID is: [DEMO10090]

org.apache.ofbiz.service.GenericServiceException: Service

[firstDataCCAuth] target threw an unexpected exception (Illegal

character

in path at

index 0: [TransactionUrl]/payments)

but reverting the commit does not fix it. So maybe another mixed stuff

Jacques

Re: buildbot failure in on ofbizTrunkFramework

[Jacques Le Roux]

It works, I commented out the data loading.

Still the other unrelated failure, looking at it...

Jacques

Le 29/06/2020 à 11:05, Pritam Kute a écrit :

Thanks, Jacques for confirming the same.

IMO, commenting it for now is better option. We should not move it to
applications. Soon or later we are going to move all 3rd party payment
gateway code outside applications may be as a separate 3rd party
integration plugins.

I am working on modifying the plugin further to support token-based
transactions and I will take care of documentation with that work.

Kind Regards,
--
Pritam Kute


On Mon, Jun 29, 2020 at 2:22 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Thanks Pritam,

Trying to comment them out.

If it works, maybe we could move them to
applications/commonext/data/OfbizSetupProductStoreData.xml or simply let
them commented out and documenting it?

Let's see...

Jacques

Le 29/06/2020 à 10:04, Pritam Kute a écrit :

Hello Jacques,

Should we remove the product store association in demo data for the first
data integration? I think it is causing this issue.

Kind Regards,
--
Pritam Kute

On Mon, Jun 29, 2020 at 1:16 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Weird again, running

"ofbiz --test component=accounting --test suitename=accountingtests

--test

case=auto-accounting-transaction-tests-sales"

Maybe a data issue when running integration tests, maybe in both case,

ie

for auto-accounting-transaction-tests-sales and
configurableServiceOrder-test

I continue...

Le 28/06/2020 à 12:52, Jacques Le Roux a écrit :

Actually that was it, had to clean and reload data.

Le 28/06/2020 à 12:25, Jacques Le Roux a écrit :

Le 28/06/2020 à 12:01, Jacques Le Roux a écrit :

There is also an issue with auto-accounting-transaction-tests-sales

I'm chasing

It seems due to

https://gitbox.apache.org/repos/asf?p=ofbiz-plugins.git;h=df753f8

2020-06-28 11:59:36,699 |main |TransactionUtil   |W| Not

committing transaction, status is No Transaction (6)

2020-06-28 11:59:36,699 |main |PaymentGatewayServices|E| Error

occurred on: firstDataCCAuth, Order ID is: [DEMO10090]

org.apache.ofbiz.service.GenericServiceException: Service

[firstDataCCAuth] target threw an unexpected exception (Illegal

character

in path at

index 0: [TransactionUrl]/payments)

but reverting the commit does not fix it. So maybe another mixed stuff

Jacques

Re: buildbot failure in on ofbizTrunkFramework

[Jacques Le Roux]

Thanks Pritam,

Trying to comment them out.

If it works, maybe we could move them to 
applications/commonext/data/OfbizSetupProductStoreData.xml or simply let them 
commented out and documenting it?

Let's see...

Jacques

Le 29/06/2020 à 10:04, Pritam Kute a écrit :

Hello Jacques,

Should we remove the product store association in demo data for the first
data integration? I think it is causing this issue.

Kind Regards,
--
Pritam Kute

On Mon, Jun 29, 2020 at 1:16 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Weird again, running

"ofbiz --test component=accounting --test suitename=accountingtests --test
case=auto-accounting-transaction-tests-sales"

Maybe a data issue when running integration tests, maybe in both case, ie
for auto-accounting-transaction-tests-sales and
configurableServiceOrder-test

I continue...

Le 28/06/2020 à 12:52, Jacques Le Roux a écrit :

Actually that was it, had to clean and reload data.

Le 28/06/2020 à 12:25, Jacques Le Roux a écrit :

Le 28/06/2020 à 12:01, Jacques Le Roux a écrit :

There is also an issue with auto-accounting-transaction-tests-sales

I'm chasing

It seems due to

https://gitbox.apache.org/repos/asf?p=ofbiz-plugins.git;h=df753f8

2020-06-28 11:59:36,699 |main |TransactionUtil   |W| Not

committing transaction, status is No Transaction (6)

2020-06-28 11:59:36,699 |main |PaymentGatewayServices|E| Error

occurred on: firstDataCCAuth, Order ID is: [DEMO10090]

org.apache.ofbiz.service.GenericServiceException: Service

[firstDataCCAuth] target threw an unexpected exception (Illegal character
in path at

index 0: [TransactionUrl]/payments)

but reverting the commit does not fix it. So maybe another mixed stuff

Jacques

Re: buildbot failure in on ofbizTrunkFramework

[Jacques Le Roux]

Weird again, running

"ofbiz --test component=accounting --test suitename=accountingtests --test 
case=auto-accounting-transaction-tests-sales"

Maybe a data issue when running integration tests, maybe in both case, ie for 
auto-accounting-transaction-tests-sales and configurableServiceOrder-test

I continue...

Le 28/06/2020 à 12:52, Jacques Le Roux a écrit :

Actually that was it, had to clean and reload data.

Le 28/06/2020 à 12:25, Jacques Le Roux a écrit :

Le 28/06/2020 à 12:01, Jacques Le Roux a écrit :
There is also an issue with auto-accounting-transaction-tests-sales I'm chasing 


It seems due to 
https://gitbox.apache.org/repos/asf?p=ofbiz-plugins.git;h=df753f8

2020-06-28 11:59:36,699 |main |TransactionUtil   |W| Not committing 
transaction, status is No Transaction (6)
2020-06-28 11:59:36,699 |main |PaymentGatewayServices    |E| Error occurred 
on: firstDataCCAuth, Order ID is: [DEMO10090]
org.apache.ofbiz.service.GenericServiceException: Service [firstDataCCAuth] target threw an unexpected exception (Illegal character in path at 
index 0: [TransactionUrl]/payments)


but reverting the commit does not fix it. So maybe another mixed stuff

Jacques

Re: EntityBatchIterator for large data set queries

[Jacques Le Roux]

Hi,

I have not looked into any details but Chandan's advice sounds like a wise one 
to me

Jacques

Le 27/06/2020 à 13:43, Chandan Khandelwal a écrit :

Hello Pawan,

Approach looks good, my only suggestion is to use batch processing only
when we are dealing with large data set, as this method takes a longer time
compared to the normal method specially on a distributed environment, which
may negatively impact the performance.

Kind Regards,
Chandan Khandelwal
Senior Manager, Enterprise Software Development

*HotWax Systems*
*Enterprise open source experts*
cell: +91-98934-81076
office: 0731-409-3684
http://www.hotwaxsystems.com


On Fri, Jun 5, 2020 at 4:07 PM Pawan Verma 
wrote:


Thanks, Pritam and Scott for the discussion.

I've created Jira OFBIZ-11789 for this improvement and also created a PR
with the proposed changes.

I request everyone to review the PR and suggest your thought on this.
Thanks!
--
Thanks & Regards
Pawan Verma
Technical Consultant
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com


On Mon, Jun 1, 2020 at 12:36 PM Pritam Kute 
Thanks Scott for your detailed explanation.

The solution looks good to me too. My confusion was with why we are going
to implement new method if we can achieve that using the current
EntityQuery methods.

+1 for adding queryBatchIterator() to EntityQuery.

Kind Regards,
--
Pritam Kute


On Thu, May 28, 2020 at 6:32 AM Scott Gray 
Hi Pritam,

I'm not sure about PostgreSQL or Derby but I know with MySQL that

using a

cursor doesn't really work.  You have to set the result set to
TYPE_FORWARD_ONLY and CONCUR_READ_ONLY and also set the fetch size to
INTEGER.MIN_VALUE.  Only then will the driver stream the results and

even

then, you may not execute any other SQL commands on the connection

until

you have fully read or closed the resultset.

So if an EntityListIterator doesn't really conserve memory, then you

need

to take a paging query approach such as this:
EntityQuery query =

EntityQuery.use(delegator).from("SomeTable").limit(100)

List results = null
while (!(results = query.queryList()).isEmpty()) {
  for (value : results) {
   // do something with each value
  }
  query.offset(query.getOffset() + query.getLimit())
}

Or with the proposed EntityBatchIterator:
Iterator query =



EntityQuery.use(delegator).from("SomeTable").limit(100).queryBatchIterator()

while (iterator.hasNext()) {
  result = iterator.next()
  // do something with each value
}

I guess an alternative approach would be to implement something similar
within the EntityListIterator and perhaps a flag to turn it off or on
depending on which database is being used and how well it supports
iterating over results without loading the entire resultset into

memory.

Regards
Scott



On Sat, 23 May 2020 at 20:59, Pritam Kute <

pritam.k...@hotwaxsystems.com

wrote:


Hello Pawan,

I just had a look into the EntityQuery.queryIterator() method and

looks

like we can achieve that by using fetchSize(), fowardOnly(),
cursorScrollInsensitive(), cursorScrollSensitive() and offset()

methods

in

EntityQuery class. Let me know if I am missing anything.

It will be good if you can post a pseudo code or something here so

that

we

could get an understanding of the exact design which you have in your

mind.

Kind Regards,
--
Pritam Kute


On Thu, May 21, 2020 at 7:41 PM Pawan Verma <

pawan.ve...@hotwaxsystems.com

wrote:


Hello Devs,

While working on the large database we have figured out that very

large

queries consume all memory and crash ofbiz(because queryIterator()

doesn't

really work, it's no different from queryList())

The EntityListIterator attempts to use a cursor to iterate over

large

result sets but in reality most databases do not give us a cursor

unless

we

ask for it in a very specific way, and instead you get back the

full

result

set and potentially consume a large amount of memory.  For example,

the

MySql details are here (ResultSet section):



https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-reference-implementation-notes.html

To work around this we've built the EntityBatchIterator which

instead

basically just pages through results like you would do on a webpage

that

uses pagination.  The iterator takes an EntityQuery and when next()

is

called it grabs the first 500 records and returns the first record,

call

next again and you get the second record, once you've called next

500

times

it runs the query again with an offset and grabs the next 500 and

so

on

until there are no more records.

The main downsides to this approach are:
1. Same as when using limit/offset you want to be sure your results

will

come back in a consistent order to avoid accidentally skipping some

rows

and seeing other rows twice.
2. Because the results are a combination of many queries rather

than

a

single query, some of the data may change while you are paging

through

it.

i.e. if you were to sort by lastUpdatedTxStamp you may see some

Re: buildbot failure in on ofbizTrunkFramework

[Jacques Le Roux]

Actually that was it, had to clean and reload data.

Le 28/06/2020 à 12:25, Jacques Le Roux a écrit :

Le 28/06/2020 à 12:01, Jacques Le Roux a écrit :
There is also an issue with auto-accounting-transaction-tests-sales I'm chasing 


It seems due to 
https://gitbox.apache.org/repos/asf?p=ofbiz-plugins.git;h=df753f8

2020-06-28 11:59:36,699 |main |TransactionUtil   |W| Not committing 
transaction, status is No Transaction (6)
2020-06-28 11:59:36,699 |main |PaymentGatewayServices    |E| Error occurred 
on: firstDataCCAuth, Order ID is: [DEMO10090]
org.apache.ofbiz.service.GenericServiceException: Service [firstDataCCAuth] target threw an unexpected exception (Illegal character in path at index 
0: [TransactionUrl]/payments)


but reverting the commit does not fix it. So maybe another mixed stuff

Jacques

Re: buildbot failure in on ofbizTrunkFramework

[Jacques Le Roux]

Le 28/06/2020 à 12:01, Jacques Le Roux a écrit :
There is also an issue with auto-accounting-transaction-tests-sales I'm chasing 


It seems due to 
https://gitbox.apache.org/repos/asf?p=ofbiz-plugins.git;h=df753f8

2020-06-28 11:59:36,699 |main |TransactionUtil   |W| Not committing 
transaction, status is No Transaction (6)
2020-06-28 11:59:36,699 |main |PaymentGatewayServices    |E| Error occurred 
on: firstDataCCAuth, Order ID is: [DEMO10090]
org.apache.ofbiz.service.GenericServiceException: Service [firstDataCCAuth] target threw an unexpected exception (Illegal character in path at index 
0: [TransactionUrl]/payments)


but reverting the commit does not fix it. So maybe another mixed stuff

Jacques

Re: buildbot failure in on ofbizTrunkFramework

[Jacques Le Roux]

Hi,

I try to understand the situation here (framework only) but it's not easy.

Tests also fail in FrameworkPlugins: 
https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins
But there is no information at 
https://ci.apache.org/projects/ofbiz/logs/trunk/plugins/html/ I manually 
launched again, to no avail.

Locally with FrameworkPlugin I get the same than in framework only, ie 
configurableServiceOrder-test fails
But when I locally run the test alone:
"ofbiz -test component=order --test suitename=shoppingcarttests --test 
case=configurableServiceOrder-test"
it succeeds

If I revert 
https://github.com/apache/ofbiz-framework/commit/0f9307c0711fff7b8aef5c795918c21b0b9243d8/
configurableServiceOrder-test passes integration tests. So it's the culprit but 
I can't yet see why.

There is also an issue with auto-accounting-transaction-tests-sales I'm chasing

Jacques

Le 27/06/2020 à 15:16, build...@apache.org a écrit :

The Buildbot has detected a new failure on builder ofbizTrunkFramework while 
building ofbiz-framework. Full details are available at:
 https://ci.apache.org/builders/ofbizTrunkFramework/builds/1645

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

Buildslave for this Build: asf947_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'onTrunkFrameworkCommit' 
triggered this build
Build Source Stamp: [branch trunk] 0f9307c0711fff7b8aef5c795918c21b0b9243d8
Blamelist: Priya Sharma 

BUILD FAILED: failed testIntegration

Sincerely,
  -The Buildbot

Re: Use cache in Type Data lookup

[Jacques Le Roux]

Hi Pawan, All,

Lazy consensus prevails when no answers ;)

Jacques

Le 27/06/2020 à 14:57, Chandan Khandelwal a écrit :

Hi Pawan,

+1 for using cache for type data.

Kind Regards,
Chandan Khandelwal



On Tue, Jun 16, 2020 at 3:52 PM Pawan Verma 
wrote:


Hello Devs,

Greetings for the day!

Using cache while fetching data from Type entity is a good practice as Type
data is permanent in the system. We've already implemented this practice
proficiently in our code base but some lookups failed to do so.

My proposal here is to use a cache for all the Type Data Lookups. If we are
unanimous for this improvement, I'll log a Jira for this.

Please let me know your thoughts on this. Thanks!

--
Thanks & Regards
Pawan Verma
Technical Consultant
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com

Re: [ofbiz-framework] branch trunk updated: Improved: Moves Shipment Services files from sub-dirs to shipment dir (OFBIZ-11468)

[Jacques Le Roux]

Indeed, thanks Pawan

Le 27/06/2020 à 09:36, Pawan Verma a écrit :

Hi Jacques,

You missed correcting the location of these services, I've corrected it at
R#d355269.

Re: [ofbiz-framework] branch trunk updated: Fixed: Updated hard coded values of location types and used all available location enums instead (OFBIZ-6042)

[Jacques Le Roux]

Hi,

The formatting was automatically done, I have to check what changed in my 
Eclipse config. I did not change it myself, weird...

Jacques

Le 25/06/2020 à 11:00, jler...@apache.org a écrit :

This is an automated email from the ASF dual-hosted git repository.

jleroux pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git


The following commit(s) were added to refs/heads/trunk by this push:
  new 2c85c8e  Fixed: Updated hard coded values of location types and used 
all available location enums instead (OFBIZ-6042)
2c85c8e is described below

commit 2c85c8e43b63b0522f69b7078eec48f3e50824d5
Author: Jacques Le Roux 
AuthorDate: Thu Jun 25 11:00:31 2020 +0200

 Fixed: Updated hard coded values of location types and used all available 
location enums instead (OFBIZ-6042)
 
 Fixes a typo

---
  .../product/inventory/InventoryServices.xml| 78 +++---
  1 file changed, 39 insertions(+), 39 deletions(-)

diff --git 
a/applications/product/minilang/product/inventory/InventoryServices.xml 
b/applications/product/minilang/product/inventory/InventoryServices.xml
index 8805fc9..2f1ad23 100644
--- a/applications/product/minilang/product/inventory/InventoryServices.xml
+++ b/applications/product/minilang/product/inventory/InventoryServices.xml
@@ -302,7 +302,7 @@ under the License.
  
  
  
-   
+
  

  
@@ -1080,7 +1080,7 @@ under the License.
  
  
  
-
+
  
  
  
@@ -1093,43 +1093,43 @@ under the License.
  
  
  
-   
-   
-   
-   
-   
-   
-  
-   
-  
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-  
-   
-   
-   
-   
-   
+
+
+
+
+
+
+   
+
+   
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+   
+
+
+
+
+