Re: (ofbiz-tools) branch master updated: Replaces 22.01 branch by 24.09 as stable

[Jacques Le Roux]

Thanks for the cleaning Daniel.

Le 12/09/2024 à 12:24, Daniel Watford a écrit :

Hi Jacques,

I have just checked on the ofbiz-vm1 host and can see that you have already
updated the demo-next container to use container images from the 24.09
branch - thank you. Everything looks correct to me.

I've removed the old demo-next log files.

Thanks,

Dan.

On Wed, 11 Sept 2024 at 17:42, Jacques Le Roux 
wrote:


Thanks to check Nicolas,

With Docker, Dan has much simplified things. The BB script is also now
easy to change*.
If we did not miss anything, things happens as we know, as long as the fan
is not on that should OK :)

Jacques

*
https://svn.apache.org/repos/infra/infrastructure/buildbot2/projects/ofbiz.py

Le 11/09/2024 à 18:03, Nicolas Malin a écrit :

Thanks Jacques !

I currently check the different change to do on CI , because I follow

your and Dan works so far :(

Nicolas

Le 11/09/2024 à 17:07, jler...@apache.org a écrit :

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

jleroux pushed a commit to branch master
in repositoryhttps://gitbox.apache.org/repos/asf/ofbiz-tools.git


The following commit(s) were added to refs/heads/master by this push:
   new 2d66d54  Replaces 22.01 branch by 24.09 as stable
2d66d54 is described below

commit 2d66d54ebb3f0b4eb922e9278b2c91422bdc81ce
Author: Jacques Le Roux
AuthorDate: Wed Sep 11 17:07:51 2024 +0200

  Replaces 22.01 branch by 24.09 as stable
---
demo-backup/ofbizdocker/home/ofbizdocker/demo-next/docker-compose.yml |

2 +-

   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git

a/demo-backup/ofbizdocker/home/ofbizdocker/demo-next/docker-compose.yml

b/demo-backup/ofbizdocker/home/ofbizdocker/demo-next/docker-compose.yml
index b5f2240..7cf5651 100644
---

a/demo-backup/ofbizdocker/home/ofbizdocker/demo-next/docker-compose.yml

+++

b/demo-backup/ofbizdocker/home/ofbizdocker/demo-next/docker-compose.yml

@@ -14,7 +14,7 @@ services:
 - ofbiz-postgres.env
   ofbiz:
-image: ghcr.io/apache/ofbiz:release22.01-plugins-snapshot
+image: ghcr.io/apache/ofbiz:release24.09-plugins-snapshot
   mem_limit: 2400M
   memswap_limit: 2400M
   cpu_shares: 200

Re: Unit testing for a custom module

[Jacques Le Roux]

Hi Carsten,

I guess you found some explanations in "sourceSets{" ?

HTH

Jacques

Le 11/09/2024 à 10:32, Carsten Schinzer a écrit :

A little update here:

This morning I found that when I place the integration tests in the main source 
tree they will not be executed in the JUnit run AND will be found by the 
testIntegration command.

So the (my?) misconception was to place the integration tests in the test 
source tree.
So for some code level separation of test vs main code, I shall convert the 
integration tests to Groovy alike many applications do as well.

Have a great day


Carsten
  


Am 10.09.2024 um 23:08 schrieb Carsten Schinzer:

Hello again,


Digging a bit deeper I find that the integration test config throws a 
java.lang.ClassNotFoundException for the four test classes I have implemented 
when I run

./gradlew "ofbiz --test component=cdc-tickets --test loglevel=info".

Disturbingly the compiler and the unit test framework find them, but for the 
above command they appear missing on the class path. I can only conclude 
something might be wrong with my test configuration XML.

Here it is:

http://www.w3.org/2001/XMLSchema-instance";
 
xsi:noNamespaceSchemaLocation="https://ofbiz.apache.org/dtds/test-suite.xsd";>
 
 
 
 
 
 
 
 

The alternative (ungrouped) also does fail with the same exception:

http://www.w3.org/2001/XMLSchema-instance";
 
xsi:noNamespaceSchemaLocation="https://ofbiz.apache.org/dtds/test-suite.xsd";>
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

As said, any guidance to crack this issue is welcome.

Warm regards


Carsten


Am 10.09.2024 um 10:47 schrieb Carsten Schinzer:

Hello all,


Me again. I forgot to mention here that actually now I do execute the Unit 
Tests, but also three integration test classes are executed as part of the 
JUnit run.

All three are extensions to org.apache.ofbiz.service.testtools.OFBizTestCase 
and to not define any Unit @Test annotation on the class methods. Yet they are 
recognized and executed … and fail of course since the data load has not 
occurred.

Any advice you might have is much appreciated.
Warm regards


Carsten


Am 10.09.2024 um 10:36 schrieb Carsten Schinzer:

Hello all,


Thanks to the help of Gaetan, we have been Abel to spot the issue:


I had attempted to install and run JUnit5 testing in my component only which 
obviously does not work as JUnit5 Test annotation would not be recognized by 
the Gradle build tool.

Therefore, in order to resolve this, I had to rework all Unit tests to comply 
with JUnit4 which - since I had quite a number of parameterized tests - was 
quite an effort.

In order to move on to more recent test concepts, namely parameterized testing 
but also improved test architecture with a better separation of asserts into a 
package instead of a class which enables custom asserts I have logged a relate 
feature request here:https://issues.apache.org/jira/browse/OFBIZ-13138.
I am happy to contribute to this myself, yet with this issue I have also 
learned that I do not fully understand the gradle build setup for OfBiz and 
would need quite some guidance.

So if anyone would like to pull on this with me - please let me know!

Thanks again to Gaetan, this current project is now moving forward again!

Warm regards


Carsten



Am 21.06.2024 um 11:17 schrieb Carsten Schinzer:

Hi Gaetan,

Thanks to get back to me. I see no change - all the things you applied I 
already did.
I also added your test case to the code and ran that locally - the test is 
obviously not found.

It might have to do with the fact that I prefer JUnit 5 because of its advanced 
parametrized testing features?
I can give you access to the code repo if you have a Gitlab account.

When running tests locally, I do not see any test reports for my classes, so 
this is the indicator I am using.
Also, I have test cases that should fail with the current code state.

So situation is unchanged unfortunately.
Warm regards


Carsten


Am 20.06.2024 um 16:58 schrieb Gaetan:

Hi Carsten, do you have any updates on your case ?

Regards,

Gaetan

On 6/11/24 09:58, Gaetan wrote:

Hello Carsten.

I set up a very small example plugin that i tested myself localy. Could you 
please reproduce the steps below ?

- get ofbiz framework from apache repo 
(https://github.com/apache/ofbiz-framework)

   - checkout trunk on ofbiz framework

- get example plugin and set it up inside plugins 
(https://github.com/gtchaboussie/ofbiz-demo-test-plugin)

at the ofbiz root location, run `./gradlew test`. The build should fail (this 
means the test in the plugin is runned) with this error:

```

org.test.TestClass > test FAILED
java.lang.AssertionError at TestClass.java:9

```

This gives you a template or example of a unit test.

As you can see, you should not have to update anything on the base framework 
for your tests 

Re: (ofbiz-tools) branch master updated: Replaces 22.01 branch by 24.09 as stable

[Jacques Le Roux]

Thanks to check Nicolas,

With Docker, Dan has much simplified things. The BB script is also now easy to 
change*.
If we did not miss anything, things happens as we know, as long as the fan is 
not on that should OK :)

Jacques

* https://svn.apache.org/repos/infra/infrastructure/buildbot2/projects/ofbiz.py

Le 11/09/2024 à 18:03, Nicolas Malin a écrit :

Thanks Jacques !

I currently check the different change to do on CI , because I follow your and 
Dan works so far :(

Nicolas

Le 11/09/2024 à 17:07, jler...@apache.org a écrit :

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

jleroux pushed a commit to branch master
in repositoryhttps://gitbox.apache.org/repos/asf/ofbiz-tools.git


The following commit(s) were added to refs/heads/master by this push:
  new 2d66d54  Replaces 22.01 branch by 24.09 as stable
2d66d54 is described below

commit 2d66d54ebb3f0b4eb922e9278b2c91422bdc81ce
Author: Jacques Le Roux
AuthorDate: Wed Sep 11 17:07:51 2024 +0200

 Replaces 22.01 branch by 24.09 as stable
---
demo-backup/ofbizdocker/home/ofbizdocker/demo-next/docker-compose.yml | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/demo-backup/ofbizdocker/home/ofbizdocker/demo-next/docker-compose.yml 
b/demo-backup/ofbizdocker/home/ofbizdocker/demo-next/docker-compose.yml

index b5f2240..7cf5651 100644
--- a/demo-backup/ofbizdocker/home/ofbizdocker/demo-next/docker-compose.yml
+++ b/demo-backup/ofbizdocker/home/ofbizdocker/demo-next/docker-compose.yml
@@ -14,7 +14,7 @@ services:
    - ofbiz-postgres.env
      ofbiz:
-    image: ghcr.io/apache/ofbiz:release22.01-plugins-snapshot
+    image: ghcr.io/apache/ofbiz:release24.09-plugins-snapshot
  mem_limit: 2400M
  memswap_limit: 2400M
  cpu_shares: 200

Re: Dependency configuration types in Gradle for components - testCompileOnly or testRuntimeOnly

[Jacques Le Roux]

Hi Carsten,

Yes, that's it

Jacques

Le 11/09/2024 à 09:39, Carsten Schinzer a écrit :

Thank you Jacques,


With a text search for „pluginLibs“ in the OFBiz project I cam across there 
options for dependencies in that context:

pluginLibsCompile
pluginLibsCompileOnly
pluginLibsRuntime

So that seem to the dependency config types that are recognized for plugins in 
OFBiz, right?

Thanks again & warm regards


Carsten


Am 11.09.2024 um 08:36 schrieb Jacques Le Roux :

Hi Carsten,

Did you have a look at 
https://www.google.fr/search?q=gradle+testCompile&ie=UTF-8 ?

Elese, "testRuntime is deprecated since many years and removed since Gradle 7" 
: https://discuss.gradle.org/t/documentation-of-dependency-configuration-testruntime/46219

HTH

Jacques

Le 10/09/2024 à 10:41, Carsten Schinzer a écrit :

Hello all,


In my custom OFBiz component I would like to declare dependencies for 
testCompile or testRuntime only as foreseen in generic Gradle, yet I face 
issues when using these configuration types in the build.gradle - the OFBiz 
Gradle build is not aware of these types and breaks.

Does the framework allow for these dependencies at all? If so, what are 
foreseen types?

Thanks for any advice in advance.
Warm regards


Carsten

Re: Dependency configuration types in Gradle for components - testCompileOnly or testRuntimeOnly

[Jacques Le Roux]

Hi Carsten,

Did you have a look at 
https://www.google.fr/search?q=gradle+testCompile&ie=UTF-8 ?

Elese, "testRuntime is deprecated since many years and removed since Gradle 7" : 
https://discuss.gradle.org/t/documentation-of-dependency-configuration-testruntime/46219


HTH

Jacques

Le 10/09/2024 à 10:41, Carsten Schinzer a écrit :

Hello all,


In my custom OFBiz component I would like to declare dependencies for 
testCompile or testRuntime only as foreseen in generic Gradle, yet I face 
issues when using these configuration types in the build.gradle - the OFBiz 
Gradle build is not aware of these types and breaks.

Does the framework allow for these dependencies at all? If so, what are 
foreseen types?

Thanks for any advice in advance.
Warm regards


Carsten

Re: Bug when uploading image to a product

[Jacques Le Roux]

Le 09/09/2024 à 18:59, Jacques Le Roux a écrit :
i wonder why even admin lack some permission, 


It's because webshell uploads are devastating. They easily lead to RCE.
If for some reason we face a post-authN attack, we can't trust any 
authentication.
And SecuredUpload is already enough complex.

Also remember that admin is a demo data and those should never be used in 
production

Re: refused

[Jacques Le Roux]

Thanks Sebb,

Indeed I was looking for the complete warning, ie

'https://ofbiz.apache.org,http://ofbiz.apache.org/pmc/ofbiz.rdf'

I did not see that we had already one (right) other asfext:pmc lower:
http://ofbiz.apache.org/pmc/ofbiz.rdf"; />

I just have to remove the commented out one.

This said, despite picking the OFBiz project in the "DOAP Creation" dropdown 
the generated file was containing

https://ofbiz.apache.org"; /> instead of http://ofbiz.apache.org/pmc/ofbiz.rdf"; />

Is that normal, is it our task to replace by the right URL? I did not find any 
advice about that.

TIA

Jacques


Le 09/09/2024 à 16:16, sebb a écrit :

On Mon, 9 Sept 2024 at 11:36, Jacques Le Roux
  wrote:

Hi,

After creating a new file usinghttps://projects.apache.org/create.html  (DOAP 
Creation),
I merged the changes got in to update our previous doap_OFBiz.rdf
(https://github.com/apache/ofbiz-site/blob/master/doap_OFBiz.rdf)

I add to comment this new merged line (generated by "DOAP Creation")

 

because we received this message

 WARN: invalid asfext:pmc 
'https://ofbiz.apache.org,http://ofbiz.apache.org/pmc/ofbiz.rdf' 
inhttps://ofbiz.apache.org/doap_OFBiz.rdf  (URL can't contain control 
characters. 'ofbiz.apache.org, http' (found at least ' '))

I tried to understand the reason but could not. What I'm missing?

It says that the value for asfext:pmc is
'https://ofbiz.apache.org,http://ofbiz.apache.org/pmc/ofbiz.rdf' which
it found in the filehttps://ofbiz.apache.org/doap_OFBiz.rdf

The value must either be the project id (ofbiz) or the URL of a the
PMC RDF for the project; it must not be a list of URLs.


Is it a relation 
withhttps://github.com/apache/ofbiz-site/blob/master/pmc/ofbiz.rdf  ?

The error message does not mention that file.


I noticed that there the indentation for  is not 
quite right.

TIA

Jacques

Re: Bug when uploading image to a product

[Jacques Le Roux]

Hi Yang, Groza,

Yang,

Forgot that, about
i wonder why even admin lack some permission, 


It's because webshell uploads are devastating. They easily lead to RCE.
If for some reason we face a post-authN attack, we can't trust any 
authentication.
And SecuredUpload is already enough complex.


and the transaction rollback cannot recover.

SecuredUpload is used in many parts.
If an anomaly appears processes stop in different manners, could be improved.


Le 09/09/2024 à 12:27, Groza Danut a écrit :

Hi Yang,

I also got that error when trying to upload the image using the "Add
Additional Images" screen in Catalog -> Products -> (Select a product) ->
Content.
When using the "Upload Image" in the bottom part of "Override Simple
Fields" screen. Not sure why we get this.


See just below


  Hi Jacques,

Option 1
Is not going to work because checkMaxLinesLength throw an
exception(java.nio.charset.MalformedInputException: Input length = 1) at
line:
-  List lines = FileUtils.readLines(file, Charset.defaultCharset());

So it never gets to check the line length.


The error we get is

java.nio.charset.UnmappableCharacterException: Input length = 1
    at 
java.base/java.nio.charset.CoderResult.throwException(CoderResult.java:275)
    at java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
    at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:188)
    at java.base/java.io.InputStreamReader.read(InputStreamReader.java:177)
    at java.base/java.io.BufferedReader.fill(BufferedReader.java:162)
    at java.base/java.io.BufferedReader.readLine(BufferedReader.java:329)
    at java.base/java.io.BufferedReader.readLine(BufferedReader.java:396)
    at java.base/java.nio.file.Files.readAllLines(Files.java:3415)
    at org.apache.commons.io.FileUtils.readLines(FileUtils.java:2665)
    at 
org.apache.ofbiz.security.SecuredUpload.checkMaxLinesLength(SecuredUpload.java:855)
    at 
org.apache.ofbiz.security.SecuredUpload.isValidFile(SecuredUpload.java:254)

Using Charset.defaultCharset (or null, which is the same, ie OS dependent) when 
reading with

FileUtils.readLines(file,Charset.defaultCharset());

is a problem. The file may have been created using another Charset. I remember having searched bout that. But even 
http://illegalargumentexception.blogspot.com/2009/05/java-rough-guide-to-character-encoding.html#javaencoding_autodetect is not a 100% solution. So 
even for text files it can be a problem and according to above there is no complete solution.



Option 2
This should work. I'll attach the fix to the issue you mentioned.
Unfortunately ATM I don't have time to
further investigate this issue, but I will leave a comment to the issue
with the findings so far.


As you certainly know image files are also text files. That's why I did not dig further than isValidImageFile() so far. Anyway I tend to agree that 
it's improbable (but possible) that a trick using a very long line would be used in an image file.



Also, quite important. When looking at the code, I could not create a unit
test for this case, because
SecuredUpload uses private static methods where it interacts with files,
thus to create an isolated
unit test for this case there are only 2 options:

1. Upload a file image in the test resources folder, that will be used in
this test.
Not really optimal, since the codebase will grow really large really fast,
if we put a lot of test resources inside.

2. Mock methods that we don't care about in this test case.
Since the methods are static, and private, we cannot mock them using
Mockito(already added as a test dependency).
The only option here to mock them would be to add PowerMockito as a test
dependency and use that.

I believe going forward we should either consider adding PowerMockito as a
test tool, or consider writing more
testable code, as I think having the ability to write easy and fast unit
tests are a must in order to maintain code stability,
and prevent introducing bugs with changes.


I totally agree,  just not a priority for me at the moment (and I guess in the 
futur).
Feel free to work on it with the suggestions you made which seem great.

I have seen, and tested a bit (with some "attacking" images), your PR834. It 
sounds OK with me.
Before pushing I'll though see if we can't handle the "All" case using 
isValidImageIncludingSvgFile()

Thanks

Jacques




On Sun, Sep 8, 2024 at 9:00 PM Jacques Le Roux
wrote:


BTW, there is already a Jira for that:
https://issues.apache.org/jira/browse/OFBIZ-12639

Any help is welcome :)

Le 08/09/2024 à 17:03, Jacques Le Roux a écrit :

Hi Groza,

After facing several webshell uploads I made SecuredUpload.java as

secure as possible OOTB.

I see 2 options here:

  * Increase maxLineLength in security.properties (could be unsecure, but

not that bad)

  * Improve SecuredUpload by having a special 

Re: want to be apache contributor

[Jacques Le Roux]

Hi Lucille,

It's done

Have a good day

Jacques

Le 05/09/2024 à 11:27, Jacques Le Roux a écrit :

Hi Lucille,

We are sorry for your loss, I'll take care of that.

Jacques

Le 04/09/2024 à 21:25, Sales Vibralung a écrit :

Hi all,
My late husband was a Linux wiz.  How can I get his email address removed from 
the database or group?
Arthur (Art) Hughes
a...@vibralung.com

Any assistance would be appreciated.

Best,
Lucille Hughes

On Wed, Sep 4, 2024 at 12:37 PM Craig Russell  wrote:

    Hi Jacques,

    As you know, PMCs are free to create their own policies on such things as 
ICLA filings and suggested logins to resources.

    There are several things that need to be corrected on that page. I can 
review your changes if you like...

    Warm regards,
    Craig

    > On Sep 3, 2024, at 23:34, Jacques Le Roux  
wrote:
    >
    > Thanks Craig,
    >
    > This page was written before the GitHub "era". I think we should rewrite 
it a bit in accordance with what you said.Jacques
    >
    > Le 04/09/2024 à 06:37, Craig Russell a écrit :
    >> Hi Yang,
    >>
    >>> On Sep 3, 2024, at 16:45, 雷咩咩 <675686...@qq.com 
<mailto:675686...@qq.com>> wrote:
    >>>
    >>> hi Craig,
    >>>
    >>> The ofbiz contributor page shows me at the bottom.
    >>> 
https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Contributors
<https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Contributors>
    >>> My initial request was the apache ofbiz jira and confluence 
accounts(now already have thanks to @Jacques).
    >>> I'm newbie to ofbiz(also to apache) and I'm excited to enrolled to an 
open source project for the first time.
    >>
    >> Welcome. It sounds like you are already in a good place.
    >>>
    >>> For now I'm not capable of contributing code yet, but I think I can 
sometimes come across bugs, incomplete documents, and report them.
    >>
    >> You should be able to report issues and make suggestions for 
improvement, even if it does not involve code.
    >>
    >>> So the ICLA is not urgent now.
    >>
    >> The project will let you know when an ICLA is recommended. Usually it 
would be for significant contributions.
    >>
    >>> Regarding the imcomplete address:
    >>> My city is not well known, let alone the district, street, door number. 
And even less if translated to English. I can send another file
    input with more detailed address, if necessary.
    >> Yes, if you need to send an ICLA a complete residence address is needed.
    >>> Does more detailed address make sense for the foundation, or other 
members? Will anyone expects to meet me offline, or mail some real papar
    material? (the form should ask for phone number in this case but didn't).
    >> The residence address is one of the few things that we can ask for to 
demonstrate you are not a robot but a real person. We don't ask you to
    find all of the bicycles in a picture but we do want to have on file some 
evidence of your being a real person. I hope you can understand.
    >>
    >> Warm regards,
    >> Craig
    >>
    >>>
    >>>
    >>> Regards,
    >>> Yang
    >>>
    >>>
    >>> Original Email
    >>>
    >>> From:"Craig Russell"< apache@gmail.com <mailto:apache@gmail.com> 
>;
    >>>
    >>> Sent Time:2024/9/4 5:29
    >>>
    >>> To:"Jacques Le Roux"< jacques.le.r...@les7arts.com 
<mailto:jacques.le.r...@les7arts.com> >;
    >>>
    >>> Cc recipient:"雷咩咩"< 675686...@qq.com <mailto:675686...@qq.com> >;
    >>>
    >>> Subject:Re: want to be apache contributor
    >>>
    >>>
    >>> Hi Jacques,
    >>>
    >>> The ICLA was not filed. The address is incomplete.
    >>>
    >>> But what is the expected end result here? Has lei yang been voted as a 
committer? If not, the ICLA is not needed.
    >>>
    >>> Warm regards,
    >>> Craig
    >>>
    >>>
    >>>> On Sep 3, 2024, at 02:52, Jacques Le Roux mailto:jacques.le.r...@les7arts.com>> wrote:
    >>>>
    >>>> Hi Craig,
    >>>>
    >>>> Sorry to bother you.
    >>>>
    >>>> I can't confirm that Yang's ICLA request has been registered using 
https://whimsy.apache.org/officers/unlistedclas.cgi
    <https://whimsy.apache.org/officers/unlistedclas.cgi>
    >>>> I guess because on his request he exactl

Re: Bug when uploading image to a product

[Jacques Le Roux]

BTW, there is already a Jira for that: 
https://issues.apache.org/jira/browse/OFBIZ-12639

Any help is welcome :)

Le 08/09/2024 à 17:03, Jacques Le Roux a écrit :

Hi Groza,

After facing several webshell uploads I made SecuredUpload.java as secure as 
possible OOTB.

I see 2 options here:

 * Increase maxLineLength in security.properties (could be unsecure, but not 
that bad)
 * Improve SecuredUpload by having a special treatment for Images at line 209

HTH

Jacques

Le 07/09/2024 à 12:52, Groza Danut a écrit :

Hi,

Have you tried to add an image to a product? I get an error message saying
type unsupported for security reasons, even if the file type is .jpeg.

When debugging I found that ProductServices.addAdditionalViewForProduct is
called.
At line 1083: org.apache.ofbiz.security.SecuredUpload.isValidFile is called

Inside SecuredUpload line 254: checkMaxLinesLength throws an error, since
this is a jpeg file.

As far as I see it, isValidFile should not checkMaxLinesLength if
the fileType is IMAGE.

Re: [VOTE] [BRANCH] Create next stable Apache OFBiz branch : release24.09

[Jacques Le Roux]

+1

Jacques

Le 08/09/2024 à 18:01, Jacopo Cappellato a écrit :

+1

Jacopo

On Fri, Sep 6, 2024 at 2:28 PM Nicolas Malin  wrote:

This is the vote thread to create the next stable branch "release24.09" from 
the current trunk

If you need more information, please refer to this thread [1]

Vote:
[ +1] create the next stable branch "release24.09"
[ -+0] feel free
[ -1] do not create the branch

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

--

[1] https://lists.apache.org/thread/k903dobd1z0hm9qxo3prn8gzc71jrnx1

Re: Bug when uploading image to a product

[Jacques Le Roux]

Hi Groza,

After facing several webshell uploads I made SecuredUpload.java as secure as 
possible OOTB.

I see 2 options here:

 * Increase maxLineLength in security.properties (could be unsecure, but not 
that bad)
 * Improve SecuredUpload by having a special treatment for Images at line 209

HTH

Jacques

Le 07/09/2024 à 12:52, Groza Danut a écrit :

Hi,

Have you tried to add an image to a product? I get an error message saying
type unsupported for security reasons, even if the file type is .jpeg.

When debugging I found that ProductServices.addAdditionalViewForProduct is
called.
At line 1083: org.apache.ofbiz.security.SecuredUpload.isValidFile is called

