[jira] [Commented] (OFBIZ-13035) Fix cross-app menu location issues
[ https://issues.apache.org/jira/browse/OFBIZ-13035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840677#comment-17840677 ] Michael Brohl commented on OFBIZ-13035: --- Hi [~jleroux] what does that mean for the state of this in trunk, quality wise? Do we now have incomplete/inconsistent functionality or is it complete? > Fix cross-app menu location issues > -- > > Key: OFBIZ-13035 > URL: https://issues.apache.org/jira/browse/OFBIZ-13035 > Project: OFBiz > Issue Type: Sub-task > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: Pierre Smits >Assignee: Jacques Le Roux >Priority: Major > Fix For: Upcoming Branch > > > address cross application menu-location issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-13049) Configurable Main page
[ https://issues.apache.org/jira/browse/OFBIZ-13049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840348#comment-17840348 ] Michael Brohl commented on OFBIZ-13049: --- If there are solutions present which are problematic, we should not go this way further with new implementations. We should stop merging those solutions until those issues are discussed and we agreed to go this way. > Configurable Main page > -- > > Key: OFBIZ-13049 > URL: https://issues.apache.org/jira/browse/OFBIZ-13049 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Reporter: Pierre Smits >Priority: Major > > Currently the OFBiz product has configurable Main pages in applications > Accounting, Order, SFA, and plugin MyPortal. Unfortunately, none in the > community felt the urge to implement the concept further in other > applications. > Having a configurable Main page of an application improves both the appeal of > OFBiz to (potential) adopters and their users, and to developers. > With a configurable Main page, developers have less screens to consider when > doing customisation, while at the same time trying to stay in sync with > changes from the project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-13049) Configurable Main page
[ https://issues.apache.org/jira/browse/OFBIZ-13049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839376#comment-17839376 ] Michael Brohl commented on OFBIZ-13049: --- It would be better to first describe what should be done and how in a single issue (this one), get approval from the community that it should be done and deliver a first implementation for review. If this is sucessful, more subtasks might be reasonable if there is a plan to deliver the solutions. Creating a lot of tickets without substance or someone who intend to do the work just makes Jira confusing. If this is a feature request without a plan to do the work, this issue is sufficient and does not need subtasks until there ist someone who picks up the work. > Configurable Main page > -- > > Key: OFBIZ-13049 > URL: https://issues.apache.org/jira/browse/OFBIZ-13049 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Reporter: Pierre Smits >Priority: Major > > Currently the OFBiz product has configurable Main pages in applications > Accounting, Order, SFA, and plugin MyPortal. Unfortunately, none in the > community felt the urge to implement the concept further in other > applications. > Having a configurable Main page of an application improves both the appeal of > OFBiz to (potential) adopters and their users, and to developers. > With a configurable Main page, developers have less screens to consider when > doing customisation, while at the same time trying to stay in sync with > changes from the project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (OFBIZ-10507) LoginServices.userLogin: Respond "fail" instead of "error" to avoid the (automatic service engine) logging of a stack trace on missing/invalid credentials
[ https://issues.apache.org/jira/browse/OFBIZ-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl closed OFBIZ-10507. - Fix Version/s: Upcoming Branch Resolution: Implemented > LoginServices.userLogin: Respond "fail" instead of "error" to avoid the > (automatic service engine) logging of a stack trace on missing/invalid > credentials > -- > > Key: OFBIZ-10507 > URL: https://issues.apache.org/jira/browse/OFBIZ-10507 > Project: OFBiz > Issue Type: Improvement > Components: framework >Reporter: Benjamin Jugl >Assignee: Michael Brohl >Priority: Minor > Fix For: Upcoming Branch > > Attachments: > OFBIZ-10507_org.apache.ofbiz.common.login.LoginServices.patch > > > There are a lot of login-related entries in the logfile, that stem from user > related errors (like no or wrong password, user not found and so on). To > reduce this, the patch introduces a distinction between ERROR messages and > FAIL messages in the Service-Result. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-10507) LoginServices.userLogin: Respond "fail" instead of "error" to avoid the (automatic service engine) logging of a stack trace on missing/invalid credentials
[ https://issues.apache.org/jira/browse/OFBIZ-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833844#comment-17833844 ] Michael Brohl commented on OFBIZ-10507: --- Thanks for the heads up Jacques, I've merged the PR. > LoginServices.userLogin: Respond "fail" instead of "error" to avoid the > (automatic service engine) logging of a stack trace on missing/invalid > credentials > -- > > Key: OFBIZ-10507 > URL: https://issues.apache.org/jira/browse/OFBIZ-10507 > Project: OFBiz > Issue Type: Improvement > Components: framework >Reporter: Benjamin Jugl >Assignee: Michael Brohl >Priority: Minor > Attachments: > OFBIZ-10507_org.apache.ofbiz.common.login.LoginServices.patch > > > There are a lot of login-related entries in the logfile, that stem from user > related errors (like no or wrong password, user not found and so on). To > reduce this, the patch introduces a distinction between ERROR messages and > FAIL messages in the Service-Result. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-10507) LoginServices.userLogin: Respond "fail" instead of "error" to avoid the (automatic service engine) logging of a stack trace on missing/invalid credentials
[ https://issues.apache.org/jira/browse/OFBIZ-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830435#comment-17830435 ] Michael Brohl commented on OFBIZ-10507: --- I was waiting for feedback to the provided PR. I will merge it soon. > LoginServices.userLogin: Respond "fail" instead of "error" to avoid the > (automatic service engine) logging of a stack trace on missing/invalid > credentials > -- > > Key: OFBIZ-10507 > URL: https://issues.apache.org/jira/browse/OFBIZ-10507 > Project: OFBiz > Issue Type: Improvement > Components: framework >Reporter: Benjamin Jugl >Assignee: Michael Brohl >Priority: Minor > Attachments: > OFBIZ-10507_org.apache.ofbiz.common.login.LoginServices.patch > > > There are a lot of login-related entries in the logfile, that stem from user > related errors (like no or wrong password, user not found and so on). To > reduce this, the patch introduces a distinction between ERROR messages and > FAIL messages in the Service-Result. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (OFBIZ-12890) Missing package and syntax error in FixedAssetServices.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl closed OFBIZ-12890. - Resolution: Fixed > Missing package and syntax error in FixedAssetServices.groovy > - > > Key: OFBIZ-12890 > URL: https://issues.apache.org/jira/browse/OFBIZ-12890 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: Upcoming Branch >Reporter: Michael Brohl >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OFBIZ-12890) Missing package and syntax error in FixedAssetServices.groovy
Michael Brohl created OFBIZ-12890: - Summary: Missing package and syntax error in FixedAssetServices.groovy Key: OFBIZ-12890 URL: https://issues.apache.org/jira/browse/OFBIZ-12890 Project: OFBiz Issue Type: Bug Components: accounting Affects Versions: Upcoming Branch Reporter: Michael Brohl Assignee: Michael Brohl Fix For: Upcoming Branch -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (OFBIZ-12888) Gradle eclipse target produces duplicate build path entries in .classpath
[
https://issues.apache.org/jira/browse/OFBIZ-12888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl closed OFBIZ-12888.
-
Fix Version/s: Upcoming Branch
Resolution: Fixed
> Gradle eclipse target produces duplicate build path entries in .classpath
> -
>
> Key: OFBIZ-12888
> URL: https://issues.apache.org/jira/browse/OFBIZ-12888
> Project: OFBiz
> Issue Type: Bug
> Components: Gradle
>Affects Versions: Upcoming Branch
>Reporter: Michael Brohl
>Assignee: Michael Brohl
>Priority: Major
> Fix For: Upcoming Branch
>
>
> I'm currently working on a solution for this.
> Maybe someone can explain why we use the GroovyScripts source set for the
> codenarc checks in the pre-push hook:
>
> {code:java}
> gitHooks {
>hooks = ['pre-push': 'checkstyleMain codenarcGroovyScripts']
> }
> {code}
> That target seems to be automatically defined through the source set
> definition for groovyScripts.
> If I remove that source set and the following task configuration:
>
> {code:java}
> tasks.named('compileGroovyScriptsGroovy') {
> // We don't want to build groovyScripts as they should be considered as
> standalone elements executed in
> // isolation by ofbiz. Building them will result in numerous error due to
> duplicated classes.
> enabled = false
> }
> {code}
>
> And change the git hooks to
>
> {code:java}
> }
> gitHooks {
> hooks = ['pre-push': 'checkstyleMain codenarcMain codenarcTest']
> }
> {code}
>
> (which is accoring to the pre-push hook definition in .git/hooks/pre-push)
> everything seems to work fine, tests are working and the codenarc Main and
> Test reports are build.
> I provide a PR for it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OFBIZ-12888) Gradle eclipse target produces duplicate build path entries in .classpath
[
https://issues.apache.org/jira/browse/OFBIZ-12888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814288#comment-17814288
]
Michael Brohl edited comment on OFBIZ-12888 at 2/5/24 9:10 AM:
---
[~jleroux] I appreciate you help but would also appreciate if you could take
your time when doing changes/reverts etc. on the work of others.
You could simply let me commit my work which was based upon the latest trunk
changes. Now it was incomplete/has errors (see my last commit) and I was not
able to merge my PR due to conflicts based on your changes. Also the history
now looks poor.
was (Author: mbrohl):
[~jleroux] I appreciate you help but would also appreciate if you could take
your time when doing changes/reverts etc. on the work of others.
You could simply let me commit my work which was based upon the latest trunk
changes. Now it was incomplete/has errors (see my last commit) and I was not
able to merge my PR due to conflicts based on your changes.
> Gradle eclipse target produces duplicate build path entries in .classpath
> -
>
> Key: OFBIZ-12888
> URL: https://issues.apache.org/jira/browse/OFBIZ-12888
> Project: OFBiz
> Issue Type: Bug
> Components: Gradle
>Affects Versions: Upcoming Branch
>Reporter: Michael Brohl
>Assignee: Michael Brohl
>Priority: Major
> Fix For: Upcoming Branch
>
>
> I'm currently working on a solution for this.
> Maybe someone can explain why we use the GroovyScripts source set for the
> codenarc checks in the pre-push hook:
>
> {code:java}
> gitHooks {
>hooks = ['pre-push': 'checkstyleMain codenarcGroovyScripts']
> }
> {code}
> That target seems to be automatically defined through the source set
> definition for groovyScripts.
> If I remove that source set and the following task configuration:
>
> {code:java}
> tasks.named('compileGroovyScriptsGroovy') {
> // We don't want to build groovyScripts as they should be considered as
> standalone elements executed in
> // isolation by ofbiz. Building them will result in numerous error due to
> duplicated classes.
> enabled = false
> }
> {code}
>
> And change the git hooks to
>
> {code:java}
> }
> gitHooks {
> hooks = ['pre-push': 'checkstyleMain codenarcMain codenarcTest']
> }
> {code}
>
> (which is accoring to the pre-push hook definition in .git/hooks/pre-push)
> everything seems to work fine, tests are working and the codenarc Main and
> Test reports are build.
> I provide a PR for it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OFBIZ-12888) Gradle eclipse target produces duplicate build path entries in .classpath
[
https://issues.apache.org/jira/browse/OFBIZ-12888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814288#comment-17814288
]
Michael Brohl commented on OFBIZ-12888:
---
[~jleroux] I appreciate you help but would also appreciate if you could take
your time when doing changes/reverts etc. on the work of others.
You could simply let me commit my work which was based upon the latest trunk
changes. Now it was incomplete/has errors (see my last commit) and I was not
able to merge my PR due to conflicts based on your changes.
> Gradle eclipse target produces duplicate build path entries in .classpath
> -
>
> Key: OFBIZ-12888
> URL: https://issues.apache.org/jira/browse/OFBIZ-12888
> Project: OFBiz
> Issue Type: Bug
> Components: Gradle
>Affects Versions: Upcoming Branch
>Reporter: Michael Brohl
>Assignee: Michael Brohl
>Priority: Major
>
> I'm currently working on a solution for this.
> Maybe someone can explain why we use the GroovyScripts source set for the
> codenarc checks in the pre-push hook:
>
> {code:java}
> gitHooks {
>hooks = ['pre-push': 'checkstyleMain codenarcGroovyScripts']
> }
> {code}
> That target seems to be automatically defined through the source set
> definition for groovyScripts.
> If I remove that source set and the following task configuration:
>
> {code:java}
> tasks.named('compileGroovyScriptsGroovy') {
> // We don't want to build groovyScripts as they should be considered as
> standalone elements executed in
> // isolation by ofbiz. Building them will result in numerous error due to
> duplicated classes.
> enabled = false
> }
> {code}
>
> And change the git hooks to
>
> {code:java}
> }
> gitHooks {
> hooks = ['pre-push': 'checkstyleMain codenarcMain codenarcTest']
> }
> {code}
>
> (which is accoring to the pre-push hook definition in .git/hooks/pre-push)
> everything seems to work fine, tests are working and the codenarc Main and
> Test reports are build.
> I provide a PR for it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OFBIZ-12888) Gradle eclipse target produces duplicate build path entries in .classpath
[
https://issues.apache.org/jira/browse/OFBIZ-12888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814257#comment-17814257
]
Michael Brohl commented on OFBIZ-12888:
---
It would have been better to leave the code base as is, because my PR is based
on latest trunk...
Anyway, I'll make a new one/amend the existing.
Thanks Daniel for the clear explanation.
> Gradle eclipse target produces duplicate build path entries in .classpath
> -
>
> Key: OFBIZ-12888
> URL: https://issues.apache.org/jira/browse/OFBIZ-12888
> Project: OFBiz
> Issue Type: Bug
> Components: Gradle
>Affects Versions: Upcoming Branch
>Reporter: Michael Brohl
>Assignee: Michael Brohl
>Priority: Major
>
> I'm currently working on a solution for this.
> Maybe someone can explain why we use the GroovyScripts source set for the
> codenarc checks in the pre-push hook:
>
> {code:java}
> gitHooks {
>hooks = ['pre-push': 'checkstyleMain codenarcGroovyScripts']
> }
> {code}
> That target seems to be automatically defined through the source set
> definition for groovyScripts.
> If I remove that source set and the following task configuration:
>
> {code:java}
> tasks.named('compileGroovyScriptsGroovy') {
> // We don't want to build groovyScripts as they should be considered as
> standalone elements executed in
> // isolation by ofbiz. Building them will result in numerous error due to
> duplicated classes.
> enabled = false
> }
> {code}
>
> And change the git hooks to
>
> {code:java}
> }
> gitHooks {
> hooks = ['pre-push': 'checkstyleMain codenarcMain codenarcTest']
> }
> {code}
>
> (which is accoring to the pre-push hook definition in .git/hooks/pre-push)
> everything seems to work fine, tests are working and the codenarc Main and
> Test reports are build.
> I provide a PR for it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OFBIZ-12888) Gradle eclipse target produces duplicate build path entries in .classpath
[
https://issues.apache.org/jira/browse/OFBIZ-12888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814116#comment-17814116
]
Michael Brohl commented on OFBIZ-12888:
---
I think we'll have to test the change...
> Gradle eclipse target produces duplicate build path entries in .classpath
> -
>
> Key: OFBIZ-12888
> URL: https://issues.apache.org/jira/browse/OFBIZ-12888
> Project: OFBiz
> Issue Type: Bug
> Components: Gradle
>Affects Versions: Upcoming Branch
>Reporter: Michael Brohl
>Assignee: Michael Brohl
>Priority: Major
>
> I'm currently working on a solution for this.
> Maybe someone can explain why we use the GroovyScripts source set for the
> codenarc checks in the pre-push hook:
>
> {code:java}
> gitHooks {
>hooks = ['pre-push': 'checkstyleMain codenarcGroovyScripts']
> }
> {code}
> That target seems to be automatically defined through the source set
> definition for groovyScripts.
> If I remove that source set and the following task configuration:
>
> {code:java}
> tasks.named('compileGroovyScriptsGroovy') {
> // We don't want to build groovyScripts as they should be considered as
> standalone elements executed in
> // isolation by ofbiz. Building them will result in numerous error due to
> duplicated classes.
> enabled = false
> }
> {code}
>
> And change the git hooks to
>
> {code:java}
> }
> gitHooks {
> hooks = ['pre-push': 'checkstyleMain codenarcMain codenarcTest']
> }
> {code}
>
> (which is accoring to the pre-push hook definition in .git/hooks/pre-push)
> everything seems to work fine, tests are working and the codenarc Main and
> Test reports are build.
> I provide a PR for it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OFBIZ-12888) Gradle eclipse target produces duplicate build path entries in .classpath
[
https://issues.apache.org/jira/browse/OFBIZ-12888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814099#comment-17814099
]
Michael Brohl commented on OFBIZ-12888:
---
A quick test shows there is no difference in the consumed time for "./gradlew
codenarcGroovyscripts" vs. "./gradlew codenarcMain codenarcTest".
Both are run after a "./gradlew clean" and take 10s each on my machine.
> Gradle eclipse target produces duplicate build path entries in .classpath
> -
>
> Key: OFBIZ-12888
> URL: https://issues.apache.org/jira/browse/OFBIZ-12888
> Project: OFBiz
> Issue Type: Bug
> Components: Gradle
>Affects Versions: Upcoming Branch
>Reporter: Michael Brohl
>Assignee: Michael Brohl
>Priority: Major
>
> I'm currently working on a solution for this.
> Maybe someone can explain why we use the GroovyScripts source set for the
> codenarc checks in the pre-push hook:
>
> {code:java}
> gitHooks {
>hooks = ['pre-push': 'checkstyleMain codenarcGroovyScripts']
> }
> {code}
> That target seems to be automatically defined through the source set
> definition for groovyScripts.
> If I remove that source set and the following task configuration:
>
> {code:java}
> tasks.named('compileGroovyScriptsGroovy') {
> // We don't want to build groovyScripts as they should be considered as
> standalone elements executed in
> // isolation by ofbiz. Building them will result in numerous error due to
> duplicated classes.
> enabled = false
> }
> {code}
>
> And change the git hooks to
>
> {code:java}
> }
> gitHooks {
> hooks = ['pre-push': 'checkstyleMain codenarcMain codenarcTest']
> }
> {code}
>
> (which is accoring to the pre-push hook definition in .git/hooks/pre-push)
> everything seems to work fine, tests are working and the codenarc Main and
> Test reports are build.
> I provide a PR for it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OFBIZ-12888) Gradle eclipse target produces duplicate build path entries in .classpath
[
https://issues.apache.org/jira/browse/OFBIZ-12888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814097#comment-17814097
]
Michael Brohl commented on OFBIZ-12888:
---
The question is, how significant the performance gap really is...
Yes, it's a lot of duplicates (ALL src/main/groovy paths are duplicated). The
generated .classpath prevents users from being able to have Eclipse build the
project because of a duplicate build path error.
> Gradle eclipse target produces duplicate build path entries in .classpath
> -
>
> Key: OFBIZ-12888
> URL: https://issues.apache.org/jira/browse/OFBIZ-12888
> Project: OFBiz
> Issue Type: Bug
> Components: Gradle
>Affects Versions: Upcoming Branch
>Reporter: Michael Brohl
>Assignee: Michael Brohl
>Priority: Major
>
> I'm currently working on a solution for this.
> Maybe someone can explain why we use the GroovyScripts source set for the
> codenarc checks in the pre-push hook:
>
> {code:java}
> gitHooks {
>hooks = ['pre-push': 'checkstyleMain codenarcGroovyScripts']
> }
> {code}
> That target seems to be automatically defined through the source set
> definition for groovyScripts.
> If I remove that source set and the following task configuration:
>
> {code:java}
> tasks.named('compileGroovyScriptsGroovy') {
> // We don't want to build groovyScripts as they should be considered as
> standalone elements executed in
> // isolation by ofbiz. Building them will result in numerous error due to
> duplicated classes.
> enabled = false
> }
> {code}
>
> And change the git hooks to
>
> {code:java}
> }
> gitHooks {
> hooks = ['pre-push': 'checkstyleMain codenarcMain codenarcTest']
> }
> {code}
>
> (which is accoring to the pre-push hook definition in .git/hooks/pre-push)
> everything seems to work fine, tests are working and the codenarc Main and
> Test reports are build.
> I provide a PR for it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OFBIZ-12888) Gradle eclipse target produces duplicate build path entries in .classpath
[
https://issues.apache.org/jira/browse/OFBIZ-12888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814072#comment-17814072
]
Michael Brohl commented on OFBIZ-12888:
---
I see there is a commit message comment on that. Does it really make a
difference to use "codenarcGroovyScripts" instead of "codenarcMain
codenarcTest" to achieve the same?
The proposed solution would fix the duplicate build path entries (which is a
bug) and seems to work fine for the codenarch checks as well.
> Gradle eclipse target produces duplicate build path entries in .classpath
> -
>
> Key: OFBIZ-12888
> URL: https://issues.apache.org/jira/browse/OFBIZ-12888
> Project: OFBiz
> Issue Type: Bug
> Components: Gradle
>Affects Versions: Upcoming Branch
>Reporter: Michael Brohl
>Assignee: Michael Brohl
>Priority: Major
>
> I'm currently working on a solution for this.
> Maybe someone can explain why we use the GroovyScripts source set for the
> codenarc checks in the pre-push hook:
>
> {code:java}
> gitHooks {
>hooks = ['pre-push': 'checkstyleMain codenarcGroovyScripts']
> }
> {code}
> That target seems to be automatically defined through the source set
> definition for groovyScripts.
> If I remove that source set and the following task configuration:
>
> {code:java}
> tasks.named('compileGroovyScriptsGroovy') {
> // We don't want to build groovyScripts as they should be considered as
> standalone elements executed in
> // isolation by ofbiz. Building them will result in numerous error due to
> duplicated classes.
> enabled = false
> }
> {code}
>
> And change the git hooks to
>
> {code:java}
> }
> gitHooks {
> hooks = ['pre-push': 'checkstyleMain codenarcMain codenarcTest']
> }
> {code}
>
> (which is accoring to the pre-push hook definition in .git/hooks/pre-push)
> everything seems to work fine, tests are working and the codenarc Main and
> Test reports are build.
> I provide a PR for it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OFBIZ-12888) Gradle eclipse target produces duplicate build path entries in .classpath
Michael Brohl created OFBIZ-12888:
-
Summary: Gradle eclipse target produces duplicate build path
entries in .classpath
Key: OFBIZ-12888
URL: https://issues.apache.org/jira/browse/OFBIZ-12888
Project: OFBiz
Issue Type: Bug
Components: Gradle
Affects Versions: Upcoming Branch
Reporter: Michael Brohl
Assignee: Michael Brohl
I'm currently working on a solution for this.
Maybe someone can explain why we use the GroovyScripts source set for the
codenarc checks in the pre-push hook:
{code:java}
gitHooks {
hooks = ['pre-push': 'checkstyleMain codenarcGroovyScripts']
}
{code}
That target seems to be automatically defined through the source set definition
for groovyScripts.
If I remove that source set and the following task configuration:
{code:java}
tasks.named('compileGroovyScriptsGroovy') {
// We don't want to build groovyScripts as they should be considered as
standalone elements executed in
// isolation by ofbiz. Building them will result in numerous error due to
duplicated classes.
enabled = false
}
{code}
And change the git hooks to
{code:java}
}
gitHooks {
hooks = ['pre-push': 'checkstyleMain codenarcMain codenarcTest']
}
{code}
(which is accoring to the pre-push hook definition in .git/hooks/pre-push)
everything seems to work fine, tests are working and the codenarc Main and Test
reports are build.
I provide a PR for it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OFBIZ-10194) ContentWrapper empty string result breaks simple FTL null check and default syntax
[
https://issues.apache.org/jira/browse/OFBIZ-10194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813962#comment-17813962
]
Michael Brohl commented on OFBIZ-10194:
---
Hi Jacques,
could be but I don't think it's worth the effort: 22.01 will be abandoned in
favor of a newer release branch and 18.12 is not supported (excl. security
fixes).
> ContentWrapper empty string result breaks simple FTL null check and default
> syntax
> --
>
> Key: OFBIZ-10194
> URL: https://issues.apache.org/jira/browse/OFBIZ-10194
> Project: OFBiz
> Issue Type: Bug
> Components: content, order, party, product
>Affects Versions: 16.11.04
>Reporter: Martin Becker
>Assignee: Michael Brohl
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBiz-10194_ContentWrappers.patch
>
>
> Since the changes to the ContentWrappers from Ticket OFBIZ-6701 the result
> for non existing content is an empty string instead of NULL.
> Aside from my opinion, that this is generally a bad design preferred by those
> who do not like to check for null values within their code, this behavior
> breaks the simple FTL syntax for using an alternate (default) value for a non
> existing content, retrieved by a ContentWrapper like this:
> {code:java}
> <#assign categoryName = categoryContentWrapper.get("CATEGORY_NAME",
> "string")!category.internalName?default(category.productCategoryId) />{code}
> Basically this was done to get the non-existing-content cached within the
> *.content.rendered cache and let the simple condition
> {code:java}
> if (cachedValue != null){code}
> after a cache.get() respect this empty value. With a simple change to the
> condition to
> {code:java}
> if (cachedValue != null || cache.containsKey(cacheKey)){code}
> it is also possible to cache and successfully retrieve NULL values from the
> cache.
> I observed this now during an upgrade of OFBiz 12 based application code to
> the current OFBiz release.
> Besides this I did following refactorings consistently for all ContentWrapper
> implementations to reduce code redundancy:
> * centralized default mimeTypeId retrieval (static Interface method in
> ContentWrapper)
> * centralized encoding of result string via UtilEncoder (static Interface
> method in ContentWrapper)
> * centralized/generalized candidate field value retrieval (static Interface
> method in ContentWrapper)
> * harmonized content cache name to „xyz.content.rendered“, some wrappers did
> not use the „.rendered“ suffix in their cache name
> * fixed some missing useCache parameter use in EntityQuery…cache()… calls
> For Category and Product ContentWrapper I updated the parameter handling of
> the central getXyzContentAsText method where both, productId and product
> GenericValue are given but no check is performed, if both are matching if
> both are given (bad parameter signature, by the way). Now the product GV is
> looked up, if a productId is given, and the productId is used from a given
> product GV always, not only if it is missing. The drawback is, that there
> will always be a lookup for Product/ProductCategory GV, even if a content
> entry could be found with the productId/productCategoryId only. On the other
> hand, the GV is always part of the content rendering input context, currently
> it is missing there, if only a ID is given as parameter, again not really
> consistent.
> I did not wanted to change this for all content wrappers directly before
> getting a feedback for it, even if it would be more consistent to have a
> content rendering context with a product GV as input, independent of the
> original call parameters productId and/or product GV.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (OFBIZ-10194) ContentWrapper empty string result breaks simple FTL null check and default syntax
[
https://issues.apache.org/jira/browse/OFBIZ-10194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl closed OFBIZ-10194.
-
Resolution: Fixed
> ContentWrapper empty string result breaks simple FTL null check and default
> syntax
> --
>
> Key: OFBIZ-10194
> URL: https://issues.apache.org/jira/browse/OFBIZ-10194
> Project: OFBiz
> Issue Type: Bug
> Components: content, order, party, product
>Affects Versions: 16.11.04
>Reporter: Martin Becker
>Assignee: Michael Brohl
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBiz-10194_ContentWrappers.patch
>
>
> Since the changes to the ContentWrappers from Ticket OFBIZ-6701 the result
> for non existing content is an empty string instead of NULL.
> Aside from my opinion, that this is generally a bad design preferred by those
> who do not like to check for null values within their code, this behavior
> breaks the simple FTL syntax for using an alternate (default) value for a non
> existing content, retrieved by a ContentWrapper like this:
> {code:java}
> <#assign categoryName = categoryContentWrapper.get("CATEGORY_NAME",
> "string")!category.internalName?default(category.productCategoryId) />{code}
> Basically this was done to get the non-existing-content cached within the
> *.content.rendered cache and let the simple condition
> {code:java}
> if (cachedValue != null){code}
> after a cache.get() respect this empty value. With a simple change to the
> condition to
> {code:java}
> if (cachedValue != null || cache.containsKey(cacheKey)){code}
> it is also possible to cache and successfully retrieve NULL values from the
> cache.
> I observed this now during an upgrade of OFBiz 12 based application code to
> the current OFBiz release.
> Besides this I did following refactorings consistently for all ContentWrapper
> implementations to reduce code redundancy:
> * centralized default mimeTypeId retrieval (static Interface method in
> ContentWrapper)
> * centralized encoding of result string via UtilEncoder (static Interface
> method in ContentWrapper)
> * centralized/generalized candidate field value retrieval (static Interface
> method in ContentWrapper)
> * harmonized content cache name to „xyz.content.rendered“, some wrappers did
> not use the „.rendered“ suffix in their cache name
> * fixed some missing useCache parameter use in EntityQuery…cache()… calls
> For Category and Product ContentWrapper I updated the parameter handling of
> the central getXyzContentAsText method where both, productId and product
> GenericValue are given but no check is performed, if both are matching if
> both are given (bad parameter signature, by the way). Now the product GV is
> looked up, if a productId is given, and the productId is used from a given
> product GV always, not only if it is missing. The drawback is, that there
> will always be a lookup for Product/ProductCategory GV, even if a content
> entry could be found with the productId/productCategoryId only. On the other
> hand, the GV is always part of the content rendering input context, currently
> it is missing there, if only a ID is given as parameter, again not really
> consistent.
> I did not wanted to change this for all content wrappers directly before
> getting a feedback for it, even if it would be more consistent to have a
> content rendering context with a product GV as input, independent of the
> original call parameters productId and/or product GV.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (OFBIZ-10194) ContentWrapper empty string result breaks simple FTL null check and default syntax
[
https://issues.apache.org/jira/browse/OFBIZ-10194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl reopened OFBIZ-10194:
---
Reopened to do some more work to make the solution complete (we did not take
over all modifications).
> ContentWrapper empty string result breaks simple FTL null check and default
> syntax
> --
>
> Key: OFBIZ-10194
> URL: https://issues.apache.org/jira/browse/OFBIZ-10194
> Project: OFBiz
> Issue Type: Bug
> Components: content, order, party, product
>Affects Versions: 16.11.04
>Reporter: Martin Becker
>Assignee: Michael Brohl
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBiz-10194_ContentWrappers.patch
>
>
> Since the changes to the ContentWrappers from Ticket OFBIZ-6701 the result
> for non existing content is an empty string instead of NULL.
> Aside from my opinion, that this is generally a bad design preferred by those
> who do not like to check for null values within their code, this behavior
> breaks the simple FTL syntax for using an alternate (default) value for a non
> existing content, retrieved by a ContentWrapper like this:
> {code:java}
> <#assign categoryName = categoryContentWrapper.get("CATEGORY_NAME",
> "string")!category.internalName?default(category.productCategoryId) />{code}
> Basically this was done to get the non-existing-content cached within the
> *.content.rendered cache and let the simple condition
> {code:java}
> if (cachedValue != null){code}
> after a cache.get() respect this empty value. With a simple change to the
> condition to
> {code:java}
> if (cachedValue != null || cache.containsKey(cacheKey)){code}
> it is also possible to cache and successfully retrieve NULL values from the
> cache.
> I observed this now during an upgrade of OFBiz 12 based application code to
> the current OFBiz release.
> Besides this I did following refactorings consistently for all ContentWrapper
> implementations to reduce code redundancy:
> * centralized default mimeTypeId retrieval (static Interface method in
> ContentWrapper)
> * centralized encoding of result string via UtilEncoder (static Interface
> method in ContentWrapper)
> * centralized/generalized candidate field value retrieval (static Interface
> method in ContentWrapper)
> * harmonized content cache name to „xyz.content.rendered“, some wrappers did
> not use the „.rendered“ suffix in their cache name
> * fixed some missing useCache parameter use in EntityQuery…cache()… calls
> For Category and Product ContentWrapper I updated the parameter handling of
> the central getXyzContentAsText method where both, productId and product
> GenericValue are given but no check is performed, if both are matching if
> both are given (bad parameter signature, by the way). Now the product GV is
> looked up, if a productId is given, and the productId is used from a given
> product GV always, not only if it is missing. The drawback is, that there
> will always be a lookup for Product/ProductCategory GV, even if a content
> entry could be found with the productId/productCategoryId only. On the other
> hand, the GV is always part of the content rendering input context, currently
> it is missing there, if only a ID is given as parameter, again not really
> consistent.
> I did not wanted to change this for all content wrappers directly before
> getting a feedback for it, even if it would be more consistent to have a
> content rendering context with a product GV as input, independent of the
> original call parameters productId and/or product GV.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (OFBIZ-12880) Keep needed classpath entries in the Eclipse .classpath file
[ https://issues.apache.org/jira/browse/OFBIZ-12880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl closed OFBIZ-12880. - Resolution: Fixed > Keep needed classpath entries in the Eclipse .classpath file > > > Key: OFBIZ-12880 > URL: https://issues.apache.org/jira/browse/OFBIZ-12880 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Upcoming Branch >Reporter: Michael Brohl >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > In the current build, classpath entries for config folders and dtds are > removed from the .classpath file after it is generated by the Eclipse Gradle > task. > Those folders and any others defined by the ofbiz-component classpath entries > must be kept to be able to run OFBiz from within Eclipse run/debug > configurations, at least for the JDK17 based OFBiz and recent Eclipse > versions. > The setting allows to create a run/debug configurations ootb in Eclipse > without the need for ofbiz.jar in the classpath and allows full hot code > replacement functionality. > I will provide a pull request for this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OFBIZ-12880) Keep needed classpath entries in the Eclipse .classpath file
[ https://issues.apache.org/jira/browse/OFBIZ-12880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl reassigned OFBIZ-12880: - Assignee: Michael Brohl > Keep needed classpath entries in the Eclipse .classpath file > > > Key: OFBIZ-12880 > URL: https://issues.apache.org/jira/browse/OFBIZ-12880 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Upcoming Branch >Reporter: Michael Brohl >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > In the current build, classpath entries for config folders and dtds are > removed from the .classpath file after it is generated by the Eclipse Gradle > task. > Those folders and any others defined by the ofbiz-component classpath entries > must be kept to be able to run OFBiz from within Eclipse run/debug > configurations, at least for the JDK17 based OFBiz and recent Eclipse > versions. > The setting allows to create a run/debug configurations ootb in Eclipse > without the need for ofbiz.jar in the classpath and allows full hot code > replacement functionality. > I will provide a pull request for this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (OFBIZ-10194) ContentWrapper empty string result breaks simple FTL null check and default syntax
[
https://issues.apache.org/jira/browse/OFBIZ-10194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl closed OFBIZ-10194.
-
Fix Version/s: Upcoming Branch
Resolution: Fixed
> ContentWrapper empty string result breaks simple FTL null check and default
> syntax
> --
>
> Key: OFBIZ-10194
> URL: https://issues.apache.org/jira/browse/OFBIZ-10194
> Project: OFBiz
> Issue Type: Bug
> Components: content, order, party, product
>Affects Versions: 16.11.04
>Reporter: Martin Becker
>Assignee: Michael Brohl
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBiz-10194_ContentWrappers.patch
>
>
> Since the changes to the ContentWrappers from Ticket OFBIZ-6701 the result
> for non existing content is an empty string instead of NULL.
> Aside from my opinion, that this is generally a bad design preferred by those
> who do not like to check for null values within their code, this behavior
> breaks the simple FTL syntax for using an alternate (default) value for a non
> existing content, retrieved by a ContentWrapper like this:
> {code:java}
> <#assign categoryName = categoryContentWrapper.get("CATEGORY_NAME",
> "string")!category.internalName?default(category.productCategoryId) />{code}
> Basically this was done to get the non-existing-content cached within the
> *.content.rendered cache and let the simple condition
> {code:java}
> if (cachedValue != null){code}
> after a cache.get() respect this empty value. With a simple change to the
> condition to
> {code:java}
> if (cachedValue != null || cache.containsKey(cacheKey)){code}
> it is also possible to cache and successfully retrieve NULL values from the
> cache.
> I observed this now during an upgrade of OFBiz 12 based application code to
> the current OFBiz release.
> Besides this I did following refactorings consistently for all ContentWrapper
> implementations to reduce code redundancy:
> * centralized default mimeTypeId retrieval (static Interface method in
> ContentWrapper)
> * centralized encoding of result string via UtilEncoder (static Interface
> method in ContentWrapper)
> * centralized/generalized candidate field value retrieval (static Interface
> method in ContentWrapper)
> * harmonized content cache name to „xyz.content.rendered“, some wrappers did
> not use the „.rendered“ suffix in their cache name
> * fixed some missing useCache parameter use in EntityQuery…cache()… calls
> For Category and Product ContentWrapper I updated the parameter handling of
> the central getXyzContentAsText method where both, productId and product
> GenericValue are given but no check is performed, if both are matching if
> both are given (bad parameter signature, by the way). Now the product GV is
> looked up, if a productId is given, and the productId is used from a given
> product GV always, not only if it is missing. The drawback is, that there
> will always be a lookup for Product/ProductCategory GV, even if a content
> entry could be found with the productId/productCategoryId only. On the other
> hand, the GV is always part of the content rendering input context, currently
> it is missing there, if only a ID is given as parameter, again not really
> consistent.
> I did not wanted to change this for all content wrappers directly before
> getting a feedback for it, even if it would be more consistent to have a
> content rendering context with a product GV as input, independent of the
> original call parameters productId and/or product GV.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (OFBIZ-12802) Extending calculateProductPrice (custom) Service and ShoppingCart / OrderItem to deliver/hold an individual discountRate value
[ https://issues.apache.org/jira/browse/OFBIZ-12802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl closed OFBIZ-12802. - Fix Version/s: Upcoming Branch Resolution: Implemented > Extending calculateProductPrice (custom) Service and ShoppingCart / OrderItem > to deliver/hold an individual discountRate value > -- > > Key: OFBIZ-12802 > URL: https://issues.apache.org/jira/browse/OFBIZ-12802 > Project: OFBiz > Issue Type: New Feature >Reporter: Adrian Wolf >Assignee: Michael Brohl >Priority: Minor > Fix For: Upcoming Branch > > > Background is the communication of an individually (informally) calculated > discount rate from the price calculation to the OrderItem, with easy access > to it (because of this not via the orderItemPriceInfos substructure). > > Extending ProductPrice.calculateProductPrice Service (all in > PriceServices.java and services_pricepromo.xml): > * Addition of additional context information "productStoreGroupId" and > "partyId" to the call parameters of a "customMethodName" price-calc-service > * Obtaining the fields discountRate and listPrice from calling a > "customMethodName" price-calc-service > * discountRate as Result Field > * Retaining the bypassing of the OFBiz Standard PriceRules based on the > presence of a ListPrice (only that it can now also come from the > "customMethodName", therefore slightly changed decision logic) > Extending ShoppingCart/Item, OrderItem Entity: > * Transport original discount rate from custom price calculation over cart > to order to have the correct rate instead of back-calculating it from > unitPrice and unitListPrice -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OFBIZ-12880) Keep needed classpath entries in the Eclipse .classpath file
[ https://issues.apache.org/jira/browse/OFBIZ-12880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl reassigned OFBIZ-12880: - Assignee: (was: Michael Brohl) > Keep needed classpath entries in the Eclipse .classpath file > > > Key: OFBIZ-12880 > URL: https://issues.apache.org/jira/browse/OFBIZ-12880 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Upcoming Branch >Reporter: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > In the current build, classpath entries for config folders and dtds are > removed from the .classpath file after it is generated by the Eclipse Gradle > task. > Those folders and any others defined by the ofbiz-component classpath entries > must be kept to be able to run OFBiz from within Eclipse run/debug > configurations, at least for the JDK17 based OFBiz and recent Eclipse > versions. > The setting allows to create a run/debug configurations ootb in Eclipse > without the need for ofbiz.jar in the classpath and allows full hot code > replacement functionality. > I will provide a pull request for this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OFBIZ-12880) Keep needed classpath entries in the Eclipse .classpath file
[ https://issues.apache.org/jira/browse/OFBIZ-12880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl updated OFBIZ-12880: -- Description: In the current build, classpath entries for config folders and dtds are removed from the .classpath file after it is generated by the Eclipse Gradle task. Those folders and any others defined by the ofbiz-component classpath entries must be kept to be able to run OFBiz from within Eclipse run/debug configurations, at least for the JDK17 based OFBiz and recent Eclipse versions. The setting allows to create a run/debug configurations ootb in Eclipse without the need for ofbiz.jar in the classpath and allows full hot code replacement functionality. I will provide a pull request for this. > Keep needed classpath entries in the Eclipse .classpath file > > > Key: OFBIZ-12880 > URL: https://issues.apache.org/jira/browse/OFBIZ-12880 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Upcoming Branch >Reporter: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > In the current build, classpath entries for config folders and dtds are > removed from the .classpath file after it is generated by the Eclipse Gradle > task. > Those folders and any others defined by the ofbiz-component classpath entries > must be kept to be able to run OFBiz from within Eclipse run/debug > configurations, at least for the JDK17 based OFBiz and recent Eclipse > versions. > The setting allows to create a run/debug configurations ootb in Eclipse > without the need for ofbiz.jar in the classpath and allows full hot code > replacement functionality. > I will provide a pull request for this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OFBIZ-12880) Keep needed classpath entries in the Eclipse .classpath file
[ https://issues.apache.org/jira/browse/OFBIZ-12880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl reassigned OFBIZ-12880: - Assignee: Michael Brohl > Keep needed classpath entries in the Eclipse .classpath file > > > Key: OFBIZ-12880 > URL: https://issues.apache.org/jira/browse/OFBIZ-12880 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Upcoming Branch >Reporter: Michael Brohl >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > In the current build, classpath entries for config folders and dtds are > removed from the .classpath file after it is generated by the Eclipse Gradle > task. > Those folders and any others defined by the ofbiz-component classpath entries > must be kept to be able to run OFBiz from within Eclipse run/debug > configurations, at least for the JDK17 based OFBiz and recent Eclipse > versions. > The setting allows to create a run/debug configurations ootb in Eclipse > without the need for ofbiz.jar in the classpath and allows full hot code > replacement functionality. > I will provide a pull request for this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OFBIZ-12880) Keep needed classpath entries in the Eclipse .classpath file
Michael Brohl created OFBIZ-12880: - Summary: Keep needed classpath entries in the Eclipse .classpath file Key: OFBIZ-12880 URL: https://issues.apache.org/jira/browse/OFBIZ-12880 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Upcoming Branch Reporter: Michael Brohl Fix For: Upcoming Branch -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (OFBIZ-12769) Fix plugins to work with release22.01 framework
[ https://issues.apache.org/jira/browse/OFBIZ-12769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl closed OFBIZ-12769. - Resolution: Won't Do Thanks for the heads-up [~jleroux] . Since we are going to abandon 22.01 in favor of a 23.x release branch where the problems are fixed, I'm closing this issue. > Fix plugins to work with release22.01 framework > --- > > Key: OFBIZ-12769 > URL: https://issues.apache.org/jira/browse/OFBIZ-12769 > Project: OFBiz > Issue Type: Sub-task > Components: ALL PLUGINS >Affects Versions: 22.01.01 >Reporter: Michael Brohl >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17752138#comment-17752138 ] Michael Brohl commented on OFBIZ-12813: --- +1 for closing [~deepak] the dependency to the projectmgr is checked, the code checks if the projectmgr plugin is active and renders the screen if so. > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > For example, under framework -> base -> src there is a distinction between > main and test. Within the test folder there is again a distinction between > groovy and Java. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “The Java Platform Module System requires that classes in distinct modules > have distinct package names. Groovy has its own "modules" but these haven’t > historically been structured according to the above requirement. For this > reason, Groovy 2.x and 3.0 should be added to the classpath not module path > when using JDK9+. This places Groovy’s classes into the unnamed module where > the split package naming requirement is not enforced.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12400) Upgrade to gradle 7.6 - support JDK 11 -> 17
[ https://issues.apache.org/jira/browse/OFBIZ-12400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17752135#comment-17752135 ] Michael Brohl commented on OFBIZ-12400: --- [~jleroux] there seem to be a mismatch between the ps1 and sh scripts functionality. The sh script not only downloads the wrapper jar file but also the corresponding properties file. For 7.6.0, it contains gradle-7.6-rc-4-bin.zip instead of gradle-7.6-bin.zip and therefore alters the content and checksums. I tried with 7.6.2, the latest 7.x version and found that the corresponding properties file states the 7.6.1 distribution instead of 7.6.2 which makes the shasum check fail. Looking though the distributions it seems that the properties file is often not correctly edited. I am not sure how much we need to check the file integrity and if we should make the shell script simpler. Any opinions? > Upgrade to gradle 7.6 - support JDK 11 -> 17 > > > Key: OFBIZ-12400 > URL: https://issues.apache.org/jira/browse/OFBIZ-12400 > Project: OFBiz > Issue Type: Task >Reporter: Ioan Eugen Stan >Assignee: Ioan Eugen Stan >Priority: Major > Attachments: OFBIZ-12400-windows-binary.patch > > > For working with Java 17, we need to upgrade to gradle 7.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12400) Upgrade to gradle 7.6 - support JDK 11 -> 17
[ https://issues.apache.org/jira/browse/OFBIZ-12400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17752111#comment-17752111 ] Michael Brohl commented on OFBIZ-12400: --- Ah, thanks for the heads-up Jacques. Will provide a pr soon. > Upgrade to gradle 7.6 - support JDK 11 -> 17 > > > Key: OFBIZ-12400 > URL: https://issues.apache.org/jira/browse/OFBIZ-12400 > Project: OFBiz > Issue Type: Task >Reporter: Ioan Eugen Stan >Assignee: Ioan Eugen Stan >Priority: Major > Attachments: OFBIZ-12400-windows-binary.patch > > > For working with Java 17, we need to upgrade to gradle 7.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749603#comment-17749603 ] Michael Brohl commented on OFBIZ-12813: --- There is a problem with a duplicate class now: ProductsExportToEbay exists as a Java class and Groovy class. I'll rename the Groovy File to ProductsExportToEbayScript.groovy like Wiebke did in the previous refactorings. > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > For example, under framework -> base -> src there is a distinction between > main and test. Within the test folder there is again a distinction between > groovy and Java. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “The Java Platform Module System requires that classes in distinct modules > have distinct package names. Groovy has its own "modules" but these haven’t > historically been structured according to the above requirement. For this > reason, Groovy 2.x and 3.0 should be added to the classpath not module path > when using JDK9+. This places Groovy’s classes into the unnamed module where > the split package naming requirement is not enforced.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749574#comment-17749574 ] Michael Brohl commented on OFBIZ-12813: --- Everything is merged now. > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > For example, under framework -> base -> src there is a distinction between > main and test. Within the test folder there is again a distinction between > groovy and Java. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “The Java Platform Module System requires that classes in distinct modules > have distinct package names. Groovy has its own "modules" but these haven’t > historically been structured according to the above requirement. For this > reason, Groovy 2.x and 3.0 should be added to the classpath not module path > when using JDK9+. This places Groovy’s classes into the unnamed module where > the split package naming requirement is not enforced.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749574#comment-17749574 ] Michael Brohl edited comment on OFBIZ-12813 at 8/1/23 8:51 AM: --- Everything is merged now. I think we can close this issue, right? was (Author: mbrohl): Everything is merged now. > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > For example, under framework -> base -> src there is a distinction between > main and test. Within the test folder there is again a distinction between > groovy and Java. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “The Java Platform Module System requires that classes in distinct modules > have distinct package names. Groovy has its own "modules" but these haven’t > historically been structured according to the above requirement. For this > reason, Groovy 2.x and 3.0 should be added to the classpath not module path > when using JDK9+. This places Groovy’s classes into the unnamed module where > the split package naming requirement is not enforced.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749256#comment-17749256 ] Michael Brohl commented on OFBIZ-12813: --- I've created a new PR fixing the remaining issues in framework. > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > For example, under framework -> base -> src there is a distinction between > main and test. Within the test folder there is again a distinction between > groovy and Java. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “The Java Platform Module System requires that classes in distinct modules > have distinct package names. Groovy has its own "modules" but these haven’t > historically been structured according to the above requirement. For this > reason, Groovy 2.x and 3.0 should be added to the classpath not module path > when using JDK9+. This places Groovy’s classes into the unnamed module where > the split package naming requirement is not enforced.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748965#comment-17748965 ] Michael Brohl commented on OFBIZ-12813: --- The changes for the plugins are added to the PR. > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > For example, under framework -> base -> src there is a distinction between > main and test. Within the test folder there is again a distinction between > groovy and Java. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “The Java Platform Module System requires that classes in distinct modules > have distinct package names. Groovy has its own "modules" but these haven’t > historically been structured according to the above requirement. For this > reason, Groovy 2.x and 3.0 should be added to the classpath not module path > when using JDK9+. This places Groovy’s classes into the unnamed module where > the split package naming requirement is not enforced.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748960#comment-17748960 ] Michael Brohl commented on OFBIZ-12813: --- Thank you Jacques for the review and the summary of the open tasks. I am working on them as well. > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > For example, under framework -> base -> src there is a distinction between > main and test. Within the test folder there is again a distinction between > groovy and Java. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “The Java Platform Module System requires that classes in distinct modules > have distinct package names. Groovy has its own "modules" but these haven’t > historically been structured according to the above requirement. For this > reason, Groovy 2.x and 3.0 should be added to the classpath not module path > when using JDK9+. This places Groovy’s classes into the unnamed module where > the split package naming requirement is not enforced.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748917#comment-17748917 ] Michael Brohl commented on OFBIZ-12813: --- I've provided pull request [https://github.com/apache/ofbiz-plugins/pull/86] for the plugins refactoring. testIntegration works, the applications are not tested yet. Help on this is welcome. > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > For example, under framework -> base -> src there is a distinction between > main and test. Within the test folder there is again a distinction between > groovy and Java. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “The Java Platform Module System requires that classes in distinct modules > have distinct package names. Groovy has its own "modules" but these haven’t > historically been structured according to the above requirement. For this > reason, Groovy 2.x and 3.0 should be added to the classpath not module path > when using JDK9+. This places Groovy’s classes into the unnamed module where > the split package naming requirement is not enforced.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl reassigned OFBIZ-12813: - Assignee: Michael Brohl (was: Deepak Dixit) > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > For example, under framework -> base -> src there is a distinction between > main and test. Within the test folder there is again a distinction between > groovy and Java. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “The Java Platform Module System requires that classes in distinct modules > have distinct package names. Groovy has its own "modules" but these haven’t > historically been structured according to the above requirement. For this > reason, Groovy 2.x and 3.0 should be added to the classpath not module path > when using JDK9+. This places Groovy’s classes into the unnamed module where > the split package naming requirement is not enforced.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748640#comment-17748640 ] Michael Brohl commented on OFBIZ-12813: --- [~jleroux] [~deepak] we will work on this asap and also on the plugins. > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Deepak Dixit >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > For example, under framework -> base -> src there is a distinction between > main and test. Within the test folder there is again a distinction between > groovy and Java. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “The Java Platform Module System requires that classes in distinct modules > have distinct package names. Groovy has its own "modules" but these haven’t > historically been structured according to the above requirement. For this > reason, Groovy 2.x and 3.0 should be added to the classpath not module path > when using JDK9+. This places Groovy’s classes into the unnamed module where > the split package naming requirement is not enforced.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748463#comment-17748463 ] Michael Brohl commented on OFBIZ-12813: --- Addition: if I do a search on GitHub with "repo:apache/ofbiz-framework groovyScripts" I only find 8 occurences in framework, only 3 references to screens of which 2 are commented out. > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Deepak Dixit >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > For example, under framework -> base -> src there is a distinction between > main and test. Within the test folder there is again a distinction between > groovy and Java. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “The Java Platform Module System requires that classes in distinct modules > have distinct package names. Groovy has its own "modules" but these haven’t > historically been structured according to the above requirement. For this > reason, Groovy 2.x and 3.0 should be added to the classpath not module path > when using JDK9+. This places Groovy’s classes into the unnamed module where > the split package naming requirement is not enforced.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748461#comment-17748461 ] Michael Brohl commented on OFBIZ-12813: --- We will organise to handle this even when Wiebke is on vacation the next 2 weeks. > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Deepak Dixit >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > For example, under framework -> base -> src there is a distinction between > main and test. Within the test folder there is again a distinction between > groovy and Java. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “The Java Platform Module System requires that classes in distinct modules > have distinct package names. Groovy has its own "modules" but these haven’t > historically been structured according to the above requirement. For this > reason, Groovy 2.x and 3.0 should be added to the classpath not module path > when using JDK9+. This places Groovy’s classes into the unnamed module where > the split package naming requirement is not enforced.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12828) Persist OrderItemAttributes of ShoppingCartItem in new entity ShoppingListItemAttributes along with persisted ShoppingCart (autoSaveList)
[ https://issues.apache.org/jira/browse/OFBIZ-12828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748252#comment-17748252 ] Michael Brohl commented on OFBIZ-12828: --- You are right, this should normally be backported to 22.01. On the other hand, we were discussing to drop 22.01 in favor of a 23.x release and 18.x should be discontinued also. Not sure if it's worth the work? > Persist OrderItemAttributes of ShoppingCartItem in new entity > ShoppingListItemAttributes along with persisted ShoppingCart (autoSaveList) > - > > Key: OFBIZ-12828 > URL: https://issues.apache.org/jira/browse/OFBIZ-12828 > Project: OFBiz > Issue Type: Bug > Components: order >Reporter: Pascal Zoschke >Assignee: Michael Brohl >Priority: Minor > Fix For: Upcoming Branch > > > Currently, the information about the attributes of the order item is not > saved and therefore cannot be retrieved later in the shopping cart > (autoSaveList). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (OFBIZ-12174) Convert InventoryServices.xml mini lang to groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl closed OFBIZ-12174. - Fix Version/s: Upcoming Branch Resolution: Implemented Thanks [~sberg] and [~cshan] ! > Convert InventoryServices.xml mini lang to groovy > - > > Key: OFBIZ-12174 > URL: https://issues.apache.org/jira/browse/OFBIZ-12174 > Project: OFBiz > Issue Type: Sub-task > Components: product >Affects Versions: Trunk, Upcoming Branch >Reporter: Sebastian Berg >Assignee: Sebastian Berg >Priority: Minor > Fix For: Upcoming Branch > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (OFBIZ-9403) DataResourceWorker: New method getMimeTypeFromFileName(...) with extracted (refactored) code from getMimeType(...) method
[ https://issues.apache.org/jira/browse/OFBIZ-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl closed OFBIZ-9403. Fix Version/s: Upcoming Branch Resolution: Implemented Thanks [~mbecker] and [~cshan] ! > DataResourceWorker: New method getMimeTypeFromFileName(...) with extracted > (refactored) code from getMimeType(...) method > - > > Key: OFBIZ-9403 > URL: https://issues.apache.org/jira/browse/OFBIZ-9403 > Project: OFBiz > Issue Type: Improvement > Components: content >Affects Versions: Trunk, Upcoming Branch >Reporter: Martin Becker >Assignee: Chenghu Shan >Priority: Trivial > Fix For: Upcoming Branch > > Attachments: OFBIZ-9403_DataResourceWorker_GetMimeType.patch, > OFBIZ-9403_DataResourceWorker_GetMimeType_with_defaultMimeTypeId.patch > > > The method DataResourceWorker.getMimeType(GenericValue) has been refactored > into two separate methods. The new additional method > getMimeTypeFromFileName(Delegator,Filename) solely focuses on getting the > MimeType from the file extension and is invoked by getMimeType(GenericValue) > if needed. getMimeType returns the type if possible via the data resource. > This results in cleaner code with the responsibility of both methods clearly > defined by the methods names. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OFBIZ-12802) Extending calculateProductPrice (custom) Service and ShoppingCart / OrderItem to deliver/hold an individual discountRate value
[ https://issues.apache.org/jira/browse/OFBIZ-12802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl reassigned OFBIZ-12802: - Assignee: Michael Brohl > Extending calculateProductPrice (custom) Service and ShoppingCart / OrderItem > to deliver/hold an individual discountRate value > -- > > Key: OFBIZ-12802 > URL: https://issues.apache.org/jira/browse/OFBIZ-12802 > Project: OFBiz > Issue Type: New Feature >Reporter: Adrian Wolf >Assignee: Michael Brohl >Priority: Minor > > Background is the communication of an individually (informally) calculated > discount rate from the price calculation to the OrderItem, with easy access > to it (because of this not via the orderItemPriceInfos substructure). > > Extending ProductPrice.calculateProductPrice Service (all in > PriceServices.java and services_pricepromo.xml): > * Addition of additional context information "productStoreGroupId" and > "partyId" to the call parameters of a "customMethodName" price-calc-service > * Obtaining the fields discountRate and listPrice from calling a > "customMethodName" price-calc-service > * discountRate as Result Field > * Retaining the bypassing of the OFBiz Standard PriceRules based on the > presence of a ListPrice (only that it can now also come from the > "customMethodName", therefore slightly changed decision logic) > Extending ShoppingCart/Item, OrderItem Entity: > * Transport original discount rate from custom price calculation over cart > to order to have the correct rate instead of back-calculating it from > unitPrice and unitListPrice -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12802) Extending calculateProductPrice (custom) Service and ShoppingCart / OrderItem to deliver/hold an individual discountRate value
[ https://issues.apache.org/jira/browse/OFBIZ-12802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748225#comment-17748225 ] Michael Brohl commented on OFBIZ-12802: --- Looks good to me. Any objections to merge? > Extending calculateProductPrice (custom) Service and ShoppingCart / OrderItem > to deliver/hold an individual discountRate value > -- > > Key: OFBIZ-12802 > URL: https://issues.apache.org/jira/browse/OFBIZ-12802 > Project: OFBiz > Issue Type: New Feature >Reporter: Adrian Wolf >Assignee: Michael Brohl >Priority: Minor > > Background is the communication of an individually (informally) calculated > discount rate from the price calculation to the OrderItem, with easy access > to it (because of this not via the orderItemPriceInfos substructure). > > Extending ProductPrice.calculateProductPrice Service (all in > PriceServices.java and services_pricepromo.xml): > * Addition of additional context information "productStoreGroupId" and > "partyId" to the call parameters of a "customMethodName" price-calc-service > * Obtaining the fields discountRate and listPrice from calling a > "customMethodName" price-calc-service > * discountRate as Result Field > * Retaining the bypassing of the OFBiz Standard PriceRules based on the > presence of a ListPrice (only that it can now also come from the > "customMethodName", therefore slightly changed decision logic) > Extending ShoppingCart/Item, OrderItem Entity: > * Transport original discount rate from custom price calculation over cart > to order to have the correct rate instead of back-calculating it from > unitPrice and unitListPrice -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (OFBIZ-12828) Persist OrderItemAttributes of ShoppingCartItem in new entity ShoppingListItemAttributes along with persisted ShoppingCart (autoSaveList)
[ https://issues.apache.org/jira/browse/OFBIZ-12828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl closed OFBIZ-12828. - Fix Version/s: Upcoming Branch Resolution: Fixed Thanks [~pzoschke] and [~sberg] for your work! > Persist OrderItemAttributes of ShoppingCartItem in new entity > ShoppingListItemAttributes along with persisted ShoppingCart (autoSaveList) > - > > Key: OFBIZ-12828 > URL: https://issues.apache.org/jira/browse/OFBIZ-12828 > Project: OFBiz > Issue Type: Bug > Components: order >Reporter: Pascal Zoschke >Assignee: Michael Brohl >Priority: Minor > Fix For: Upcoming Branch > > > Currently, the information about the attributes of the order item is not > saved and therefore cannot be retrieved later in the shopping cart > (autoSaveList). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OFBIZ-12828) Persist OrderItemAttributes of ShoppingCartItem in new entity ShoppingListItemAttributes along with persisted ShoppingCart (autoSaveList)
[ https://issues.apache.org/jira/browse/OFBIZ-12828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl reassigned OFBIZ-12828: - Assignee: Michael Brohl (was: Pascal Zoschke) > Persist OrderItemAttributes of ShoppingCartItem in new entity > ShoppingListItemAttributes along with persisted ShoppingCart (autoSaveList) > - > > Key: OFBIZ-12828 > URL: https://issues.apache.org/jira/browse/OFBIZ-12828 > Project: OFBiz > Issue Type: Bug > Components: order >Reporter: Pascal Zoschke >Assignee: Michael Brohl >Priority: Minor > > Currently, the information about the attributes of the order item is not > saved and therefore cannot be retrieved later in the shopping cart > (autoSaveList). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12828) Persist OrderItemAttributes of ShoppingCartItem in new entity ShoppingListItemAttributes along with persisted ShoppingCart (autoSaveList)
[ https://issues.apache.org/jira/browse/OFBIZ-12828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748169#comment-17748169 ] Michael Brohl commented on OFBIZ-12828: --- I think this should be classified as a bug because data is lost after retrieving a persisted ShoppingCart. > Persist OrderItemAttributes of ShoppingCartItem in new entity > ShoppingListItemAttributes along with persisted ShoppingCart (autoSaveList) > - > > Key: OFBIZ-12828 > URL: https://issues.apache.org/jira/browse/OFBIZ-12828 > Project: OFBiz > Issue Type: Bug > Components: order >Reporter: Pascal Zoschke >Assignee: Pascal Zoschke >Priority: Minor > > Currently, the information about the attributes of the order item is not > saved and therefore cannot be retrieved later in the shopping cart > (autoSaveList). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OFBIZ-12828) Persist OrderItemAttributes of ShoppingCartItem in new entity ShoppingListItemAttributes along with persisted ShoppingCart (autoSaveList)
[ https://issues.apache.org/jira/browse/OFBIZ-12828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl updated OFBIZ-12828: -- Component/s: order Issue Type: Bug (was: Improvement) > Persist OrderItemAttributes of ShoppingCartItem in new entity > ShoppingListItemAttributes along with persisted ShoppingCart (autoSaveList) > - > > Key: OFBIZ-12828 > URL: https://issues.apache.org/jira/browse/OFBIZ-12828 > Project: OFBiz > Issue Type: Bug > Components: order >Reporter: Pascal Zoschke >Assignee: Pascal Zoschke >Priority: Minor > > Currently, the information about the attributes of the order item is not > saved and therefore cannot be retrieved later in the shopping cart > (autoSaveList). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-11434) Forum Articles do not respond to pagination
[
https://issues.apache.org/jira/browse/OFBIZ-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748132#comment-17748132
]
Michael Brohl commented on OFBIZ-11434:
---
Thanks, [~jleroux] !
> Forum Articles do not respond to pagination
> ---
>
> Key: OFBIZ-11434
> URL: https://issues.apache.org/jira/browse/OFBIZ-11434
> Project: OFBiz
> Issue Type: Bug
> Components: ecommerce
>Affects Versions: Trunk, 22.01.01, Upcoming Branch
>Reporter: Benjamin Jugl
>Assignee: Michael Brohl
>Priority: Minor
> Labels: backport-needed
> Fix For: 22.01.01, 18.12.09
>
> Attachments: OFBIZ-11434.patch
>
>
> Neither the view-size nor the view-index have any effect on the shown
> articles in the forum.
> To reproduce:
> # Log into the Frontend (ecommerce) as admin
> # go to Browse Forums
> # click any link ("Ask the Experts" was used for testing)
> # Create "New Message" 21 times
> # Try using the pagination
> Should be: The view should be limited to 20 items on the first page, if the
> view-size is 20. The second page should only display the 21st entry.
> Is: The list always shows all 21 entries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OFBIZ-9403) DataResourceWorker: New method getMimeTypeFromFileName(...) with extracted (refactored) code from getMimeType(...) method
[ https://issues.apache.org/jira/browse/OFBIZ-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748111#comment-17748111 ] Michael Brohl commented on OFBIZ-9403: -- [~cshan] I think we should take the defaultMimeType from applications/content/config/content.properties instead of a hard coded one, can you please change it accordingly? > DataResourceWorker: New method getMimeTypeFromFileName(...) with extracted > (refactored) code from getMimeType(...) method > - > > Key: OFBIZ-9403 > URL: https://issues.apache.org/jira/browse/OFBIZ-9403 > Project: OFBiz > Issue Type: Improvement > Components: content >Affects Versions: Trunk, Upcoming Branch >Reporter: Martin Becker >Assignee: Michael Brohl >Priority: Trivial > Attachments: OFBIZ-9403_DataResourceWorker_GetMimeType.patch, > OFBIZ-9403_DataResourceWorker_GetMimeType_with_defaultMimeTypeId.patch > > > The method DataResourceWorker.getMimeType(GenericValue) has been refactored > into two separate methods. The new additional method > getMimeTypeFromFileName(Delegator,Filename) solely focuses on getting the > MimeType from the file extension and is invoked by getMimeType(GenericValue) > if needed. getMimeType returns the type if possible via the data resource. > This results in cleaner code with the responsibility of both methods clearly > defined by the methods names. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-11434) Forum Articles do not respond to pagination
[
https://issues.apache.org/jira/browse/OFBIZ-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748106#comment-17748106
]
Michael Brohl commented on OFBIZ-11434:
---
[~jleroux] shouldn't this be closed already?
> Forum Articles do not respond to pagination
> ---
>
> Key: OFBIZ-11434
> URL: https://issues.apache.org/jira/browse/OFBIZ-11434
> Project: OFBiz
> Issue Type: Bug
> Components: ecommerce
>Affects Versions: Trunk, 22.01.01, Upcoming Branch
>Reporter: Benjamin Jugl
>Assignee: Michael Brohl
>Priority: Minor
> Labels: backport-needed
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-11434.patch
>
>
> Neither the view-size nor the view-index have any effect on the shown
> articles in the forum.
> To reproduce:
> # Log into the Frontend (ecommerce) as admin
> # go to Browse Forums
> # click any link ("Ask the Experts" was used for testing)
> # Create "New Message" 21 times
> # Try using the pagination
> Should be: The view should be limited to 20 items on the first page, if the
> view-size is 20. The second page should only display the 21st entry.
> Is: The list always shows all 21 entries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OFBIZ-12830) Reduction of recurring INFO logs
[ https://issues.apache.org/jira/browse/OFBIZ-12830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl reassigned OFBIZ-12830: - Assignee: Michael Brohl (was: Chenghu Shan) > Reduction of recurring INFO logs > > > Key: OFBIZ-12830 > URL: https://issues.apache.org/jira/browse/OFBIZ-12830 > Project: OFBiz > Issue Type: Improvement > Components: content, framework >Affects Versions: Upcoming Branch >Reporter: Chenghu Shan >Assignee: Michael Brohl >Priority: Trivial > Fix For: Upcoming Branch > > > Many standard recurring actions are currently logged at the INFO level. These > include actions such as creating a certain number of screens via > ScreenFactory, loading a controller in a certain amount of time via > ConfigXMLReader or setting default values via ModelService. > We should bump them down to VERBOSE level to reduce the amount of log > cluttering. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OFBIZ-12830) Reduction of recurring INFO logs
[ https://issues.apache.org/jira/browse/OFBIZ-12830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl reassigned OFBIZ-12830: - Assignee: (was: Michael Brohl) > Reduction of recurring INFO logs > > > Key: OFBIZ-12830 > URL: https://issues.apache.org/jira/browse/OFBIZ-12830 > Project: OFBiz > Issue Type: Improvement > Components: content, framework >Affects Versions: Upcoming Branch >Reporter: Chenghu Shan >Priority: Trivial > Fix For: Upcoming Branch > > > Many standard recurring actions are currently logged at the INFO level. These > include actions such as creating a certain number of screens via > ScreenFactory, loading a controller in a certain amount of time via > ConfigXMLReader or setting default values via ModelService. > We should bump them down to VERBOSE level to reduce the amount of log > cluttering. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (OFBIZ-12842) UtilHttp.getPathInfoOnlyParameterMap should be public
[ https://issues.apache.org/jira/browse/OFBIZ-12842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl closed OFBIZ-12842. - Fix Version/s: Upcoming Branch Resolution: Implemented Thanks [~cshan] > UtilHttp.getPathInfoOnlyParameterMap should be public > - > > Key: OFBIZ-12842 > URL: https://issues.apache.org/jira/browse/OFBIZ-12842 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Upcoming Branch >Reporter: Chenghu Shan >Assignee: Michael Brohl >Priority: Minor > Fix For: Upcoming Branch > > > The method UtilHttp.getPathInfoOnlyParameterMap should be public. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (OFBIZ-12841) GenericDelegator.findList should return unmodifiable list when using cache
[ https://issues.apache.org/jira/browse/OFBIZ-12841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl closed OFBIZ-12841. - Fix Version/s: Upcoming Branch Resolution: Fixed Thanks [~cshan] > GenericDelegator.findList should return unmodifiable list when using cache > -- > > Key: OFBIZ-12841 > URL: https://issues.apache.org/jira/browse/OFBIZ-12841 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Upcoming Branch >Reporter: Chenghu Shan >Assignee: Michael Brohl >Priority: Minor > Fix For: Upcoming Branch > > > The findList method in GenericDelegator may return different results for the > same search parameters when using caching if list operations are used on the > returned list. This is because the actual cacheList is returned instead of an > unmodifiable copy. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OFBIZ-12842) UtilHttp.getPathInfoOnlyParameterMap should be public
[ https://issues.apache.org/jira/browse/OFBIZ-12842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl reassigned OFBIZ-12842: - Assignee: Michael Brohl (was: Chenghu Shan) > UtilHttp.getPathInfoOnlyParameterMap should be public > - > > Key: OFBIZ-12842 > URL: https://issues.apache.org/jira/browse/OFBIZ-12842 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Upcoming Branch >Reporter: Chenghu Shan >Assignee: Michael Brohl >Priority: Minor > > The method UtilHttp.getPathInfoOnlyParameterMap should be public. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OFBIZ-12841) GenericDelegator.findList should return unmodifiable list when using cache
[ https://issues.apache.org/jira/browse/OFBIZ-12841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl reassigned OFBIZ-12841: - Assignee: Michael Brohl > GenericDelegator.findList should return unmodifiable list when using cache > -- > > Key: OFBIZ-12841 > URL: https://issues.apache.org/jira/browse/OFBIZ-12841 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Upcoming Branch >Reporter: Chenghu Shan >Assignee: Michael Brohl >Priority: Minor > > The findList method in GenericDelegator may return different results for the > same search parameters when using caching if list operations are used on the > returned list. This is because the actual cacheList is returned instead of an > unmodifiable copy. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12829) Improvements for ContentWorker methods and view-entities
[ https://issues.apache.org/jira/browse/OFBIZ-12829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748096#comment-17748096 ] Michael Brohl commented on OFBIZ-12829: --- Looks good to me, any objections to merge? > Improvements for ContentWorker methods and view-entities > > > Key: OFBIZ-12829 > URL: https://issues.apache.org/jira/browse/OFBIZ-12829 > Project: OFBiz > Issue Type: Improvement > Components: content >Affects Versions: Upcoming Branch >Reporter: Chenghu Shan >Assignee: Michael Brohl >Priority: Minor > > Adds additional methods to ContentWorker: > * New method findAlternateLocalContents to find all alternate locale > contents instead of just one specific. > * Overloaded methods of findAlternateLocalContents and > findAlternateLocalContent to enable/disable cache use. > * These methods are no longer case sensitive when comparing localeStrings > Changes to view-entites ProductContentAndInfo and > ProductCategoryContentAndInfo: > * Both now use an outer join instead of inner join between DataResource and > Content, because there may be a Content object without a DataResource for its > locale but with alternate locale content objects associated to it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OFBIZ-12829) Improvements for ContentWorker methods and view-entities
[ https://issues.apache.org/jira/browse/OFBIZ-12829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl reassigned OFBIZ-12829: - Assignee: Michael Brohl (was: Chenghu Shan) > Improvements for ContentWorker methods and view-entities > > > Key: OFBIZ-12829 > URL: https://issues.apache.org/jira/browse/OFBIZ-12829 > Project: OFBiz > Issue Type: Improvement > Components: content >Affects Versions: Upcoming Branch >Reporter: Chenghu Shan >Assignee: Michael Brohl >Priority: Minor > > Adds additional methods to ContentWorker: > * New method findAlternateLocalContents to find all alternate locale > contents instead of just one specific. > * Overloaded methods of findAlternateLocalContents and > findAlternateLocalContent to enable/disable cache use. > * These methods are no longer case sensitive when comparing localeStrings > Changes to view-entites ProductContentAndInfo and > ProductCategoryContentAndInfo: > * Both now use an outer join instead of inner join between DataResource and > Content, because there may be a Content object without a DataResource for its > locale but with alternate locale content objects associated to it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747913#comment-17747913 ] Michael Brohl commented on OFBIZ-12813: --- return is a reserved word and cannot be used for package names. > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Wiebke Paetzold >Priority: Major > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > For example, under framework -> base -> src there is a distinction between > main and test. Within the test folder there is again a distinction between > groovy and Java. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “The Java Platform Module System requires that classes in distinct modules > have distinct package names. Groovy has its own "modules" but these haven’t > historically been structured according to the above requirement. For this > reason, Groovy 2.x and 3.0 should be added to the classpath not module path > when using JDK9+. This places Groovy’s classes into the unnamed module where > the split package naming requirement is not enforced.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-10194) ContentWrapper empty string result breaks simple FTL null check and default syntax
[
https://issues.apache.org/jira/browse/OFBIZ-10194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747911#comment-17747911
]
Michael Brohl commented on OFBIZ-10194:
---
This looks good to me an is field tested in custom projects for some time now.
Any objections to merge?
> ContentWrapper empty string result breaks simple FTL null check and default
> syntax
> --
>
> Key: OFBIZ-10194
> URL: https://issues.apache.org/jira/browse/OFBIZ-10194
> Project: OFBiz
> Issue Type: Bug
> Components: content, order, party, product
>Affects Versions: 16.11.04
>Reporter: Martin Becker
>Assignee: Michael Brohl
>Priority: Minor
> Attachments: OFBiz-10194_ContentWrappers.patch
>
>
> Since the changes to the ContentWrappers from Ticket
> https://issues.apache.org/jira/browse/OFBIZ-6701 the result for non existing
> content is an empty string instead of NULL.
> Aside from my opinion, that this is generally a bad design preferred by those
> who do not like to check for null values within their code, this behavior
> breaks the simple FTL syntax for using an alternate (default) value for a non
> existing content, retrieved by a ContentWrapper like this:
> {code:java}
> <#assign categoryName = categoryContentWrapper.get("CATEGORY_NAME",
> "string")!category.internalName?default(category.productCategoryId) />{code}
> Basically this was done to get the non-existing-content cached within the
> *.content.rendered cache and let the simple condition
> {code:java}
> if (cachedValue != null){code}
> after a cache.get() respect this empty value. With a simple change to the
> condition to
> {code:java}
> if (cachedValue != null || cache.containsKey(cacheKey)){code}
> it is also possible to cache and successfully retrieve NULL values from the
> cache.
> I observed this now during an upgrade of OFBiz 12 based application code to
> the current OFBiz release.
> Besides this I did following refactorings consistently for all ContentWrapper
> implementations to reduce code redundancy:
> * centralized default mimeTypeId retrieval (static Interface method in
> ContentWrapper)
> * centralized encoding of result string via UtilEncoder (static Interface
> method in ContentWrapper)
> * centralized/generalized candidate field value retrieval (static Interface
> method in ContentWrapper)
> * harmonized content cache name to „xyz.content.rendered“, some wrappers did
> not use the „.rendered“ suffix in their cache name
> * fixed some missing useCache parameter use in EntityQuery…cache()… calls
> For Category and Product ContentWrapper I updated the parameter handling of
> the central getXyzContentAsText method where both, productId and product
> GenericValue are given but no check is performed, if both are matching if
> both are given (bad parameter signature, by the way). Now the product GV is
> looked up, if a productId is given, and the productId is used from a given
> product GV always, not only if it is missing. The drawback is, that there
> will always be a lookup for Product/ProductCategory GV, even if a content
> entry could be found with the productId/productCategoryId only. On the other
> hand, the GV is always part of the content rendering input context, currently
> it is missing there, if only a ID is given as parameter, again not really
> consistent.
> I did not wanted to change this for all content wrappers directly before
> getting a feedback for it, even if it would be more consistent to have a
> content rendering context with a product GV as input, independent of the
> original call parameters productId and/or product GV.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (OFBIZ-12840) Missing Getter in ShoppingCart and ConfigXMLReader
[ https://issues.apache.org/jira/browse/OFBIZ-12840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl closed OFBIZ-12840. - Fix Version/s: Upcoming Branch Resolution: Implemented Thanks [~cshan] > Missing Getter in ShoppingCart and ConfigXMLReader > -- > > Key: OFBIZ-12840 > URL: https://issues.apache.org/jira/browse/OFBIZ-12840 > Project: OFBiz > Issue Type: Improvement > Components: framework, order >Affects Versions: Upcoming Branch >Reporter: Chenghu Shan >Assignee: Michael Brohl >Priority: Minor > Fix For: Upcoming Branch > > > Some attributes are still missing getters. They should be added. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OFBIZ-12840) Missing Getter in ShoppingCart and ConfigXMLReader
[ https://issues.apache.org/jira/browse/OFBIZ-12840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl reassigned OFBIZ-12840: - Assignee: Michael Brohl (was: Chenghu Shan) > Missing Getter in ShoppingCart and ConfigXMLReader > -- > > Key: OFBIZ-12840 > URL: https://issues.apache.org/jira/browse/OFBIZ-12840 > Project: OFBiz > Issue Type: Improvement > Components: framework, order >Affects Versions: Upcoming Branch >Reporter: Chenghu Shan >Assignee: Michael Brohl >Priority: Minor > > Some attributes are still missing getters. They should be added. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OFBIZ-12815) EntityUtil getProperty Methods dont use entity
[ https://issues.apache.org/jira/browse/OFBIZ-12815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl reassigned OFBIZ-12815: - Assignee: Michael Brohl > EntityUtil getProperty Methods dont use entity > -- > > Key: OFBIZ-12815 > URL: https://issues.apache.org/jira/browse/OFBIZ-12815 > Project: OFBiz > Issue Type: Improvement > Components: framework/entity >Affects Versions: 18.12.07 >Reporter: Tobias Hahn >Assignee: Michael Brohl >Priority: Minor > Fix For: Upcoming Branch > > > The getProperty methods in EntityUtilProperties don't use entity at all. All > of the getProperty methods simply lead to UtilProperties and therefore no > configure during runtime is possible. New methods have been written so the > entity usage is now functional. > Due to a wrong commit description/title the PR #634 were closed. i opened a > new PR #635. > Also i will adjust the code with an upcoming commit, thanks to Gil who > commented on PR #634. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-10478) Reducing scope of variables in org.apache.ofbiz.base package
[ https://issues.apache.org/jira/browse/OFBIZ-10478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724159#comment-17724159 ] Michael Brohl commented on OFBIZ-10478: --- Thanks Jacques, just had a quick glance because I'm on my way to vacation but it looks good to me. I don't see a security issue with the mentioned method expandGeoGroup(GenericValue) from the type GeoWorker so it would be good to include it also. > Reducing scope of variables in org.apache.ofbiz.base package > > > Key: OFBIZ-10478 > URL: https://issues.apache.org/jira/browse/OFBIZ-10478 > Project: OFBiz > Issue Type: Sub-task > Components: base >Affects Versions: Trunk, Upcoming Branch >Reporter: Pradhan Yash Sharma >Assignee: Jacques Le Roux >Priority: Minor > Fix For: Upcoming Branch > > Attachments: OFBIZ-10478-1.patch, OFBIZ-10478.patch > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-5618) Update Password
[ https://issues.apache.org/jira/browse/OFBIZ-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17719767#comment-17719767 ] Michael Brohl commented on OFBIZ-5618: -- Hi Jacques, we are currently on the move to rework the password handling a bit and stumbled upon this issue during the process. There will be a follow-up Jira issue soon where we describe the changes that should be done in our opinion. > Update Password > --- > > Key: OFBIZ-5618 > URL: https://issues.apache.org/jira/browse/OFBIZ-5618 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Yachna chadha >Assignee: Chenghu Shan >Priority: Major > Attachments: LoginServices.java > > > In LoginServices.updatePassword there is a check to see if the Logged in User > is equal to the user login the password is being changed for. This check IS > case sensitive. Since the logged in User has already passed validations in > signing in this check should NOT be case sensitive. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (OFBIZ-5618) Update Password
[ https://issues.apache.org/jira/browse/OFBIZ-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl reopened OFBIZ-5618: -- Assignee: Chenghu Shan Don't know why this is closed, I think it is a problem indeed. > Update Password > --- > > Key: OFBIZ-5618 > URL: https://issues.apache.org/jira/browse/OFBIZ-5618 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Yachna chadha >Assignee: Chenghu Shan >Priority: Major > Attachments: LoginServices.java > > > In LoginServices.updatePassword there is a check to see if the Logged in User > is equal to the user login the password is being changed for. This check IS > case sensitive. Since the logged in User has already passed validations in > signing in this check should NOT be case sensitive. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12772) Setting verbose log results in 500
[
https://issues.apache.org/jira/browse/OFBIZ-12772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717316#comment-17717316
]
Michael Brohl commented on OFBIZ-12772:
---
The patch looks good to me. I suggest to commit this to trunk and release22.01.
> Setting verbose log results in 500
> --
>
> Key: OFBIZ-12772
> URL: https://issues.apache.org/jira/browse/OFBIZ-12772
> Project: OFBiz
> Issue Type: Improvement
>Affects Versions: Upcoming Branch
>Reporter: Ingo Wolfmayr
>Priority: Major
> Attachments: verbose.patch
>
>
> When changing debug.properties
> print.verbose=true
> will bring up the following error when accessing any application:
> for example: [https://localhost:8443/catalog/control/main]
> Tested on: trunk, java 17
> {code:java}
> Mar 07, 2023 5:20:53 PM org.apache.catalina.core.StandardWrapperValve invoke
> SEVERE: Servlet.service() for servlet [ControlServlet] in context with path
> [/webtools] threw exception
> java.lang.ArrayStoreException: javax.servlet.http.Cookie
> at
> java.base/java.util.stream.Nodes$FixedNodeBuilder.accept(Nodes.java:1222)
> at
> java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:992)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575)
> at
> java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (OFBIZ-12808) Eclipse build problems and proper dependency setup
[ https://issues.apache.org/jira/browse/OFBIZ-12808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl closed OFBIZ-12808. - Resolution: Fixed The fixes are implemented and merged for framework/plugins in the trunk and release22.01 branches. > Eclipse build problems and proper dependency setup > -- > > Key: OFBIZ-12808 > URL: https://issues.apache.org/jira/browse/OFBIZ-12808 > Project: OFBiz > Issue Type: Bug > Components: ALL APPLICATIONS, ALL COMPONENTS, ALL PLUGINS >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Michael Brohl >Assignee: Michael Brohl >Priority: Major > Fix For: 22.01.01, Upcoming Branch > > > Due to improper dependency configurations and the JPMS (Java Plattform Module > System) which was introduced to Java since version 9, the Eclipse build and > running/debugging is not working with JDK 17 (trunk and release22.01). > The reason is that there are dependencies to libraries which are also shipped > with the JDK which causes a conflict leading to ignore those packages/classes > in the build. > We have a working solution for this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12808) Eclipse build problems and proper dependency setup
[
https://issues.apache.org/jira/browse/OFBIZ-12808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715663#comment-17715663
]
Michael Brohl commented on OFBIZ-12808:
---
[~danwatford]
{quote}Would a non-eclipse user be able to recognise if they introduce the same
sort of issue again, perhaps by adding new dependencies to plugins?
{quote}
Yes, definetely. We'll have to check when things get contributed, especially
when new dependencies get introduced within a build file.
{quote}Is it something the gradle could detect and use to deliberately fail a
build?
{quote}
I don't think so. Gradle cannot decide if a (transitive) dependency is ok to be
used or should be avoided, at least I am not aware of such a mechanism.
Maybe others have an idea?
> Eclipse build problems and proper dependency setup
> --
>
> Key: OFBIZ-12808
> URL: https://issues.apache.org/jira/browse/OFBIZ-12808
> Project: OFBiz
> Issue Type: Bug
> Components: ALL APPLICATIONS, ALL COMPONENTS, ALL PLUGINS
>Affects Versions: 22.01.01, Upcoming Branch
>Reporter: Michael Brohl
>Assignee: Michael Brohl
>Priority: Major
> Fix For: 22.01.01, Upcoming Branch
>
>
> Due to improper dependency configurations and the JPMS (Java Plattform Module
> System) which was introduced to Java since version 9, the Eclipse build and
> running/debugging is not working with JDK 17 (trunk and release22.01).
> The reason is that there are dependencies to libraries which are also shipped
> with the JDK which causes a conflict leading to ignore those packages/classes
> in the build.
> We have a working solution for this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OFBIZ-12808) Eclipse build problems and proper dependency setup
[ https://issues.apache.org/jira/browse/OFBIZ-12808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714986#comment-17714986 ] Michael Brohl commented on OFBIZ-12808: --- Fixes for framework / plugins for trunk and release22.01 are now in the pull requests. To test, the corresponding pr's for framework and plugins have to be checked out respectively. > Eclipse build problems and proper dependency setup > -- > > Key: OFBIZ-12808 > URL: https://issues.apache.org/jira/browse/OFBIZ-12808 > Project: OFBiz > Issue Type: Bug > Components: ALL APPLICATIONS, ALL COMPONENTS, ALL PLUGINS >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Michael Brohl >Assignee: Michael Brohl >Priority: Major > Fix For: 22.01.01, Upcoming Branch > > > Due to improper dependency configurations and the JPMS (Java Plattform Module > System) which was introduced to Java since version 9, the Eclipse build and > running/debugging is not working with JDK 17 (trunk and release22.01). > The reason is that there are dependencies to libraries which are also shipped > with the JDK which causes a conflict leading to ignore those packages/classes > in the build. > We have a working solution for this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12808) Eclipse build problems and proper dependency setup
[ https://issues.apache.org/jira/browse/OFBIZ-12808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714953#comment-17714953 ] Michael Brohl commented on OFBIZ-12808: --- Thanks Jacques. We are working on the dependency problems for plugins so the framework build configuration can possibly change in the course. > Eclipse build problems and proper dependency setup > -- > > Key: OFBIZ-12808 > URL: https://issues.apache.org/jira/browse/OFBIZ-12808 > Project: OFBiz > Issue Type: Bug > Components: ALL APPLICATIONS, ALL COMPONENTS, ALL PLUGINS >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Michael Brohl >Assignee: Michael Brohl >Priority: Major > Fix For: 22.01.01, Upcoming Branch > > > Due to improper dependency configurations and the JPMS (Java Plattform Module > System) which was introduced to Java since version 9, the Eclipse build and > running/debugging is not working with JDK 17 (trunk and release22.01). > The reason is that there are dependencies to libraries which are also shipped > with the JDK which causes a conflict leading to ignore those packages/classes > in the build. > We have a working solution for this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12808) Eclipse build problems and proper dependency setup
[ https://issues.apache.org/jira/browse/OFBIZ-12808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714522#comment-17714522 ] Michael Brohl commented on OFBIZ-12808: --- The pull requests fix the problems in framework for trunk and release22.01. There are problems with the plugins also, we are working on this as well. > Eclipse build problems and proper dependency setup > -- > > Key: OFBIZ-12808 > URL: https://issues.apache.org/jira/browse/OFBIZ-12808 > Project: OFBiz > Issue Type: Bug > Components: ALL APPLICATIONS, ALL COMPONENTS, ALL PLUGINS >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Michael Brohl >Assignee: Michael Brohl >Priority: Major > > Due to improper dependency configurations and the JPMS (Java Plattform Module > System) which was introduced to Java since version 9, the Eclipse build and > running/debugging is not working with JDK 17 (trunk and release22.01). > The reason is that there are dependencies to libraries which are also shipped > with the JDK which causes a conflict leading to ignore those packages/classes > in the build. > We have a working solution for this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OFBIZ-12808) Eclipse build problems and proper dependency setup
[ https://issues.apache.org/jira/browse/OFBIZ-12808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl updated OFBIZ-12808: -- Fix Version/s: 22.01.01 Upcoming Branch > Eclipse build problems and proper dependency setup > -- > > Key: OFBIZ-12808 > URL: https://issues.apache.org/jira/browse/OFBIZ-12808 > Project: OFBiz > Issue Type: Bug > Components: ALL APPLICATIONS, ALL COMPONENTS, ALL PLUGINS >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Michael Brohl >Assignee: Michael Brohl >Priority: Major > Fix For: 22.01.01, Upcoming Branch > > > Due to improper dependency configurations and the JPMS (Java Plattform Module > System) which was introduced to Java since version 9, the Eclipse build and > running/debugging is not working with JDK 17 (trunk and release22.01). > The reason is that there are dependencies to libraries which are also shipped > with the JDK which causes a conflict leading to ignore those packages/classes > in the build. > We have a working solution for this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OFBIZ-12808) Eclipse build problems and proper dependency setup
[ https://issues.apache.org/jira/browse/OFBIZ-12808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl updated OFBIZ-12808: -- Component/s: ALL PLUGINS > Eclipse build problems and proper dependency setup > -- > > Key: OFBIZ-12808 > URL: https://issues.apache.org/jira/browse/OFBIZ-12808 > Project: OFBiz > Issue Type: Bug > Components: ALL APPLICATIONS, ALL COMPONENTS, ALL PLUGINS >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Michael Brohl >Assignee: Michael Brohl >Priority: Major > > Due to improper dependency configurations and the JPMS (Java Plattform Module > System) which was introduced to Java since version 9, the Eclipse build and > running/debugging is not working with JDK 17 (trunk and release22.01). > The reason is that there are dependencies to libraries which are also shipped > with the JDK which causes a conflict leading to ignore those packages/classes > in the build. > We have a working solution for this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OFBIZ-12808) Eclipse build problems and proper dependency setup
Michael Brohl created OFBIZ-12808: - Summary: Eclipse build problems and proper dependency setup Key: OFBIZ-12808 URL: https://issues.apache.org/jira/browse/OFBIZ-12808 Project: OFBiz Issue Type: Bug Components: ALL APPLICATIONS, ALL COMPONENTS Affects Versions: 22.01.01, Upcoming Branch Reporter: Michael Brohl Assignee: Michael Brohl Due to improper dependency configurations and the JPMS (Java Plattform Module System) which was introduced to Java since version 9, the Eclipse build and running/debugging is not working with JDK 17 (trunk and release22.01). The reason is that there are dependencies to libraries which are also shipped with the JDK which causes a conflict leading to ignore those packages/classes in the build. We have a working solution for this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (OFBIZ-10197) Added isEmpty interface to StringWrapper
[ https://issues.apache.org/jira/browse/OFBIZ-10197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl closed OFBIZ-10197. - Fix Version/s: Upcoming Branch Resolution: Implemented > Added isEmpty interface to StringWrapper > > > Key: OFBIZ-10197 > URL: https://issues.apache.org/jira/browse/OFBIZ-10197 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Martin Becker >Assignee: Michael Brohl >Priority: Trivial > Fix For: Upcoming Branch > > Attachments: OFBIZ-10197_StringWrapper_IsEmpty_Interface.patch > > > Added convenience API to check if contained String is null/empty. Useful for > empty check via UtilValidate.isEmpty, also. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OFBIZ-11434) Forum Articles do not respond to pagination
[
https://issues.apache.org/jira/browse/OFBIZ-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl updated OFBIZ-11434:
--
Fix Version/s: Upcoming Branch
> Forum Articles do not respond to pagination
> ---
>
> Key: OFBIZ-11434
> URL: https://issues.apache.org/jira/browse/OFBIZ-11434
> Project: OFBiz
> Issue Type: Bug
> Components: ecommerce
>Affects Versions: Trunk, 22.01.01, Upcoming Branch
>Reporter: Benjamin Jugl
>Assignee: Michael Brohl
>Priority: Minor
> Labels: backport-needed
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-11434.patch
>
>
> Neither the view-size nor the view-index have any effect on the shown
> articles in the forum.
> To reproduce:
> # Log into the Frontend (ecommerce) as admin
> # go to Browse Forums
> # click any link ("Ask the Experts" was used for testing)
> # Create "New Message" 21 times
> # Try using the pagination
> Should be: The view should be limited to 20 items on the first page, if the
> view-size is 20. The second page should only display the 21st entry.
> Is: The list always shows all 21 entries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OFBIZ-11434) Forum Articles do not respond to pagination
[
https://issues.apache.org/jira/browse/OFBIZ-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl updated OFBIZ-11434:
--
Labels: backport-needed (was: )
> Forum Articles do not respond to pagination
> ---
>
> Key: OFBIZ-11434
> URL: https://issues.apache.org/jira/browse/OFBIZ-11434
> Project: OFBiz
> Issue Type: Bug
> Components: ecommerce
>Affects Versions: Trunk, Upcoming Branch
>Reporter: Benjamin Jugl
>Assignee: Michael Brohl
>Priority: Minor
> Labels: backport-needed
> Attachments: OFBIZ-11434.patch
>
>
> Neither the view-size nor the view-index have any effect on the shown
> articles in the forum.
> To reproduce:
> # Log into the Frontend (ecommerce) as admin
> # go to Browse Forums
> # click any link ("Ask the Experts" was used for testing)
> # Create "New Message" 21 times
> # Try using the pagination
> Should be: The view should be limited to 20 items on the first page, if the
> view-size is 20. The second page should only display the 21st entry.
> Is: The list always shows all 21 entries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OFBIZ-11434) Forum Articles do not respond to pagination
[
https://issues.apache.org/jira/browse/OFBIZ-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl updated OFBIZ-11434:
--
Affects Version/s: 22.01.01
> Forum Articles do not respond to pagination
> ---
>
> Key: OFBIZ-11434
> URL: https://issues.apache.org/jira/browse/OFBIZ-11434
> Project: OFBiz
> Issue Type: Bug
> Components: ecommerce
>Affects Versions: Trunk, 22.01.01, Upcoming Branch
>Reporter: Benjamin Jugl
>Assignee: Michael Brohl
>Priority: Minor
> Labels: backport-needed
> Attachments: OFBIZ-11434.patch
>
>
> Neither the view-size nor the view-index have any effect on the shown
> articles in the forum.
> To reproduce:
> # Log into the Frontend (ecommerce) as admin
> # go to Browse Forums
> # click any link ("Ask the Experts" was used for testing)
> # Create "New Message" 21 times
> # Try using the pagination
> Should be: The view should be limited to 20 items on the first page, if the
> view-size is 20. The second page should only display the 21st entry.
> Is: The list always shows all 21 entries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OFBIZ-11434) Forum Articles do not respond to pagination
[
https://issues.apache.org/jira/browse/OFBIZ-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl reassigned OFBIZ-11434:
-
Assignee: Michael Brohl (was: Benjamin Jugl)
> Forum Articles do not respond to pagination
> ---
>
> Key: OFBIZ-11434
> URL: https://issues.apache.org/jira/browse/OFBIZ-11434
> Project: OFBiz
> Issue Type: Bug
> Components: ecommerce
>Affects Versions: Trunk, Upcoming Branch
>Reporter: Benjamin Jugl
>Assignee: Michael Brohl
>Priority: Minor
> Attachments: OFBIZ-11434.patch
>
>
> Neither the view-size nor the view-index have any effect on the shown
> articles in the forum.
> To reproduce:
> # Log into the Frontend (ecommerce) as admin
> # go to Browse Forums
> # click any link ("Ask the Experts" was used for testing)
> # Create "New Message" 21 times
> # Try using the pagination
> Should be: The view should be limited to 20 items on the first page, if the
> view-size is 20. The second page should only display the 21st entry.
> Is: The list always shows all 21 entries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OFBIZ-12765) Improvement to createPartyRelationship service
[ https://issues.apache.org/jira/browse/OFBIZ-12765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl reassigned OFBIZ-12765: - Assignee: Michael Brohl (was: Chenghu Shan) > Improvement to createPartyRelationship service > --- > > Key: OFBIZ-12765 > URL: https://issues.apache.org/jira/browse/OFBIZ-12765 > Project: OFBiz > Issue Type: Improvement > Components: party >Reporter: Chenghu Shan >Assignee: Michael Brohl >Priority: Minor > > Currently, createPartyRelationship service does not allow the creation of a > new PartyRelationship of the same parties until the thruDate has passed. This > also disallows the creation new PartyRelationships of the same parties beyond > that thruDate. > This improvement checks for time interval conflicts and allows the creation > of a different PartyRelationship of the same parties before the thruDate has > passed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OFBIZ-12769) Fix plugins to work with release22.01 framework
Michael Brohl created OFBIZ-12769: - Summary: Fix plugins to work with release22.01 framework Key: OFBIZ-12769 URL: https://issues.apache.org/jira/browse/OFBIZ-12769 Project: OFBiz Issue Type: Sub-task Components: ALL PLUGINS Affects Versions: 22.01.01 Reporter: Michael Brohl -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12400) Upgrade to gradle 7.6 - support JDK 11 -> 17
[ https://issues.apache.org/jira/browse/OFBIZ-12400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696197#comment-17696197 ] Michael Brohl commented on OFBIZ-12400: --- You are right, [~danwatford] . Currently working on it in the course of a 18.12 -> 22.01 migration. Will provide a commit soon. > Upgrade to gradle 7.6 - support JDK 11 -> 17 > > > Key: OFBIZ-12400 > URL: https://issues.apache.org/jira/browse/OFBIZ-12400 > Project: OFBiz > Issue Type: Task >Reporter: Ioan Eugen Stan >Assignee: Ioan Eugen Stan >Priority: Major > Attachments: OFBIZ-12400-windows-binary.patch > > > For working with Java 17, we need to upgrade to gradle 7.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (OFBIZ-10139) New centralized API getProdCatalogCategoryId() in CategoryWorker.java
[ https://issues.apache.org/jira/browse/OFBIZ-10139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl closed OFBIZ-10139. - Assignee: Michael Brohl Resolution: Invalid This is already in the codebase, must have been done in another issue, maybe a duplicate. Recognized while doing a vendor import / migration of our codebase from 18.12 to 22.01. > New centralized API getProdCatalogCategoryId() in CategoryWorker.java > - > > Key: OFBIZ-10139 > URL: https://issues.apache.org/jira/browse/OFBIZ-10139 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: Trunk, Upcoming Branch >Reporter: Kyra Pritzel-Hentley >Assignee: Michael Brohl >Priority: Minor > Attachments: > OFBIZ-10139_centralized_API_getProdCatalogCategoryId.patch > > > A new centralized API getProdCatalogCategoryId to get first > prodCatalogCategoryId of a type should be put in place. The patch includes > the new method and refactoring of specific category type methods to use this > new method. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (OFBIZ-2712) Ecommerce time machine
[ https://issues.apache.org/jira/browse/OFBIZ-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl closed OFBIZ-2712. Resolution: Won't Do This is abandoned for a long time and there seems to be no interest - closing. > Ecommerce time machine > -- > > Key: OFBIZ-2712 > URL: https://issues.apache.org/jira/browse/OFBIZ-2712 > Project: OFBiz > Issue Type: New Feature > Components: ecommerce >Reporter: Patrick Antivackis >Priority: Major > Attachments: OFBIZ-2712-2009-07-27.patch > > Original Estimate: 336h > Remaining Estimate: 336h > > The idea of this new feature is to allow a "power" user (having a specific > right) to choose a date (future or past) allowing him to browse the ecommerce > site at his chosen date. > This feature will allow for example an administrator to check that all > products/categories/prices/promotions are well configured for a time > special event (christmas, new product/category launch). > The impact is quite uge as a lot of services need to take into account a new > IN parameter (Timestamp moment) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (OFBIZ-12763) OFBiz Website: store and load fonts locally
[ https://issues.apache.org/jira/browse/OFBIZ-12763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl closed OFBIZ-12763. - Resolution: Implemented > OFBiz Website: store and load fonts locally > --- > > Key: OFBIZ-12763 > URL: https://issues.apache.org/jira/browse/OFBIZ-12763 > Project: OFBiz > Issue Type: Improvement > Components: site >Reporter: Michael Brohl >Assignee: Michael Brohl >Priority: Major > > The fonts should be stored locally and loaded from the webserver instead of > external sites. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12763) OFBiz Website: store and load fonts locally
[ https://issues.apache.org/jira/browse/OFBIZ-12763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17690755#comment-17690755 ] Michael Brohl commented on OFBIZ-12763: --- I provided a pull request for the change. The changes are tested with a local webserver. I would appreciate if at least one other contributor could test this before I merge. > OFBiz Website: store and load fonts locally > --- > > Key: OFBIZ-12763 > URL: https://issues.apache.org/jira/browse/OFBIZ-12763 > Project: OFBiz > Issue Type: Improvement > Components: site >Reporter: Michael Brohl >Assignee: Michael Brohl >Priority: Major > > The fonts should be stored locally and loaded from the webserver instead of > external sites. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OFBIZ-12763) OFBiz Website: store and load fonts locally
Michael Brohl created OFBIZ-12763: - Summary: OFBiz Website: store and load fonts locally Key: OFBIZ-12763 URL: https://issues.apache.org/jira/browse/OFBIZ-12763 Project: OFBiz Issue Type: Improvement Components: site Reporter: Michael Brohl Assignee: Michael Brohl The fonts should be stored locally and loaded from the webserver instead of external sites. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-9350) Deprecate Mini Lang
[ https://issues.apache.org/jira/browse/OFBIZ-9350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17686932#comment-17686932 ] Michael Brohl commented on OFBIZ-9350: -- I think it should pop up as a conflict if the pull request or patch contains the new groovy file and also the deletion of the corresponding minilang service. No need for extra monitoring or do I miss something? > Deprecate Mini Lang > --- > > Key: OFBIZ-9350 > URL: https://issues.apache.org/jira/browse/OFBIZ-9350 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS, ALL COMPONENTS, ALL PLUGINS >Affects Versions: Trunk, Upcoming Branch >Reporter: Michael Brohl >Assignee: Nicolas Malin >Priority: Minor > Labels: documentation, refactoring > > According to the proposal thread in [1] we decided to deprecate mini lang. > This issue tracks the next steps proposed in the aformentioned thread, namely: > 1. create a Wiki page for the documentation and description of the migration > process and how mini lang will be replaced. > 2. prominently state in the Wiki that minilang will be deprecated, e.g. in [2] > 3. put deprecation tags in the corresponding code > 4. kindly ask contributors with open patches written in mini lang to replace > them by Groovy code [3] > 5. start an initiative to replace existing mini lang code with Groovy code > where applicable. This needs some more planning and discussion which parts > we'll like to replace with Groovy code and which parts will better be > replaced by some kind of DSL. A good starting point can be [4][5][6]. > [1] > [https://lists.apache.org/thread.html/253b41060a295b8ab68bc78763cc129fc74b712cf776f8716022097f@%3Cdev.ofbiz.apache.org%3E] > [2] > [https://cwiki.apache.org/confluence/display/OFBADMIN/Mini+Language+-+minilang+-+simple-method+-+Reference] > [3] does anyone know a way to batch comment Jira issues like it is possible > in Redmine? > [4] > [https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+DSL+for+OFBiz+business+logic] > [5] > [https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Tutorial+-+A+Beginners+Development+Guide] > [6] [https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12033) Separate login service for API calls
[
https://issues.apache.org/jira/browse/OFBIZ-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17685223#comment-17685223
]
Michael Brohl commented on OFBIZ-12033:
---
Ah, of course, thanks for the explanation, [~rohit.koushal]
> Separate login service for API calls
>
>
> Key: OFBIZ-12033
> URL: https://issues.apache.org/jira/browse/OFBIZ-12033
> Project: OFBiz
> Issue Type: Sub-task
> Components: ALL COMPONENTS
>Reporter: Girish Vasmatkar
>Assignee: Michael Brohl
>Priority: Minor
> Attachments: OFBIZ-12033.patch
>
>
> We're using {color:#2a00ff}userLogin {color}{color:#00}service to
> authenticate users before generating auth tokens for REST API and GraphQL
> calls. However, we figured that a session is also getting created and
> returned in response which is defeating the purpose of having an API in
> place. Even though that session is not getting used anywhere when subsequent
> calls are made using the token, we still think it is an extra session lying
> around in tomcat's session cache. {color}
> {color:#00} {color}
> {color:#00}Proposal is to implement a new basic userLogin service
> (basicAuthUserLogin) that would just do username/password matching and be
> done with it without ever calling request.getSession(). This will ensure that
> APIs are stateless and no session is generated.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OFBIZ-10134) [Refactoring] Package org.apache.ofbiz.product.category
[ https://issues.apache.org/jira/browse/OFBIZ-10134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17685211#comment-17685211 ] Michael Brohl commented on OFBIZ-10134: --- No problem [~danwatford] , just a reminder. Best practice would be to ask the assignee if the issue can be taken over. It prevents doing 2 people doing the same work in parallel. See https://cwiki.apache.org/confluence/display/OFBIZ/Guidelines+for+Using+JIRA+Draft+Proposal+1/#GuidelinesforUsingJIRADraftProposal1-Assignee > [Refactoring] Package org.apache.ofbiz.product.category > --- > > Key: OFBIZ-10134 > URL: https://issues.apache.org/jira/browse/OFBIZ-10134 > Project: OFBiz > Issue Type: Sub-task > Components: product >Affects Versions: Trunk, Upcoming Branch >Reporter: Dennis Balkir >Assignee: Michael Brohl >Priority: Minor > Attachments: > OFBIZ-10134_org.apache.ofbiz.product.category.CatalogUrlDirective_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.CatalogUrlFilter_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.CatalogUrlServlet_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.CategoryContentWrapper_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.CategoryServices_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.CategoryWorker_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.SeoCatalogUrlServlet_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.SeoConfigUtil_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.SeoContextFilter_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.SeoControlServlet_refactoring.patch > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-10134) [Refactoring] Package org.apache.ofbiz.product.category
[ https://issues.apache.org/jira/browse/OFBIZ-10134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17685139#comment-17685139 ] Michael Brohl commented on OFBIZ-10134: --- [~danwatford] thanks for taking care of this. It would be nice if you could follow the Jira process as well and also consider actual ticket assignments. Thanks! > [Refactoring] Package org.apache.ofbiz.product.category > --- > > Key: OFBIZ-10134 > URL: https://issues.apache.org/jira/browse/OFBIZ-10134 > Project: OFBiz > Issue Type: Sub-task > Components: product >Affects Versions: Trunk, Upcoming Branch >Reporter: Dennis Balkir >Assignee: Michael Brohl >Priority: Minor > Attachments: > OFBIZ-10134_org.apache.ofbiz.product.category.CatalogUrlDirective_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.CatalogUrlFilter_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.CatalogUrlServlet_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.CategoryContentWrapper_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.CategoryServices_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.CategoryWorker_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.SeoCatalogUrlServlet_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.SeoConfigUtil_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.SeoContextFilter_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.SeoControlServlet_refactoring.patch > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12033) Separate login service for API calls
[
https://issues.apache.org/jira/browse/OFBIZ-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17685125#comment-17685125
]
Michael Brohl commented on OFBIZ-12033:
---
Thanks [~rohit.koushal] for your observations and the patch!
{quote}While reviewing the implementation of the REST component, I discovered
that it primarily focuses on exposing OFBiz services for REST calls. But what
if a service takes a complex object, such as a user-defined class (e.g.
GenericValue)? In that case, it may be necessary to define data mappers or do
we have a better solution?
{quote}
Yes, we'll need a mapping mechanism to/from complex objects. We have a
configurable solution for this worked out for OFBIZ-12517 using annotated java
objects.
We have a field tested overall solution for the subtasks of OFBIZ-11328 which
is going to be contributed.
{quote}Additionally, I discovered three methods for creating APIs with the
existing code, but I couldn't find any documentation or examples for two of
them. Do we have documents that I am missing?
{quote}
The documentation will be updated/enhanced with the above mentioned
contributions as well.
What do you mean by the first solution
{quote}Using a Java Resource
{quote}
> Separate login service for API calls
>
>
> Key: OFBIZ-12033
> URL: https://issues.apache.org/jira/browse/OFBIZ-12033
> Project: OFBiz
> Issue Type: Sub-task
> Components: ALL COMPONENTS
>Reporter: Girish Vasmatkar
>Assignee: Michael Brohl
>Priority: Minor
> Attachments: OFBIZ-12033.patch
>
>
> We're using {color:#2a00ff}userLogin {color}{color:#00}service to
> authenticate users before generating auth tokens for REST API and GraphQL
> calls. However, we figured that a session is also getting created and
> returned in response which is defeating the purpose of having an API in
> place. Even though that session is not getting used anywhere when subsequent
> calls are made using the token, we still think it is an extra session lying
> around in tomcat's session cache. {color}
> {color:#00} {color}
> {color:#00}Proposal is to implement a new basic userLogin service
> (basicAuthUserLogin) that would just do username/password matching and be
> done with it without ever calling request.getSession(). This will ensure that
> APIs are stateless and no session is generated.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OFBIZ-10134) [Refactoring] Package org.apache.ofbiz.product.category
[ https://issues.apache.org/jira/browse/OFBIZ-10134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl reassigned OFBIZ-10134: - Assignee: Michael Brohl > [Refactoring] Package org.apache.ofbiz.product.category > --- > > Key: OFBIZ-10134 > URL: https://issues.apache.org/jira/browse/OFBIZ-10134 > Project: OFBiz > Issue Type: Sub-task > Components: product >Affects Versions: Trunk, Upcoming Branch >Reporter: Dennis Balkir >Assignee: Michael Brohl >Priority: Minor > Attachments: > OFBIZ-10134_org.apache.ofbiz.product.category.CatalogUrlDirective_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.CatalogUrlFilter_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.CatalogUrlServlet_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.CategoryContentWrapper_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.CategoryServices_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.CategoryWorker_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.SeoCatalogUrlServlet_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.SeoConfigUtil_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.SeoContextFilter_refactoring.patch, > > OFBIZ-10134_org.apache.ofbiz.product.category.SeoControlServlet_refactoring.patch > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OFBIZ-9403) DataResourceWorker: New method getMimeTypeFromFileName(...) with extracted (refactored) code from getMimeType(...) method
[ https://issues.apache.org/jira/browse/OFBIZ-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl reassigned OFBIZ-9403: Assignee: Michael Brohl (was: Deepak Dixit) > DataResourceWorker: New method getMimeTypeFromFileName(...) with extracted > (refactored) code from getMimeType(...) method > - > > Key: OFBIZ-9403 > URL: https://issues.apache.org/jira/browse/OFBIZ-9403 > Project: OFBiz > Issue Type: Improvement > Components: content >Affects Versions: Trunk, Upcoming Branch >Reporter: Martin Becker >Assignee: Michael Brohl >Priority: Trivial > Attachments: OFBIZ-9403_DataResourceWorker_GetMimeType.patch, > OFBIZ-9403_DataResourceWorker_GetMimeType_with_defaultMimeTypeId.patch > > > The method DataResourceWorker.getMimeType(GenericValue) has been refactored > into two separate methods. The new additional method > getMimeTypeFromFileName(Delegator,Filename) solely focuses on getting the > MimeType from the file extension and is invoked by getMimeType(GenericValue) > if needed. getMimeType returns the type if possible via the data resource. > This results in cleaner code with the responsibility of both methods clearly > defined by the methods names. -- This message was sent by Atlassian Jira (v8.20.10#820010)