Inside SecuredUpload line 254: checkMaxLinesLength throws an error, since
this is a jpeg file.

As far as I see it, isValidFile should not checkMaxLinesLength if
the fileType is IMAGE.

Re: 回复：Re: 回复：URL Issue

[Jacques Le Roux]

Hi,

It works well in trunk but not in 18.12 with the same configuration (at least 
Servlet and Tomcat versions). Not sure why yet.

At 
https://sites.google.com/site/javatechnologyworld/remove-jsessionid-from-url-java
 there is this interesting information, notably last line:

   <<*Why is jsessionid appended to some URLs even after cookies are enabled?
   *If the cookies are disabled on the browser or cookies are absent, and URL 
is being encoded, jsessionid will be appended to the URL
   Note that even when cookies are enabled, if URLs are being encoded, java 
application appends jsessionid to all the URLs for the first request.
   This happens because when the first request is sent, the server doesn’t know if 
cookies are enabled on the browser.>>

I did not see a such thing. But clearly when logging out the issue arises if you have cleared the cookies before, at start (before signing in) or 
during the session. That no longer happens in trunk for both cases.


Please test, TIA

Jacques

Le 07/09/2024 à 18:01, Jacques Le Roux a écrit :

Hi,

Thanks All for your help. Here is the origin and the fix of this issue.

The official documentation about @WebListener is sparse and confusing.
I initially relied on 
https://docs.oracle.com/javaee/7/api/javax/servlet/annotation/WebListener.html 
when @WebListener appeared

So I was no aware that for this to work you need also to put the resulting 
class in something like
framework\webtools\webapp\webtools\WEB-INF\classes\org\apache\ofbiz\webapp\control\WebAppServletContextListener.class
Thanks to 
https://stackoverflow.com/questions/18367514/servletcontextlistener-not-being-invoked

Moreover soon that would need to be changed with Jakarta
https://tomcat.apache.org/tomcat-10.0-doc/servletapi/jakarta/servlet/ServletContext.html
A task we will need to do anyway, OFBIZ-12989 is part of it

To fix the issue, it's much more simple to set
COOKIE
in catalina/config/web.xml

Then WebAppServletContextListener class can be safely removed.
Apart setting a comment which is not quite useful, all what was done by WebAppServletContextListener class is also done in LoginWorker by 
autoLoginSet when called by doMainLogin.


I have created https://issues.apache.org/jira/browse/OFBIZ-13136 for that and 
will push now

Jacques


Le 06/09/2024 à 14:50, Jacques Le Roux a écrit :

Thanks Groza,

I have an idea about that, I'll check it does not introduce a regression


Le 06/09/2024 à 11:29, Groza Danut a écrit :

Yes it is, the line at 168 removes the char: .replaceAll(";", "")

That is from the commit 11986593b668661d748789154a6052ef4e1ab1c6 Improved:
Prevent special encoded characters sequences in URLs (OFBIZ-13092)

On Fri, Sep 6, 2024 at 11:16 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Thanks Groza,

I'll check why we get this URI:

/facility/control/logoutjsessionid=47426E5B6F9A20CD2134E70F4DE525DF.jvm1

Looks like something ahead is removing the ";". Could be related to a
recent security change.

Jacques

Le 05/09/2024 à 11:08, Groza Danut a écrit :

I am able to consistently reproduce the error using the above steps
mentioned by Yang, with one addition: make sure you clear the cookies

each

time before starting. The error is thrown after you click logout.

Debugging in LoginWorker.logout at the following line:
RequestHandler rh = RequestHandler.getRequestHandler(request
.getSession().getServletContext());

I can see that for the servlet context the values are:
sessionTrackingModes null
supportedSessionTrackingModes [COOKIE, URL, SSL]

Also, the program never stops for my breakpoint at the first line in
WebAppServletContextListener.contextInitialized
Are you sure this listener is registered?

Indeed the problem is caused by this line in the ControlFilter: if (!
initialURI.equals(uRIFiltered))
Because the 2 uris are different:
/facility/control/logout;jsessionid=47426E5B6F9A20CD2134E70F4DE525DF.jvm1
/facility/control/logoutjsessionid=47426E5B6F9A20CD2134E70F4DE525DF.jvm1

Can we not provide a fix in here for this jsessionid case?

On Thu, Sep 5, 2024 at 5:38 AM 雷咩咩 <675686...@qq.com.invalid> wrote:


now i get a lot of errors for a lot of pages





https://demo-trunk.ofbiz.apache.org/content/control/main?externalLoginKey=EL2e3c96f3-bd6f-4609-a954-bd795856f143

Internal Server Error
The server encountered an internal error or misconfiguration and was
unable to complete your request.


Please contact the server administrator at dev@ofbiz.apache.org to

inform

them of the time this error occurred, and the actions you performed just
before this error.


More information about this error may be available in the server error

log.








原始邮件



发件人："雷咩咩"< 675686...@qq.com >;

发件时间：2024/9/5 7:54

收件人："ofbiz user"< u...@ofbiz.apache.org >;"dev"<

dev@ofbiz.apache.org

>;

主题：回复：Re: 回复：URL Issue


I found one stable steps to reproduce this issue in 

Re: Consultation for new plugin

[Jacques Le Roux]

Hi Groza,

You need a Confluence write access. Have you created a Confluence account? If 
you did, what is your Confluence username?

HTH

Jacques

Le 07/09/2024 à 19:05, Groza Danut a écrit :

I propose we move the requirement planning and architectural design draft
in a new temporary page on Confluence.

I'm not very familiar with Confluence. Do I need approval to create a new
page, or do I just need to sign up for a contributor account on Confluence
and fill an ICLA?
Groza Danut

On Sat, 31 Aug 2024, 15:22 Omar Abdullwahhab, 
wrote:


Hi Groza,
That is really fantastic  let me review that and understand it well,
And will get back to you, as soon as possible.
Regards

On Sat, Aug 31, 2024 at 10:27 AM Groza Danut 
wrote:


Tech stack proposals:

1. Data mapping
The proposal is to use AtlasMap for this. See
https://dzone.com/articles/implementing-low-code-data-mapping-in-java
This would allow us to have dynamic data mappings at runtime based on
different countries, suppliers etc...

2. Authorization
2.1 OAuth2
Passport plugin provides authentication using OAuth2 credentials(Github,
linkedin etc..) to the web stores. The implemented flow currently is only
Authorization Code Flow. We could use code from here, but I still have a
problem writing code for functionality that is standardized, instead of
using a library for it, especially for security libraries. My proposal is
to use a ready made library for this, for example this one:
https://github.com/dmfs/oauth2-essentials or this one:
https://github.com/scribejava/scribejava and only write the integration
code specific to Ofbiz(here we can use the passport plugin as a

reference).

2.2 x509 certificates
Didn't research much on this topic, but as I see there is some
functionality for certificates implemented in Ofbiz already, so maybe

this

one can be used.

3. Workflow
I think the best choice here is Apache Camel. We could then have a
different route for each country, or even reuse parts of routes between
countries, if they are the same.

The overall picture

1. Entity layer
- configurations
- reporting statuses
- Invoice xml(for example save received Invoice xml for archiving

purposes)

2. Service layer
Have a standard set of apis for the base operations:
- upload invoice(report invoice)
- check status(for reported invoices)
- check received messages(for new received invoices)
- download invoice(for received invoices)
- reject invoice(for received invoices)

This would be the layer that the clients of the plugin will interact

with.

They will use these apis for reporting purposes.

3. Workflow layer
This is the core part of the reporting engine. This layer would do the
following:
- route the api call to the correct implementation based on different
criteria: configurations, invoice recipient, country etc...
- perform required data mappings
- perform required authorization steps

Basically administrators would use the workflow layer to perform the
required setup for each country, and then the sales representatives or
other low level employees would use the service layer for actual invoice
reporting.


On Sat, Aug 31, 2024 at 9:27 AM Groza Danut 
wrote:


Hi Omar,

Thank you for your feedback. The eInvoicing for Romania has a different
workflow:
A. Boarding stage: ANAF uses OAuth to generate a token so the flow is:
1. Ofbiz sends a request to ANAF authorization server using OAuth2
Authorization Code Flow
2. The user is redirected to the ANAF login page, where he needs to
present his digital signature(yes, each end user need his own digital
signature)
3. Upon successful authentication Ofbiz gets a JWT access and refresh
token from ANAF.

B. Reporting stage.
1. Ofbiz converts the Invoice to the accepted format(UBL, CN, CII sau

RASP)

2. Ofbiz sends the Invoice xml to the upload api using the JWT access
token for authentication. Note: there are 2 upload apis: one is the

testing

environment, and one is the production environment, but you still need
valid credentials for testing.
3. Ofbiz sends a request to the ANAF status api and gets the response
whether the Invoice was accepted, or rejected and the reason for

rejection.

Upon fixing the rejection issue, we need to resend the invoice.

Based on these 2 cases, I think Ofbiz should have the following
requirements:
1. Configurable Invoice data mapping for each country(and even

different

data mapping within the same country, for instance different data

mappings

for different suppliers)
2. Configurable workflow for each registry. I think this would be the

hard

part. Since one country might use Oauth and JWT tokens, another uses

X509

for signing Invoices, so each has a different workflow.
3. Status tracking, so we know if the Invoice was already reported, if

it

was accepted or rejected after reporting. We already have Invoice

statuses

in Ofbiz, we could use those.

On Fri, Aug 30, 2024 at 10:57 PM Omar Abdullwahhab <
omar.abdullwah...@gmail.com> wrote:


You are welcome Groza
first ZATCA uses x509 c

Re: 回复：Re: 回复：URL Issue

[Jacques Le Roux]

Hi,

Thanks All for your help. Here is the origin and the fix of this issue.

The official documentation about @WebListener is sparse and confusing.
I initially relied on 
https://docs.oracle.com/javaee/7/api/javax/servlet/annotation/WebListener.html 
when @WebListener appeared

So I was no aware that for this to work you need also to put the resulting 
class in something like
framework\webtools\webapp\webtools\WEB-INF\classes\org\apache\ofbiz\webapp\control\WebAppServletContextListener.class
Thanks to 
https://stackoverflow.com/questions/18367514/servletcontextlistener-not-being-invoked

Moreover soon that would need to be changed with Jakarta
https://tomcat.apache.org/tomcat-10.0-doc/servletapi/jakarta/servlet/ServletContext.html
A task we will need to do anyway, OFBIZ-12989 is part of it

To fix the issue, it's much more simple to set
COOKIE
in catalina/config/web.xml

Then WebAppServletContextListener class can be safely removed.
Apart setting a comment which is not quite useful, all what was done by WebAppServletContextListener class is also done in LoginWorker by autoLoginSet 
when called by doMainLogin.


I have created https://issues.apache.org/jira/browse/OFBIZ-13136 for that and 
will push now

Jacques


Le 06/09/2024 à 14:50, Jacques Le Roux a écrit :

Thanks Groza,

I have an idea about that, I'll check it does not introduce a regression


Le 06/09/2024 à 11:29, Groza Danut a écrit :

Yes it is, the line at 168 removes the char: .replaceAll(";", "")

That is from the commit 11986593b668661d748789154a6052ef4e1ab1c6 Improved:
Prevent special encoded characters sequences in URLs (OFBIZ-13092)

On Fri, Sep 6, 2024 at 11:16 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Thanks Groza,

I'll check why we get this URI:

/facility/control/logoutjsessionid=47426E5B6F9A20CD2134E70F4DE525DF.jvm1

Looks like something ahead is removing the ";". Could be related to a
recent security change.

Jacques

Le 05/09/2024 à 11:08, Groza Danut a écrit :

I am able to consistently reproduce the error using the above steps
mentioned by Yang, with one addition: make sure you clear the cookies

each

time before starting. The error is thrown after you click logout.

Debugging in LoginWorker.logout at the following line:
RequestHandler rh = RequestHandler.getRequestHandler(request
.getSession().getServletContext());

I can see that for the servlet context the values are:
sessionTrackingModes null
supportedSessionTrackingModes [COOKIE, URL, SSL]

Also, the program never stops for my breakpoint at the first line in
WebAppServletContextListener.contextInitialized
Are you sure this listener is registered?

Indeed the problem is caused by this line in the ControlFilter: if (!
initialURI.equals(uRIFiltered))
Because the 2 uris are different:
/facility/control/logout;jsessionid=47426E5B6F9A20CD2134E70F4DE525DF.jvm1
/facility/control/logoutjsessionid=47426E5B6F9A20CD2134E70F4DE525DF.jvm1

Can we not provide a fix in here for this jsessionid case?

On Thu, Sep 5, 2024 at 5:38 AM 雷咩咩 <675686...@qq.com.invalid> wrote:


now i get a lot of errors for a lot of pages





https://demo-trunk.ofbiz.apache.org/content/control/main?externalLoginKey=EL2e3c96f3-bd6f-4609-a954-bd795856f143

Internal Server Error
The server encountered an internal error or misconfiguration and was
unable to complete your request.


Please contact the server administrator at dev@ofbiz.apache.org to

inform

them of the time this error occurred, and the actions you performed just
before this error.


More information about this error may be available in the server error

log.








原始邮件



发件人："雷咩咩"< 675686...@qq.com >;

发件时间：2024/9/5 7:54

收件人："ofbiz user"< u...@ofbiz.apache.org >;"dev"<

dev@ofbiz.apache.org

>;

主题：回复：Re: 回复：URL Issue


I found one stable steps to reproduce this issue in official trunk demo
site.

go to https://demo-trunk.ofbiz.apache.org/catalog/control/login,
login with admin. the url will be like 


https://demo-trunk.ofbiz.apache.org/content/control/main?externalLoginKey=EL9a0d332c-0a33-47a2-8dfd-5fa39aa8ffdd


go to menu content, then click any of the items, such

as WebStorePos



Expected:
can browse


Actual:
url is 


https://demo-trunk.ofbiz.apache.org/content/control/EditWebSite;jsessionid=167CC5B83474F1F8F5C7204282259AE3.jvm1?webSiteId=WebStorePos

error
HTTP Status 500 – Internal Server ErrorType Exception Report


Message For security reason this URL is not accepted


Description The server encountered an unexpected condition that

prevented

it from fulfilling the request.


Exception


java.lang.RuntimeException: For security reason this URL is not accepted



org.apache.ofbiz.webapp.control.ControlFilter.doFilter(ControlFilter.java:172)

javax.servlet.http.HttpFilter.doFilter(HttpFilter.java:53)



org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:71)

Note The full s

Re: 回复：Re: 回复：URL Issue

[Jacques Le Roux]

Thanks Groza,

I'll check why we get this URI:

/facility/control/logoutjsessionid=47426E5B6F9A20CD2134E70F4DE525DF.jvm1

Looks like something ahead is removing the ";". Could be related to a recent 
security change.

Jacques

Le 05/09/2024 à 11:08, Groza Danut a écrit :

I am able to consistently reproduce the error using the above steps
mentioned by Yang, with one addition: make sure you clear the cookies each
time before starting. The error is thrown after you click logout.

Debugging in LoginWorker.logout at the following line:
RequestHandler rh = RequestHandler.getRequestHandler(request
.getSession().getServletContext());

I can see that for the servlet context the values are:
sessionTrackingModes null
supportedSessionTrackingModes [COOKIE, URL, SSL]

Also, the program never stops for my breakpoint at the first line in
WebAppServletContextListener.contextInitialized
Are you sure this listener is registered?

Indeed the problem is caused by this line in the ControlFilter: if (!
initialURI.equals(uRIFiltered))
Because the 2 uris are different:
/facility/control/logout;jsessionid=47426E5B6F9A20CD2134E70F4DE525DF.jvm1
/facility/control/logoutjsessionid=47426E5B6F9A20CD2134E70F4DE525DF.jvm1

Can we not provide a fix in here for this jsessionid case?

On Thu, Sep 5, 2024 at 5:38 AM 雷咩咩 <675686...@qq.com.invalid> wrote:


now i get a lot of errors for a lot of pages



https://demo-trunk.ofbiz.apache.org/content/control/main?externalLoginKey=EL2e3c96f3-bd6f-4609-a954-bd795856f143

Internal Server Error
The server encountered an internal error or misconfiguration and was
unable to complete your request.


Please contact the server administrator at dev@ofbiz.apache.org to inform
them of the time this error occurred, and the actions you performed just
before this error.


More information about this error may be available in the server error log.








原始邮件



发件人："雷咩咩"< 675686...@qq.com >;

发件时间：2024/9/5 7:54

收件人："ofbiz user"< u...@ofbiz.apache.org >;"dev"< dev@ofbiz.apache.org
>;

主题：回复：Re: 回复：URL Issue


I found one stable steps to reproduce this issue in official trunk demo
site.

go to https://demo-trunk.ofbiz.apache.org/catalog/control/login,
login with admin. the url will be like 
https://demo-trunk.ofbiz.apache.org/content/control/main?externalLoginKey=EL9a0d332c-0a33-47a2-8dfd-5fa39aa8ffdd


go to menu content, then click any of the items, such as WebStorePos



Expected:
can browse


Actual:
url is 
https://demo-trunk.ofbiz.apache.org/content/control/EditWebSite;jsessionid=167CC5B83474F1F8F5C7204282259AE3.jvm1?webSiteId=WebStorePos
error
HTTP Status 500 – Internal Server ErrorType Exception Report


Message For security reason this URL is not accepted


Description The server encountered an unexpected condition that prevented
it from fulfilling the request.


Exception


java.lang.RuntimeException: For security reason this URL is not accepted

org.apache.ofbiz.webapp.control.ControlFilter.doFilter(ControlFilter.java:172)
javax.servlet.http.HttpFilter.doFilter(HttpFilter.java:53)

org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:71)
Note The full stack trace of the root cause is available in the server
logs.


Apache Tomcat/9.0.91









原始邮件



发件人："Jacques Le Roux"< jacques.le.r...@les7arts.com >;

发件时间：2024/8/31 22:58

收件人："user"< u...@ofbiz.apache.org >;

主题：Re: 回复：URL Issue


That's interesting. Because locally I initially did not find any on mine,
but finally found one (and only one among 9 logs):

127.0.0.1 - - [28/Aug/2024:20:59:40 +0200] "GET
/common/js/jquery/plugins/jsTree/themes/default/d.png HTTP/2.0" 200 7635
"
https://localhost:8443/common/js/jquery/plugins/jsTree/themes/default/style.css";
"Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101
Firefox/56.0"
127.0.0.1 - - [28/Aug/2024:21:00:10 +0200] "GET
/example/control/FindExample%3FexternalLoginKey=EL8b0c355f-d7a6-4a59-9b34-bb0fa6bd0d05&sortField=description&noConditionFind=N;jsessionid=7C492ACEDE914E38A49E17F9151F02B2.jvm1

HTTP/2.0" 500 1169 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0)
Gecko/20100101 Firefox/56.0"
127.0.0.1 - - [28/Aug/2024:21:00:11 +0200] "GET /favicon.ico HTTP/2.0" 404
682 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101
Firefox/56.0"
127.0.0.1 - - [28/Aug/2024:21:00:11 +0200] "GET /favicon.ico HTTP/2.0" 404
682 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101
Firefox/56.0"
127.0.0.1 - - [28/Aug/2024:21:00:12 +0200] "GET /favicon.ico HTTP/2.0" 404
682 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101
Firefox/56.0"

As others, it's a HTTP 500, rejected for security reason, actually
unrelated to jsessionid. The log stops there. So 

Re: 回复：Re: 回复：Re: ofibz causes system extremely slow after one night

[Jacques Le Roux]

What did you change exactly? I mean not only in cache.properties.

Also please rather send to the user ML. You are not developing OFBiz, you are 
asking for help.

TIA

Jacques

Le 06/09/2024 à 02:56, 雷咩咩 a écrit :

Bad news is the updated config only extended life span of ofbiz websites(and 
also my system) to 2 days.
today i see same issue again. only restarting os can solve.


org.apache.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://common/widget/CommonScreens.xml#login]: 
org.apache.ofbiz.entity.transaction.GenericTransactionException: Roll back 
error (with no rollbackOnly cause found), could not commit transaction, was 
rolled back instead: java.lang.Exception: Transaction has timed out 
(Transaction has timed out) (Roll back error (with no rollbackOnly cause 
found), could not commit transaction, was rolled back instead: 
java.lang.Exception: Transaction has timed out (Transaction has timed out)) 
 at 
org.apache.ofbiz.widget.model.ModelScreen.renderScreenString(ModelScreen.java:176)
 ~[main/:?]
...
  at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:63)
 [tomcat-util-9.0.91.jar:9.0.91]
  at java.lang.Thread.run(Thread.java:840) [?:?]
Caused by: org.apache.ofbiz.entity.transaction.GenericTransactionException: 
Roll back error (with no rollbackOnly cause found), could not commit 
transaction, was rolled back instead: java.lang.Exception: Transaction has 
timed out (Transaction has timed out)
  at 
org.apache.ofbiz.entity.transaction.TransactionUtil.commit(TransactionUtil.java:279)
 ~[main/:?]
  at 
org.apache.ofbiz.entity.transaction.TransactionUtil.commit(TransactionUtil.java:233)
 ~[main/:?]
  at 
org.apache.ofbiz.widget.model.ModelScreen.renderScreenString(ModelScreen.java:160)
 ~[main/:?]
  ... 40 more
Caused by: java.lang.Exception: Transaction has timed out
  at 
org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:266)
 ~[geronimo-transaction-3.1.5.jar:3.1.5]
  at 
org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:263)
 ~[geronimo-transaction-3.1.5.jar:3.1.5]
  at 
org.apache.ofbiz.entity.transaction.TransactionUtil.commit(TransactionUtil.java:250)
 ~[main/:?]
  at 
org.apache.ofbiz.entity.transaction.TransactionUtil.commit(TransactionUtil.java:233)
 ~[main/:?]
  at 
org.apache.ofbiz.widget.model.ModelScreen.renderScreenString(ModelScreen.java:160)
 ~[main/:?]
  ... 40 more








Original Email

  


From:"雷咩咩"< 675686...@qq.com >;

Sent Time:2024/9/5 7:47

To:"ofbiz user"< u...@ofbiz.apache.org >;"dev"< dev@ofbiz.apache.org >;

Subject:回复：Re: 回复：Re: ofibz causes system extremely slow after one night







Good news is under this config ofbiz endured last night, will monitor more few 
days.



原始邮件
            
  


发件人："Jacques Le Roux"< jacques.le.r...@les7arts.com >;

发件时间：2024/9/4 15:36

收件人："dev"< dev@ofbiz.apache.org >;"雷咩咩"< 675686...@qq.com.INVALID >;"ofbiz 
user"< u...@ofbiz.apache.org >;

主题：Re: 回复：Re: ofibz causes system extremely slow after one night


Yes indeed

Good day

Le 04/09/2024 à 09:06, 雷咩咩 a écrit :
> hi Jacques,
>
>
> You mean framework\base\config\cache.properties, right?
> I was not touching this file.
> Just looked into, and found two possible section that 'can comment this 
out or increase for better performance'
>
>
> Do you mean proceed like this?
>
>
> Regards,
> Yang
>
>
>
>
>
>
>
> 原始邮件
>
>
>
> 发件人："Jacques Le Roux"< jacques.le.r...@les7arts.com >;
>
> 发件时间：2024/9/4 14:36
>
> 收件人："dev"< dev@ofbiz.apache.org >;
>
> 主题：Re: ofibz causes system extremely slow after one night
>
>
> Hi Yang,
>
> Have you looked at cache.properties?
>
> HTH
>
> Jacques
>
> Le 04/09/2024 à 04:48, 雷咩咩 a écrit :
> > Hi ofbiz users,
> >
> >
> > I run ofbiz trunk with default configurations(jdk17, local derby) in 
my ubuntu. Within the 1 hour or so after starting it is just working fine(most ui 
response in 1s). But after one night, when I try to access, the server seems to not 
respond, or repond only after very long time(as long as 141s), and what's worse, causes 
my system very slow, even blocking my ssh login.If I run `pkill -f ofbiz` then the 
system is recovered and fast.
> > Below is result of `top` command when this happens:
> >
> >
> >     PID USER      PR  NI    VIRT    RES 
   SHR S  %CPU  %MEM     TIME+ COMMAND
> >      85 root      20   0       0     
 0      0 S   2.4   0.0   4:31.32 kswapd0
> >    9528 ci     

Re: want to be apache contributor

[Jacques Le Roux]

Hi Lucille,

We are sorry for your loss, I'll take care of that.

Jacques

Le 04/09/2024 à 21:25, Sales Vibralung a écrit :

Hi all,
My late husband was a Linux wiz.  How can I get his email address removed from 
the database or group?
Arthur (Art) Hughes
a...@vibralung.com

Any assistance would be appreciated.

Best,
Lucille Hughes

On Wed, Sep 4, 2024 at 12:37 PM Craig Russell  wrote:

Hi Jacques,

As you know, PMCs are free to create their own policies on such things as 
ICLA filings and suggested logins to resources.

There are several things that need to be corrected on that page. I can 
review your changes if you like...

Warm regards,
Craig

> On Sep 3, 2024, at 23:34, Jacques Le Roux  
wrote:
>
> Thanks Craig,
>
> This page was written before the GitHub "era". I think we should rewrite 
it a bit in accordance with what you said.Jacques
>
> Le 04/09/2024 à 06:37, Craig Russell a écrit :
>> Hi Yang,
>>
>>> On Sep 3, 2024, at 16:45, 雷咩咩 <675686...@qq.com 
<mailto:675686...@qq.com>> wrote:
>>>
>>> hi Craig,
>>>
>>> The ofbiz contributor page shows me at the bottom.
>>> 
https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Contributors

<https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Contributors>
>>> My initial request was the apache ofbiz jira and confluence 
accounts(now already have thanks to @Jacques).
>>> I'm newbie to ofbiz(also to apache) and I'm excited to enrolled to an 
open source project for the first time.
>>
>> Welcome. It sounds like you are already in a good place.
>>>
>>> For now I'm not capable of contributing code yet, but I think I can 
sometimes come across bugs, incomplete documents, and report them.
>>
>> You should be able to report issues and make suggestions for 
improvement, even if it does not involve code.
>>
>>> So the ICLA is not urgent now.
>>
>> The project will let you know when an ICLA is recommended. Usually it 
would be for significant contributions.
>>
>>> Regarding the imcomplete address:
>>> My city is not well known, let alone the district, street, door number. 
And even less if translated to English. I can send another file
input with more detailed address, if necessary.
>> Yes, if you need to send an ICLA a complete residence address is needed.
>>> Does more detailed address make sense for the foundation, or other 
members? Will anyone expects to meet me offline, or mail some real papar
material? (the form should ask for phone number in this case but didn't).
>> The residence address is one of the few things that we can ask for to 
demonstrate you are not a robot but a real person. We don't ask you to
find all of the bicycles in a picture but we do want to have on file some 
evidence of your being a real person. I hope you can understand.
>>
    >> Warm regards,
>> Craig
>>
>>>
>>>
>>> Regards,
>>> Yang
>>>
>>>
>>> Original Email
>>>
>>> From:"Craig Russell"< apache@gmail.com <mailto:apache@gmail.com> 
>;
>>>
>>> Sent Time:2024/9/4 5:29
>>>
>>> To:"Jacques Le Roux"< jacques.le.r...@les7arts.com 
<mailto:jacques.le.r...@les7arts.com> >;
>>>
    >>> Cc recipient:"雷咩咩"< 675686...@qq.com <mailto:675686...@qq.com> >;
>>>
>>> Subject:Re: want to be apache contributor
>>>
>>>
>>> Hi Jacques,
>>>
>>> The ICLA was not filed. The address is incomplete.
>>>
>>> But what is the expected end result here? Has lei yang been voted as a 
committer? If not, the ICLA is not needed.
>>>
>>> Warm regards,
>>> Craig
>>>
>>>
>>>> On Sep 3, 2024, at 02:52, Jacques Le Roux mailto:jacques.le.r...@les7arts.com>> wrote:
>>>>
>>>> Hi Craig,
>>>>
>>>> Sorry to bother you.
>>>>
>>>> I can't confirm that Yang's ICLA request has been registered using 
https://whimsy.apache.org/officers/unlistedclas.cgi
<https://whimsy.apache.org/officers/unlistedclas.cgi>
>>>> I guess because on his request he exactly wrote "675686...@qq.com, 
leiyanghe...@gmail.com" <mailto:675686...@qq.com,leiyangh

Re: want to be apache contributor

[Jacques Le Roux]

Hi,

Not "pas" but "page" of course. I'll rewrite few parts.

Jacques

Le 04/09/2024 à 08:34, Jacques Le Roux a écrit :

Thanks Craig,

This pas was written before the GitHub "era". I think we should rewrite it a 
bit in accordance with what you said.

Jacques

Le 04/09/2024 à 06:37, Craig Russell a écrit :

Hi Yang,


On Sep 3, 2024, at 16:45, 雷咩咩 <675686...@qq.com> wrote:

hi Craig,

The ofbiz contributor page shows me at the bottom.
https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Contributors
My initial request was the apache ofbiz jira and confluence accounts(now 
already have thanks to @Jacques).
I'm newbie to ofbiz(also to apache) and I'm excited to enrolled to an open 
source project for the first time.


Welcome. It sounds like you are already in a good place.


For now I'm not capable of contributing code yet, but I think I can sometimes 
come across bugs, incomplete documents, and report them.


You should be able to report issues and make suggestions for improvement, even 
if it does not involve code.


So the ICLA is not urgent now.


The project will let you know when an ICLA is recommended. Usually it would be 
for significant contributions.


Regarding the imcomplete address:

 1. My city is not well known, let alone the district, street, door number. And 
even less if translated to English. I can send another file input
    with more detailed address, if necessary.


Yes, if you need to send an ICLA a complete residence address is needed.


 2. Does more detailed address make sense for the foundation, or other members? 
Will anyone expects to meet me offline, or mail some real papar
    material? (the form should ask for phone number in this case but didn't).

The residence address is one of the few things that we can ask for to demonstrate you are not a robot but a real person. We don't ask you to find 
all of the bicycles in a picture but we do want to have on file some evidence of your being a real person. I hope you can understand.


Warm regards,
Craig


2.


3.



Regards,
Yang


Original Email

From:"Craig Russell";

Sent Time:2024/9/4 5:29

To:"Jacques Le Roux";

Cc recipient:"雷咩咩"<675686...@qq.com>;

Subject:Re: want to be apache contributor


Hi Jacques,

The ICLA was not filed. The address is incomplete.

But what is the expected end result here? Has lei yang been voted as a 
committer? If not, the ICLA is not needed.

Warm regards,
Craig



On Sep 3, 2024, at 02:52, Jacques Le Roux  wrote:

Hi Craig,

Sorry to bother you.

I can't confirm that Yang's ICLA request has been registered 
usinghttps://whimsy.apache.org/officers/unlistedclas.cgi

I guess because on his request he exactly wrote"675686...@qq.com, 
leiyanghe...@gmail.com".

I tried that (ie"675686...@qq.com, leiyanghe...@gmail.com", also w/o the space and w/o the comma but with the space) and each email apart (ie 
"675686...@qq.com"and then"leiyanghe...@gmail.com") but got no result.


Could you please confirm that Yang's ICLA request has been registered, please ?

TIA

Jacques


Le 30/08/2024 à 23:32, Craig Russell a écrit :

Hi,

To engage with the OFBIZ community, please use the public mail lists:

Our *dev@ofbiz.apache.orgmailing list *is where additions or changes to OFBiz are discussed. The list is open to everyone and all are encouraged 
to give their feedback and opinions of anything discussed.


Our *user@ofbiz.apache.orgmailing list* is for our users. Use this list to ask questions and get advice on setting up OFBiz and also if you are 
an end-user interested in helping other OFBiz users.


You only need to send an ICLA if the project asks you to.

Warm regards,
Craig



On Aug 30, 2024, at 01:23, 雷咩咩 <675686...@qq.com> wrote:

hi admins,


I'd like to be apache ofbiz contributor, so that I can edit confluence wiki or 
even code.

attached the ICLA scans.

I already registered 2 jira accounts today,


 1. this mail, name leiyang
 2. leiyanghe...@gmai.com, name yang.lei

I'm not sure what 'Create confluence user id' means in this document 
https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Contributors
but if my above two names can be used, then please help add, thanks!

Regard,
Yang





Craig L Russell
Assistant Secretary, Apache Software Foundation
c...@apache.org http://db.apache.org/jdo



Craig L Russell
c...@apache.org




Craig L Russell
c...@apache.org

Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Jacques Le Roux]

+1

Sounds good, thanks

Jacques

Le 03/09/2024 à 17:32, gil a écrit :

+1

Thanks,

Gil

On 03/09/2024 15:21, Nicolas Malin wrote:

Hello,

After going through this thread [1], I propose to go ahead with the
creation of the `release24` branch in a few weeks, and the release of
the next official version 2 or 3 weeks later.

Why:
  * We've decided to leave release22.01 unpublished.
  * The trunk has been stable for a long time (integration tests are
working well).
  * The current version is over 6 years old
  * If we wait another year for stabilization, there's a chance that a
lot of work-in-progress will be added, and as with release 22, we'll
probably miss the release stage.
  * We have a lot of work to do on the trunk :D

If there are no major objection, I'll put the release24 branch
creation to the vote in a few days.

Nicolas

[1] https://lists.apache.org/thread/k903dobd1z0hm9qxo3prn8gzc71jrnx1

Re: Want to be a committer , ICLA filled

[Jacques Le Roux]

Hi Omar,

We note that. Note on your side that it's the PMC to decide who should be a 
commiter.

https://community.apache.org/contributors/becomingacommitter.html

Thanks for your interest in OFBiz and keep it

Jacques

Le 02/09/2024 à 12:51, Omar Abdullwahhab a écrit :

Hello developers at Ofbiz
I have filled the ICLA form and submitted it,
They requested an invitation from the project.
So please help.
Regards

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.16 - Second attempt

[Jacques Le Roux]

Thanks Jacopo,

Verification, back and front ends (small checks) work for me.

Ubuntu 20.04 LTS
openjdk version "1.8.0_422"

+1

Jacques

Le 31/08/2024 à 08:46, Jacopo Cappellato a écrit :

This is the second vote thread to publish "Apache OFBiz 18.12.16", the 16th
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.16.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.16.zip.asc: the detached signature file
* apache-ofbiz-18.12.16.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 18.12.16
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: 回复：URL Issue

[Jacques Le Roux]

Thanks Dan,

That looks like something interesting to think about indeed!

When you right-click on a link, you get something like
https://demo-trunk.ofbiz.apache.org/facility/control/main?externalLoginKey=EL1ad4c84d-3cb7-41d5-bf80-9a24247d6b40

And at the moment our issue is not about externalLoginKey but jessionid. It's 
maybe related.

Note that jessionid only appears in access_log files (A Tomcat log) and not in 
any other OFBiz log.
I still don't know how jessionid is added to URLs. It could be due to cookies 
somehow...

Not a big deal for now, just something we need to fix.

Jacques


Le 29/08/2024 à 10:56, Daniel Watford a écrit :

[Only sending to dev mailing list as is an application architecture related
comment]

I don't have a solution to offer yet around the URL issue raised by Johan,
but have a feeling it it will relate to the issue below.

This is a message to highlight a deep unease I have around the OFBiz use of
query arguments in URLs to carry authentication/session information between
client and server. In particular, clickable links between applications in
the client are rendered with the externalLoginKey query argument since each
application maintains its own login mechanism and session cookie.

One immediate problem I see is if a user right-clicks a link to copy the
URL target, and then shares that URL, they have unwittingly also shared a
credential that will allow recipients of the URL to masquerade as the
original user.

I assume the reason for tying session cookies to applications, rather than
to the root of the OFBiz website, is to ensure a separation between
back-end office applications and front-end ecommerce applications.

As mentioned, I don't have a solution to offer at the moment, but perhaps
we should looks at configuring the applications with the names of their
session cookies. All the back-end applications could then use a single
'backend' cookie, and any front-end consumer facing application could have
their own distinct session cookie.

Thanks,

Dan.

On Thu, 29 Aug 2024 at 09:17, Jacques Le Roux 
wrote:


Hi,

Finally it's not that clear.

As can be found in trunk demo access_logs, such URLs exist at least since
June 17 2024.

 access_log.2024-06-17:28:66.249.75.98 - - [17/Jun/2024:00:11:51 +]
"GET

/partymgr/control/main%3FexternalLoginKey=ELf5183769-2759-476b-946c-2a70afe3c42d&sortField=partyId;jsessionid=EBB57C6C3C345E70501827509E05744C.jvm1
 HTTP/1.1" 500 1165 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X
Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.6422.175
 Mobile Safari/537.36 (compatible; Googlebot/2.1; +
http://www.google.com/bot.html)"

As you can see they are rejected (HTTP 500) since then too. Actually I
guess they exist for a very long time. Have yet no idea why and how these
URLs
are generated.

The rejection is "new" and due to a security fix done in May 20 2024 with
(OFBIZ-13092) "Prevent special encoded characters sequences in URLs"

So we need to clearly define steps to manually generate these URLs. Then,
if it's OK, we could allow URLs containing ";jsessionid=" to bypass the
security filter.

I copy this email to the dev ML because of its importance

Jacques


Le 28/08/2024 à 15:27, Jacques Le Roux a écrit :

Thanks Guys,

I could not reproduce yet, but I think we have already enough clues to

fix that.

Also I can find a lot of in trunk demo log. That will be helpful too.

Jacques

Le 27/08/2024 à 16:20, 雷咩咩 a écrit :

i can reproduce by login with admin, randomly click severl places, then

when click logout, see such error:


HTTP Status 500 – Internal Server Error
Type Exception Report


Message For security reason this URL is not accepted


Description The server encountered an unexpected condition that

prevented it from fulfilling the request.


Exception


java.lang.RuntimeException: For security reason this URL is not accepted


 
org.apache.ofbiz.webapp.control.ControlFilter.doFilter(ControlFilter.java:144)
 
org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:71)

Note The full stack trace of the root cause is available in the server

logs.


Apache Tomcat/9.0.91




Regards,
Yang


-- 原始邮件 --
发件人: "user" 
which

can also be replicated within the demo.
This issue normally occurs as you navigate to a module after login. It

is

not easily replicable, once you refresh it works and does not occur

again.

Replicated the issue in multiple modules.
It usually adds ;jsessionid=##.jvm1 to all the URLs

and

this causes a navigation issue.
Once you submit a form or try to click the logout link, an Internal 500
Internal Server Error is being returned
As an example:
https://demo-stable.ofbiz.apache.org/partymgr/control/main

I have screenshots available, however I am not able to attach to this

mail.

Please let me know if you need me to upload it somewhere.

Kind Regards,
Johan Cronjé

Re: 回复：URL Issue

[Jacques Le Roux]

Hi,

Finally it's not that clear.

As can be found in trunk demo access_logs, such URLs exist at least since June 
17 2024.

   access_log.2024-06-17:28:66.249.75.98 - - [17/Jun/2024:00:11:51 +] "GET
   
/partymgr/control/main%3FexternalLoginKey=ELf5183769-2759-476b-946c-2a70afe3c42d&sortField=partyId;jsessionid=EBB57C6C3C345E70501827509E05744C.jvm1
   HTTP/1.1" 500 1165 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X 
Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.6422.175
   Mobile Safari/537.36 (compatible; Googlebot/2.1; 
+http://www.google.com/bot.html)"

As you can see they are rejected (HTTP 500) since then too. Actually I guess they exist for a very long time. Have yet no idea why and how these URLs 
are generated.


The rejection is "new" and due to a security fix done in May 20 2024 with (OFBIZ-13092) 
"Prevent special encoded characters sequences in URLs"

So we need to clearly define steps to manually generate these URLs. Then, if it's OK, we could allow URLs containing ";jsessionid=" to bypass the 
security filter.


I copy this email to the dev ML because of its importance

Jacques


Le 28/08/2024 à 15:27, Jacques Le Roux a écrit :

Thanks Guys,

I could not reproduce yet, but I think we have already enough clues to fix that.
Also I can find a lot of in trunk demo log. That will be helpful too.

Jacques

Le 27/08/2024 à 16:20, 雷咩咩 a écrit :

i can reproduce by login with admin, randomly click severl places, then when 
click logout, see such error:


HTTP Status 500 – Internal Server Error
Type Exception Report


Message For security reason this URL is not accepted


Description The server encountered an unexpected condition that prevented it 
from fulfilling the request.


Exception


java.lang.RuntimeException: For security reason this URL is not accepted

org.apache.ofbiz.webapp.control.ControlFilter.doFilter(ControlFilter.java:144)

org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:71)
Note The full stack trace of the root cause is available in the server logs.


Apache Tomcat/9.0.91




Regards,
Yang


-- 原始邮件 --
发件人: "user" https://demo-stable.ofbiz.apache.org/partymgr/control/main

I have screenshots available, however I am not able to attach to this mail.
Please let me know if you need me to upload it somewhere.

Kind Regards,
Johan Cronjé

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.16

[Jacques Le Roux]

Thanks Jacopo,

Verification, back and front ends (small checks) work for me

Ubuntu 20.04 LTS under Oracle VM virtualBox Version 7.0.6 r155176 (Qt5.15.2) on 
Windows 7 (yes! :)
openjdk version "1.8.0_422"
OpenJDK Runtime Environment (build 1.8.0_422-8u422-b05-1~20.04-b05)
OpenJDK 64-Bit Server VM (build 25.422-b05, mixed mode)

+1

Jacques

Le 28/08/2024 à 12:35, Jacopo Cappellato a écrit :

This is the vote thread to publish "Apache OFBiz 18.12.16", the 16th
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.16.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.16.zip.asc: the detached signature file
* apache-ofbiz-18.12.16.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 18.12.16
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.15 - third attempt

[Jacques Le Roux]

Thanks Jacopo,

verify-ofbiz-release.sh, back and front ends work with me

+1

Jacques

Le 19/07/2024 à 15:31, Jacopo Cappellato a écrit :

This is the third vote thread to publish "Apache OFBiz 18.12.15", the 15th
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.15.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.15.zip.asc: the detached signature file
* apache-ofbiz-18.12.15.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 18.12.15
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: [jira] [Commented] (OFBIZ-13122) Error with executeMRP service

[Jacques Le Roux]

Le 25/07/2024 à 08:41, Jacques Le Roux a écrit :

Hi Omar,

As Emad demonstrated at 
https://issues.apache.org/jira/secure/attachment/13070416/13070416_Screenshot+2024-07-23+at+8.49.52+PM+%282%29.png
he is correctly sending the requested data. 


Hi Omar,

You were maybe right by suggesting to check the data. See last comments at 
OFBIZ-13122

BTW have you a Jira username? I could refer to you there now :)

Thanks

Jacques

Re: [jira] [Commented] (OFBIZ-13122) Error with executeMRP service

[Jacques Le Roux]

3 org.apache.ofbiz.entity.serialize.SerializeException:
Problem deserializing object from byte array + cus-obj
2024-07-24 14:58:13 at
org.apache.ofbiz.entity.serialize.XmlSerializer.deserializeCustom(XmlSerializer.java:481)
~[ofbiz.jar:?]
2024-07-24 14:58:13 at
org.apache.ofbiz.entity.serialize.XmlSerializer.deserializeSingle(XmlSerializer.java:465)
~[ofbiz.jar:?]
2024-07-24 14:58:13 at
org.apache.ofbiz.entity.serialize.XmlSerializer.deserializeSingle(XmlSerializer.java:453)
~[ofbiz.jar:?]
2024-07-24 14:58:13 at
org.apache.ofbiz.entity.serialize.XmlSerializer.deserialize(XmlSerializer.java:128)
~[ofbiz.jar:?]
2024-07-24 14:58:13 at
org.apache.ofbiz.entity.serialize.XmlSerializer.deserialize(XmlSerializer.java:102)
~[ofbiz.jar:?]
2024-07-24 14:58:13 at
org.apache.ofbiz.service.job.PersistedServiceJob.getContext(PersistedServiceJob.java:319)
~[ofbiz.jar:?]
2024-07-24 14:58:13 at
org.apache.ofbiz.service.job.GenericServiceJob.exec(GenericServiceJob.java:70)
~[ofbiz.jar:?]
2024-07-24 14:58:13 at
org.apache.ofbiz.service.job.AbstractJob.run(AbstractJob.java:87)
~[ofbiz.jar:?]
2024-07-24 14:58:13 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
~[?:?]
2024-07-24 14:58:13 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
~[?:?]
2024-07-24 14:58:13 at java.lang.Thread.run(Thread.java:829) ~[?:?]
2024-07-24 14:58:13 2024-07-24 11:58:13,240 |OFBiz-JobQueue-1
|PersistedServiceJob   |E| Job context is null
2024-07-24 14:58:13 2024-07-24 11:58:13,242 |OFBiz-JobQueue-1
|MrpServices   |I| executeMrp called
2024-07-24 14:58:13 2024-07-24 11:58:13,242 |OFBiz-JobQueue-1
|ServiceUtil   |E| \{errorMessage=facilityId and
facilityGroupId cannot be both null, responseMessage=error}
2024-07-24 14:58:13 2024-07-24 11:58:13,242 |OFBiz-JobQueue-1
|ServiceDispatcher |E| Error in Service [executeMrp]:
facilityId and facilityGroupId cannot be both null
2024-07-24 14:58:13 2024-07-24 11:58:13,242 |OFBiz-JobQueue-1
|TransactionUtil   |E| [TransactionUtil.rollback]
2024-07-24 14:58:13 java.lang.Exception: Stack Trace
2024-07-24 14:58:13 at
org.apache.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:314)
~[ofbiz.jar:?]
2024-07-24 14:58:13 at
org.apache.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:290)
~[ofbiz.jar:?]
2024-07-24 14:58:13 at
org.apache.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:559)
~[ofbiz.jar:?]
2024-07-24 14:58:13 at
org.apache.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:240)
~[ofbiz.jar:?]
2024-07-24 14:58:13 at
org.apache.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:88)
~[ofbiz.jar:?]
2024-07-24 14:58:13 at
org.apache.ofbiz.service.job.GenericServiceJob.exec(GenericServiceJob.java:70)
~[ofbiz.jar:?]
2024-07-24 14:58:13 at
org.apache.ofbiz.service.job.AbstractJob.run(AbstractJob.java:87)
~[ofbiz.jar:?]
2024-07-24 14:58:13 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
~[?:?]
2024-07-24 14:58:13 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
~[?:?]
2024-07-24 14:58:13 at java.lang.Thread.run(Thread.java:829) ~[?:?]
2024-07-24 14:58:13 2024-07-24 11:58:13,243 |OFBiz-JobQueue-1
|TransactionUtil   |I| Transaction rolled back
2024-07-24 14:58:13 2024-07-24 11:58:13,245 |OFBiz-JobQueue-1
|ServiceDispatcher |T| Sync service [default/executeMrp]
finished in [3] milliseconds
2024-07-24 14:58:13 2024-07-24 11:58:13,245 |OFBiz-JobQueue-1
|GenericServiceJob |E| Async-Service failed.
2024-07-24 14:58:13 java.lang.Exception: facilityId and facilityGroupId
cannot be both null
2024-07-24 14:58:13 at
org.apache.ofbiz.service.job.GenericServiceJob.exec(GenericServiceJob.java:73)
~[ofbiz.jar:?]
2024-07-24 14:58:13 at
org.apache.ofbiz.service.job.AbstractJob.run(AbstractJob.java:87)
~[ofbiz.jar:?]
2024-07-24 14:58:13 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
~[?:?]
2024-07-24 14:58:13 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
~[?:?]
2024-07-24 14:58:13 at java.lang.Thread.run(Thread.java:829) ~[?:?]
2024-07-24 14:58:13 2024-07-24 11:58:13,245 |OFBiz-JobQueue-1
|PersistedServiceJob   |W| Persisted Job [10017] Failed. Max Retry
Hit, not re-scheduling


Error with executeMRP service
-

 Key: OFBIZ-13122
 URL: https://issues.apache.org/jira/browse/OFBIZ-13122
 Project: OFBiz
  Issue Type: Bug
  Components: manufacturing
Affects Versions: Upcoming Branch
    Reporter: Emad Radwan
Assignee: Jacques Le Roux
Priority: Major
 Fix For: Upcoming Branch

 Attachments: Image 019.png, Image 020.png, Screenshot 2024-07-22

at 8.41.00 PM-1.png, Screenshot 2024-07-

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.15 - second attempt

[Jacques Le Roux]

Fortunately we are able to fix these issues by reverting OFBIZ-13117 commits.
I tried locally on trunk. Without surprises it works as expected

Thanks Christian, I forgot your 1st June report :/

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

And of course locally for 18.12.015 on Ubuntu 20.04 with JDK 8

Le 15/07/2024 à 14:09, Jacques Le Roux a écrit :

BTW, logically the same exists in trunk

Le 15/07/2024 à 14:03, Jacques Le Roux a écrit :

Hi Christian,

You are right, and not only that I also get this one on stable demo with
ordermgr/control/updateCheckoutOptions/quickcheckout

org.apache.ofbiz.webapp.control.RequestHandlerException:
Unknown request [updateCheckoutOptions]; this request does not exist or cannot 
be called directly.

Note that by getting back and continuing it works, at least for this one.
I just created 
https://demo-stable.ofbiz.apache.org/ordermgr/control/orderview?orderId=WSCO10001
It's in "Current Status: Approved" trying to cancel I get the same than new 
below.

I'll try locally, I guess we have an issue with few requests.

Jacques

Le 15/07/2024 à 12:30, Christian Geisert a écrit :

Hi,

looks like there is still the problem with order entry.

I just had a quick test... "./gradlew cleanAll loadAll", Order Entry
with "DemoCustomer", 1x GZ-1000 .. Order is created, but when clicking
on "Approve Order" I get a
"org.apache.ofbiz.webapp.control.RequestHandlerException: Unknown
request [changeOrderStatus]; this request does not exist or cannot be
called directly." error


(Ubuntu 22.04.4 LTS, openjdk version "1.8.0_412" OpenJDK 64-Bit Server
VM (build 25.412-b08, mixed mode), Firefox (probably latest) and Edge)

Christian

Am 11.07.24 um 10:52 schrieb Jacopo Cappellato:

This is the second vote thread to publish "Apache OFBiz 18.12.15", the 15th
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.15.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.15.zip.asc: the detached signature file
* apache-ofbiz-18.12.15.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 18.12.15
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.15 - second attempt

[Jacques Le Roux]

And of course locally for 18.12.015 on Ubuntu 20.04 with JDK 8

Le 15/07/2024 à 14:09, Jacques Le Roux a écrit :

BTW, logically the same exists in trunk

Le 15/07/2024 à 14:03, Jacques Le Roux a écrit :

Hi Christian,

You are right, and not only that I also get this one on stable demo with
ordermgr/control/updateCheckoutOptions/quickcheckout

org.apache.ofbiz.webapp.control.RequestHandlerException:
Unknown request [updateCheckoutOptions]; this request does not exist or cannot 
be called directly.

Note that by getting back and continuing it works, at least for this one.
I just created 
https://demo-stable.ofbiz.apache.org/ordermgr/control/orderview?orderId=WSCO10001
It's in "Current Status: Approved" trying to cancel I get the same than new 
below.

I'll try locally, I guess we have an issue with few requests.

Jacques

Le 15/07/2024 à 12:30, Christian Geisert a écrit :

Hi,

looks like there is still the problem with order entry.

I just had a quick test... "./gradlew cleanAll loadAll", Order Entry
with "DemoCustomer", 1x GZ-1000 .. Order is created, but when clicking
on "Approve Order" I get a
"org.apache.ofbiz.webapp.control.RequestHandlerException: Unknown
request [changeOrderStatus]; this request does not exist or cannot be
called directly." error


(Ubuntu 22.04.4 LTS, openjdk version "1.8.0_412" OpenJDK 64-Bit Server
VM (build 25.412-b08, mixed mode), Firefox (probably latest) and Edge)

Christian

Am 11.07.24 um 10:52 schrieb Jacopo Cappellato:

This is the second vote thread to publish "Apache OFBiz 18.12.15", the 15th
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.15.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.15.zip.asc: the detached signature file
* apache-ofbiz-18.12.15.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 18.12.15
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.15 - second attempt

[Jacques Le Roux]

BTW, logically the same exists in trunk

Le 15/07/2024 à 14:03, Jacques Le Roux a écrit :

Hi Christian,

You are right, and not only that I also get this one on stable demo with
ordermgr/control/updateCheckoutOptions/quickcheckout

org.apache.ofbiz.webapp.control.RequestHandlerException:
Unknown request [updateCheckoutOptions]; this request does not exist or cannot 
be called directly.

Note that by getting back and continuing it works, at least for this one.
I just created 
https://demo-stable.ofbiz.apache.org/ordermgr/control/orderview?orderId=WSCO10001
It's in "Current Status: Approved" trying to cancel I get the same than new 
below.

I'll try locally, I guess we have an issue with few requests.

Jacques

Le 15/07/2024 à 12:30, Christian Geisert a écrit :

Hi,

looks like there is still the problem with order entry.

I just had a quick test... "./gradlew cleanAll loadAll",  Order Entry
with "DemoCustomer", 1x GZ-1000 .. Order is created, but when clicking
on "Approve Order" I get a
"org.apache.ofbiz.webapp.control.RequestHandlerException: Unknown
request [changeOrderStatus]; this request does not exist or cannot be
called directly." error


(Ubuntu 22.04.4 LTS, openjdk version "1.8.0_412" OpenJDK 64-Bit Server
VM (build 25.412-b08, mixed mode), Firefox (probably latest) and Edge)

Christian

Am 11.07.24 um 10:52 schrieb Jacopo Cappellato:

This is the second vote thread to publish "Apache OFBiz 18.12.15", the 15th
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.15.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.15.zip.asc: the detached signature file
* apache-ofbiz-18.12.15.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 18.12.15
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.15 - second attempt

[Jacques Le Roux]

Hi Christian,

You are right, and not only that I also get this one on stable demo with
ordermgr/control/updateCheckoutOptions/quickcheckout

org.apache.ofbiz.webapp.control.RequestHandlerException:
Unknown request [updateCheckoutOptions]; this request does not exist or cannot 
be called directly.

Note that by getting back and continuing it works, at least for this one.
I just created 
https://demo-stable.ofbiz.apache.org/ordermgr/control/orderview?orderId=WSCO10001
It's in "Current Status: Approved" trying to cancel I get the same than new 
below.

I'll try locally, I guess we have an issue with few requests.

Jacques

Le 15/07/2024 à 12:30, Christian Geisert a écrit :

Hi,

looks like there is still the problem with order entry.

I just had a quick test... "./gradlew cleanAll loadAll",  Order Entry
with "DemoCustomer", 1x GZ-1000 .. Order is created, but when clicking
on "Approve Order" I get a
"org.apache.ofbiz.webapp.control.RequestHandlerException: Unknown
request [changeOrderStatus]; this request does not exist or cannot be
called directly." error


(Ubuntu 22.04.4 LTS, openjdk version "1.8.0_412" OpenJDK 64-Bit Server
VM (build 25.412-b08, mixed mode), Firefox (probably latest) and Edge)

Christian

Am 11.07.24 um 10:52 schrieb Jacopo Cappellato:

This is the second vote thread to publish "Apache OFBiz 18.12.15", the 15th
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.15.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.15.zip.asc: the detached signature file
* apache-ofbiz-18.12.15.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 18.12.15
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.15 - second attempt

[Jacques Le Roux]

Thanks Jacopo,

verify-ofbiz-release.sh, back and front ends work for me me

+1

Jacques

Le 11/07/2024 à 10:52, Jacopo Cappellato a écrit :

This is the second vote thread to publish "Apache OFBiz 18.12.15", the 15th
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.15.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.15.zip.asc: the detached signature file
* apache-ofbiz-18.12.15.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 18.12.15
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Groovy compilation and @CompileStatic

[Jacques Le Roux]

Hi,

With https://github.com/apache/ofbiz-framework/commit/231650e1b6 I fixed few errors that would not happen if we were using @CompileStatic  in Groovy 
files as mentioned at

https://stackoverflow.com/questions/57982247/groovy-compiler-and-non-existing-call-method

I vaguely remember having using it before it was incorporated in Groovy.
It was then with a Groovy fork and if IIRW it was slow or/and not totally ready 
(was arounf 2012/2013 IIRW)

Has someone tried to using it with a large number of Groovy files, like in 
OFBiz (600+  files) and if so how was the experience?

This said, if it's reasonable I wonder if we should not try to use it, at least 
temporarily, after our migration from Minilang to Groovy.

I tried a bit but it's not that easy because we have some (or a lot of) files which are not classes so CompileStatic  fails there, and correctly 
changing all files takes time...


Another question: what has refrained us to make all Groovy scripts as classes, 
if there is a reason?

TIA for enlightenment

Jacques
PS: I regularly (almost weekly) check the trunk demo error.logs. I'm happy to 
say that it's much more clean than it was months ago.

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.15

[Jacques Le Roux]

Thanks Jacopo,

Verification, back and front ends work for me me

+1

Jacques

Le 24/06/2024 à 16:53, Jacopo Cappellato a écrit :

This is the vote thread to publish "Apache OFBiz 18.12.15", the 15th
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.15.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.15.zip.asc: the detached signature file
* apache-ofbiz-18.12.15.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 18.12.15
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: Welcome to Sebastian Tschikin as new committer

[Jacques Le Roux]

Hi Sebastian,

Welcome on board

Jacques

Le 20/06/2024 à 21:02, michael.br...@ecomify.de a écrit :

Congratulations and welcome, Sebastian!

Michael


Am 20.06.2024 um 16:21 schrieb Jacopo Cappellato:

The OFBiz PMC has invited Sebastian Tschikin to become a committer and
we are pleased to announce that Sebastian has accepted.

On behalf of the OFBiz PMC, welcome on board!

Re: Overriding template Week.tpl

[Jacques Le Roux]

BTW, you should rather use the user ML for such questions. It's explained at 
https://ofbiz.apache.org/mailing-lists.html:

<>

TIA

Le 13/06/2024 à 08:59, Jacques Le Roux a écrit :

Hi San,

Most of the Freemarker templates like Week.ftl  (not Week.tpl) are not part of the common-theme. Because they are not common but specific to some 
applications. For instance Week.ftl is only used by workeffort and humanres. So it's not a simple task to adapt it to your own theme. Sincerely out 
of the blue I'm not sure how to do that. I'd certainly try to see the content of common-theme and how generic templates are used. Though unrelated 
to your request CcYears.ftl could be an example to follow as a start.


HTH

Jacques

Le 11/06/2024 à 03:18, Sankatha Bamunuge a écrit :

 Hi All

I’m very new to OfBiz so apologies in advance if I’m asking something obvious. I started developing my own theme sub themed off the common-theme. 
There is a template called Week.tpl under workeffort component. How do I override this template in my custom theme?. All your help is much 
appreciated. I’m using OfBiz version 18.12


Kind regards
San

Re: Overriding template Week.tpl

[Jacques Le Roux]

Hi San,

Most of the Freemarker templates like Week.ftl  (not Week.tpl) are not part of the common-theme. Because they are not common but specific to some 
applications. For instance Week.ftl is only used by workeffort and humanres. So it's not a simple task to adapt it to your own theme. Sincerely out of 
the blue I'm not sure how to do that. I'd certainly try to see the content of common-theme and how generic templates are used. Though unrelated to 
your request CcYears.ftl could be an example to follow as a start.


HTH

Jacques

Le 11/06/2024 à 03:18, Sankatha Bamunuge a écrit :

 Hi All

I’m very new to OfBiz so apologies in advance if I’m asking something obvious. 
I started developing my own theme sub themed off the common-theme. There is a 
template called Week.tpl under workeffort component. How do I override this 
template in my custom theme?. All your help is much appreciated. I’m using 
OfBiz version 18.12

Kind regards
San

Re: [jira] [Closed] (OFBIZ-11725) Have Order Entry Screen always show selection field for available agreement(s)

[Jacques Le Roux]

Hi Bill,

Though, as explained at https://ofbiz.apache.org/mailing-lists.html: > the dev ML is also open as long as your are subscribed.

Anyway, your report fits.

Speak to you later...

Jacques

Le 07/06/2024 à 02:25, Bill Harder a écrit :

I am new to this, but have been tracking this mail list for close to 6
months and trying to figure out OFBiz.  I am not even sure if I can respond
to this mail list as I have no permissions to do anything. I spent 10+
hours trying to figure out why this drop down agreements list was not
showing.  I finally traced it back to Stores-Payments.  You see, I am
trying to set up OFBiz with no demo data from scratch.  So I am not sure
why this Jira is being closed.  I personally would like to see the drop
down with None.  Please forgive my ignorance and advise.  TIA.

Bill

On Thu, Jun 6, 2024 at 2:19 PM Michael Brohl (Jira)  wrote:


  [
https://issues.apache.org/jira/browse/OFBIZ-11725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Brohl closed OFBIZ-11725.
-
   Assignee: Michael Brohl  (was: Pierre Smits)
 Resolution: Won't Do


Have Order Entry Screen always show selection field for available

agreement(s)
--

 Key: OFBIZ-11725
 URL: https://issues.apache.org/jira/browse/OFBIZ-11725
 Project: OFBiz
  Issue Type: Improvement
  Components: order
Affects Versions: 17.12.03, Trunk, Upcoming Branch
Reporter: Pierre Smits
Assignee: Michael Brohl
Priority: Major
  Labels: usability
 Attachments: Screen Shot 2020-05-23 at 08.49.01.png, Screen Shot

2020-05-23 at 09.25.31.png


See attached screenshot.
Though the screenlet indicates that an agreement can be selected, there

is no selection field.

addendum:
When one or more agreements are available for the counter party, then

the selection field is shown. When no agreements are available, the label
should still be shown plus an indication that no agreements are available.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: (ofbiz-framework) branch trunk updated: Fixed: PartyFinancialHistory shows parentTypeId of invoice, not invoiceTypeId (OFBIZ-13068)

[Jacques Le Roux]

Typo

Le 30/05/2024 à 15:47, Jacques Le Roux a écrit :

In "Invoices not yet (fully) applied", I'll also re-add the invoice description 
list as it was present before.

In "Invoices not yet (fully) applied" list, I'll also re-add the invoice 
description as it was present before.

Re: (ofbiz-framework) branch trunk updated: Fixed: PartyFinancialHistory shows parentTypeId of invoice, not invoiceTypeId (OFBIZ-13068)

[Jacques Le Roux]

Hi Deepak,

Yes you are right, /parentPaymentType/ is useless and cache on InvoiceType 
would be better.

The idea is we get no information on the invoice type with the previous (old) situation. With other columns, we already know it's an invoice as can be 
seen at

https://demo-trunk.ofbiz.apache.org/partymgr/control/PartyFinancialHistory?partyId=AcctBigSupplier
But I then missed to remove useless parentInvoiceType DB retrievings. I'll 
remove them.

In "Invoices not yet (fully) applied", I'll also re-add the invoice description 
list as it was present before.

Finally , there is no need for changes in ListInvoicesApplPayments form.

I'll improve all that.

Thanks for your review and help, much appreciated.

Jacques

Le 30/05/2024 à 12:01, Deepak Dixit a écrit :

Hi Jacques,

I didn't get the logic behind this commit.
{code}
 
+            
+            
+            
+        



+            
         


{code}


Why are we fetching parentPaymentType?
As we are using paymentType.description for display, same as other fields as 
well.
This is not used anywhere in the code. Ideally we should use the cache as well, 
as type data does not change.

Please correct me if I am missing something!!
It'd be good to revert this commit.

Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org <http://ofbiz.apache.org>


On Thu, May 30, 2024 at 3:03 PM  wrote:

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 6718c4645d Fixed: PartyFinancialHistory shows parentTypeId of 
invoice, not invoiceTypeId (OFBIZ-13068)
6718c4645d is described below

commit 6718c4645dba7195317de3084cf2a24116f7dfdc
Author: Jacques Le Roux 
AuthorDate: Thu May 30 11:33:08 2024 +0200

    Fixed: PartyFinancialHistory shows parentTypeId of invoice, not 
invoiceTypeId (OFBIZ-13068)

    This fixes an old bug (at least 8 years)
---
 applications/party/widget/partymgr/PartyForms.xml | 36 
+++
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/applications/party/widget/partymgr/PartyForms.xml 
b/applications/party/widget/partymgr/PartyForms.xml
index 7ba6d88410..4eaa195d72 100644
--- a/applications/party/widget/partymgr/PartyForms.xml
+++ b/applications/party/widget/partymgr/PartyForms.xml
@@ -1099,6 +1099,9 @@ under the License.
             
             
             
+            
+            
+            
         
         
             
@@ -1107,7 +1110,9 @@ under the License.
                 
             
         
-        
+        
+            
+        
         
         
         
@@ -1131,15 +1136,18 @@ under the License.
             
             
         
+        
+            
+            
+            
+        
         
-            
-                
-                    
-                
-            
+            
+                
+            
         
-        
-            
+        
+            
         
         
         
@@ -1153,6 +1161,11 @@ under the License.
             
             
         
+        
+            
+            
+            
+        
         
         
             
@@ -1162,11 +1175,8 @@ under the License.
             
         
         
-        
-            
-        
-        
-            
+        
+            
         
         
         

Do we need both a menu and a button for same action?

[Jacques Le Roux]

Hi,

Mostly for a creating action, do we need both a menu and a button for same 
action? And if so why?

This has recently appeared at OFBIZ-13101, but IIRW some other cases where 
handled the same.

If we do so (both) we then need to handle the permissions correctly. For instance, a person with only the VIEW permission should not see these menu 
and button.

For now in some places if they click they see a message saying they are not 
authorised, better hide the possible click.

I guess we have much cases like that.

TIA

Jacques

Re: Docker and new release branch

[Jacques Le Roux]

Thanks Daniel!

Le 25/05/2024 à 12:04, Daniel Watford a écrit :

Hi Jacques,

No documentation on how to handle the creation of a new release branch (and
nether the retirement of an old stable branch).

When the new branch is created, I'll take care of updating the docker
related build processes and deployments to the demo server. I'll also write
up some documentation about the process at the same time (including
updating the WIKI page you linked to)


On Sat, 25 May 2024 at 10:37, Jacques Le Roux 
wrote:


Le 25/05/2024 à 11:32, Jacques Le Roux a écrit :

Hi Daniel,

I don't remember if we talk about that already, sorry if it's the case.

Have we  a documentation on how to update Docker for demos in case of

the creation of a new release branch?

TIA

Jacques

And please add a link at

https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz#ReleaseManagementGuideforOFBiz-Creatinganewreleasebranch

Re: Docker and new release branch

[Jacques Le Roux]

Le 25/05/2024 à 11:32, Jacques Le Roux a écrit :

Hi Daniel,

I don't remember if we talk about that already, sorry if it's the case.

Have we  a documentation on how to update Docker for demos in case of the 
creation of a new release branch?

TIA

Jacques
And please add a link at 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz#ReleaseManagementGuideforOFBiz-Creatinganewreleasebranch

Docker and new release branch

[Jacques Le Roux]

Hi Daniel,

I don't remember if we talk about that already, sorry if it's the case.

Have we  a documentation on how to update Docker for demos in case of the 
creation of a new release branch?

TIA

Jacques

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.14

[Jacques Le Roux]

Thanks Jacopo,

Works for me on Ubuntu 20.04

+1

Jacques

Le 24/05/2024 à 11:31, Jacopo Cappellato a écrit :

This is the vote thread to publish "Apache OFBiz 18.12.14", the 14th
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.14.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.14.zip.asc: the detached signature file
* apache-ofbiz-18.12.14.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 18.12.14
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: Proposal: Merge (bundle) selected plugins into ofbiz-framework

[Jacques Le Roux]

Thanks Pierre,

I relayed your propositions, not telling it's you, else... you know...

Le 24/05/2024 à 10:49, Pierre Smits a écrit :

Hi Daniel, Jacques,


Given that the content application has some sort of dependency on the lucene plugin, please consider making the indexing functionality of lucene 
part of the framework services, and the rest of plugin part of the content component.


I would also suggest to make the project component part of the application stack, if the community decides to abandon plugins, as it is being used 
by adopters.


Met vriendelijke groet,

Pierre


On Fri, May 24, 2024 at 10:31 AM Daniel Watford  wrote:

Hello all,

Following on from discussions around a previous proposal regarding merging
_all_ plugins into ofbiz-framework [1], I would like to instead propose
that we consider 'bundling' _some_ selected plugins into ofbiz-framework.

The bundled plugins would be those deemed important enough by the
development community that we want to ensure they continue to build and are
updated alongside the core OFBiz code. These would be the plugins that the
development community is prepared to expend effort maintaining.

Those selected (bundled) plugins would then be regularly built as part of
the CI process and their code processed by the various analysis tools we
utilise.

The bundled plugins should be disabled by default. We may then need to
create guidance or some technical solution to help users enable only those
bundled plugins that they need. (We have example code to enable/disable
plugins in the Docker startup scripts).

With those important plugins bundled as part of ofbiz-framework, we could
then consider excluding the ofbiz-plugins repository from the release
process. System integrators would be responsible for retrieving any
non-bundled plugins that they use as part of their deployment process.

If bundling key plugins into ofbiz-framework is considered worthwhile,
which plugins should we bundle? Some suggestions might be:
- REST-API
- ecommerce
- birt (assuming it is brought up to date and is secure)
- passport / ldap
- solr

Please refer to [1] for some of the possible benefits and negatives to the
above as I think they are mostly still relevant even if only bundling a
subset of plugins into ofbiz-framework.

Thanks,

Dan.

[1] https://lists.apache.org/thread/jhjohny4ovb2tnpo6qpcwmz5m6513f57

-- 
Daniel Watford

Re: Proposal: Merge (bundle) selected plugins into ofbiz-framework

[Jacques Le Roux]

Hi Daniel,

I would add example (maybe not examplext), quite useful when starting a 
project. projectmgr and myportal seems interesting too.

About ecommerce, after years of ecomseo introduction I believe it should 
replace ecommerce. So there would be no wondering about what to use.

lucene (w/o Solr but now part of it, to clarify) is also used from other 
applications, catalog and content come to mind

Jacques

Le 24/05/2024 à 10:30, Daniel Watford a écrit :

Hello all,

Following on from discussions around a previous proposal regarding merging
_all_ plugins into ofbiz-framework [1], I would like to instead propose
that we consider 'bundling' _some_ selected plugins into ofbiz-framework.

The bundled plugins would be those deemed important enough by the
development community that we want to ensure they continue to build and are
updated alongside the core OFBiz code. These would be the plugins that the
development community is prepared to expend effort maintaining.

Those selected (bundled) plugins would then be regularly built as part of
the CI process and their code processed by the various analysis tools we
utilise.

The bundled plugins should be disabled by default. We may then need to
create guidance or some technical solution to help users enable only those
bundled plugins that they need. (We have example code to enable/disable
plugins in the Docker startup scripts).

With those important plugins bundled as part of ofbiz-framework, we could
then consider excluding the ofbiz-plugins repository from the release
process. System integrators would be responsible for retrieving any
non-bundled plugins that they use as part of their deployment process.

If bundling key plugins into ofbiz-framework is considered worthwhile,
which plugins should we bundle? Some suggestions might be:
- REST-API
- ecommerce
- birt (assuming it is brought up to date and is secure)
- passport / ldap
- solr

Please refer to [1] for some of the possible benefits and negatives to the
above as I think they are mostly still relevant even if only bundling a
subset of plugins into ofbiz-framework.

Thanks,

Dan.

[1] https://lists.apache.org/thread/jhjohny4ovb2tnpo6qpcwmz5m6513f57

Re: [VOTE] Apache OFBiz 18.12.09

[Jacques Le Roux]

Hi Daniel,

Now that with OFBIZ-13092 ecommerce is protected, at least so far. And as it's 
the most important plugin, we could indeed put it in the framework

That would also definitely resolve OFBIZ-9185.

Example (and exampleext) would be good to be put in too, maybe projectmgr and 
myportal. I'm also looking at birt with OFBIZ-5744

We should start a new thread about that and discuss about which plugins to 
integrate and what to release.

Jacques

Le 20/05/2024 à 11:12, Daniel Watford a écrit :

Hi Jacques,

I raised the topic of merging the plugins into ofbiz-framework a while ago,
mostly due to the difficulty I found matching branches between the
ofbiz-framework and ofbiz-plugins repositories and keeping the two in sync.

I don't think we went in depth on the topic, but I think the general
preference of the dev mailing list was to keep the two repositories
separate.

However, given your points about 'fragile' plugins, perhaps we could
consider moving those plugins we feel are robust and well used into
ofbiz-framework and leave those fragile plugins in the ofbiz-plugins
repository?

I know that I am banging the same old drum again with the above
suggestion(!) but I really do feel we will be able to better maintain those
favoured plugins more easily if they are kept alongside the core
ofbiz-framework code. The additional benefit is that it will be easier to
release those plugins we are more confident of if they are already in the
ofbiz-framework repository. Perhaps we would then mark those plugins as
disabled by default.

As far as 'framework only' distributions, I think this should be the
default approach we point users of ofbiz to. Interested users can then seek
out the plugins that meet their needs and install them by either retrieving
the relevant plugin files or running the appropriate gradle task.  We
already have framework-only versions of the docker images that we publish.

Thanks,

Dan.


On Mon, 20 May 2024 at 08:08, Jacques Le Roux 
wrote:


Hi,

This thread is already a 7 month "discussion", actually a vote. But I
don't remember another about this point (not releasing the plugins). So I
reuse
it, with a security perspective.

The last CVEs we had are possible because of ecommerce. A bunch of others
were related to Solr, etc.

I believe we would have much secure OFBiz releases if indeed we did not
include the more fragile plugins.

On the other hand when we fix these plugins vulnerabilities we also secure
their usage by our users.

But for ecommerce the problem is you can create an user without being
signed on. Because it's about open ecommerce. We can't seriously change
that,
can we?

Also I wonder how much people are using all the plugins. For some of them
I guess not much.

So what do you thing about Jacopo's proposition?

Jacques

Le 02/11/2023 à 11:18, Jacopo Cappellato a écrit :

Yes, the plugins are included in all the releases of 18.12; for newer
release branches we can definitely revisit this decision (in fact I
think it would be nice to have framework only distributions).

Re: [VOTE] Apache OFBiz 18.12.09

[Jacques Le Roux]

Hi,

This thread is already a 7 month "discussion", actually a vote. But I don't remember another about this point (not releasing the plugins). So I reuse 
it, with a security perspective.


The last CVEs we had are possible because of ecommerce. A bunch of others were 
related to Solr, etc.

I believe we would have much secure OFBiz releases if indeed we did not include 
the more fragile plugins.

On the other hand when we fix these plugins vulnerabilities we also secure 
their usage by our users.

But for ecommerce the problem is you can create an user without being signed on. Because it's about open ecommerce. We can't seriously change that, 
can we?


Also I wonder how much people are using all the plugins. For some of them I 
guess not much.

So what do you thing about Jacopo's proposition?

Jacques

Le 02/11/2023 à 11:18, Jacopo Cappellato a écrit :

Yes, the plugins are included in all the releases of 18.12; for newer
release branches we can definitely revisit this decision (in fact I
think it would be nice to have framework only distributions).

Re: Documention about createPlugin Gradle task

[Jacques Le Roux]

Le 19/05/2024 à 10:58, Jacques Le Roux a écrit :

Hi,

Is there somewhere some documentation about createPlugin Gradle task?

TIA

Jacques

Forgot, I did not find any at 
https://nightlies.apache.org/ofbiz/trunk/ofbiz/html5/developer-manual.html#_apache_ofbiz_plugins_for_developer

Documention about createPlugin Gradle task

[Jacques Le Roux]

Hi,

Is there somewhere some documentation about createPlugin Gradle task?

TIA

Jacques

Re: [OFBIZ-12935] Test 2.3.33 FreeMarker release - ASF JIRA

[Jacques Le Roux]

Hi Nicolas,

No thank you, I just wait for the Freemarker vote to pass...

I have also created 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+24.xx+Roadmap

HTH

Jacques

Le 14/05/2024 à 17:20, Nicolas Malin a écrit :

Hello Jacques,

Do you need some help to move forward on this subject ?

Nicolas

Le 28/03/2024 à 10:05, Jacques Le Roux a écrit :

Hi,

Without negative answer this week, I'll set the 2.3.33 version on trunk next 
week

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

TIA (for your tests see also the patch in OFBIZ-12934)

Jacques

Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Jacques Le Roux]

Le 09/05/2024 à 13:21, Jacques Le Roux a écrit :

Hi Michael,

Inline again

Le 08/05/2024 à 21:00, Jacques Le Roux a écrit :


3. suddenly there was a mass of new PR's which were merged in a hurry 
unneccesarily (my personal point of view), with some corrections soon after

4. 3. blocks 1. even further now because those changes are not complete/not 
rolled out for every component.


I'm unsure that these changes are not complete for every component and even if 
it's the case it should not block the creation of a release branch.
And if ever issues remain (not necessarily related to these changes) it's not a 
big deal to fix them once freezed.


Instead of 3. we should have delayed merging those new features and worked on the blocking issues of 2. to be able to create a release from an 
almost stable trunk.


So you speak about other known issues than 
https://issues.apache.org/jira/browse/OFBIZ-12995.
Have you a clear view about them ? Else my answer to 4. should be reassure you, 
not a big deal.

To complete, I guess you speak about 
https://issues.apache.org/jira/browse/OFBIZ-12928.
A large majority is completely done and resolved when needed (thanks to trunk 
demo logs)

Only 3 (on 46)  are pending:
https://issues.apache.org/jira/browse/OFBIZ-12951. I let a bit of time to 
Pierre. If it's still pending when we want to Freeze we should revert.
https://issues.apache.org/jira/browse/OFBIZ-12978. Nothing done there yet.
https://issues.apache.org/jira/browse/OFBIZ-13042. Waiting for a fix before 
pushing.

As ever with Pierre, we disagree about 
https://issues.apache.org/jira/browse/OFBIZ-13068.
As I said there, and knowing how it gets in such cases, I prefer to "keep this issue 
reopened and I'll not close your PR."

I have created 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+24.xx+Roadmap

Unrelated : I also plan to close a lot of old pending Jira soon...

Jacques


There is also https://issues.apache.org/jira/browse/OFBIZ-13049. But that's out 
of scope for the moment.

Re: Cleaning site repo

[Jacques Le Roux]

OK, make sense, let's wait

Le 09/05/2024 à 12:43, michael.br...@ecomify.de a écrit :

-1

I propose to wait until we have finished the move to the Hugo based website, 
review and then link to the corresponding confluence pages.

We are almost finished with Hugo, one of our students (Nurhak) takes care of 
it. He is currently at University and returns end of June to finish his work.

Best regards,

Michael



Am 09.05.2024 um 10:48 schrieb Jacques Le Roux :

Hi,

The pages

https://ofbiz.apache.org/user-stories.html
https://ofbiz.apache.org/service-providers.html
https://ofbiz.apache.org/about-ofbiz.html
https://ofbiz.apache.org/blog/ (It's only a link)

exists but are not maintained. I propose to remove them from the repo.
The News menu also would be now useless, so to be removed.

Opinions?

Jacques

Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Jacques Le Roux]

Hi Michael,

Inline again

Le 08/05/2024 à 21:00, Jacques Le Roux a écrit :


3. suddenly there was a mass of new PR's which were merged in a hurry 
unneccesarily (my personal point of view), with some corrections soon after

4. 3. blocks 1. even further now because those changes are not complete/not 
rolled out for every component.


I'm unsure that these changes are not complete for every component and even if 
it's the case it should not block the creation of a release branch.
And if ever issues remain (not necessarily related to these changes) it's not a 
big deal to fix them once freezed.


Instead of 3. we should have delayed merging those new features and worked on the blocking issues of 2. to be able to create a release from an 
almost stable trunk.


So you speak about other known issues than 
https://issues.apache.org/jira/browse/OFBIZ-12995.
Have you a clear view about them ? Else my answer to 4. should be reassure you, 
not a big deal.

To complete, I guess you speak about 
https://issues.apache.org/jira/browse/OFBIZ-12928.
A large majority is completely done and resolved when needed (thanks to trunk 
demo logs)

Only 3 (on 46)  are pending:
https://issues.apache.org/jira/browse/OFBIZ-12951. I let a bit of time to 
Pierre. If it's still pending when we want to Freeze we should revert.
https://issues.apache.org/jira/browse/OFBIZ-12978. Nothing done there yet.
https://issues.apache.org/jira/browse/OFBIZ-13042. Waiting for a fix before 
pushing.

As ever with Pierre, we disagree about 
https://issues.apache.org/jira/browse/OFBIZ-13068.
As I said there, and knowing how it gets in such cases, I prefer to "keep this issue 
reopened and I'll not close your PR."

I have created 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+24.xx+Roadmap

Unrelated : I also plan to close a lot of old pending Jira soon...

Jacques

Cleaning site repo

[Jacques Le Roux]

Hi,

The pages

https://ofbiz.apache.org/user-stories.html
https://ofbiz.apache.org/service-providers.html
https://ofbiz.apache.org/about-ofbiz.html
https://ofbiz.apache.org/blog/ (It's only a link)

exists but are not maintained. I propose to remove them from the repo.
The News menu also would be now useless, so to be removed.

Opinions?

Jacques

Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Jacques Le Roux]

Ah, last but not least: I think we should at least wait for Freemarker 2.3.33 that we successfully tested on demo. The vote should be soon, hence the 
release.


Le 08/05/2024 à 20:47, Jacques Le Roux a écrit :

Thanks to clarify Michael,

Inline when needed...

Le 08/05/2024 à 13:59, Michael Brohl a écrit :

Hi everyone,

my main point for having a roadmap and (if necessary) freezing trunk (for a short time) before creating a release branch in the future was to avoid 
the situation we have now:


1. we agreed to create a new release branch some time ago

2. there were some open tasks which blocked 1., mainly brought up by Jacques if 
I remember correctly


I guess you speak about https://issues.apache.org/jira/browse/OFBIZ-12995 ?




3. suddenly there was a mass of new PR's which were merged in a hurry 
unneccesarily (my personal point of view), with some corrections soon after

4. 3. blocks 1. even further now because those changes are not complete/not 
rolled out for every component.


I'm unsure that these changes are not complete for every component and even if 
it's the case it should not block the creation of a release branch.
And if ever issues remain (not necessarily related to these changes) it's not a 
big deal to fix them once freezed.


Instead of 3. we should have delayed merging those new features and worked on the blocking issues of 2. to be able to create a release from an 
almost stable trunk.


So you speak about other known issues than 
https://issues.apache.org/jira/browse/OFBIZ-12995.
Have you a clear view about them ? Else my answer to 4. should be reassure you, 
not a big deal.
What helped me a lot in this recent experience is to review the demos logs 
(stable and trunk).
I remember a project I worked on and was the last person to leave because they 
needed me to scrutinise the logs :)




If we had a roadmap, I think we would have discussed 3. before it was happening and decided to wait merging those new features in favor of working 
on the creation of the new branch.

That would be good, we used roadmaps in the past. Not all among them were 
successful or even followed.

IIRW the 1st one was mostly successful: 
https://cwiki.apache.org/confluence/display/OFBIZ/4.x+Proposed+Roadmap+Items

Others maybe less, just search "roadmap" in the wiki. Most were created by Sharan. Just to give an idea, here is one roadmap seriously discussed 
(most others were less).

https://cwiki.apache.org/confluence/display/OFBIZ/Roadmap+Diagrams+-+In+Progress

We also need to plan the time we want to give to fix the release branch before 
releasing. We use to finish it in the current year.
From my OFBiz experience, it's just a plan anyway, ie it can be shorter or 
longer.




My approach is simply about some structure, coordination and collaboration to reach goals the project has defined instead of going with the flow of 
incoming pull requests.


I hope I was more clear now.


Yes, thanks

Jacques



Thanks and regards,

Michael


Am 07.05.24 um 17:19 schrieb Pranay Pandey:

Hi Daniel,

I am in favor of creating a new release.

After we create a new release, IMO we shouldn't be committing any new
features there.

This is critical that we limit the scope of release with ongoing
development in the trunk.

Best regards,
Pranay Pandey


On Tue, 7 May 2024 at 20:31, Daniel Watford  wrote:


Hi Jacques,

I'm sorry, but I can't quite parse your question, 'What is the
difference...'.   Could you restate it another way?

Are you asking what the difference is between enforcing a feature-freeze on
trunk versus continuing to allow all changes to trunk whilst having a
feature-freeze on a release branch (e.g. release-24.x)?

I think it will be very difficult to define a prescriptive policy on what
sort of fixes might be permitted on a release branch (e.g. release-24.x),
but the availability of committers to do the work of applying patches to
the branch might help us reach a de facto policy.

I personally would want to avoid backporting changes from trunk to a
release branch without good reason since I view this as duplicate work.
Therefore I would only want to backport fixes from trunk to release where
we have a defect that impacts users or if we felt that some new feature was
very very very important to OFBiz that it couldn't wait for the future
release branch.

If it helps, the project has used the phrase 'This series has been
stabilized with bug fixes since' on the Release History page:
https://downloads.apache.org/ofbiz/. I would interpret this as the release
branch was used to *stabilise* the features that were in trunk at the time
the release branch was created.

I fear that we all might be roughly in agreement but getting lost in the
weeds of discussion.

Should we go ahead and create a release-24.05 branch from trunk soon for
the purpose of stabilising a future release? Or are there any important
features that OFBiz developers wa

Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Jacques Le Roux]

e-24.05 branch will increase the test
burden before a public release can be made?

Thanks,

Dan.

On Tue, 7 May 2024 at 15:20, Jacques Le Roux 
What is the difference between freezing the trunk in a release-24.xx

where

the rule is no improvements but if a consensus agrees with? In other

words,

apart exceptions only bugs and not only blockers,as we did so far and the
"new" proposition? Do we really wants to backport only blockerbugs? And
then
what is a blocker bug, only security?

Somehow related, I also remember we freezed the trunk in few branches

that

we never released. 14.12 and 15.12 come to mind:
https://ofbiz.apache.org/download.html

HTH

Jacques

Le 07/05/2024 à 15:11, Pranay Pandey a écrit :

Dear Daniel,

Thank you for outlining the proposed release strategy for OFBiz. I

liked

the idea of creating a new branch from trunk named 'release-24.05' to
address blockers for the upcoming release.

I agree with Michael's proposal that targeting a release while working

on

the trunk is worth considering. Maintaining a consistent flow of new
releases is crucial for project success. New releases with smaller

changes

are not only easier to adopt but also facilitate a smoother migration

for

existing ERP implementations, especially if users find value in the new
features introduced.

I believe this approach aligns well with the project's goals and will

help

in ensuring a structured and efficient release process. Let's continue

the

discussion on how we can further enhance this strategy to benefit the

OFBiz

development community.

Thank you for your efforts in driving this conversation forward.

Best regards,

Pranay Pandey


On Tue, 7 May 2024 at 13:36, Daniel Watford  wrote:


Hello all,

I'm a little confused by what the differences in opinions actually are

in

this thread. I think this is because the differences are minor and we

are

probably close to an agreement on how to proceed.

Although there are not many of us involved in this conversation, it

seems

there is a desire to NOT impose any sort of feature freeze on the

trunk

branch.

Instead we take the approach of creating a new branch from trunk,

named

something like 'release-24.05'. The purpose of this new branch is to
address any issues that might be considered blockers for an upcoming

OFBiz

release. New features would not normally be applied to the

release-24.05

branch, but exceptions to this rule would be considered on a

case-by-case

basis.

Issues blocking an OFBiz 24.05.xx release would be tracked in Jira,

and

once addressed the release would be made public. A suitable tag - e.g.
release-24.05.01 - would be applied to the release-24.05 branch to

denote

the commit that was publicly released.

I believe the above describes how the OFBiz project has managed

releases in

the past.

The discussions around a road map are orthogonal to the above release
process, but would definitely help the OFBiz development community/PMC
decide when would be an appropriate time to create a new release

branch.

It seems like the major project undertakings - such as the movement of
Groovy Scripts within the source tree - have been completed, so now

might

be a good time to go ahead and create the release-24.05 branch from

trunk.

Thanks,

Dan.

On Mon, 6 May 2024 at 18:01, Jacques Le Roux <

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

wrote:


Le 06/05/2024 à 18:35, Jacques Le Roux a écrit :

BTW, to avoid to speak in the void. Again, what are those tasks

precisely? And that are their situations?

BTW, to avoid to speak in the void. Again, what are those tasks

precisely?

And WHAT are their situations?

Sorry, typo



--
Daniel Watford




--
Daniel Watford

Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Jacques Le Roux]

Thanks for confirming

Le 08/05/2024 à 15:45, Pranay Pandey a écrit :

Hi Jacques,

Yeah, I wanted to say that. As long as we are sure of test coverage, all
the critical paths are working.

Best regards,
Pranay Pandey


On Tue, 7 May 2024 at 22:11, Jacques Le Roux 
wrote:


Ha sorry Pranay,

I did not get your point, I guess you were discussing before frezzing the
release branch, right?
Then of course we can't guarantee to have fixed all known bugs.
Only blocker bugs (decided by the reporter and discussed if needed) and of
course security bugs are blocking a release.

Jacques

Le 07/05/2024 à 17:42, Jacques Le Roux a écrit :

Hi Pranay,

OK, but then only that? So far we backported any bug. So we would

release a branch with bugs in?

Le 07/05/2024 à 16:42, Pranay Pandey a écrit :

Hi Jacques,

what is a blocker bug, only security?
I think it should also include anything broken on the UI or at the

process

level.

Best regards,
Pranay Pandey


On Tue, 7 May 2024 at 19:48, Jacques Le Roux <

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

wrote:


What is the difference between freezing the trunk in a release-24.xx

where

the rule is no improvements but if a consensus agrees with? In other

words,

apart exceptions only bugs and not only blockers,as we did so far and

the

"new" proposition? Do we really wants to backport only blockerbugs? And
then
what is a blocker bug, only security?

Somehow related, I also remember we freezed the trunk in few branches

that

we never released. 14.12 and 15.12 come to mind:
https://ofbiz.apache.org/download.html

HTH

Jacques

Le 07/05/2024 à 15:11, Pranay Pandey a écrit :

Dear Daniel,

Thank you for outlining the proposed release strategy for OFBiz. I

liked

the idea of creating a new branch from trunk named 'release-24.05' to
address blockers for the upcoming release.

I agree with Michael's proposal that targeting a release while

working on

the trunk is worth considering. Maintaining a consistent flow of new
releases is crucial for project success. New releases with smaller

changes

are not only easier to adopt but also facilitate a smoother migration

for

existing ERP implementations, especially if users find value in the

new

features introduced.

I believe this approach aligns well with the project's goals and will

help

in ensuring a structured and efficient release process. Let's continue

the

discussion on how we can further enhance this strategy to benefit the

OFBiz

development community.

Thank you for your efforts in driving this conversation forward.

Best regards,

Pranay Pandey


On Tue, 7 May 2024 at 13:36, Daniel Watford  wrote:


Hello all,

I'm a little confused by what the differences in opinions actually

are

in

this thread. I think this is because the differences are minor and we

are

probably close to an agreement on how to proceed.

Although there are not many of us involved in this conversation, it

seems

there is a desire to NOT impose any sort of feature freeze on the

trunk

branch.

Instead we take the approach of creating a new branch from trunk,

named

something like 'release-24.05'. The purpose of this new branch is to
address any issues that might be considered blockers for an upcoming

OFBiz

release. New features would not normally be applied to the

release-24.05

branch, but exceptions to this rule would be considered on a

case-by-case

basis.

Issues blocking an OFBiz 24.05.xx release would be tracked in Jira,

and

once addressed the release would be made public. A suitable tag -

e.g.

release-24.05.01 - would be applied to the release-24.05 branch to

denote

the commit that was publicly released.

I believe the above describes how the OFBiz project has managed

releases in

the past.

The discussions around a road map are orthogonal to the above release
process, but would definitely help the OFBiz development

community/PMC

decide when would be an appropriate time to create a new release

branch.

It seems like the major project undertakings - such as the movement

of

Groovy Scripts within the source tree - have been completed, so now

might

be a good time to go ahead and create the release-24.05 branch from

trunk.

Thanks,

Dan.

On Mon, 6 May 2024 at 18:01, Jacques Le Roux <

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

wrote:


Le 06/05/2024 à 18:35, Jacques Le Roux a écrit :

BTW, to avoid to speak in the void. Again, what are those tasks

precisely? And that are their situations?

BTW, to avoid to speak in the void. Again, what are those tasks

precisely?

And WHAT are their situations?

Sorry, typo



--
Daniel Watford

CVE-2024-32113: Apache OFBiz: Path traversal leading to RCE

[Jacques Le Roux]

Severity: important

Affected versions:

- Apache OFBiz before 18.12.13

Description:

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') 
vulnerability in Apache OFBiz.This issue affects Apache OFBiz: before 18.12.13.

Users are recommended to upgrade to version 18.12.13, which fixes the issue.

Credit:

Qiyi Zhang (RacerZ) @secsys from Fudan (finder)

References:

https://ofbiz.apache.org/download.html
https://ofbiz.apache.org/security.html
https://issues.apache.org/jira/browse/OFBIZ-13006
https://lists.apache.org/thread/np8vgzr06z6cwm3tz7cs3609bdrj8526
https://ofbiz.apache.org/
https://www.cve.org/CVERecord?id=CVE-2024-32113

Re: [VOTE] [RESULT] Apache OFBiz 18.12.13

[Jacques Le Roux]

OK, thanks Jacopo

Le 08/05/2024 à 13:50, Jacopo Cappellato a écrit :

Yes, it is normal because that is the dev distribution folder: as soon
as the release becomes official the files are moved to the official
distribution folder: https://downloads.apache.org/ofbiz/

Jacopo

On Tue, May 7, 2024 at 4:07 PM Jacques Le Roux
 wrote:

Hi Jacopo,

I see only KEYS

TIA

Jacqued

Le 07/05/2024 à 11:41, Jacopo Cappellato a écrit :

The vote is successful with seven positive votes (all binding) and no
negative votes.
I am going to publish and announce the release soon.

Jacopo

On Tue, Apr 30, 2024 at 5:06 PM Jacopo Cappellato
 wrote:

This is the vote thread to publish "Apache OFBiz 18.12.13", the thirteenth
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.13.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.13.zip.asc: the detached signature file
* apache-ofbiz-18.12.13.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 18.12.13
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Jacques Le Roux]

I totally agree, our enemy is regression and we should be very sure to avoid it.

Le 07/05/2024 à 17:19, Pranay Pandey a écrit :

Hi Daniel,

I am in favor of creating a new release.

After we create a new release, IMO we shouldn't be committing any new
features there.

This is critical that we limit the scope of release with ongoing
development in the trunk.

Best regards,
Pranay Pandey


On Tue, 7 May 2024 at 20:31, Daniel Watford  wrote:


Hi Jacques,

I'm sorry, but I can't quite parse your question, 'What is the
difference...'.   Could you restate it another way?

Are you asking what the difference is between enforcing a feature-freeze on
trunk versus continuing to allow all changes to trunk whilst having a
feature-freeze on a release branch (e.g. release-24.x)?

I think it will be very difficult to define a prescriptive policy on what
sort of fixes might be permitted on a release branch (e.g. release-24.x),
but the availability of committers to do the work of applying patches to
the branch might help us reach a de facto policy.

I personally would want to avoid backporting changes from trunk to a
release branch without good reason since I view this as duplicate work.
Therefore I would only want to backport fixes from trunk to release where
we have a defect that impacts users or if we felt that some new feature was
very very very important to OFBiz that it couldn't wait for the future
release branch.

If it helps, the project has used the phrase 'This series has been
stabilized with bug fixes since' on the Release History page:
https://downloads.apache.org/ofbiz/. I would interpret this as the release
branch was used to *stabilise* the features that were in trunk at the time
the release branch was created.

I fear that we all might be roughly in agreement but getting lost in the
weeds of discussion.

Should we go ahead and create a release-24.05 branch from trunk soon for
the purpose of stabilising a future release? Or are there any important
features that OFBiz developers want to see in trunk first?

As far as which commits are later applied to the release-24.05 branch,
shall we leave that up to the committers at the time, but with a reminder
that adding new features on the release-24.05 branch will increase the test
burden before a public release can be made?

Thanks,

Dan.

On Tue, 7 May 2024 at 15:20, Jacques Le Roux 
What is the difference between freezing the trunk in a release-24.xx

where

the rule is no improvements but if a consensus agrees with? In other

words,

apart exceptions only bugs and not only blockers,as we did so far and the
"new" proposition? Do we really wants to backport only blockerbugs? And
then
what is a blocker bug, only security?

Somehow related, I also remember we freezed the trunk in few branches

that

we never released. 14.12 and 15.12 come to mind:
https://ofbiz.apache.org/download.html

HTH

Jacques

Le 07/05/2024 à 15:11, Pranay Pandey a écrit :

Dear Daniel,

Thank you for outlining the proposed release strategy for OFBiz. I

liked

the idea of creating a new branch from trunk named 'release-24.05' to
address blockers for the upcoming release.

I agree with Michael's proposal that targeting a release while working

on

the trunk is worth considering. Maintaining a consistent flow of new
releases is crucial for project success. New releases with smaller

changes

are not only easier to adopt but also facilitate a smoother migration

for

existing ERP implementations, especially if users find value in the new
features introduced.

I believe this approach aligns well with the project's goals and will

help

in ensuring a structured and efficient release process. Let's continue

the

discussion on how we can further enhance this strategy to benefit the

OFBiz

development community.

Thank you for your efforts in driving this conversation forward.

Best regards,

Pranay Pandey


On Tue, 7 May 2024 at 13:36, Daniel Watford  wrote:


Hello all,

I'm a little confused by what the differences in opinions actually are

in

this thread. I think this is because the differences are minor and we

are

probably close to an agreement on how to proceed.

Although there are not many of us involved in this conversation, it

seems

there is a desire to NOT impose any sort of feature freeze on the

trunk

branch.

Instead we take the approach of creating a new branch from trunk,

named

something like 'release-24.05'. The purpose of this new branch is to
address any issues that might be considered blockers for an upcoming

OFBiz

release. New features would not normally be applied to the

release-24.05

branch, but exceptions to this rule would be considered on a

case-by-case

basis.

Issues blocking an OFBiz 24.05.xx release would be tracked in Jira,

and

once addressed the release would be made public. A suitable tag - e.g.
release-24.05.01 - would be applied to the release-24.05 br

Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Jacques Le Roux]

Ha sorry Pranay,

I did not get your point, I guess you were discussing before frezzing the 
release branch, right?
Then of course we can't guarantee to have fixed all known bugs.
Only blocker bugs (decided by the reporter and discussed if needed) and of 
course security bugs are blocking a release.

Jacques

Le 07/05/2024 à 17:42, Jacques Le Roux a écrit :

Hi Pranay,

OK, but then only that? So far we backported any bug. So we would release a 
branch with bugs in?

Le 07/05/2024 à 16:42, Pranay Pandey a écrit :

Hi Jacques,

what is a blocker bug, only security?
I think it should also include anything broken on the UI or at the process
level.

Best regards,
Pranay Pandey


On Tue, 7 May 2024 at 19:48, Jacques Le Roux 
wrote:


What is the difference between freezing the trunk in a release-24.xx where
the rule is no improvements but if a consensus agrees with? In other words,
apart exceptions only bugs and not only blockers,as we did so far and the
"new" proposition? Do we really wants to backport only blockerbugs? And
then
what is a blocker bug, only security?

Somehow related, I also remember we freezed the trunk in few branches that
we never released. 14.12 and 15.12 come to mind:
https://ofbiz.apache.org/download.html

HTH

Jacques

Le 07/05/2024 à 15:11, Pranay Pandey a écrit :

Dear Daniel,

Thank you for outlining the proposed release strategy for OFBiz. I liked
the idea of creating a new branch from trunk named 'release-24.05' to
address blockers for the upcoming release.

I agree with Michael's proposal that targeting a release while working on
the trunk is worth considering. Maintaining a consistent flow of new
releases is crucial for project success. New releases with smaller

changes

are not only easier to adopt but also facilitate a smoother migration for
existing ERP implementations, especially if users find value in the new
features introduced.

I believe this approach aligns well with the project's goals and will

help

in ensuring a structured and efficient release process. Let's continue

the

discussion on how we can further enhance this strategy to benefit the

OFBiz

development community.

Thank you for your efforts in driving this conversation forward.

Best regards,

Pranay Pandey


On Tue, 7 May 2024 at 13:36, Daniel Watford  wrote:


Hello all,

I'm a little confused by what the differences in opinions actually are

in

this thread. I think this is because the differences are minor and we

are

probably close to an agreement on how to proceed.

Although there are not many of us involved in this conversation, it

seems

there is a desire to NOT impose any sort of feature freeze on the trunk
branch.

Instead we take the approach of creating a new branch from trunk, named
something like 'release-24.05'. The purpose of this new branch is to
address any issues that might be considered blockers for an upcoming

OFBiz

release. New features would not normally be applied to the release-24.05
branch, but exceptions to this rule would be considered on a

case-by-case

basis.

Issues blocking an OFBiz 24.05.xx release would be tracked in Jira, and
once addressed the release would be made public. A suitable tag - e.g.
release-24.05.01 - would be applied to the release-24.05 branch to

denote

the commit that was publicly released.

I believe the above describes how the OFBiz project has managed

releases in

the past.

The discussions around a road map are orthogonal to the above release
process, but would definitely help the OFBiz development community/PMC
decide when would be an appropriate time to create a new release branch.

It seems like the major project undertakings - such as the movement of
Groovy Scripts within the source tree - have been completed, so now

might

be a good time to go ahead and create the release-24.05 branch from

trunk.

Thanks,

Dan.

On Mon, 6 May 2024 at 18:01, Jacques Le Roux <

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

wrote:


Le 06/05/2024 à 18:35, Jacques Le Roux a écrit :

BTW, to avoid to speak in the void. Again, what are those tasks

precisely? And that are their situations?

BTW, to avoid to speak in the void. Again, what are those tasks

precisely?

And WHAT are their situations?

Sorry, typo



--
Daniel Watford

Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Jacques Le Roux]

Le 07/05/2024 à 17:01, Daniel Watford a écrit :

Hi Jacques,

I'm sorry, but I can't quite parse your question, 'What is the
difference...'.   Could you restate it another way?


Simple, what is the process so far?

We freeze the trunk into a release branch, says 24.xx in our case
.05 seems short to me, though possible, as we need to check the situation for 
important things to be complete (or not), like OFBIZ-9350
I see the recent good will of Nicolas about that. We should not put the 
pression on anybody. Errors come from such situations.

Then improvements are of course allowed in trunk but not in 24.xx apart 
exceptions agreed with a consensus (lazy or not, ie with a vote)
As we use the CTR (Commit Then Review) mode it's always possible to revert 
before releasing, here 24.xx. So no known damage is theoretically possible.

Blocker bugs are used to prevent a release as long as not fixed, as mentioned 
at :
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
There is no strict definition for a blocker bug. The reporter decides. It can 
be then discussed.
Of course security is blocking, but we don't publish any information about it 
before releasing. Else it's a zero day for attackers.



Are you asking what the difference is between enforcing a feature-freeze on
trunk versus continuing to allow all changes to trunk whilst having a
feature-freeze on a release branch (e.g. release-24.x)?


I just try to explain that the current process is OK.
We never feature-freezed the trunk but the upcoming release, again with very 
rare exceptions.
So I'd like to know what should be changed if any.



I think it will be very difficult to define a prescriptive policy on what
sort of fixes might be permitted on a release branch (e.g. release-24.x),
but the availability of committers to do the work of applying patches to
the branch might help us reach a de facto policy.


I agree about that. We have never been able to fix all bugs. Just blocker bugs 
block the release and that can be discussed.
For blocker bugs, if we don't agree in Jira or PR we discuss it on dev ML to 
tend to a consensus. That can be a lazy one (no vote) if nobody is against.



I personally would want to avoid backporting changes from trunk to a
release branch without good reason since I view this as duplicate work.


Only bugs are backported, except (very rare) exceptions



Therefore I would only want to backport fixes from trunk to release where
we have a defect that impacts users or if we felt that some new feature was
very very very important to OFBiz that it couldn't wait for the future
release branch.


And if everybody is OK. A veto can block a commit (not a release) but that must 
be justified:
https://www.apache.org/foundation/voting.html



If it helps, the project has used the phrase 'This series has been
stabilized with bug fixes since' on the Release History page:
https://downloads.apache.org/ofbiz/. I would interpret this as the release
branch was used to *stabilise* the features that were in trunk at the time
the release branch was created.


Yes that's it. We could maybe slightly change this sentence to explain that 
very important improvements may be rarely backported.



I fear that we all might be roughly in agreement but getting lost in the
weeds of discussion.


Exactly, the devil is in the details and we get sometimes lost.




Should we go ahead and create a release-24.05 branch from trunk soon for
the purpose of stabilising a future release? Or are there any important
features that OFBiz developers want to see in trunk first?


That need to be discussed IMO. With clear cases, like OFBIZ-9350 but not only.
We still need to find and agree about possible other cases I guess, hence 3 
weeks being short to me.



As far as which commits are later applied to the release-24.05 branch,
shall we leave that up to the committers at the time, but with a reminder
that adding new features on the release-24.05 branch will increase the test
burden before a public release can be made?


I prefer that we openly discuss that here (dev ML) before allowing improvements 
in release branches.

I hope I'm clear :)

Thanks

Jacques




Thanks,

Dan.

On Tue, 7 May 2024 at 15:20, Jacques Le Roux
wrote:


What is the difference between freezing the trunk in a release-24.xx where
the rule is no improvements but if a consensus agrees with? In other words,
apart exceptions only bugs and not only blockers,as we did so far and the
"new" proposition? Do we really wants to backport only blockerbugs? And
then
what is a blocker bug, only security?

Somehow related, I also remember we freezed the trunk in few branches that
we never released. 14.12 and 15.12 come to mind:
https://ofbiz.apache.org/download.html

HTH

Jacques

Le 07/05/2024 à 15:11, Pranay Pandey a écrit :

Dear Daniel,

Thank you for outlining the proposed release strategy for OFBi

Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Jacques Le Roux]

Hi Pranay,

OK, but then only that? So far we backported any bug. So we would release a 
branch with bugs in?

Le 07/05/2024 à 16:42, Pranay Pandey a écrit :

Hi Jacques,

what is a blocker bug, only security?
I think it should also include anything broken on the UI or at the process
level.

Best regards,
Pranay Pandey


On Tue, 7 May 2024 at 19:48, Jacques Le Roux 
wrote:


What is the difference between freezing the trunk in a release-24.xx where
the rule is no improvements but if a consensus agrees with? In other words,
apart exceptions only bugs and not only blockers,as we did so far and the
"new" proposition? Do we really wants to backport only blockerbugs? And
then
what is a blocker bug, only security?

Somehow related, I also remember we freezed the trunk in few branches that
we never released. 14.12 and 15.12 come to mind:
https://ofbiz.apache.org/download.html

HTH

Jacques

Le 07/05/2024 à 15:11, Pranay Pandey a écrit :

Dear Daniel,

Thank you for outlining the proposed release strategy for OFBiz. I liked
the idea of creating a new branch from trunk named 'release-24.05' to
address blockers for the upcoming release.

I agree with Michael's proposal that targeting a release while working on
the trunk is worth considering. Maintaining a consistent flow of new
releases is crucial for project success. New releases with smaller

changes

are not only easier to adopt but also facilitate a smoother migration for
existing ERP implementations, especially if users find value in the new
features introduced.

I believe this approach aligns well with the project's goals and will

help

in ensuring a structured and efficient release process. Let's continue

the

discussion on how we can further enhance this strategy to benefit the

OFBiz

development community.

Thank you for your efforts in driving this conversation forward.

Best regards,

Pranay Pandey


On Tue, 7 May 2024 at 13:36, Daniel Watford  wrote:


Hello all,

I'm a little confused by what the differences in opinions actually are

in

this thread. I think this is because the differences are minor and we

are

probably close to an agreement on how to proceed.

Although there are not many of us involved in this conversation, it

seems

there is a desire to NOT impose any sort of feature freeze on the trunk
branch.

Instead we take the approach of creating a new branch from trunk, named
something like 'release-24.05'. The purpose of this new branch is to
address any issues that might be considered blockers for an upcoming

OFBiz

release. New features would not normally be applied to the release-24.05
branch, but exceptions to this rule would be considered on a

case-by-case

basis.

Issues blocking an OFBiz 24.05.xx release would be tracked in Jira, and
once addressed the release would be made public. A suitable tag - e.g.
release-24.05.01 - would be applied to the release-24.05 branch to

denote

the commit that was publicly released.

I believe the above describes how the OFBiz project has managed

releases in

the past.

The discussions around a road map are orthogonal to the above release
process, but would definitely help the OFBiz development community/PMC
decide when would be an appropriate time to create a new release branch.

It seems like the major project undertakings - such as the movement of
Groovy Scripts within the source tree - have been completed, so now

might

be a good time to go ahead and create the release-24.05 branch from

trunk.

Thanks,

Dan.

On Mon, 6 May 2024 at 18:01, Jacques Le Roux <

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

wrote:


Le 06/05/2024 à 18:35, Jacques Le Roux a écrit :

BTW, to avoid to speak in the void. Again, what are those tasks

precisely? And that are their situations?

BTW, to avoid to speak in the void. Again, what are those tasks

precisely?

And WHAT are their situations?

Sorry, typo



--
Daniel Watford

Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Jacques Le Roux]

What is the difference between freezing the trunk in a release-24.xx where the rule is no improvements but if a consensus agrees with? In other words, 
apart exceptions only bugs and not only blockers,as we did so far and the "new" proposition? Do we really wants to backport only blockerbugs? And then 
what is a blocker bug, only security?


Somehow related, I also remember we freezed the trunk in few branches that we never released. 14.12 and 15.12 come to mind: 
https://ofbiz.apache.org/download.html


HTH

Jacques

Le 07/05/2024 à 15:11, Pranay Pandey a écrit :

Dear Daniel,

Thank you for outlining the proposed release strategy for OFBiz. I liked
the idea of creating a new branch from trunk named 'release-24.05' to
address blockers for the upcoming release.

I agree with Michael's proposal that targeting a release while working on
the trunk is worth considering. Maintaining a consistent flow of new
releases is crucial for project success. New releases with smaller changes
are not only easier to adopt but also facilitate a smoother migration for
existing ERP implementations, especially if users find value in the new
features introduced.

I believe this approach aligns well with the project's goals and will help
in ensuring a structured and efficient release process. Let's continue the
discussion on how we can further enhance this strategy to benefit the OFBiz
development community.

Thank you for your efforts in driving this conversation forward.

Best regards,

Pranay Pandey


On Tue, 7 May 2024 at 13:36, Daniel Watford  wrote:


Hello all,

I'm a little confused by what the differences in opinions actually are in
this thread. I think this is because the differences are minor and we are
probably close to an agreement on how to proceed.

Although there are not many of us involved in this conversation, it seems
there is a desire to NOT impose any sort of feature freeze on the trunk
branch.

Instead we take the approach of creating a new branch from trunk, named
something like 'release-24.05'. The purpose of this new branch is to
address any issues that might be considered blockers for an upcoming OFBiz
release. New features would not normally be applied to the release-24.05
branch, but exceptions to this rule would be considered on a case-by-case
basis.

Issues blocking an OFBiz 24.05.xx release would be tracked in Jira, and
once addressed the release would be made public. A suitable tag - e.g.
release-24.05.01 - would be applied to the release-24.05 branch to denote
the commit that was publicly released.

I believe the above describes how the OFBiz project has managed releases in
the past.

The discussions around a road map are orthogonal to the above release
process, but would definitely help the OFBiz development community/PMC
decide when would be an appropriate time to create a new release branch.

It seems like the major project undertakings - such as the movement of
Groovy Scripts within the source tree - have been completed, so now might
be a good time to go ahead and create the release-24.05 branch from trunk.

Thanks,

Dan.

On Mon, 6 May 2024 at 18:01, Jacques Le Roux 
Le 06/05/2024 à 18:35, Jacques Le Roux a écrit :

BTW, to avoid to speak in the void. Again, what are those tasks

precisely? And that are their situations?

BTW, to avoid to speak in the void. Again, what are those tasks

precisely?

And WHAT are their situations?

Sorry, typo



--
Daniel Watford

Re: [VOTE] [RESULT] Apache OFBiz 18.12.13

[Jacques Le Roux]

Hi Jacopo,

I see only KEYS

TIA

Jacqued

Le 07/05/2024 à 11:41, Jacopo Cappellato a écrit :

The vote is successful with seven positive votes (all binding) and no
negative votes.
I am going to publish and announce the release soon.

Jacopo

On Tue, Apr 30, 2024 at 5:06 PM Jacopo Cappellato
 wrote:

This is the vote thread to publish "Apache OFBiz 18.12.13", the thirteenth
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.13.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.13.zip.asc: the detached signature file
* apache-ofbiz-18.12.13.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 18.12.13
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Jacques Le Roux]

Le 06/05/2024 à 18:35, Jacques Le Roux a écrit :
BTW, to avoid to speak in the void. Again, what are those tasks precisely? And that are their situations? 


BTW, to avoid to speak in the void. Again, what are those tasks precisely? And 
WHAT are their situations?

Sorry, typo

Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Jacques Le Roux]

BTW, to avoid to speak in the void. Again, what are those tasks precisely? And 
that are their situations?

Le 06/05/2024 à 18:24, Jacques Le Roux a écrit :

Hi Stephen,

As I can see it, because of the number of people really involved in such tasks.

Jacques

Le 06/05/2024 à 17:45, Stephen Davidson a écrit :

Good afternoon.

Maybe I am missing something, but why can't WIP be executed finished & 
stabilized on the Release Branch and then merged to Trunk?

Regards,
Steve

On 5/6/24 04:07, Jacques Le Roux wrote:

Hi,

We should 1st clearly identify WIPs in trunk and at which stage they are each.

We can't wait and complicate the situation before that.

Jacques

Le 06/05/2024 à 10:36, gil.portenseigne a écrit :

Hi,

I feel like Michael, when there are 'in progress' work in trunk, when we
create a release branch for stabilisation, the remaining work of such
task will only be in trunk (since those are improvements).

But delaying release is not good when we look at the name of our last
release that show the 2018 year.

The concession we could agree on should be to identify such tasks to let
user know the partial improvements contained in the release.

i.e. creating release branch + roadmap :)

WDYT ?

Gil
On 22/04/24 04:12, Jacques Le Roux wrote:

Hi Guys,

Without getting into details, I tend to disagree with your propositions. I 
can't see why we would change our very simple way of doing.

When we freeze a branch, the activity can continue on trunk. It does not 
interfere with the new release branch.
The only variable is the period we allow before releasing the branch. Then, 
that depends on the breaking changes (or not) we recently made.

Why should we change? I fear it will rather introduce complications. Please 
keep it simple.

TIA for your explanations on simple reasons to change : what is wrong with our 
current way of doing?

Jacques

Le 22/04/2024 à 09:37, Daniel Watford a écrit :

Hi Michael,

I'm broadly in favour of your proposal, but perhaps with a slightly
different 'shape' to the approach.

I too was hoping that we could freeze trunk before creating a 24.x release
branch as I was concerned about the about of duplicate work (backporting)
that might need to be done if we took a 24.x release branch earlier in the
year, but alas trunk marches on and I think it will be difficult to
mandate a period of release-related-only changes in trunk.

Instead I think, as Deepak mentioned, we should take a new 24.x branch to
use for stabilisation - with tags denoting the actual releases along that
branch. It feels that the large projects - such as groovy-scripts migration
- have completed which should reduce the amount of rework that would have
to take place simultaneously on trunk and the 24.x release branch.

>From your comments I infer that you may be suggesting yearly releases. I
think this is a good idea as it will allow the introduction of major new
functionalities in trunk without needing to wait years for them to become
generally accessible. Without more frequent releases we will have the
temptation to port major functionality into already existing release
branches which might take a large amount of effort and could introduce
instability between minor releases. I hope my inference reflects your
intended proposal! :)

Yes to a roadmap.

Thanks,

Dan.


On Sun, 21 Apr 2024 at 14:50, Michael Brohl 
wrote:


Hi everyone,

we agreed to work towards a stabilizing trunk to be able to create a
24.x release branch, which means we have to thoroughly decide which
changes should go into trunk. There are currently lots of changes going
into trunk with PR's created and rapidly be merged into the codebase.
This causes potential for errors being introduced in trunk, potentially
leading to delay the creation of the next release branch even more.

In my opinion, this is contraproductive to the goal of creating a stable
release branch 24.x in due time.

I propose to make a decision to have a code freeze for new features and
improvements and focus on bug fixes until we have created a 24.x branch.

I also propose that we start organizing a roadmap to give the community
some guidelines where to focus and which main features can be expected
in the next release branches. It might also give developers some goals
to provide the features according to planned releases and maybe work
together to reach those project goals.

For example, there are some initiatives for Tomcat migration,
introducing REST functionality in the framework and others which we can
assign to future release branches. Maybe we can have a plan for a 25.x
release branch which introduces those features.

I do not intend to make this an unflexible roadmap, means there can
always be more planned/unplanned features be added to the roadmap and be
discussed. We should have some deadlines for new features though, just
to be able to create the next feature branch in the planned time periods.

What do yo

Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Jacques Le Roux]

Hi Stephen,

As I can see it, because of the number of people really involved in such tasks.

Jacques

Le 06/05/2024 à 17:45, Stephen Davidson a écrit :

Good afternoon.

Maybe I am missing something, but why can't WIP be executed finished & 
stabilized on the Release Branch and then merged to Trunk?

Regards,
Steve

On 5/6/24 04:07, Jacques Le Roux wrote:

Hi,

We should 1st clearly identify WIPs in trunk and at which stage they are each.

We can't wait and complicate the situation before that.

Jacques

Le 06/05/2024 à 10:36, gil.portenseigne a écrit :

Hi,

I feel like Michael, when there are 'in progress' work in trunk, when we
create a release branch for stabilisation, the remaining work of such
task will only be in trunk (since those are improvements).

But delaying release is not good when we look at the name of our last
release that show the 2018 year.

The concession we could agree on should be to identify such tasks to let
user know the partial improvements contained in the release.

i.e. creating release branch + roadmap :)

WDYT ?

Gil
On 22/04/24 04:12, Jacques Le Roux wrote:

Hi Guys,

Without getting into details, I tend to disagree with your propositions. I 
can't see why we would change our very simple way of doing.

When we freeze a branch, the activity can continue on trunk. It does not 
interfere with the new release branch.
The only variable is the period we allow before releasing the branch. Then, 
that depends on the breaking changes (or not) we recently made.

Why should we change? I fear it will rather introduce complications. Please 
keep it simple.

TIA for your explanations on simple reasons to change : what is wrong with our 
current way of doing?

Jacques

Le 22/04/2024 à 09:37, Daniel Watford a écrit :

Hi Michael,

I'm broadly in favour of your proposal, but perhaps with a slightly
different 'shape' to the approach.

I too was hoping that we could freeze trunk before creating a 24.x release
branch as I was concerned about the about of duplicate work (backporting)
that might need to be done if we took a 24.x release branch earlier in the
year, but alas trunk marches on and I think it will be difficult to
mandate a period of release-related-only changes in trunk.

Instead I think, as Deepak mentioned, we should take a new 24.x branch to
use for stabilisation - with tags denoting the actual releases along that
branch. It feels that the large projects - such as groovy-scripts migration
- have completed which should reduce the amount of rework that would have
to take place simultaneously on trunk and the 24.x release branch.

>From your comments I infer that you may be suggesting yearly releases. I
think this is a good idea as it will allow the introduction of major new
functionalities in trunk without needing to wait years for them to become
generally accessible. Without more frequent releases we will have the
temptation to port major functionality into already existing release
branches which might take a large amount of effort and could introduce
instability between minor releases. I hope my inference reflects your
intended proposal! :)

Yes to a roadmap.

Thanks,

Dan.


On Sun, 21 Apr 2024 at 14:50, Michael Brohl 
wrote:


Hi everyone,

we agreed to work towards a stabilizing trunk to be able to create a
24.x release branch, which means we have to thoroughly decide which
changes should go into trunk. There are currently lots of changes going
into trunk with PR's created and rapidly be merged into the codebase.
This causes potential for errors being introduced in trunk, potentially
leading to delay the creation of the next release branch even more.

In my opinion, this is contraproductive to the goal of creating a stable
release branch 24.x in due time.

I propose to make a decision to have a code freeze for new features and
improvements and focus on bug fixes until we have created a 24.x branch.

I also propose that we start organizing a roadmap to give the community
some guidelines where to focus and which main features can be expected
in the next release branches. It might also give developers some goals
to provide the features according to planned releases and maybe work
together to reach those project goals.

For example, there are some initiatives for Tomcat migration,
introducing REST functionality in the framework and others which we can
assign to future release branches. Maybe we can have a plan for a 25.x
release branch which introduces those features.

I do not intend to make this an unflexible roadmap, means there can
always be more planned/unplanned features be added to the roadmap and be
discussed. We should have some deadlines for new features though, just
to be able to create the next feature branch in the planned time periods.

What do you think?

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Jacques Le Roux]

Hi,

We should 1st clearly identify WIPs in trunk and at which stage they are each.

We can't wait and complicate the situation before that.

Jacques

Le 06/05/2024 à 10:36, gil.portenseigne a écrit :

Hi,

I feel like Michael, when there are 'in progress' work in trunk, when we
create a release branch for stabilisation, the remaining work of such
task will only be in trunk (since those are improvements).

But delaying release is not good when we look at the name of our last
release that show the 2018 year.

The concession we could agree on should be to identify such tasks to let
user know the partial improvements contained in the release.

i.e. creating release branch + roadmap :)

WDYT ?

Gil
On 22/04/24 04:12, Jacques Le Roux wrote:

Hi Guys,

Without getting into details, I tend to disagree with your propositions. I 
can't see why we would change our very simple way of doing.

When we freeze a branch, the activity can continue on trunk. It does not 
interfere with the new release branch.
The only variable is the period we allow before releasing the branch. Then, 
that depends on the breaking changes (or not) we recently made.

Why should we change? I fear it will rather introduce complications. Please 
keep it simple.

TIA for your explanations on simple reasons to change : what is wrong with our 
current way of doing?

Jacques

Le 22/04/2024 à 09:37, Daniel Watford a écrit :

Hi Michael,

I'm broadly in favour of your proposal, but perhaps with a slightly
different 'shape' to the approach.

I too was hoping that we could freeze trunk before creating a 24.x release
branch as I was concerned about the about of duplicate work (backporting)
that might need to be done if we took a 24.x release branch earlier in the
year, but alas trunk marches on and I think it will be difficult to
mandate a period of release-related-only changes in trunk.

Instead I think, as Deepak mentioned, we should take a new 24.x branch to
use for stabilisation - with tags denoting the actual releases along that
branch. It feels that the large projects - such as groovy-scripts migration
- have completed which should reduce the amount of rework that would have
to take place simultaneously on trunk and the 24.x release branch.

>From your comments I infer that you may be suggesting yearly releases. I
think this is a good idea as it will allow the introduction of major new
functionalities in trunk without needing to wait years for them to become
generally accessible. Without more frequent releases we will have the
temptation to port major functionality into already existing release
branches which might take a large amount of effort and could introduce
instability between minor releases. I hope my inference reflects your
intended proposal! :)

Yes to a roadmap.

Thanks,

Dan.


On Sun, 21 Apr 2024 at 14:50, Michael Brohl 
wrote:


Hi everyone,

we agreed to work towards a stabilizing trunk to be able to create a
24.x release branch, which means we have to thoroughly decide which
changes should go into trunk. There are currently lots of changes going
into trunk with PR's created and rapidly be merged into the codebase.
This causes potential for errors being introduced in trunk, potentially
leading to delay the creation of the next release branch even more.

In my opinion, this is contraproductive to the goal of creating a stable
release branch 24.x in due time.

I propose to make a decision to have a code freeze for new features and
improvements and focus on bug fixes until we have created a 24.x branch.

I also propose that we start organizing a roadmap to give the community
some guidelines where to focus and which main features can be expected
in the next release branches. It might also give developers some goals
to provide the features according to planned releases and maybe work
together to reach those project goals.

For example, there are some initiatives for Tomcat migration,
introducing REST functionality in the framework and others which we can
assign to future release branches. Maybe we can have a plan for a 25.x
release branch which introduces those features.

I do not intend to make this an unflexible roadmap, means there can
always be more planned/unplanned features be added to the roadmap and be
discussed. We should have some deadlines for new features though, just
to be able to create the next feature branch in the planned time periods.

What do you think?

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.13

[Jacques Le Roux]

Thanks Jacopo,

<<./verify-ofbiz-release.sh -a apache-ofbiz-18.12.13>> works perfectly on 
Ubuntu 20.04

+1

Jacques

Le 30/04/2024 à 17:06, Jacopo Cappellato a écrit :

This is the vote thread to publish "Apache OFBiz 18.12.13", the thirteenth
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.13.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.13.zip.asc: the detached signature file
* apache-ofbiz-18.12.13.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 18.12.13
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Jacques Le Roux]

Le 22/04/2024 à 16:12, Jacques Le Roux a écrit :

Without getting into details, I tend to disagree with your propositions.

I start writing that. Maybe I should rather have started by saying that I don't 
understand why we should change our (simple) way of doing.

Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Jacques Le Roux]

Hi Guys,

Without getting into details, I tend to disagree with your propositions. I 
can't see why we would change our very simple way of doing.

When we freeze a branch, the activity can continue on trunk. It does not 
interfere with the new release branch.
The only variable is the period we allow before releasing the branch. Then, 
that depends on the breaking changes (or not) we recently made.

Why should we change? I fear it will rather introduce complications. Please 
keep it simple.

TIA for your explanations on simple reasons to change : what is wrong with our 
current way of doing?

Jacques

Le 22/04/2024 à 09:37, Daniel Watford a écrit :

Hi Michael,

I'm broadly in favour of your proposal, but perhaps with a slightly
different 'shape' to the approach.

I too was hoping that we could freeze trunk before creating a 24.x release
branch as I was concerned about the about of duplicate work (backporting)
that might need to be done if we took a 24.x release branch earlier in the
year, but alas trunk marches on and I think it will be difficult to
mandate a period of release-related-only changes in trunk.

Instead I think, as Deepak mentioned, we should take a new 24.x branch to
use for stabilisation - with tags denoting the actual releases along that
branch. It feels that the large projects - such as groovy-scripts migration
- have completed which should reduce the amount of rework that would have
to take place simultaneously on trunk and the 24.x release branch.

>From your comments I infer that you may be suggesting yearly releases. I
think this is a good idea as it will allow the introduction of major new
functionalities in trunk without needing to wait years for them to become
generally accessible. Without more frequent releases we will have the
temptation to port major functionality into already existing release
branches which might take a large amount of effort and could introduce
instability between minor releases. I hope my inference reflects your
intended proposal! :)

Yes to a roadmap.

Thanks,

Dan.


On Sun, 21 Apr 2024 at 14:50, Michael Brohl 
wrote:


Hi everyone,

we agreed to work towards a stabilizing trunk to be able to create a
24.x release branch, which means we have to thoroughly decide which
changes should go into trunk. There are currently lots of changes going
into trunk with PR's created and rapidly be merged into the codebase.
This causes potential for errors being introduced in trunk, potentially
leading to delay the creation of the next release branch even more.

In my opinion, this is contraproductive to the goal of creating a stable
release branch 24.x in due time.

I propose to make a decision to have a code freeze for new features and
improvements and focus on bug fixes until we have created a 24.x branch.

I also propose that we start organizing a roadmap to give the community
some guidelines where to focus and which main features can be expected
in the next release branches. It might also give developers some goals
to provide the features according to planned releases and maybe work
together to reach those project goals.

For example, there are some initiatives for Tomcat migration,
introducing REST functionality in the framework and others which we can
assign to future release branches. Maybe we can have a plan for a 25.x
release branch which introduces those features.

I do not intend to make this an unflexible roadmap, means there can
always be more planned/unplanned features be added to the roadmap and be
discussed. We should have some deadlines for new features though, just
to be able to create the next feature branch in the planned time periods.

What do you think?

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

Re: (ofbiz-framework) branch trunk updated: Improved: FACILITY- Move from hard-coded menu location to parameterized (OFBIZ-12976) (#758)

[Jacques Le Roux]

Hi,

Just FYI: I inadvertently pushed /webapp/common-theme/js/package-lock.json 
which was part of Pierre's PR. It uses lockfileVersion 3.

So it was build with npm 9* which is "Backwards compatible to npm v7." Actually it's also "Backwards compatible to v1 lockfiles as I experienced 
(using Win7 I stuck with Node.js v13.14.0 hence npm 8.1.0)


* https://docs.npmjs.com/cli/v9/configuring-npm/package-lock-json

Jacques

Le 17/04/2024 à 17:24, 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 repositoryhttps://gitbox.apache.org/repos/asf/ofbiz-framework.git


The following commit(s) were added to refs/heads/trunk by this push:
  new 98d2b78bec Improved: FACILITY- Move from hard-coded menu location to 
parameterized (OFBIZ-12976) (#758)
98d2b78bec is described below

commit 98d2b78bece10ac2ddea7e75bcb66dd4aa7276fc
Author: Pierre Smits
AuthorDate: Wed Apr 17 17:24:49 2024 +0200

 Improved: FACILITY- Move from hard-coded menu location to parameterized 
(OFBIZ-12976) (#758)
 
 Improved: FACILITY- Move from hard-coded menu location to parameterized (OFBIZ-12976)
 
 Move the menu location in the various facility screens from hard-coded to parameterized.
 
 modified: CommonScreens.xml, FacilityGroupScreens.xml, FacilityScreens.xml

 changed location of various menus from hard-coded to parameterized
 
 modified:

 - FacilitiesMenus.xml: added menus re shipment
 - ShipmentScreens.xml: changed location of menus from hard-coded to 
parameterized
 
 Improved: Move the menu location in the various facility screens from hard-coded to parameterized. (OFBIZ-12976)
 
 removed: ShipmentMenus.xml

---
  .../product/widget/facility/FacilityMenus.xml  | 128 +
  .../facility/ShipmentGatewayConfigScreens.xml  |   2 +-
  .../product/widget/facility/ShipmentMenus.xml  | 152 -
  .../product/widget/facility/ShipmentScreens.xml|   4 +-
  .../webapp/common-theme/js/package-lock.json   |  81 ---
  5 files changed, 191 insertions(+), 176 deletions(-)

diff --git a/applications/product/widget/facility/FacilityMenus.xml 
b/applications/product/widget/facility/FacilityMenus.xml
index 2661f121fc..b97e881d06 100644
--- a/applications/product/widget/facility/FacilityMenus.xml
+++ b/applications/product/widget/facility/FacilityMenus.xml
@@ -318,5 +318,133 @@ under the License.
  
  
  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
  
  
diff --git 
a/applications/product/widget/facility/ShipmentGatewayConfigScreens.xml 
b/applications/product/widget/facility/ShipmentGatewayConfigScreens.xml
index 7b3f2a812e..2458d9f385 100644
--- a/applications/product/widget/facility/ShipmentGatewayConfigScreens.xml
+++ b/applications/product/widget/facility/ShipmentGatewayConfigScreens.xml
@@ -29,7 +29,7 @@ under the License.
  
  
  
-
+
  
  
  
diff --git a/applications/product/widget/facility/Shipm

Re: (ofbiz-framework) branch CharlesNereide-seo-improvements created (now d272bbf512)

[Jacques Le Roux]

I no longer maintain the 22.01 branch, but use "git push all" when backporting to 18.12 Not sure what happened there, we can neglect it anyway : "No 
new revisions were added by this update."


Jacques

Le 11/04/2024 à 11:14, jler...@apache.org a écrit :

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

jleroux pushed a change to branch CharlesNereide-seo-improvements
in repositoryhttps://gitbox.apache.org/repos/asf/ofbiz-framework.git


   at d272bbf512 Improved: Remove duplicate create trigger from catalog 
main template (OFBIZ-12953) (#738)

No new revisions were added by this update.

Re: Discussion on OFBiz Tomcat upgrade

[Jacques Le Roux]

Hi,

There is yet no specified EOL for Tomcat 9. We can expect 2027: 
https://lists.apache.org/thread/qlzpscgoqct9wspkj5qjkm34s66jswj0

I guess Daniel thought about freezed (for 24.xx) rather than released. I guess 
we all agree on that.

Gaetan can of course start to work on the Tomcat 10 migration and even on 
Prometheus plugin idea as own forks.
Maybe we could even create framework and plugins feature branches. But I doubt 
there will be much help for now.

Jacques

Le 11/04/2024 à 09:09, Michael Brohl a écrit :

Hi,

as I said before, I would also favour creating a 24.x branch before we migrate 
to Tomcat 10.

I don't think 24.x must necessarily be released before we begin the migration (if that's 
what you meant with "released").

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 11.04.24 um 08:52 schrieb Daniel Watford:

Hello,

Checking the End-of-life announcements linked from
https://tomcat.apache.org/whichversion.html it looks like we should have
plenty of time before Tomcat 9 goes end-of-life.

We have quite a few changes/fixes we are trying to complete that are
blocking us from making a new release, so I am reluctant to pursue an
upgrade to Tomcat 10 until after 24.x is released.

My preference is to delay the Tomcat 10 upgrade until after OFBiz 24 is
released.

Thanks,

Dan.

On Thu, 11 Apr 2024 at 07:35, Nicolas Malin 
wrote:


Hi,

Thanks Gaetan to push this subject.

If we want keep OFBiz up to date, hence we need to realize this big step.

My preference go to freeze this migration, focus to release the next
stable branch (24.xx) and restart it after.

Nicolas

Le 10/04/2024 à 14:27, Gaetan a écrit :

Hi all. I'm opening a new thread to discuss the upgrade of the Tomcat
version used by OFBiz.

First, i pushed the task a bit hard without consulting the community
first, and i apologize for it. I got carried away.
The initial task came from a Prometheus plugin idea. [1]

There is a documentation provided by tomcat on how to do the basic
migration operations. [2]

My opinion is that it will have to be done at some point.
I don't have enough experience on OFBiz to know the full implications
of a Tomcat migration.
This one would be bigger even, because it would imply migrating from
javax package to jakarta package.

javax to jakarta change breaks some other things, such as JUEL
dependency.
Migration would be a lot of work and testing.

The advantages i see in migrating as soon as possible would be that we
could put it behind us.

Any thougts ? The ticket has been created some days ago [3]

[1] https://lists.apache.org/thread/jy7y96nmdr0rl43bss3sjm0jkcf2s2gz
[2] https://tomcat.apache.org/migration-10.html
[3] https://issues.apache.org/jira/browse/OFBIZ-12989

Re: UEL migration

[Jacques Le Roux]

Le 10/04/2024 à 09:45, Florian Motteau a écrit :
Sure, I just question the fact that this important discussion (updating tomcat, which leads to a lot of work/implications) occurs via a remote task. 
It may need its own thread (updating tomcat : yes ? no ? why ? how ? people insights about this subject). 


+1

Jacques

Re: Any ideas on how to make demo-site logs accessible and whether it is safe to do so?

[Jacques Le Roux]

Hi Daniel, Team,

For 3 days now I have collected trunk demo errors in error.log.

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

Jacques

Le 29/02/2024 à 16:15, Daniel Watford a écrit :

Hello,

I was just checking the demo-stable logs - accessible on ofbiz-vm1 at
/home/ofbizdocker/demo-stable/logs - and found plenty of interesting stack
traces that would be good candidates for investigation.

Given that the demo sites use well known administrator passwords and should
not contain any sensitive information, how would the project's members feel
about making these logs automatically accessible to any interested parties?

If it is deemed appropriate to make the logs publicly accessible, we then
need to figure out how we could technically do so.

One approach I can think of is to add some Alias directives (
https://httpd.apache.org/docs/current/mod/mod_alias.html#alias) to the
Apache HTTP Server configuration to map relevant paths to the logs
directory of each demo site. For example, to the demo-trunk 
configuration, we could add:

Alias "/logs" "/home/ofbizdocker/demo-trunk/logs"

Similarly, to the demo-stable  configuration we would add:

Alias "/logs" "/home/ofbizdocker/demo-stable/logs"

We would then configure directory listings in Apache HTTP Server for those
log directory locations allowing access via a web browser.

There is some pre-existing functionality in Web Tools to access logs, but
it does require interaction through the OFBiz UI. The ability to retrieve
demo-site logs via an unauthenticated HTTP(S) get request might offer some
opportunities to automatically scan for a particular class of error and
might make it easier for ofbiz developers to check on the demo logs from
time to time.

Thanks,

Dan.

Re: Groovy integration tests

[Jacques Le Roux]

Hi Gil, Nicolas,

I agree it was a good thing to do. We just missed some information and 
documentation.
I have added some at OFBIZ-12320

I have also replaced all groovy-test-suite by junit-test-suite in OOTB code.

I still wonder why Eclipse proposes but does not accept groovy-test-suite as a 
right token and shows this message:

   <>

when in https://ofbiz.apache.org/dtds/test-suite.xsd 
 there is no important
differences between junit-test-suite and groovy-test-suite definitions

Actually it's not too bad for committers. It makes you wonder and read the documentation. So learn that groovy-test-suite should better not used in 
production.


TIA

Jacques

Le 09/09/2021 à 09:43, Nicolas Malin a écrit :

I endorse the words,

I currently implement some new test for
https://issues.apache.org/jira/browse/OFBIZ-6988, and after 3 hours to
build ofbiz, it's really boring without clear most valuable.

If for technical best practice it's better to keep test compile, it's
possible when you test write is terminate to move the groovy-test-suite
to junit-test-suite, so no reason to remove the possibility to write
test as script.

Nicolas

On 08/09/2021 15:30, Gil Portenseigne wrote:

Hello,

Currently using release 18.12 for some project we got the habit to
develop using integration test while developing in groovy.

For that usage we use mainly :
 groovy-test-suite

That allow coding tests in groovy script that do not need to be compiled
for their execution and executing them from webtools [1] (small
improvement will be contributed soon), there is no need to reboot the
local dev OFBiz instance for each modification in that test.

But these type of test has been removed with OFBIZ-11165 [2], while I
thinks that these resources are better compiled, during development
process, not having to restart OFBiz is nice.

So if nobody is against, I will reintroduce it in trunk with a note
explaining the `dev` usage.

WDYT

Regards,

Gil

[1]https://localhost:8443/webtools/control/TestSuiteInfo
[2]https://issues.apache.org/jira/browse/OFBIZ-11165

Re: Buildbot failure in on ofbizTrunkFramework

[Jacques Le Roux]

WIP with https://issues.apache.org/jira/browse/OFBIZ-12995

Le 04/04/2024 à 19:13, build...@apache.org a écrit :

Build status: BUILD FAILED: failed './gradlew --no-daemon ...' (failure)
Worker used: bb_worker4_ubuntu
URL: https://ci2.apache.org/#builders/49/builds/843
Blamelist: Jacques Le Roux 
Build Text: failed './gradlew --no-daemon ...' (failure)
Status Detected: new failure
Build Source Stamp: [branch trunk] d559ea8ca1ce4d93fe38ac0099137f9c238252e7


Steps:

   worker_preparation: 0

   git: 0

   build: 0

   loadAll: 0

   testIntegration: 2


-- ASF Buildbot

Re: Groovy tests fails in trunk (OK in 18.12)

[Jacques Le Roux]

Sorry for the buzz (and multiple description editions), it seems easier than I 
thought...

Le 01/04/2024 à 12:55, Jacques Le Roux a écrit :

Hi,

Please have a look at https://issues.apache.org/jira/browse/OFBIZ-12985

TIA

Jacques

Groovy tests fails in trunk (OK in 18.12)

[Jacques Le Roux]

Hi,

Please have a look at https://issues.apache.org/jira/browse/OFBIZ-12985

TIA

Jacques

[OFBIZ-12935] Test 2.3.33 FreeMarker release - ASF JIRA

[Jacques Le Roux]

Hi,

Without negative answer this week, I'll set the 2.3.33 version on trunk next 
week

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

TIA (for your tests see also the patch in OFBIZ-12934)

Jacques

Re: Shiro and Maven

[Jacques Le Roux]

It was that.

In Gradle I used
org.apache.shiro:shiro-crypto:2.0.0
instead of
org.apache.shiro:shiro-crypto-cipher:2.0.0
I started from https://mvnrepository.com/artifact/org.apache.shiro using core 
then switched to crypto, forgoting cipher.

I don't work how that worked in a situation (w/ OFBiz plugins) and not another 
(w/o OFBiz plugins).
As you suggested (pulling in the old version somewhere unexpectedly) maybe the 
reason.
Though I tried with Gradle --no-cache-build. Anyway who cares now ;)

Remains an issue with HashRequest. I'll have a look at 
https://github.com/apache/shiro/issues/1022
And https://www.google.fr/search?q=%22shiro+2.0.0%22+Hash&ie=UTF-8 globally
It's time for us to envisage argon or such...

Thanks again

Jacques

Le 24/03/2024 à 17:35, le...@flowlogix.com a écrit :

Make sure to look at the dependency tree, I bet you are pulling in the old 
version somewhere unexpectedly.


On Mar 24, 2024, at 11:32 AM, Jacques Le Roux  
wrote:

Thanks Lenny,

Oops, indeed it should be 2.0.0 everywhere. Else nothing would work ;)

I did not want to repeat all what's in links, that why I just put links.

Anyway, I'll have a look at Crypto classes’ package names, easier than anything 
else.
I'm though surprised that it works with current names when we have the 3 
org.apereo.cas packages in the classpath.

Maybe we miss something else...

Jacques

Le 24/03/2024 à 15:54,le...@flowlogix.com  <mailto:le...@flowlogix.com>  a 
écrit :

I am not quite sure that there enough information here to help…
First, you mention shiro-core 2.2.0 (vs. 2.0.0) are you sure you have the 
correct version?

Crypto classes’ package names have changed. All you would need to do is change 
Java source to reflect this.


On Mar 24, 2024, at 3:51 AM, Jacques Le Roux  
<mailto:jacques.le.r...@les7arts.com>  wrote:

Hi,

We (the Apache OFBiz project) use Shiro mostly for ciphering.
We use Gradle and refer to Maven for dependencies.

We recently upgraded from 1.13.0 to 2.0.0
https://issues.apache.org/jira/browse/OFBIZ-12961  
<https://issues.apache.org/jira/browse/OFBIZ-12961>  
<https://issues.apache.org/jira/browse/OFBIZ-12961>  
<https://issues.apache.org/jira/browse/OFBIZ-12961>
As we we had only this dependency, I started by replacing shiro-core:1.13.0 by 
shiro-core:2.2.0
It did not work (mostly AesCipherService creation compile errors).

I then tried only shiro-crypto:2.0.0 and It worked.

Then (thanks to our CI) we discovered that there was other dependencies related 
to org.apereo.cas:cas-server
https://lists.apache.org/thread/cszft6134oon9tx0xy0wn3hgvh4ogbpz  
<https://lists.apache.org/thread/cszft6134oon9tx0xy0wn3hgvh4ogbpz>  
<https://lists.apache.org/thread/cszft6134oon9tx0xy0wn3hgvh4ogbpz>  
<https://lists.apache.org/thread/cszft6134oon9tx0xy0wn3hgvh4ogbpz>

So I added them withhttps://github.com/apache/ofbiz-framework/commit/61f5831400  
<https://github.com/apache/ofbiz-framework/commit/61f5831400>  
<https://github.com/apache/ofbiz-framework/commit/61f5831400>  
<https://github.com/apache/ofbiz-framework/commit/61f5831400>

This morning I removed them and tried to add shiro-core:2.2.0, to no avail.

If it's possible, could you please give us more information to get read of the 
org.apereo.cas:cas-server  dependencies?

Thanks in advance

Jacques

Re: Shiro and Maven

[Jacques Le Roux]

Thanks Lenny,

Oops, indeed it should be 2.0.0 everywhere. Else nothing would work ;)

I did not want to repeat all what's in links, that why I just put links.

Anyway, I'll have a look at Crypto classes’ package names, easier than anything else. I'm though surprised that it works with current names when we 
have the 3 org.apereo.cas packages in the classpath.


Maybe we miss something else...

Jacques

Le 24/03/2024 à 15:54, le...@flowlogix.com a écrit :

I am not quite sure that there enough information here to help…
First, you mention shiro-core 2.2.0 (vs. 2.0.0) are you sure you have the 
correct version?

Crypto classes’ package names have changed. All you would need to do is change 
Java source to reflect this.


On Mar 24, 2024, at 3:51 AM, Jacques Le Roux  
wrote:

Hi,

We (the Apache OFBiz project) use Shiro mostly for ciphering.
We use Gradle and refer to Maven for dependencies.

We recently upgraded from 1.13.0 to 2.0.0
https://issues.apache.org/jira/browse/OFBIZ-12961  
<https://issues.apache.org/jira/browse/OFBIZ-12961>
As we we had only this dependency, I started by replacing shiro-core:1.13.0 by 
shiro-core:2.2.0
It did not work (mostly AesCipherService creation compile errors).

I then tried only shiro-crypto:2.0.0 and It worked.

Then (thanks to our CI) we discovered that there was other dependencies related 
to org.apereo.cas:cas-server
https://lists.apache.org/thread/cszft6134oon9tx0xy0wn3hgvh4ogbpz  
<https://lists.apache.org/thread/cszft6134oon9tx0xy0wn3hgvh4ogbpz>

So I added them withhttps://github.com/apache/ofbiz-framework/commit/61f5831400  
<https://github.com/apache/ofbiz-framework/commit/61f5831400>

This morning I removed them and tried to add shiro-core:2.2.0, to no avail.

If it's possible, could you please give us more information to get read of the 
org.apereo.cas:cas-server  dependencies?

Thanks in advance

Jacques

Shiro and Maven

[Jacques Le Roux]

Hi,

We (the Apache OFBiz project) use Shiro mostly for ciphering.
We use Gradle and refer to Maven for dependencies.

We recently upgraded from 1.13.0 to 2.0.0
https://issues.apache.org/jira/browse/OFBIZ-12961

As we we had only this dependency, I started by replacing shiro-core:1.13.0 by 
shiro-core:2.2.0
It did not work (mostly AesCipherService creation compile errors).

I then tried only shiro-crypto:2.0.0 and It worked.

Then (thanks to our CI) we discovered that there was other dependencies related 
to org.apereo.cas:cas-server
https://lists.apache.org/thread/cszft6134oon9tx0xy0wn3hgvh4ogbpz

So I added them with https://github.com/apache/ofbiz-framework/commit/61f5831400 This morning I removed them and tried to add shiro-core:2.2.0, to no 
avail.


If it's possible, could you please give us more information to get read of the 
org.apereo.cas:cas-server dependencies? Thanks in advance

Jacques

Re: [FYI] No relation longer between Git commits and Jira comments

[Jacques Le Roux]

Fixed

Le 23/03/2024 à 07:23, Jacques Le Roux a écrit :

https://issues.apache.org/jira/browse/INFRA-25642

Re: [jira] [Commented] (OFBIZ-12961) Upgrade Apache Shiro from 1.13.0 to 2.0.0

[Jacques Le Roux]

After completely removing LDAP, adding this works too:

diff --git a/dependencies.gradle b/dependencies.gradle
index b1a2e29..bb89c2e 100644
--- a/dependencies.gradle
+++ b/dependencies.gradle
@@ -83,0 +84,3 @@
+    implementation 'org.apereo.cas:cas-server-core-api-authentication:5.0.10'
+    implementation 'org.apereo.cas:cas-server-core-util:5.0.10'
+    implementation 'org.apereo.cas:cas-server-support-ldap-core:5.0.10'

Still not sure what to do yet anyway

Jacques

Le 23/03/2024 à 12:11, Jacques Le Roux a écrit :

Thanks Daniel for the quick answer :)

Maybe in the meantime we could simply "comment out" the ldap plugin, not sure 
how yet...

Jacques

Le 23/03/2024 à 11:56, Daniel Watford a écrit :

Hi Jacques,

Here's the cause of the failure for the docker-image github workflow:

#31 31.81 > Task :buildSrc:build
#31 60.80
#31 60.80 > Task :compileJava
#31 60.80
/builder/framework/entity/src/main/java/org/apache/ofbiz/entity/util/EntityCrypto.java:43:
error: package org.apache.shiro.crypto does not exist
#31 60.80 import org.apache.shiro.crypto.AesCipherService;
#31 60.80   ^
#31 60.80
/builder/framework/entity/src/main/java/org/apache/ofbiz/entity/util/EntityCrypto.java:44:
error: package org.apache.shiro.crypto does not exist
#31 60.80 import org.apache.shiro.crypto.OperationMode;
#31 60.80   ^
#31 60.80
/builder/framework/entity/src/main/java/org/apache/ofbiz/entity/util/EntityCrypto.java:45:
error: package org.apache.shiro.crypto does not exist
#31 60.80 import org.apache.shiro.crypto.PaddingScheme;

Whichever module provides org.apache.shiro.crypto is missing. But it's odd
that the gradle github workflow doesn't have a problem...

The difference between the two is that the gradle github workflow includes
the plugins, whereas the failing part of the docker-image workflow does not.

I confirmed the behaviour with some local builds:
- without plugins: Build fails
- with plugins: Build succeeds.

We can use './gradlew dependencies' to review the dependency tree.
Searching the tree for shiro we find:
- org.apache.shiro:shiro-core:1.3.2
- - > org.apereo.cas:cas-server-core-api-authentication:5.0.10
- - - > org.apereo.cas:cas-server-core-util:5.0.10
- - - - > org.apereo.cas:cas-server-support-ldap-core:5.0.10
- - - - - > project :plugins:ldap

So the missing dependency is getting brought in through the ldap plugin.

The above suggests we should consider removing the plugins from the gradle
github workflow, or at least consider creating two workflows, one with and
one without plugins.

Thanks,

Dan.





On Sat, 23 Mar 2024 at 10:28, Jacques Le Roux 
wrote:


Hi,

I'd appreciate confirmations about local build.
And, before reverting, if you have an idea don't hesitate :)

TIA

Jacques

Le 23/03/2024 à 11:23, Jacques Le Roux (Jira) a écrit :

  [
https://issues.apache.org/jira/browse/OFBIZ-12961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17830052#comment-17830052 


]

Jacques Le Roux commented on OFBIZ-12961:
-

There are currently some, for now, incomprehensible issues while

building.

It works locally on both Win7 and Ubuntu 20.04:


{noformat}
C:\projectsASF\Git\ofbiz-framework>gradlew --no-daemon clean build

--no-build-cache

To honour the JVM settings for this build a single-use Daemon process

will be forked. See
https://docs.gradle.org/7.6/userguide/gradle_daemon.html#sec:disabling_the_daemon
.

Daemon will be stopped at the end of the build

Task :buildSrc:extractPluginRequests UP-TO-DATE
Task :buildSrc:generatePluginAdapters UP-TO-DATE
Task :buildSrc:compileJava UP-TO-DATE
Task :buildSrc:compileGroovy NO-SOURCE
Task :buildSrc:compileGroovyPlugins UP-TO-DATE
Task :buildSrc:pluginDescriptors UP-TO-DATE
Task :buildSrc:processResources UP-TO-DATE
Task :buildSrc:classes UP-TO-DATE
Task :buildSrc:jar UP-TO-DATE
Task :buildSrc:assemble UP-TO-DATE
Task :buildSrc:compileTestJava NO-SOURCE
Task :buildSrc:compileTestGroovy NO-SOURCE
Task :buildSrc:pluginUnderTestMetadata UP-TO-DATE
Task :buildSrc:processTestResources NO-SOURCE
Task :buildSrc:testClasses UP-TO-DATE
Task :buildSrc:test NO-SOURCE
Task :buildSrc:validatePlugins UP-TO-DATE
Task :buildSrc:check UP-TO-DATE
Task :buildSrc:build UP-TO-DATE
Task :themes:common-theme:clean UP-TO-DATE
Task :plugins:projectmgr:clean UP-TO-DATE
Task :clean UP-TO-DATE
Task :plugins:example:clean UP-TO-DATE
Task :themes:common-theme:nodeSetup UP-TO-DATE
Task :themes:common-theme:npmSetup SKIPPED
Task :plugins:projectmgr:nodeSetup UP-TO-DATE
Task :plugins:projectmgr:npmSetup SKIPPED
Task :plugins:example:nodeSetup UP-TO-DATE
Task :plugins:example:npmSetup SKIPPED
Task :plugins:example:npmInstall NO-SOURCE
Task :plugins:example:assemble UP-TO-DATE
Task :plugins:example:check UP-TO-DATE
Task :plugins:example:build UP-TO-DAT

Re: [jira] [Commented] (OFBIZ-12961) Upgrade Apache Shiro from 1.13.0 to 2.0.0

[Jacques Le Roux]

Thanks Daniel for the quick answer :)

Maybe in the meantime we could simply "comment out" the ldap plugin, not sure 
how yet...

Jacques

Le 23/03/2024 à 11:56, Daniel Watford a écrit :

Hi Jacques,

Here's the cause of the failure for the docker-image github workflow:

#31 31.81 > Task :buildSrc:build
#31 60.80
#31 60.80 > Task :compileJava
#31 60.80
/builder/framework/entity/src/main/java/org/apache/ofbiz/entity/util/EntityCrypto.java:43:
error: package org.apache.shiro.crypto does not exist
#31 60.80 import org.apache.shiro.crypto.AesCipherService;
#31 60.80   ^
#31 60.80
/builder/framework/entity/src/main/java/org/apache/ofbiz/entity/util/EntityCrypto.java:44:
error: package org.apache.shiro.crypto does not exist
#31 60.80 import org.apache.shiro.crypto.OperationMode;
#31 60.80   ^
#31 60.80
/builder/framework/entity/src/main/java/org/apache/ofbiz/entity/util/EntityCrypto.java:45:
error: package org.apache.shiro.crypto does not exist
#31 60.80 import org.apache.shiro.crypto.PaddingScheme;

Whichever module provides org.apache.shiro.crypto is missing. But it's odd
that the gradle github workflow doesn't have a problem...

The difference between the two is that the gradle github workflow includes
the plugins, whereas the failing part of the docker-image workflow does not.

I confirmed the behaviour with some local builds:
- without plugins: Build fails
- with plugins: Build succeeds.

We can use './gradlew dependencies' to review the dependency tree.
Searching the tree for shiro we find:
- org.apache.shiro:shiro-core:1.3.2
- - > org.apereo.cas:cas-server-core-api-authentication:5.0.10
- - - > org.apereo.cas:cas-server-core-util:5.0.10
- - - - > org.apereo.cas:cas-server-support-ldap-core:5.0.10
- - - - - > project :plugins:ldap

So the missing dependency is getting brought in through the ldap plugin.

The above suggests we should consider removing the plugins from the gradle
github workflow, or at least consider creating two workflows, one with and
one without plugins.

Thanks,

Dan.





On Sat, 23 Mar 2024 at 10:28, Jacques Le Roux 
wrote:


Hi,

I'd appreciate confirmations about local build.
And, before reverting, if you have an idea don't hesitate :)

TIA

Jacques

Le 23/03/2024 à 11:23, Jacques Le Roux (Jira) a écrit :

  [

https://issues.apache.org/jira/browse/OFBIZ-12961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17830052#comment-17830052
]

Jacques Le Roux commented on OFBIZ-12961:
-

There are currently some, for now, incomprehensible issues while

building.

It works locally on both Win7 and Ubuntu 20.04:


{noformat}
C:\projectsASF\Git\ofbiz-framework>gradlew --no-daemon clean build

--no-build-cache

To honour the JVM settings for this build a single-use Daemon process

will be forked. See
https://docs.gradle.org/7.6/userguide/gradle_daemon.html#sec:disabling_the_daemon
.

Daemon will be stopped at the end of the build

Task :buildSrc:extractPluginRequests UP-TO-DATE
Task :buildSrc:generatePluginAdapters UP-TO-DATE
Task :buildSrc:compileJava UP-TO-DATE
Task :buildSrc:compileGroovy NO-SOURCE
Task :buildSrc:compileGroovyPlugins UP-TO-DATE
Task :buildSrc:pluginDescriptors UP-TO-DATE
Task :buildSrc:processResources UP-TO-DATE
Task :buildSrc:classes UP-TO-DATE
Task :buildSrc:jar UP-TO-DATE
Task :buildSrc:assemble UP-TO-DATE
Task :buildSrc:compileTestJava NO-SOURCE
Task :buildSrc:compileTestGroovy NO-SOURCE
Task :buildSrc:pluginUnderTestMetadata UP-TO-DATE
Task :buildSrc:processTestResources NO-SOURCE
Task :buildSrc:testClasses UP-TO-DATE
Task :buildSrc:test NO-SOURCE
Task :buildSrc:validatePlugins UP-TO-DATE
Task :buildSrc:check UP-TO-DATE
Task :buildSrc:build UP-TO-DATE
Task :themes:common-theme:clean UP-TO-DATE
Task :plugins:projectmgr:clean UP-TO-DATE
Task :clean UP-TO-DATE
Task :plugins:example:clean UP-TO-DATE
Task :themes:common-theme:nodeSetup UP-TO-DATE
Task :themes:common-theme:npmSetup SKIPPED
Task :plugins:projectmgr:nodeSetup UP-TO-DATE
Task :plugins:projectmgr:npmSetup SKIPPED
Task :plugins:example:nodeSetup UP-TO-DATE
Task :plugins:example:npmSetup SKIPPED
Task :plugins:example:npmInstall NO-SOURCE
Task :plugins:example:assemble UP-TO-DATE
Task :plugins:example:check UP-TO-DATE
Task :plugins:example:build UP-TO-DATE
Task :themes:common-theme:npmInstall UP-TO-DATE
Task :themes:common-theme:assemble UP-TO-DATE
Task :themes:common-theme:check UP-TO-DATE
Task :themes:common-theme:build UP-TO-DATE
Task :plugins:projectmgr:npmInstall UP-TO-DATE
Task :plugins:projectmgr:assemble UP-TO-DATE
Task :plugins:projectmgr:check UP-TO-DATE
Task :plugins:projectmgr:build UP-TO-DATE
Task :compileJava

C:\projectsASF\Git\ofbiz-framework\framework\common\src\main\java\org\apache\ofbiz\common\authentication\AuthHelper.java:132:
warning: [removal] AccessController in java

Re: [jira] [Commented] (OFBIZ-12961) Upgrade Apache Shiro from 1.13.0 to 2.0.0

[Jacques Le Roux]

Hi,

I'd appreciate confirmations about local build.
And, before reverting, if you have an idea don't hesitate :)

TIA

Jacques

Le 23/03/2024 à 11:23, Jacques Le Roux (Jira) a écrit :

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17830052#comment-17830052
 ]

Jacques Le Roux commented on OFBIZ-12961:
-

There are currently some, for now, incomprehensible issues while building.
It works locally on both Win7 and Ubuntu 20.04:


{noformat}
C:\projectsASF\Git\ofbiz-framework>gradlew --no-daemon clean build 
--no-build-cache
To honour the JVM settings for this build a single-use Daemon process will be 
forked. See 
https://docs.gradle.org/7.6/userguide/gradle_daemon.html#sec:disabling_the_daemon.
Daemon will be stopped at the end of the build

Task :buildSrc:extractPluginRequests UP-TO-DATE
Task :buildSrc:generatePluginAdapters UP-TO-DATE
Task :buildSrc:compileJava UP-TO-DATE
Task :buildSrc:compileGroovy NO-SOURCE
Task :buildSrc:compileGroovyPlugins UP-TO-DATE
Task :buildSrc:pluginDescriptors UP-TO-DATE
Task :buildSrc:processResources UP-TO-DATE
Task :buildSrc:classes UP-TO-DATE
Task :buildSrc:jar UP-TO-DATE
Task :buildSrc:assemble UP-TO-DATE
Task :buildSrc:compileTestJava NO-SOURCE
Task :buildSrc:compileTestGroovy NO-SOURCE
Task :buildSrc:pluginUnderTestMetadata UP-TO-DATE
Task :buildSrc:processTestResources NO-SOURCE
Task :buildSrc:testClasses UP-TO-DATE
Task :buildSrc:test NO-SOURCE
Task :buildSrc:validatePlugins UP-TO-DATE
Task :buildSrc:check UP-TO-DATE
Task :buildSrc:build UP-TO-DATE
Task :themes:common-theme:clean UP-TO-DATE
Task :plugins:projectmgr:clean UP-TO-DATE
Task :clean UP-TO-DATE
Task :plugins:example:clean UP-TO-DATE
Task :themes:common-theme:nodeSetup UP-TO-DATE
Task :themes:common-theme:npmSetup SKIPPED
Task :plugins:projectmgr:nodeSetup UP-TO-DATE
Task :plugins:projectmgr:npmSetup SKIPPED
Task :plugins:example:nodeSetup UP-TO-DATE
Task :plugins:example:npmSetup SKIPPED
Task :plugins:example:npmInstall NO-SOURCE
Task :plugins:example:assemble UP-TO-DATE
Task :plugins:example:check UP-TO-DATE
Task :plugins:example:build UP-TO-DATE
Task :themes:common-theme:npmInstall UP-TO-DATE
Task :themes:common-theme:assemble UP-TO-DATE
Task :themes:common-theme:check UP-TO-DATE
Task :themes:common-theme:build UP-TO-DATE
Task :plugins:projectmgr:npmInstall UP-TO-DATE
Task :plugins:projectmgr:assemble UP-TO-DATE
Task :plugins:projectmgr:check UP-TO-DATE
Task :plugins:projectmgr:build UP-TO-DATE
Task :compileJava

C:\projectsASF\Git\ofbiz-framework\framework\common\src\main\java\org\apache\ofbiz\common\authentication\AuthHelper.java:132:
 warning: [removal] AccessController in java.security has been deprecated and 
marked for removal
 return AccessController.doPrivileged(
^
C:\projectsASF\Git\ofbiz-framework\framework\testtools\src\main\java\org\apache\ofbiz\testtools\GroovyScriptTestCase.java:29:
 warning: [deprecation] GroovyTestCase in groovy.util has been deprecated
public class GroovyScriptTestCase extends GroovyTestCase {
   ^
2 warnings


Task :compileGroovy
Task :processResources
Task :classes
Task :jar
Task :startScripts
Task :distTar
Task :distZip
Task :assemble
Task :compileTestJava
Task :compileTestGroovy
Task :processTestResources
Task :testClasses

The Cobertura XML file [null] is not accessible; skipping this rule

Task :checkstyleMain
Task :checkstyleTest
Task :codenarcMain

The Cobertura XML file [null] is not accessible; skipping this rule

Task :codenarcTest
Task :test

OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader 
classes because bootstrap classpath has been appended


Task :check
Task :build

BUILD SUCCESSFUL in 4m 56s
33 actionable tasks: 15 executed, 18 up-to-date
C:\projectsASF\Git\ofbiz-framework>
{noformat}

{noformat}
jacques@jacques-VirtualBox:~/ofbiz-framework$ ./gradlew clean build 
--no-build-cache

Task :buildSrc:extractPluginRequests UP-TO-DATE
Task :buildSrc:generatePluginAdapters UP-TO-DATE
Task :buildSrc:compileJava UP-TO-DATE
Task :buildSrc:compileGroovy NO-SOURCE
Task :buildSrc:compileGroovyPlugins UP-TO-DATE
Task :buildSrc:pluginDescriptors UP-TO-DATE
Task :buildSrc:processResources UP-TO-DATE
Task :buildSrc:classes UP-TO-DATE
Task :buildSrc:jar UP-TO-DATE
Task :buildSrc:assemble UP-TO-DATE
Task :buildSrc:compileTestJava NO-SOURCE
Task :buildSrc:compileTestGroovy NO-SOURCE
Task :buildSrc:pluginUnderTestMetadata UP-TO-DATE
Task :buildSrc:processTestResources NO-SOURCE
Task :buildSrc:testClasses UP-TO-DATE
Task :buildSrc:test NO-SOURCE
Task :buildSrc:validatePlugins UP-TO-DATE
Task :buildSrc:check UP-TO-DATE
Task :buildSrc:build UP-TO-DATE
Task :plugins:example:cleanBuildReactApp UP-TO-DATE
Task :clean
Task :plugins:example:clean UP-TO-DATE
Task :plugins:projectmgr:clean UP-TO-DATE
Task :themes:common-theme:c

[FYI] No relation longer between Git commits and Jira comments

[Jacques Le Roux]

https://issues.apache.org/jira/browse/INFRA-25642

Re: [apache/ofbiz-framework] Run failed: Scorecard supply-chain security - trunk (a9a3d13)

[Jacques Le Roux]

Happens: 
https://www.google.com/search?q=GitHub+Actions+has+encountered+an+internal+error

Le 18/03/2024 à 07:41, Jacques Le Roux a écrit :

[apache/ofbiz-framework] Run failed: Scorecard supply-chain security - trunk 
(a9a3d13)

GitHub


[apache/ofbiz-framework] Scorecard supply-chain security workflow run


  Scorecard supply-chain security: All jobs have failed

View workflow run 
<https://github.com/apache/ofbiz-framework/actions/runs/8322326563>


Scorecard analysis  

*Scorecard supply-chain security* / Scorecard analysis
Failed in 0 seconds

annotations for Scorecard supply-chain security / Scorecard analysis 1 
<https://github.com/apache/ofbiz-framework/actions/runs/8322326563>

—
You are receiving this because you are subscribed to this thread.
Manage your GitHub Actions notifications 
<https://github.com/settings/notifications>

GitHub, Inc. ・88 Colin P Kelly Jr Street ・San Francisco, CA 94107

Fwd: [jira] [Created] (OFBIZ-12934) Test next FreeMarker release

[Jacques Le Roux]

Hi Team,

I created this Jira in order to test next FreeMarker release.

Of course everyone is called to test

TIA

Jacques

 Message transféré 
Sujet : [jira] [Created] (OFBIZ-12934) Test next FreeMarker release
Date :  Sat, 9 Mar 2024 16:18:00 + (UTC)
De :Jacques Le Roux (Jira) 
Répondre à :dev@ofbiz.apache.org
Pour :  notificati...@ofbiz.apache.org



Jacques Le Roux created OFBIZ-12934:
---

Summary: Test next FreeMarker release Key: OFBIZ-12934
URL: https://issues.apache.org/jira/browse/OFBIZ-12934
Project: OFBiz
Issue Type: Task
Components: Freemarker
Affects Versions: Upcoming Branch
Reporter: Jacques Le Roux


{color:#FF8B00}This issue is a "reusable" one.{color}.

It's intended to test the next FreeMarker releases [as requested by the 
FreeMarker 
team|https://lists.apache.org/thread/t4c9z7wkcp3dbdokmnjd32fcptq8h9tz]

As it's not an as simple change, here I attach a patch as an exemple based on 
the test requested above:



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Apache Project Website Checks

[Jacques Le Roux]

Hi,

Forgot to say that this has been done as suggested below and can be easily seen 
on site

Jacques

Le 21/02/2024 à 09:56, Jacques Le Roux a écrit :

Le 19/02/2024 à 09:55, Jacques Le Roux a écrit :

Le 18/02/2024 à 20:05, Jacques Le Roux a écrit :

Le 13/02/2024 à 09:35, Jacques Le Roux a écrit :

Hi,

Now that it's soon 3 years that we did not Tweet anything, I think we should 
follow this advice

https://whimsy.apache.org/site/project/ofbiz

Jacques

Actually there is more than that: Linkedin and Facebook.
Both need you to sign in, hence to give up your personal data.

I believe it's not to Apache OFBiz to propose that.
So we should remove all social networks from the site.
Even if whimsy did not spot those 2.

Jacques

I did not speak about Youtube. I'd say it's still apart, you don't need yet to 
sign in to see things. And you can refuse cookies.
X is the same but it seems we no longer use it. Apart to refer to our blog... 
that we don't use anymore.

According to https://privacy.apache.org/faq/committers.html anyway Facebook and X are 
"forbidden".
We should also change Google Maps, YouTube and Vimeo a bit.

Finally, maybe we should have a look at https://github.com/heiseonline/shariff

Please share you thoughts

TIA


Hi,

Next week I'll apply necessary changes

Jacques

Re: [GH] (ofbiz-framework): Workflow run "Build and push docker images" failed!

[Jacques Le Roux]

Pierre's help was successful: 
https://github.com/apache/ofbiz-framework/actions/runs/8122898106

Le 02/03/2024 à 08:17, Jacques Le Roux a écrit :

Hi Daniel,

I don't know what to do with that. I locally tried "gradlew --console plain 
distTar"  and it works. But when I rebuild on GH it does not.

Jacques

Le 01/03/2024 à 21:24, GitBox a écrit :

The GitHub Actions job "Build and push docker images" on ofbiz-framework.git 
has failed.
Run started by GitHub user JacquesLeRoux (triggered by JacquesLeRoux).

Head commit for run:
7d3a069b36d60fa9b049be5cbdbda2c24af8c6a8 / Pierre Smits 

Improved: Have library dependencies moved to a dependencies.gradle file 
(OFBIZ-10924) (#717)

* Improved: Have library dependencies moved to a dependencies.gradle file 
(OFBIZ-10924)

Currently the libraries needed by ofbiz are defined in the build.gradle file. These should reside in a separate dependencies.gradle file that is 
referenced in the build.gradle file, like the common.gradle. As is common practice in other projects/solutions that work with dependencies on 
external libraries.


modified:

build.gradle: removed implementation, testImplementation and runtimeOnly 
library dependencies added:
dependencies.gradle, having the implementation, testImplementation and 
runtimeOnly library dependencies

* adding 'apply from' regarding dependencies

Report URL: https://github.com/apache/ofbiz-framework/actions/runs/8114883721

With regards,
GitHub Actions via GitBox

Re: Any ideas on how to make demo-site logs accessible and whether it is safe to do so?

[Jacques Le Roux]

Hi Dan,

About the logs in Webtools it's also limited to "OFBiz logs".
I mean you can't see the access_logs. They are sometime very useful too.

So yes I agree this would be something we could do.

Jacques

Le 29/02/2024 à 16:15, Daniel Watford a écrit :

Hello,

I was just checking the demo-stable logs - accessible on ofbiz-vm1 at
/home/ofbizdocker/demo-stable/logs - and found plenty of interesting stack
traces that would be good candidates for investigation.

Given that the demo sites use well known administrator passwords and should
not contain any sensitive information, how would the project's members feel
about making these logs automatically accessible to any interested parties?

If it is deemed appropriate to make the logs publicly accessible, we then
need to figure out how we could technically do so.

One approach I can think of is to add some Alias directives (
https://httpd.apache.org/docs/current/mod/mod_alias.html#alias) to the
Apache HTTP Server configuration to map relevant paths to the logs
directory of each demo site. For example, to the demo-trunk 
configuration, we could add:

Alias "/logs" "/home/ofbizdocker/demo-trunk/logs"

Similarly, to the demo-stable  configuration we would add:

Alias "/logs" "/home/ofbizdocker/demo-stable/logs"

We would then configure directory listings in Apache HTTP Server for those
log directory locations allowing access via a web browser.

There is some pre-existing functionality in Web Tools to access logs, but
it does require interaction through the OFBiz UI. The ability to retrieve
demo-site logs via an unauthenticated HTTP(S) get request might offer some
opportunities to automatically scan for a particular class of error and
might make it easier for ofbiz developers to check on the demo logs from
time to time.

Thanks,

Dan.

Re: [GH] (ofbiz-framework): Workflow run "Build and push docker images" failed!

[Jacques Le Roux]

Hi Daniel,

I don't know what to do with that. I locally tried "gradlew --console plain 
distTar"  and it works. But when I rebuild on GH it does not.

Jacques

Le 01/03/2024 à 21:24, GitBox a écrit :

The GitHub Actions job "Build and push docker images" on ofbiz-framework.git 
has failed.
Run started by GitHub user JacquesLeRoux (triggered by JacquesLeRoux).

Head commit for run:
7d3a069b36d60fa9b049be5cbdbda2c24af8c6a8 / Pierre Smits 

Improved: Have library dependencies moved to a dependencies.gradle file 
(OFBIZ-10924) (#717)

* Improved: Have library dependencies moved to a dependencies.gradle file 
(OFBIZ-10924)

Currently the libraries needed by ofbiz are defined in the build.gradle file. 
These should reside in a separate dependencies.gradle file that is referenced 
in the build.gradle file, like the common.gradle. As is common practice in 
other projects/solutions that work with dependencies on external libraries.

modified:

build.gradle: removed implementation, testImplementation and runtimeOnly 
library dependencies added:
dependencies.gradle, having the implementation, testImplementation and 
runtimeOnly library dependencies

* adding 'apply from' regarding dependencies

Report URL: https://github.com/apache/ofbiz-framework/actions/runs/8114883721

With regards,
GitHub Actions via GitBox

Re: Buildbot failure in on ofbizTrunkFrameworkPlugins

[Jacques Le Roux]

Hi,

@committers: I don't remember if I already told you so: in case BB fails and it works locally, you can rebuild in BB by login with you complete a.o 
email address (eg: jler...@apache.org) and your ASF password


Jacques

Le 29/02/2024 à 20:09, build...@apache.org a écrit :

Build status: BUILD FAILED: failed './gradlew --no-daemon ...' (failure)
Worker used: bb_worker4_ubuntu
URL: https://ci2.apache.org/#builders/46/builds/698
Blamelist: Daniel Watford 
Build Text: failed './gradlew --no-daemon ...' (failure)
Status Detected: new failure
Build Source Stamp: [branch trunk] c438302149830cd5f8153dab8e58e623915b21cf


Steps:

   worker_preparation: 0

   git: 0

   pullAllPluginsSource: 0

   build: 0

   check: 0

   Copy checkstyle to destination directory structure: 0

   Copy codenarc to destination directory structure: 0

   generateReadmeFiles: 0

   Copy readme: 0

   generateOfbizDocumentation: 0

   Copy OfbizDocumentation: 0

   generateAllPluginsDocumentation: 0

   Copy AllPluginsDocumentation: 0

   javadoc: 0

   Copy javadoc: 0

   loadAll: 0

   testIntegration: 2

   clean things: 0


-- ASF Buildbot