[jira] [Created] (OFBIZ-9842) Service level check is missing on transfer inventory
Vaibhav Jain created OFBIZ-9842: --- Summary: Service level check is missing on transfer inventory Key: OFBIZ-9842 URL: https://issues.apache.org/jira/browse/OFBIZ-9842 Project: OFBiz Issue Type: Bug Reporter: Vaibhav Jain If we mark Complete to the transferred inventory then transfer inventory run twice. Which corrupt the inventory data. Because service level check of status valid change is not working.Which corrupt the inventory data due to execution of SECA on it -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9839) Using try-with-resources with JDBC objects
[ https://issues.apache.org/jira/browse/OFBIZ-9839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203347#comment-16203347 ] Jacques Le Roux commented on OFBIZ-9839: Thanks Yash, Your patch is trunk at revision: 1812104. > Using try-with-resources with JDBC objects > -- > > Key: OFBIZ-9839 > URL: https://issues.apache.org/jira/browse/OFBIZ-9839 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Pradhan Yash Sharma >Assignee: Jacques Le Roux > Attachments: OFBIZ-9839.patch > > > Proposal to use try with resources for SQL objects like ResultSet and other > objects. SQL classes have AutoCloseable interface. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OFBIZ-9839) Using try-with-resources with JDBC objects
[ https://issues.apache.org/jira/browse/OFBIZ-9839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-9839: -- Assignee: Pradhan Yash Sharma (was: Jacques Le Roux) > Using try-with-resources with JDBC objects > -- > > Key: OFBIZ-9839 > URL: https://issues.apache.org/jira/browse/OFBIZ-9839 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Pradhan Yash Sharma >Assignee: Pradhan Yash Sharma > Attachments: OFBIZ-9839.patch > > > Proposal to use try with resources for SQL objects like ResultSet and other > objects. SQL classes have AutoCloseable interface. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OFBIZ-9674) Update build.gradle to the latest dependencies
[
https://issues.apache.org/jira/browse/OFBIZ-9674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Leichert updated OFBIZ-9674:
---
Attachment: OFBIZ-9674_Update_buildgradle.patch
- changed Version in FreeMarkerWorker to 2.3.26
> Update build.gradle to the latest dependencies
> --
>
> Key: OFBIZ-9674
> URL: https://issues.apache.org/jira/browse/OFBIZ-9674
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Michael Brohl
>Assignee: Michael Brohl
>Priority: Minor
> Attachments: OFBIZ-9674_Update_buildgradle.patch,
> OFBIZ-9674_Update_buildgradle.patch
>
>
> I wondered how up-to-date our project dependencies are and searched for an
> efficient way how to check this. I found the gradle-versions-plugin [1] which
> analyzes the dependencies and checks if there are newer versions available.
> I ran the check with
> {code:java}
> ./gradlew dependencyUpdates -Drevision=release
> {code}
> and got the following result:
>
> : Project Dependency Updates (report to plain text file)
>
> The following dependencies are using the latest release version:
> - net.sf.barcode4j:barcode4j:2.1
> - net.sf.barcode4j:barcode4j-fop-ext:2.1
> - org.codeartisans.thirdparties.swing:batik-all:1.8pre-r1084380
> - org.apache.commons:commons-collections4:4.1
> - com.googlecode.ez-vcard:ez-vcard:0.9.10
> - org.apache.geronimo.specs:geronimo-jms_1.1_spec:1.1.1
> - org.apache.geronimo.components:geronimo-transaction:3.1.4
> - at.bxm.gradleplugins:gradle-svntools-plugin:2.2.1
> - com.github.ben-manes:gradle-versions-plugin:0.15.0
> - org.hamcrest:hamcrest-all:1.3
> - net.fortuna.ical4j:ical4j:1.0-rc3-atlassian-11
> - javax.el:javax.el-api:3.0.1-b04
> - de.odysseus.juel:juel-impl:2.2.7
> - de.odysseus.juel:juel-spi:2.2.7
> - junit:junit:4.12
> - oro:oro:2.0.8
> - apache-xerces:xercesImpl:2.9.1
> The following dependencies exceed the version found at the release revision
> level:
> - com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer
> [20160628.1 <- 1.1]
> The following dependencies have later release versions:
> - org.apache.ant:ant-junit [1.9.0 -> 1.10.1]
> - org.apache.ant:ant-junit [1.9.7 -> 1.10.1]
> - org.apache.axis2:axis2-kernel [1.7.1 -> 1.7.6]
> - org.apache.axis2:axis2-transport-http [1.7.1 -> 1.7.6]
> - org.apache.axis2:axis2-transport-local [1.7.1 -> 1.7.6]
> - commons-cli:commons-cli [1.3.1 -> 1.4]
> - org.apache.commons:commons-csv [1.1 -> 1.5]
> - org.apache.commons:commons-dbcp2 [2.1 -> 2.1.1]
> - commons-net:commons-net [3.3 -> 3.6]
> - commons-validator:commons-validator [1.5.1 -> 1.6]
> - com.googlecode.concurrentlinkedhashmap:concurrentlinkedhashmap-lru [1.0 ->
> 1.4.2]
> - com.google.zxing:core [3.2.1 -> 3.3.0]
> - org.apache.derby:derby [10.11.1.1 -> 10.13.1.1]
> - org.owasp.esapi:esapi [2.1.0 -> 2.1.0.1]
> - org.apache.xmlgraphics:fop [2.1 -> 2.2]
> - org.freemarker:freemarker [2.3.25-incubating -> 2.3.26-incubating]
> - org.codehaus.groovy:groovy-all [2.4.12 -> 2.5.0-beta-1]
> - org.apache.httpcomponents:httpclient-cache [4.4.1 -> 4.5.3]
> - com.ibm.icu:icu4j [57.1 -> 59.1]
> - com.lowagie:itext [2.1.7 -> 4.2.2]
> - org.zapodot:jackson-databind-java-optional [2.4.2 -> 2.6.1]
> - com.sun.mail:javax.mail [1.5.1 -> 1.6.0]
> - javax.servlet:javax.servlet-api [3.1.0 -> 4.0.0]
> - javax.servlet.jsp:javax.servlet.jsp-api [2.3.0 -> 2.3.2-b02]
> - junit:junit-dep [4.10 -> 4.11]
> - com.googlecode.libphonenumber:libphonenumber [8.6.0 -> 8.8.0]
> - org.apache.logging.log4j:log4j-1.2-api [2.6.2 -> 2.9.0]
> - org.apache.logging.log4j:log4j-api [2.6.2 -> 2.9.0]
> - org.apache.logging.log4j:log4j-core [2.6.2 -> 2.9.0]
> - org.apache.logging.log4j:log4j-jul [2.6.2 -> 2.9.0]
> - org.apache.logging.log4j:log4j-slf4j-impl [2.6.2 -> 2.9.0]
> - org.mockito:mockito-core [1.10.19 -> 2.9.0]
> - org.apache.poi:poi [3.14 -> 3.17-beta1]
> - org.apache.shiro:shiro-core [1.3.0 -> 1.4.0]
> - org.springframework:spring-test [4.2.3.RELEASE -> 4.3.10.RELEASE]
> - org.apache.tika:tika-core [1.12 -> 1.16]
> - org.apache.tika:tika-parsers [1.12 -> 1.16]
> - org.apache.tomcat:tomcat-catalina [8.5.16 -> 9.0.0.M26]
> - org.apache.tomcat:tomcat-catalina-ha [8.5.16 -> 9.0.0.M25]
> - org.apache.tomcat:tomcat-jasper [8.5.16 -> 9.0.0.M26]
> - org.apache.tomcat:tomcat-tribes [8.5.16 -> 9.0.0.M25]
> - wsdl4j:wsdl4j [1.6.2 -> 1.6.3]
> - org.apache.xmlrpc:xmlrpc-client [3.1.2 -> 3.1.3]
> - org.apache.xmlrpc:xmlrpc-server [3.1.2 -> 3.1.3]
> - com.thoughtworks.xstream:xstream [1.4.9 -> 1.4.10]
> Failed to determine the latest version for the following dependencies (use
> --info for deta
[jira] [Updated] (OFBIZ-9674) Update build.gradle to the latest dependencies
[
https://issues.apache.org/jira/browse/OFBIZ-9674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Leichert updated OFBIZ-9674:
---
Attachment: (was: OFBIZ-9674_Update_buildgradle.patch)
> Update build.gradle to the latest dependencies
> --
>
> Key: OFBIZ-9674
> URL: https://issues.apache.org/jira/browse/OFBIZ-9674
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Michael Brohl
>Assignee: Michael Brohl
>Priority: Minor
> Attachments: OFBIZ-9674_Update_buildgradle.patch
>
>
> I wondered how up-to-date our project dependencies are and searched for an
> efficient way how to check this. I found the gradle-versions-plugin [1] which
> analyzes the dependencies and checks if there are newer versions available.
> I ran the check with
> {code:java}
> ./gradlew dependencyUpdates -Drevision=release
> {code}
> and got the following result:
>
> : Project Dependency Updates (report to plain text file)
>
> The following dependencies are using the latest release version:
> - net.sf.barcode4j:barcode4j:2.1
> - net.sf.barcode4j:barcode4j-fop-ext:2.1
> - org.codeartisans.thirdparties.swing:batik-all:1.8pre-r1084380
> - org.apache.commons:commons-collections4:4.1
> - com.googlecode.ez-vcard:ez-vcard:0.9.10
> - org.apache.geronimo.specs:geronimo-jms_1.1_spec:1.1.1
> - org.apache.geronimo.components:geronimo-transaction:3.1.4
> - at.bxm.gradleplugins:gradle-svntools-plugin:2.2.1
> - com.github.ben-manes:gradle-versions-plugin:0.15.0
> - org.hamcrest:hamcrest-all:1.3
> - net.fortuna.ical4j:ical4j:1.0-rc3-atlassian-11
> - javax.el:javax.el-api:3.0.1-b04
> - de.odysseus.juel:juel-impl:2.2.7
> - de.odysseus.juel:juel-spi:2.2.7
> - junit:junit:4.12
> - oro:oro:2.0.8
> - apache-xerces:xercesImpl:2.9.1
> The following dependencies exceed the version found at the release revision
> level:
> - com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer
> [20160628.1 <- 1.1]
> The following dependencies have later release versions:
> - org.apache.ant:ant-junit [1.9.0 -> 1.10.1]
> - org.apache.ant:ant-junit [1.9.7 -> 1.10.1]
> - org.apache.axis2:axis2-kernel [1.7.1 -> 1.7.6]
> - org.apache.axis2:axis2-transport-http [1.7.1 -> 1.7.6]
> - org.apache.axis2:axis2-transport-local [1.7.1 -> 1.7.6]
> - commons-cli:commons-cli [1.3.1 -> 1.4]
> - org.apache.commons:commons-csv [1.1 -> 1.5]
> - org.apache.commons:commons-dbcp2 [2.1 -> 2.1.1]
> - commons-net:commons-net [3.3 -> 3.6]
> - commons-validator:commons-validator [1.5.1 -> 1.6]
> - com.googlecode.concurrentlinkedhashmap:concurrentlinkedhashmap-lru [1.0 ->
> 1.4.2]
> - com.google.zxing:core [3.2.1 -> 3.3.0]
> - org.apache.derby:derby [10.11.1.1 -> 10.13.1.1]
> - org.owasp.esapi:esapi [2.1.0 -> 2.1.0.1]
> - org.apache.xmlgraphics:fop [2.1 -> 2.2]
> - org.freemarker:freemarker [2.3.25-incubating -> 2.3.26-incubating]
> - org.codehaus.groovy:groovy-all [2.4.12 -> 2.5.0-beta-1]
> - org.apache.httpcomponents:httpclient-cache [4.4.1 -> 4.5.3]
> - com.ibm.icu:icu4j [57.1 -> 59.1]
> - com.lowagie:itext [2.1.7 -> 4.2.2]
> - org.zapodot:jackson-databind-java-optional [2.4.2 -> 2.6.1]
> - com.sun.mail:javax.mail [1.5.1 -> 1.6.0]
> - javax.servlet:javax.servlet-api [3.1.0 -> 4.0.0]
> - javax.servlet.jsp:javax.servlet.jsp-api [2.3.0 -> 2.3.2-b02]
> - junit:junit-dep [4.10 -> 4.11]
> - com.googlecode.libphonenumber:libphonenumber [8.6.0 -> 8.8.0]
> - org.apache.logging.log4j:log4j-1.2-api [2.6.2 -> 2.9.0]
> - org.apache.logging.log4j:log4j-api [2.6.2 -> 2.9.0]
> - org.apache.logging.log4j:log4j-core [2.6.2 -> 2.9.0]
> - org.apache.logging.log4j:log4j-jul [2.6.2 -> 2.9.0]
> - org.apache.logging.log4j:log4j-slf4j-impl [2.6.2 -> 2.9.0]
> - org.mockito:mockito-core [1.10.19 -> 2.9.0]
> - org.apache.poi:poi [3.14 -> 3.17-beta1]
> - org.apache.shiro:shiro-core [1.3.0 -> 1.4.0]
> - org.springframework:spring-test [4.2.3.RELEASE -> 4.3.10.RELEASE]
> - org.apache.tika:tika-core [1.12 -> 1.16]
> - org.apache.tika:tika-parsers [1.12 -> 1.16]
> - org.apache.tomcat:tomcat-catalina [8.5.16 -> 9.0.0.M26]
> - org.apache.tomcat:tomcat-catalina-ha [8.5.16 -> 9.0.0.M25]
> - org.apache.tomcat:tomcat-jasper [8.5.16 -> 9.0.0.M26]
> - org.apache.tomcat:tomcat-tribes [8.5.16 -> 9.0.0.M25]
> - wsdl4j:wsdl4j [1.6.2 -> 1.6.3]
> - org.apache.xmlrpc:xmlrpc-client [3.1.2 -> 3.1.3]
> - org.apache.xmlrpc:xmlrpc-server [3.1.2 -> 3.1.3]
> - com.thoughtworks.xstream:xstream [1.4.9 -> 1.4.10]
> Failed to determine the latest version for the following dependencies (use
> --info for details):
> - com.sun.syndication:com.springsource.com.sun.syndication
> - org.a
[jira] [Updated] (OFBIZ-9841) Implement AutoCloseable interface in SQLProcessor Class
[ https://issues.apache.org/jira/browse/OFBIZ-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pradhan Yash Sharma updated OFBIZ-9841: --- Attachment: OFBIZ-9841.patch Attaching patch file. > Implement AutoCloseable interface in SQLProcessor Class > --- > > Key: OFBIZ-9841 > URL: https://issues.apache.org/jira/browse/OFBIZ-9841 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Pradhan Yash Sharma >Assignee: Pradhan Yash Sharma >Priority: Critical > Fix For: Trunk > > Attachments: OFBIZ-9841.patch > > > Implement SQLProcessor class with the AutoCloseable interface. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9826) Add ability to disable seca rule
[ https://issues.apache.org/jira/browse/OFBIZ-9826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203496#comment-16203496 ] Jacques Le Roux commented on OFBIZ-9826: Hi Deepak, This patch looks good to me, any reason why it's not committed? > Add ability to disable seca rule > - > > Key: OFBIZ-9826 > URL: https://issues.apache.org/jira/browse/OFBIZ-9826 > Project: OFBiz > Issue Type: Improvement >Reporter: Deepak Dixit >Assignee: Deepak Dixit > Attachments: OFBIZ-9826.patch > > > We have enabled flag in ServiceEcaRule class, if its set false then seca rule > will not be execute. > But there is not way to disable seca. > We can add enabled flag in SECA definition to disable the existing seca rule. > Here is the proposal: > - Add new attribute on seca tag named enabled > - Default value will be true for this. > - If user want to disable existing OOTB seca rule, then user can define same > rule in custom component and set the enabled=false > - Need some changes in code to honor the enabled attribute while loading seca > rule. > Also as per current flow if same seca rule is define more then once, system > will execute all the rule, ideally it should not execute same rule (same > rule, condition and action) if its defined more than one. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OFBIZ-9841) Implement AutoCloseable interface in SQLProcessor Class
[ https://issues.apache.org/jira/browse/OFBIZ-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pradhan Yash Sharma updated OFBIZ-9841: --- Attachment: OFBIZ-9841.patch Attaching patch file with removed indentation. > Implement AutoCloseable interface in SQLProcessor Class > --- > > Key: OFBIZ-9841 > URL: https://issues.apache.org/jira/browse/OFBIZ-9841 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Pradhan Yash Sharma >Assignee: Pradhan Yash Sharma >Priority: Critical > Fix For: Trunk > > Attachments: OFBIZ-9841.patch, OFBIZ-9841.patch > > > Implement SQLProcessor class with the AutoCloseable interface. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9841) Implement AutoCloseable interface in SQLProcessor Class
[ https://issues.apache.org/jira/browse/OFBIZ-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203584#comment-16203584 ] Pradhan Yash Sharma commented on OFBIZ-9841: Added AutoCloseable interface to SQLProcessor class and overridden Close method, Added closing of ResultSet, PreparedStatement and Connection Objects. While calling SQLProcessor object in GenericDAO used Try-with-Resources and removed unnecessary calls of the same object before actual use, also removed finally blocks for method invocation. > Implement AutoCloseable interface in SQLProcessor Class > --- > > Key: OFBIZ-9841 > URL: https://issues.apache.org/jira/browse/OFBIZ-9841 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Pradhan Yash Sharma >Assignee: Pradhan Yash Sharma >Priority: Critical > Fix For: Trunk > > Attachments: OFBIZ-9841.patch, OFBIZ-9841.patch > > > Implement SQLProcessor class with the AutoCloseable interface. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9826) Add ability to disable seca rule
[ https://issues.apache.org/jira/browse/OFBIZ-9826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203602#comment-16203602 ] Michael Brohl commented on OFBIZ-9826: -- +1 > Add ability to disable seca rule > - > > Key: OFBIZ-9826 > URL: https://issues.apache.org/jira/browse/OFBIZ-9826 > Project: OFBiz > Issue Type: Improvement >Reporter: Deepak Dixit >Assignee: Deepak Dixit > Attachments: OFBIZ-9826.patch > > > We have enabled flag in ServiceEcaRule class, if its set false then seca rule > will not be execute. > But there is not way to disable seca. > We can add enabled flag in SECA definition to disable the existing seca rule. > Here is the proposal: > - Add new attribute on seca tag named enabled > - Default value will be true for this. > - If user want to disable existing OOTB seca rule, then user can define same > rule in custom component and set the enabled=false > - Need some changes in code to honor the enabled attribute while loading seca > rule. > Also as per current flow if same seca rule is define more then once, system > will execute all the rule, ideally it should not execute same rule (same > rule, condition and action) if its defined more than one. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (OFBIZ-5938) GlAccountOrganizations manually added using accounting forms do not appear on trial report because fromDate gets set to NULL
[ https://issues.apache.org/jira/browse/OFBIZ-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reopened OFBIZ-5938: > GlAccountOrganizations manually added using accounting forms do not appear on > trial report because fromDate gets set to NULL > > > Key: OFBIZ-5938 > URL: https://issues.apache.org/jira/browse/OFBIZ-5938 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: Release Branch 14.12, Trunk >Reporter: Christian Carlow >Assignee: Jacques Le Roux >Priority: Minor > Fix For: 14.12.01, 15.12.01 > > Attachments: OFBIZ-5938.patch > > > To reproduce: > 1. Manually assign a glAccount to an organization (Accounting->Global GL > Settings->Chart Of Accounts->Assign Gl Account or Accounting->Organization GL > Settings->Setup->Chart of Accounts) > 2. Perform operations that create transactions for the organizations > glAccount > 3. Run the Accounting->Organization GL Settings->Accounting->Reports->Trial > Balance > Notice that the glAccountId assigned in step 1 is not listed in the results. > This is due to TrialBalance.groovy applying a fromDate filter to > GlAccountOrganizationAndClass which is not set in step 1. Updating > glAccountOrganization fromDate to something within the trial balance range > resolves the problem. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OFBIZ-5938) GlAccountOrganizations manually added using accounting forms do not appear on trial report because fromDate gets set to NULL
[ https://issues.apache.org/jira/browse/OFBIZ-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-5938: -- Assignee: Jacques Le Roux (was: Pranay Pandey) > GlAccountOrganizations manually added using accounting forms do not appear on > trial report because fromDate gets set to NULL > > > Key: OFBIZ-5938 > URL: https://issues.apache.org/jira/browse/OFBIZ-5938 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: Release Branch 14.12, Trunk >Reporter: Christian Carlow >Assignee: Jacques Le Roux >Priority: Minor > Fix For: 14.12.01, 15.12.01 > > Attachments: OFBIZ-5938.patch > > > To reproduce: > 1. Manually assign a glAccount to an organization (Accounting->Global GL > Settings->Chart Of Accounts->Assign Gl Account or Accounting->Organization GL > Settings->Setup->Chart of Accounts) > 2. Perform operations that create transactions for the organizations > glAccount > 3. Run the Accounting->Organization GL Settings->Accounting->Reports->Trial > Balance > Notice that the glAccountId assigned in step 1 is not listed in the results. > This is due to TrialBalance.groovy applying a fromDate filter to > GlAccountOrganizationAndClass which is not set in step 1. Updating > glAccountOrganization fromDate to something within the trial balance range > resolves the problem. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-5938) GlAccountOrganizations manually added using accounting forms do not appear on trial report because fromDate gets set to NULL
[
https://issues.apache.org/jira/browse/OFBIZ-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203624#comment-16203624
]
Jacques Le Roux commented on OFBIZ-5938:
Hi Rajesh,
The createGlAccountOrganization as since been transformed to use entity-auto
and that's certainly the reason why the fromDate misses again.
Please try if these changes are enough
{code}
Index: applications/accounting/widget/GlobalGlAccountsForms.xml
===
--- applications/accounting/widget/GlobalGlAccountsForms.xml(revision
1812128)
+++ applications/accounting/widget/GlobalGlAccountsForms.xml(working copy)
@@ -62,6 +62,7 @@
+
Index: applications/accounting/widget/GlSetupForms.xml
===
--- applications/accounting/widget/GlSetupForms.xml (revision 1812128)
+++ applications/accounting/widget/GlSetupForms.xml (working copy)
@@ -143,6 +143,7 @@
+
{code}
> GlAccountOrganizations manually added using accounting forms do not appear on
> trial report because fromDate gets set to NULL
>
>
> Key: OFBIZ-5938
> URL: https://issues.apache.org/jira/browse/OFBIZ-5938
> Project: OFBiz
> Issue Type: Bug
> Components: accounting
>Affects Versions: Release Branch 14.12, Trunk
>Reporter: Christian Carlow
>Assignee: Pranay Pandey
>Priority: Minor
> Fix For: 14.12.01, 15.12.01
>
> Attachments: OFBIZ-5938.patch
>
>
> To reproduce:
> 1. Manually assign a glAccount to an organization (Accounting->Global GL
> Settings->Chart Of Accounts->Assign Gl Account or Accounting->Organization GL
> Settings->Setup->Chart of Accounts)
> 2. Perform operations that create transactions for the organizations
> glAccount
> 3. Run the Accounting->Organization GL Settings->Accounting->Reports->Trial
> Balance
> Notice that the glAccountId assigned in step 1 is not listed in the results.
> This is due to TrialBalance.groovy applying a fromDate filter to
> GlAccountOrganizationAndClass which is not set in step 1. Updating
> glAccountOrganization fromDate to something within the trial balance range
> resolves the problem.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (OFBIZ-9841) Implement AutoCloseable interface in SQLProcessor Class
[ https://issues.apache.org/jira/browse/OFBIZ-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-9841: -- Assignee: Jacques Le Roux (was: Pradhan Yash Sharma) > Implement AutoCloseable interface in SQLProcessor Class > --- > > Key: OFBIZ-9841 > URL: https://issues.apache.org/jira/browse/OFBIZ-9841 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Pradhan Yash Sharma >Assignee: Jacques Le Roux >Priority: Critical > Fix For: Trunk > > Attachments: OFBIZ-9841.patch, OFBIZ-9841.patch > > > Implement SQLProcessor class with the AutoCloseable interface. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-5938) GlAccountOrganizations manually added using accounting forms do not appear on trial report because fromDate gets set to NULL
[ https://issues.apache.org/jira/browse/OFBIZ-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203692#comment-16203692 ] Rajesh Kumar Mallah commented on OFBIZ-5938: just checking > GlAccountOrganizations manually added using accounting forms do not appear on > trial report because fromDate gets set to NULL > > > Key: OFBIZ-5938 > URL: https://issues.apache.org/jira/browse/OFBIZ-5938 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: Release Branch 14.12, Trunk >Reporter: Christian Carlow >Assignee: Jacques Le Roux >Priority: Minor > Fix For: 14.12.01, 15.12.01 > > Attachments: OFBIZ-5938.patch > > > To reproduce: > 1. Manually assign a glAccount to an organization (Accounting->Global GL > Settings->Chart Of Accounts->Assign Gl Account or Accounting->Organization GL > Settings->Setup->Chart of Accounts) > 2. Perform operations that create transactions for the organizations > glAccount > 3. Run the Accounting->Organization GL Settings->Accounting->Reports->Trial > Balance > Notice that the glAccountId assigned in step 1 is not listed in the results. > This is due to TrialBalance.groovy applying a fromDate filter to > GlAccountOrganizationAndClass which is not set in step 1. Updating > glAccountOrganization fromDate to something within the trial balance range > resolves the problem. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-5938) GlAccountOrganizations manually added using accounting forms do not appear on trial report because fromDate gets set to NULL
[ https://issues.apache.org/jira/browse/OFBIZ-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203712#comment-16203712 ] Rajesh Kumar Mallah commented on OFBIZ-5938: I use the URL endpoint /accounting/control/ListGlAccountOrganization?organizationPartyId=1 to assign new GL accounts to the organisation . After making the changes in the XML files , followed by ./gradlew , i do not see any change in the form UI . Neither did the new entry in database had from_date populated . am I looking at the wrong place? regds mallah. > GlAccountOrganizations manually added using accounting forms do not appear on > trial report because fromDate gets set to NULL > > > Key: OFBIZ-5938 > URL: https://issues.apache.org/jira/browse/OFBIZ-5938 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: Release Branch 14.12, Trunk >Reporter: Christian Carlow >Assignee: Jacques Le Roux >Priority: Minor > Fix For: 14.12.01, 15.12.01 > > Attachments: OFBIZ-5938.patch > > > To reproduce: > 1. Manually assign a glAccount to an organization (Accounting->Global GL > Settings->Chart Of Accounts->Assign Gl Account or Accounting->Organization GL > Settings->Setup->Chart of Accounts) > 2. Perform operations that create transactions for the organizations > glAccount > 3. Run the Accounting->Organization GL Settings->Accounting->Reports->Trial > Balance > Notice that the glAccountId assigned in step 1 is not listed in the results. > This is due to TrialBalance.groovy applying a fromDate filter to > GlAccountOrganizationAndClass which is not set in step 1. Updating > glAccountOrganization fromDate to something within the trial balance range > resolves the problem. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9841) Implement AutoCloseable interface in SQLProcessor Class
[ https://issues.apache.org/jira/browse/OFBIZ-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203713#comment-16203713 ] Jacques Le Roux commented on OFBIZ-9841: Thanks Yash, Your patch is in trunk at revision: 1812144 I have just formatted both updateByCondition methods BTW, why do you consider this a critical bug. Even with the useless but also harmless closings of the passed SQLProcessor in updateByCondition and select methods I see no reasons to consider this a bug, even less a critical one. If you agree please change and close. Else explain and we will need to backport... > Implement AutoCloseable interface in SQLProcessor Class > --- > > Key: OFBIZ-9841 > URL: https://issues.apache.org/jira/browse/OFBIZ-9841 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Pradhan Yash Sharma >Assignee: Jacques Le Roux >Priority: Critical > Fix For: Trunk > > Attachments: OFBIZ-9841.patch, OFBIZ-9841.patch > > > Implement SQLProcessor class with the AutoCloseable interface. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (OFBIZ-9841) Implement AutoCloseable interface in SQLProcessor Class
[ https://issues.apache.org/jira/browse/OFBIZ-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203713#comment-16203713 ] Jacques Le Roux edited comment on OFBIZ-9841 at 10/13/17 3:38 PM: -- Thanks Yash, Your patch is in trunk at revision: 1812144 I have just formatted both updateByCondition methods BTW, why do you consider this a critical bug? Even with the useless but also harmless closings of the passed SQLProcessor in updateByCondition and select methods I see no reasons to consider this a bug, even less a critical one. If you agree please change and close. Else explain and we will need to backport... was (Author: jacques.le.roux): Thanks Yash, Your patch is in trunk at revision: 1812144 I have just formatted both updateByCondition methods BTW, why do you consider this a critical bug. Even with the useless but also harmless closings of the passed SQLProcessor in updateByCondition and select methods I see no reasons to consider this a bug, even less a critical one. If you agree please change and close. Else explain and we will need to backport... > Implement AutoCloseable interface in SQLProcessor Class > --- > > Key: OFBIZ-9841 > URL: https://issues.apache.org/jira/browse/OFBIZ-9841 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Pradhan Yash Sharma >Assignee: Pradhan Yash Sharma >Priority: Critical > Fix For: Trunk > > Attachments: OFBIZ-9841.patch, OFBIZ-9841.patch > > > Implement SQLProcessor class with the AutoCloseable interface. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OFBIZ-9841) Implement AutoCloseable interface in SQLProcessor Class
[ https://issues.apache.org/jira/browse/OFBIZ-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-9841: -- Assignee: Pradhan Yash Sharma (was: Jacques Le Roux) > Implement AutoCloseable interface in SQLProcessor Class > --- > > Key: OFBIZ-9841 > URL: https://issues.apache.org/jira/browse/OFBIZ-9841 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Pradhan Yash Sharma >Assignee: Pradhan Yash Sharma >Priority: Critical > Fix For: Trunk > > Attachments: OFBIZ-9841.patch, OFBIZ-9841.patch > > > Implement SQLProcessor class with the AutoCloseable interface. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-5938) GlAccountOrganizations manually added using accounting forms do not appear on trial report because fromDate gets set to NULL
[ https://issues.apache.org/jira/browse/OFBIZ-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203724#comment-16203724 ] Jacques Le Roux commented on OFBIZ-5938: PLease try accounting/control/AssignGlAccount?organizationPartyId=company and accounting/control/ListGlAccountOrganization > GlAccountOrganizations manually added using accounting forms do not appear on > trial report because fromDate gets set to NULL > > > Key: OFBIZ-5938 > URL: https://issues.apache.org/jira/browse/OFBIZ-5938 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: Release Branch 14.12, Trunk >Reporter: Christian Carlow >Assignee: Jacques Le Roux >Priority: Minor > Fix For: 14.12.01, 15.12.01 > > Attachments: OFBIZ-5938.patch > > > To reproduce: > 1. Manually assign a glAccount to an organization (Accounting->Global GL > Settings->Chart Of Accounts->Assign Gl Account or Accounting->Organization GL > Settings->Setup->Chart of Accounts) > 2. Perform operations that create transactions for the organizations > glAccount > 3. Run the Accounting->Organization GL Settings->Accounting->Reports->Trial > Balance > Notice that the glAccountId assigned in step 1 is not listed in the results. > This is due to TrialBalance.groovy applying a fromDate filter to > GlAccountOrganizationAndClass which is not set in step 1. Updating > glAccountOrganization fromDate to something within the trial balance range > resolves the problem. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (OFBIZ-5938) GlAccountOrganizations manually added using accounting forms do not appear on trial report because fromDate gets set to NULL
[ https://issues.apache.org/jira/browse/OFBIZ-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203724#comment-16203724 ] Jacques Le Roux edited comment on OFBIZ-5938 at 10/13/17 3:49 PM: -- PLease try accounting/control/AssignGlAccount?organizationPartyId=company and accounting/control/ListGlAccountOrganization These are the 2 places where the createGlAccountOrganization service is called. Just a bet so far... was (Author: jacques.le.roux): PLease try accounting/control/AssignGlAccount?organizationPartyId=company and accounting/control/ListGlAccountOrganization > GlAccountOrganizations manually added using accounting forms do not appear on > trial report because fromDate gets set to NULL > > > Key: OFBIZ-5938 > URL: https://issues.apache.org/jira/browse/OFBIZ-5938 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: Release Branch 14.12, Trunk >Reporter: Christian Carlow >Assignee: Jacques Le Roux >Priority: Minor > Fix For: 14.12.01, 15.12.01 > > Attachments: OFBIZ-5938.patch > > > To reproduce: > 1. Manually assign a glAccount to an organization (Accounting->Global GL > Settings->Chart Of Accounts->Assign Gl Account or Accounting->Organization GL > Settings->Setup->Chart of Accounts) > 2. Perform operations that create transactions for the organizations > glAccount > 3. Run the Accounting->Organization GL Settings->Accounting->Reports->Trial > Balance > Notice that the glAccountId assigned in step 1 is not listed in the results. > This is due to TrialBalance.groovy applying a fromDate filter to > GlAccountOrganizationAndClass which is not set in step 1. Updating > glAccountOrganization fromDate to something within the trial balance range > resolves the problem. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-5938) GlAccountOrganizations manually added using accounting forms do not appear on trial report because fromDate gets set to NULL
[
https://issues.apache.org/jira/browse/OFBIZ-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203753#comment-16203753
]
Rajesh Kumar Mallah commented on OFBIZ-5938:
the change in accounting/control/AssignGlAccount?organizationPartyId=company
does produce correct result. But accounting/control/ListGlAccountOrganization
remains
unchanged.
{{
select gl_account_id,organization_party_id,role_type_id,from_date,
last_updated_stamp from gl_account_organization where
organization_party_id='1' order by last_updated_stamp desc limit 10;
gl_account_id | organization_party_id | role_type_id | from_date
| last_updated_stamp
---+---+--+---+---
999 | 1 | | 2017-10-13
21:28:25+05:30 | 2017-10-13 21:28:48.691+05:30
6152545 | 1 | |
| 2017-10-13 20:55:11.977+05:30
2051500 | 1 | |
| 2017-10-13 20:45:45.531+05:30
1502000 | 1 | | 2001-01-01
00:00:00+05:30 | 2017-10-13 16:51:34.21+05:30
}}
> GlAccountOrganizations manually added using accounting forms do not appear on
> trial report because fromDate gets set to NULL
>
>
> Key: OFBIZ-5938
> URL: https://issues.apache.org/jira/browse/OFBIZ-5938
> Project: OFBiz
> Issue Type: Bug
> Components: accounting
>Affects Versions: Release Branch 14.12, Trunk
>Reporter: Christian Carlow
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: 14.12.01, 15.12.01
>
> Attachments: OFBIZ-5938.patch
>
>
> To reproduce:
> 1. Manually assign a glAccount to an organization (Accounting->Global GL
> Settings->Chart Of Accounts->Assign Gl Account or Accounting->Organization GL
> Settings->Setup->Chart of Accounts)
> 2. Perform operations that create transactions for the organizations
> glAccount
> 3. Run the Accounting->Organization GL Settings->Accounting->Reports->Trial
> Balance
> Notice that the glAccountId assigned in step 1 is not listed in the results.
> This is due to TrialBalance.groovy applying a fromDate filter to
> GlAccountOrganizationAndClass which is not set in step 1. Updating
> glAccountOrganization fromDate to something within the trial balance range
> resolves the problem.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (OFBIZ-5938) GlAccountOrganizations manually added using accounting forms do not appear on trial report because fromDate gets set to NULL
[
https://issues.apache.org/jira/browse/OFBIZ-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203753#comment-16203753
]
Rajesh Kumar Mallah edited comment on OFBIZ-5938 at 10/13/17 4:02 PM:
--
the change in accounting/control/AssignGlAccount?organizationPartyId=company
does produce correct result. But accounting/control/ListGlAccountOrganization
remains
unchanged.
was (Author: rmallah):
the change in accounting/control/AssignGlAccount?organizationPartyId=company
does produce correct result. But accounting/control/ListGlAccountOrganization
remains
unchanged.
{{
select gl_account_id,organization_party_id,role_type_id,from_date,
last_updated_stamp from gl_account_organization where
organization_party_id='1' order by last_updated_stamp desc limit 10;
gl_account_id | organization_party_id | role_type_id | from_date
| last_updated_stamp
---+---+--+---+---
999 | 1 | | 2017-10-13
21:28:25+05:30 | 2017-10-13 21:28:48.691+05:30
6152545 | 1 | |
| 2017-10-13 20:55:11.977+05:30
2051500 | 1 | |
| 2017-10-13 20:45:45.531+05:30
1502000 | 1 | | 2001-01-01
00:00:00+05:30 | 2017-10-13 16:51:34.21+05:30
}}
> GlAccountOrganizations manually added using accounting forms do not appear on
> trial report because fromDate gets set to NULL
>
>
> Key: OFBIZ-5938
> URL: https://issues.apache.org/jira/browse/OFBIZ-5938
> Project: OFBiz
> Issue Type: Bug
> Components: accounting
>Affects Versions: Release Branch 14.12, Trunk
>Reporter: Christian Carlow
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: 14.12.01, 15.12.01
>
> Attachments: OFBIZ-5938.patch
>
>
> To reproduce:
> 1. Manually assign a glAccount to an organization (Accounting->Global GL
> Settings->Chart Of Accounts->Assign Gl Account or Accounting->Organization GL
> Settings->Setup->Chart of Accounts)
> 2. Perform operations that create transactions for the organizations
> glAccount
> 3. Run the Accounting->Organization GL Settings->Accounting->Reports->Trial
> Balance
> Notice that the glAccountId assigned in step 1 is not listed in the results.
> This is due to TrialBalance.groovy applying a fromDate filter to
> GlAccountOrganizationAndClass which is not set in step 1. Updating
> glAccountOrganization fromDate to something within the trial balance range
> resolves the problem.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (OFBIZ-5938) GlAccountOrganizations manually added using accounting forms do not appear on trial report because fromDate gets set to NULL
[
https://issues.apache.org/jira/browse/OFBIZ-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203753#comment-16203753
]
Rajesh Kumar Mallah edited comment on OFBIZ-5938 at 10/13/17 4:02 PM:
--
the change in accounting/control/AssignGlAccount?organizationPartyId=company
does produce correct result. But accounting/control/ListGlAccountOrganization
remains
unchanged.
{{
select gl_account_id,organization_party_id,role_type_id,from_date,
last_updated_stamp from gl_account_organization where
organization_party_id='1' order by last_updated_stamp desc limit 10;
gl_account_id | organization_party_id | role_type_id | from_date
| last_updated_stamp
---+---+--+---+---
999 | 1 | | 2017-10-13
21:28:25+05:30 | 2017-10-13 21:28:48.691+05:30
6152545 | 1 | |
| 2017-10-13 20:55:11.977+05:30
2051500 | 1 | |
| 2017-10-13 20:45:45.531+05:30
1502000 | 1 | | 2001-01-01
00:00:00+05:30 | 2017-10-13 16:51:34.21+05:30
}}
was (Author: rmallah):
the change in accounting/control/AssignGlAccount?organizationPartyId=company
does produce correct result. But accounting/control/ListGlAccountOrganization
remains
unchanged.
{{
select gl_account_id,organization_party_id,role_type_id,from_date,
last_updated_stamp from gl_account_organization where
organization_party_id='1' order by last_updated_stamp desc limit 10;
gl_account_id | organization_party_id | role_type_id | from_date
| last_updated_stamp
---+---+--+---+---
999 | 1 | | 2017-10-13
21:28:25+05:30 | 2017-10-13 21:28:48.691+05:30
6152545 | 1 | |
| 2017-10-13 20:55:11.977+05:30
2051500 | 1 | |
| 2017-10-13 20:45:45.531+05:30
1502000 | 1 | | 2001-01-01
00:00:00+05:30 | 2017-10-13 16:51:34.21+05:30
}}
> GlAccountOrganizations manually added using accounting forms do not appear on
> trial report because fromDate gets set to NULL
>
>
> Key: OFBIZ-5938
> URL: https://issues.apache.org/jira/browse/OFBIZ-5938
> Project: OFBiz
> Issue Type: Bug
> Components: accounting
>Affects Versions: Release Branch 14.12, Trunk
>Reporter: Christian Carlow
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: 14.12.01, 15.12.01
>
> Attachments: OFBIZ-5938.patch
>
>
> To reproduce:
> 1. Manually assign a glAccount to an organization (Accounting->Global GL
> Settings->Chart Of Accounts->Assign Gl Account or Accounting->Organization GL
> Settings->Setup->Chart of Accounts)
> 2. Perform operations that create transactions for the organizations
> glAccount
> 3. Run the Accounting->Organization GL Settings->Accounting->Reports->Trial
> Balance
> Notice that the glAccountId assigned in step 1 is not listed in the results.
> This is due to TrialBalance.groovy applying a fromDate filter to
> GlAccountOrganizationAndClass which is not set in step 1. Updating
> glAccountOrganization fromDate to something within the trial balance range
> resolves the problem.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OFBIZ-9841) Implement AutoCloseable interface in SQLProcessor Class
[ https://issues.apache.org/jira/browse/OFBIZ-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pradhan Yash Sharma updated OFBIZ-9841: --- Issue Type: Improvement (was: Bug) > Implement AutoCloseable interface in SQLProcessor Class > --- > > Key: OFBIZ-9841 > URL: https://issues.apache.org/jira/browse/OFBIZ-9841 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Pradhan Yash Sharma >Assignee: Pradhan Yash Sharma >Priority: Trivial > Fix For: Trunk > > Attachments: OFBIZ-9841.patch, OFBIZ-9841.patch > > > Implement SQLProcessor class with the AutoCloseable interface. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-5938) GlAccountOrganizations manually added using accounting forms do not appear on trial report because fromDate gets set to NULL
[ https://issues.apache.org/jira/browse/OFBIZ-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203769#comment-16203769 ] Jacques Le Roux commented on OFBIZ-5938: Don't you see a field to enter a from data in accounting/control/ListGlAccountOrganization ? If you see it, try adding bq. 901000 FEDERAL INCOME TAX INCOME TAX \[90] > GlAccountOrganizations manually added using accounting forms do not appear on > trial report because fromDate gets set to NULL > > > Key: OFBIZ-5938 > URL: https://issues.apache.org/jira/browse/OFBIZ-5938 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: Release Branch 14.12, Trunk >Reporter: Christian Carlow >Assignee: Jacques Le Roux >Priority: Minor > Fix For: 14.12.01, 15.12.01 > > Attachments: OFBIZ-5938.patch > > > To reproduce: > 1. Manually assign a glAccount to an organization (Accounting->Global GL > Settings->Chart Of Accounts->Assign Gl Account or Accounting->Organization GL > Settings->Setup->Chart of Accounts) > 2. Perform operations that create transactions for the organizations > glAccount > 3. Run the Accounting->Organization GL Settings->Accounting->Reports->Trial > Balance > Notice that the glAccountId assigned in step 1 is not listed in the results. > This is due to TrialBalance.groovy applying a fromDate filter to > GlAccountOrganizationAndClass which is not set in step 1. Updating > glAccountOrganization fromDate to something within the trial balance range > resolves the problem. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OFBIZ-9841) Implement AutoCloseable interface in SQLProcessor Class
[ https://issues.apache.org/jira/browse/OFBIZ-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pradhan Yash Sharma updated OFBIZ-9841: --- Priority: Trivial (was: Critical) > Implement AutoCloseable interface in SQLProcessor Class > --- > > Key: OFBIZ-9841 > URL: https://issues.apache.org/jira/browse/OFBIZ-9841 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Pradhan Yash Sharma >Assignee: Pradhan Yash Sharma >Priority: Trivial > Fix For: Trunk > > Attachments: OFBIZ-9841.patch, OFBIZ-9841.patch > > > Implement SQLProcessor class with the AutoCloseable interface. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9841) Implement AutoCloseable interface in SQLProcessor Class
[ https://issues.apache.org/jira/browse/OFBIZ-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203774#comment-16203774 ] Pradhan Yash Sharma commented on OFBIZ-9841: Thank you, Jacques, Yes, I agree with you, I have updated the ticket and closed it. > Implement AutoCloseable interface in SQLProcessor Class > --- > > Key: OFBIZ-9841 > URL: https://issues.apache.org/jira/browse/OFBIZ-9841 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Pradhan Yash Sharma >Assignee: Pradhan Yash Sharma >Priority: Trivial > Fix For: Trunk > > Attachments: OFBIZ-9841.patch, OFBIZ-9841.patch > > > Implement SQLProcessor class with the AutoCloseable interface. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (OFBIZ-9841) Implement AutoCloseable interface in SQLProcessor Class
[ https://issues.apache.org/jira/browse/OFBIZ-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pradhan Yash Sharma closed OFBIZ-9841. -- Resolution: Fixed Closing this ticket. > Implement AutoCloseable interface in SQLProcessor Class > --- > > Key: OFBIZ-9841 > URL: https://issues.apache.org/jira/browse/OFBIZ-9841 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Pradhan Yash Sharma >Assignee: Pradhan Yash Sharma >Priority: Trivial > Fix For: Trunk > > Attachments: OFBIZ-9841.patch, OFBIZ-9841.patch > > > Implement SQLProcessor class with the AutoCloseable interface. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-5938) GlAccountOrganizations manually added using accounting forms do not appear on trial report because fromDate gets set to NULL
[
https://issues.apache.org/jira/browse/OFBIZ-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203793#comment-16203793
]
Rajesh Kumar Mallah commented on OFBIZ-5938:
I did below change:
{noformat}
git diff applications/accounting/widget/GlobalGlAccountsForms.xml
applications/accounting/widget/GlSetupForms.xml
diff --git a/applications/accounting/widget/GlSetupForms.xml
b/applications/accounting/widget/GlSetupForms.xml
index aae00b3..b8a3a2e 100644
--- a/applications/accounting/widget/GlSetupForms.xml
+++ b/applications/accounting/widget/GlSetupForms.xml
@@ -81,6 +81,7 @@ under the License.
+
diff --git a/applications/accounting/widget/GlobalGlAccountsForms.xml
b/applications/accounting/widget/GlobalGlAccountsForms.xml
index 0d568a5..1e69dd3 100644
--- a/applications/accounting/widget/GlobalGlAccountsForms.xml
+++ b/applications/accounting/widget/GlobalGlAccountsForms.xml
@@ -62,6 +62,7 @@ under the License.
+
==
{noformat}
!https://drive.google.com/file/d/0B4yfAVMLmbQxTF9mcmxOdUFtbVk/view?usp=sharing!
> GlAccountOrganizations manually added using accounting forms do not appear on
> trial report because fromDate gets set to NULL
>
>
> Key: OFBIZ-5938
> URL: https://issues.apache.org/jira/browse/OFBIZ-5938
> Project: OFBiz
> Issue Type: Bug
> Components: accounting
>Affects Versions: Release Branch 14.12, Trunk
>Reporter: Christian Carlow
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: 14.12.01, 15.12.01
>
> Attachments: OFBIZ-5938.patch
>
>
> To reproduce:
> 1. Manually assign a glAccount to an organization (Accounting->Global GL
> Settings->Chart Of Accounts->Assign Gl Account or Accounting->Organization GL
> Settings->Setup->Chart of Accounts)
> 2. Perform operations that create transactions for the organizations
> glAccount
> 3. Run the Accounting->Organization GL Settings->Accounting->Reports->Trial
> Balance
> Notice that the glAccountId assigned in step 1 is not listed in the results.
> This is due to TrialBalance.groovy applying a fromDate filter to
> GlAccountOrganizationAndClass which is not set in step 1. Updating
> glAccountOrganization fromDate to something within the trial balance range
> resolves the problem.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (OFBIZ-5938) GlAccountOrganizations manually added using accounting forms do not appear on trial report because fromDate gets set to NULL
[
https://issues.apache.org/jira/browse/OFBIZ-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203793#comment-16203793
]
Rajesh Kumar Mallah edited comment on OFBIZ-5938 at 10/13/17 4:23 PM:
--
I did below change:
{noformat}
git diff applications/accounting/widget/GlobalGlAccountsForms.xml
applications/accounting/widget/GlSetupForms.xml
diff --git a/applications/accounting/widget/GlSetupForms.xml
b/applications/accounting/widget/GlSetupForms.xml
index aae00b3..b8a3a2e 100644
--- a/applications/accounting/widget/GlSetupForms.xml
+++ b/applications/accounting/widget/GlSetupForms.xml
@@ -81,6 +81,7 @@ under the License.
+
diff --git a/applications/accounting/widget/GlobalGlAccountsForms.xml
b/applications/accounting/widget/GlobalGlAccountsForms.xml
index 0d568a5..1e69dd3 100644
--- a/applications/accounting/widget/GlobalGlAccountsForms.xml
+++ b/applications/accounting/widget/GlobalGlAccountsForms.xml
@@ -62,6 +62,7 @@ under the License.
+
==
{noformat}
https://drive.google.com/file/d/0B4yfAVMLmbQxTF9mcmxOdUFtbVk/view?usp=sharing
was (Author: rmallah):
I did below change:
{noformat}
git diff applications/accounting/widget/GlobalGlAccountsForms.xml
applications/accounting/widget/GlSetupForms.xml
diff --git a/applications/accounting/widget/GlSetupForms.xml
b/applications/accounting/widget/GlSetupForms.xml
index aae00b3..b8a3a2e 100644
--- a/applications/accounting/widget/GlSetupForms.xml
+++ b/applications/accounting/widget/GlSetupForms.xml
@@ -81,6 +81,7 @@ under the License.
+
diff --git a/applications/accounting/widget/GlobalGlAccountsForms.xml
b/applications/accounting/widget/GlobalGlAccountsForms.xml
index 0d568a5..1e69dd3 100644
--- a/applications/accounting/widget/GlobalGlAccountsForms.xml
+++ b/applications/accounting/widget/GlobalGlAccountsForms.xml
@@ -62,6 +62,7 @@ under the License.
+
==
{noformat}
!https://drive.google.com/file/d/0B4yfAVMLmbQxTF9mcmxOdUFtbVk/view?usp=sharing!
> GlAccountOrganizations manually added using accounting forms do not appear on
> trial report because fromDate gets set to NULL
>
>
> Key: OFBIZ-5938
> URL: https://issues.apache.org/jira/browse/OFBIZ-5938
> Project: OFBiz
> Issue Type: Bug
> Components: accounting
>Affects Versions: Release Branch 14.12, Trunk
>Reporter: Christian Carlow
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: 14.12.01, 15.12.01
>
> Attachments: OFBIZ-5938.patch
>
>
> To reproduce:
> 1. Manually assign a glAccount to an organization (Accounting->Global GL
> Settings->Chart Of Accounts->Assign Gl Account or Accounting->Organization GL
> Settings->Setup->Chart of Accounts)
> 2. Perform operations that create transactions for the organizations
> glAccount
> 3. Run the Accounting->Organization GL Settings->Accounting->Reports->Trial
> Balance
> Notice that the glAccountId assigned in step 1 is not listed in the results.
> This is due to TrialBalance.groovy applying a fromDate filter to
> GlAccountOrganizationAndClass which is not set in step 1. Updating
> glAccountOrganization fromDate to something within the trial balance range
> resolves the problem.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OFBIZ-5938) GlAccountOrganizations manually added using accounting forms do not appear on trial report because fromDate gets set to NULL
[ https://issues.apache.org/jira/browse/OFBIZ-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203797#comment-16203797 ] Rajesh Kumar Mallah commented on OFBIZ-5938: pls note i am not applying on trunk , i use released versions. eg this is: 16.11.03 > GlAccountOrganizations manually added using accounting forms do not appear on > trial report because fromDate gets set to NULL > > > Key: OFBIZ-5938 > URL: https://issues.apache.org/jira/browse/OFBIZ-5938 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: Release Branch 14.12, Trunk >Reporter: Christian Carlow >Assignee: Jacques Le Roux >Priority: Minor > Fix For: 14.12.01, 15.12.01 > > Attachments: OFBIZ-5938.patch > > > To reproduce: > 1. Manually assign a glAccount to an organization (Accounting->Global GL > Settings->Chart Of Accounts->Assign Gl Account or Accounting->Organization GL > Settings->Setup->Chart of Accounts) > 2. Perform operations that create transactions for the organizations > glAccount > 3. Run the Accounting->Organization GL Settings->Accounting->Reports->Trial > Balance > Notice that the glAccountId assigned in step 1 is not listed in the results. > This is due to TrialBalance.groovy applying a fromDate filter to > GlAccountOrganizationAndClass which is not set in step 1. Updating > glAccountOrganization fromDate to something within the trial balance range > resolves the problem. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (OFBIZ-5938) GlAccountOrganizations manually added using accounting forms do not appear on trial report because fromDate gets set to NULL
[ https://issues.apache.org/jira/browse/OFBIZ-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16196031#comment-16196031 ] Rajesh Kumar Mallah edited comment on OFBIZ-5938 at 10/13/17 5:19 PM: -- I faced this issue with 16.11 also and had to manually update using SQL update gl_account_organization set from_date='2001-01-01 00:00:00+05:30' where organization_party_id='1'; steps summary: 1) create a new organisation 2) assign gl_accounts to it 3) carry out some transations 4) try checking trial balance. it shall display cr:0 dr:0 after updating the 'from_date' it worked as expected. regds mallah. was (Author: rmallah): I faced this issue with 11.6 also and had to manually update using SQL update gl_account_organization set from_date='2001-01-01 00:00:00+05:30' where organization_party_id='1'; steps summary: 1) create a new organisation 2) assign gl_accounts to it 3) carry out some transations 4) try checking trial balance. it shall display cr:0 dr:0 after updating the 'from_date' it worked as expected. regds mallah. > GlAccountOrganizations manually added using accounting forms do not appear on > trial report because fromDate gets set to NULL > > > Key: OFBIZ-5938 > URL: https://issues.apache.org/jira/browse/OFBIZ-5938 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: Release Branch 14.12, Trunk >Reporter: Christian Carlow >Assignee: Jacques Le Roux >Priority: Minor > Fix For: 14.12.01, 15.12.01 > > Attachments: OFBIZ-5938.patch > > > To reproduce: > 1. Manually assign a glAccount to an organization (Accounting->Global GL > Settings->Chart Of Accounts->Assign Gl Account or Accounting->Organization GL > Settings->Setup->Chart of Accounts) > 2. Perform operations that create transactions for the organizations > glAccount > 3. Run the Accounting->Organization GL Settings->Accounting->Reports->Trial > Balance > Notice that the glAccountId assigned in step 1 is not listed in the results. > This is due to TrialBalance.groovy applying a fromDate filter to > GlAccountOrganizationAndClass which is not set in step 1. Updating > glAccountOrganization fromDate to something within the trial balance range > resolves the problem. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9826) Add ability to disable seca rule
[ https://issues.apache.org/jira/browse/OFBIZ-9826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203942#comment-16203942 ] Deepak Dixit commented on OFBIZ-9826: - Thanks Jacques and Michael for review, I have to verify one more scenario, once it verified I'll commit it. I'll try to commit it tomorrow. > Add ability to disable seca rule > - > > Key: OFBIZ-9826 > URL: https://issues.apache.org/jira/browse/OFBIZ-9826 > Project: OFBiz > Issue Type: Improvement >Reporter: Deepak Dixit >Assignee: Deepak Dixit > Attachments: OFBIZ-9826.patch > > > We have enabled flag in ServiceEcaRule class, if its set false then seca rule > will not be execute. > But there is not way to disable seca. > We can add enabled flag in SECA definition to disable the existing seca rule. > Here is the proposal: > - Add new attribute on seca tag named enabled > - Default value will be true for this. > - If user want to disable existing OOTB seca rule, then user can define same > rule in custom component and set the enabled=false > - Need some changes in code to honor the enabled attribute while loading seca > rule. > Also as per current flow if same seca rule is define more then once, system > will execute all the rule, ideally it should not execute same rule (same > rule, condition and action) if its defined more than one. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (OFBIZ-9674) Update build.gradle to the latest dependencies
[
https://issues.apache.org/jira/browse/OFBIZ-9674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl closed OFBIZ-9674.
Resolution: Implemented
Fix Version/s: Upcoming Release
Thanks Julian,
your patch is in trunk r1812161.
> Update build.gradle to the latest dependencies
> --
>
> Key: OFBIZ-9674
> URL: https://issues.apache.org/jira/browse/OFBIZ-9674
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Michael Brohl
>Assignee: Michael Brohl
>Priority: Minor
> Fix For: Upcoming Release
>
> Attachments: OFBIZ-9674_Update_buildgradle.patch
>
>
> I wondered how up-to-date our project dependencies are and searched for an
> efficient way how to check this. I found the gradle-versions-plugin [1] which
> analyzes the dependencies and checks if there are newer versions available.
> I ran the check with
> {code:java}
> ./gradlew dependencyUpdates -Drevision=release
> {code}
> and got the following result:
>
> : Project Dependency Updates (report to plain text file)
>
> The following dependencies are using the latest release version:
> - net.sf.barcode4j:barcode4j:2.1
> - net.sf.barcode4j:barcode4j-fop-ext:2.1
> - org.codeartisans.thirdparties.swing:batik-all:1.8pre-r1084380
> - org.apache.commons:commons-collections4:4.1
> - com.googlecode.ez-vcard:ez-vcard:0.9.10
> - org.apache.geronimo.specs:geronimo-jms_1.1_spec:1.1.1
> - org.apache.geronimo.components:geronimo-transaction:3.1.4
> - at.bxm.gradleplugins:gradle-svntools-plugin:2.2.1
> - com.github.ben-manes:gradle-versions-plugin:0.15.0
> - org.hamcrest:hamcrest-all:1.3
> - net.fortuna.ical4j:ical4j:1.0-rc3-atlassian-11
> - javax.el:javax.el-api:3.0.1-b04
> - de.odysseus.juel:juel-impl:2.2.7
> - de.odysseus.juel:juel-spi:2.2.7
> - junit:junit:4.12
> - oro:oro:2.0.8
> - apache-xerces:xercesImpl:2.9.1
> The following dependencies exceed the version found at the release revision
> level:
> - com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer
> [20160628.1 <- 1.1]
> The following dependencies have later release versions:
> - org.apache.ant:ant-junit [1.9.0 -> 1.10.1]
> - org.apache.ant:ant-junit [1.9.7 -> 1.10.1]
> - org.apache.axis2:axis2-kernel [1.7.1 -> 1.7.6]
> - org.apache.axis2:axis2-transport-http [1.7.1 -> 1.7.6]
> - org.apache.axis2:axis2-transport-local [1.7.1 -> 1.7.6]
> - commons-cli:commons-cli [1.3.1 -> 1.4]
> - org.apache.commons:commons-csv [1.1 -> 1.5]
> - org.apache.commons:commons-dbcp2 [2.1 -> 2.1.1]
> - commons-net:commons-net [3.3 -> 3.6]
> - commons-validator:commons-validator [1.5.1 -> 1.6]
> - com.googlecode.concurrentlinkedhashmap:concurrentlinkedhashmap-lru [1.0 ->
> 1.4.2]
> - com.google.zxing:core [3.2.1 -> 3.3.0]
> - org.apache.derby:derby [10.11.1.1 -> 10.13.1.1]
> - org.owasp.esapi:esapi [2.1.0 -> 2.1.0.1]
> - org.apache.xmlgraphics:fop [2.1 -> 2.2]
> - org.freemarker:freemarker [2.3.25-incubating -> 2.3.26-incubating]
> - org.codehaus.groovy:groovy-all [2.4.12 -> 2.5.0-beta-1]
> - org.apache.httpcomponents:httpclient-cache [4.4.1 -> 4.5.3]
> - com.ibm.icu:icu4j [57.1 -> 59.1]
> - com.lowagie:itext [2.1.7 -> 4.2.2]
> - org.zapodot:jackson-databind-java-optional [2.4.2 -> 2.6.1]
> - com.sun.mail:javax.mail [1.5.1 -> 1.6.0]
> - javax.servlet:javax.servlet-api [3.1.0 -> 4.0.0]
> - javax.servlet.jsp:javax.servlet.jsp-api [2.3.0 -> 2.3.2-b02]
> - junit:junit-dep [4.10 -> 4.11]
> - com.googlecode.libphonenumber:libphonenumber [8.6.0 -> 8.8.0]
> - org.apache.logging.log4j:log4j-1.2-api [2.6.2 -> 2.9.0]
> - org.apache.logging.log4j:log4j-api [2.6.2 -> 2.9.0]
> - org.apache.logging.log4j:log4j-core [2.6.2 -> 2.9.0]
> - org.apache.logging.log4j:log4j-jul [2.6.2 -> 2.9.0]
> - org.apache.logging.log4j:log4j-slf4j-impl [2.6.2 -> 2.9.0]
> - org.mockito:mockito-core [1.10.19 -> 2.9.0]
> - org.apache.poi:poi [3.14 -> 3.17-beta1]
> - org.apache.shiro:shiro-core [1.3.0 -> 1.4.0]
> - org.springframework:spring-test [4.2.3.RELEASE -> 4.3.10.RELEASE]
> - org.apache.tika:tika-core [1.12 -> 1.16]
> - org.apache.tika:tika-parsers [1.12 -> 1.16]
> - org.apache.tomcat:tomcat-catalina [8.5.16 -> 9.0.0.M26]
> - org.apache.tomcat:tomcat-catalina-ha [8.5.16 -> 9.0.0.M25]
> - org.apache.tomcat:tomcat-jasper [8.5.16 -> 9.0.0.M26]
> - org.apache.tomcat:tomcat-tribes [8.5.16 -> 9.0.0.M25]
> - wsdl4j:wsdl4j [1.6.2 -> 1.6.3]
> - org.apache.xmlrpc:xmlrpc-client [3.1.2 -> 3.1.3]
> - org.apache.xmlrpc:xmlrpc-server [3.1.2 -> 3.1.3]
> - com.thoughtworks.xstream:xstream [1.4.9 -> 1.4.10]
> Failed to determine the latest version for the following dependencies (use
> --
[jira] [Closed] (OFBIZ-9693) [FB] Package org.apache.ofbiz.service.semaphore
[ https://issues.apache.org/jira/browse/OFBIZ-9693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl closed OFBIZ-9693. Resolution: Implemented Fix Version/s: Upcoming Release Thanks Dennis, your patch is in trunk r1812163. > [FB] Package org.apache.ofbiz.service.semaphore > --- > > Key: OFBIZ-9693 > URL: https://issues.apache.org/jira/browse/OFBIZ-9693 > Project: OFBiz > Issue Type: Sub-task > Components: framework >Reporter: Dennis Balkir >Assignee: Michael Brohl >Priority: Minor > Fix For: Upcoming Release > > Attachments: > OFBIZ-9693_org.apache.ofbiz.service.semaphore_bugfixes.patch > > > - ServiceSemaphore.java:77, IS2_INCONSISTENT_SYNC > IS: Inconsistent synchronization of > org.apache.ofbiz.service.semaphore.ServiceSemaphore.lock; locked 40% of time > The fields of this class appear to be accessed inconsistently with respect to > synchronization. This bug report indicates that the bug pattern detector > judged that > The class contains a mix of locked and unlocked accesses, > The class is not annotated as javax.annotation.concurrent.NotThreadSafe, > At least one locked access was performed by one of the class's own methods, > and > The number of unsynchronized field accesses (reads and writes) was no more > than one third of all accesses, with writes being weighed twice as high as > reads > A typical bug matching this bug pattern is forgetting to synchronize one of > the methods in a class that is intended to be thread-safe. > You can select the nodes labeled "Unsynchronized access" to show the code > locations where the detector believed that a field was accessed without > synchronization. > Note that there are various sources of inaccuracy in this detector; for > example, the detector cannot statically detect all situations in which a lock > is held. Also, even when the detector is accurate in distinguishing locked > vs. unlocked accesses, the code in question may still be correct. > - ServiceSemaphore.java:176, UC_USELESS_CONDITION > Condition has no effect > This condition always produces the same result as the value of the involved > variable was narrowed before. Probably something else was meant or condition > can be removed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OFBIZ-9700) [FB] Package org.apache.ofbiz.base.util.string
[
https://issues.apache.org/jira/browse/OFBIZ-9700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl reassigned OFBIZ-9700:
Assignee: Michael Brohl
> [FB] Package org.apache.ofbiz.base.util.string
> --
>
> Key: OFBIZ-9700
> URL: https://issues.apache.org/jira/browse/OFBIZ-9700
> Project: OFBiz
> Issue Type: Sub-task
> Components: base
>Affects Versions: Trunk
>Reporter: Julian Leichert
>Assignee: Michael Brohl
>Priority: Minor
> Attachments:
> OFBIZ-9700_org.apache.ofbiz.base.util.string_bugfixes.patch
>
>
> FlexibleStringExpander.java:245, NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT
> - NP:
> org.apache.ofbiz.base.util.string.FlexibleStringExpander$Key.equals(Object)
> does not check for null argument
> This implementation of equals(Object) violates the contract defined by
> java.lang.Object.equals() because it does not check for null being passed as
> the argument. All equals() methods should return false if passed a null value.
> FlexibleStringExpander.java:444, REC_CATCH_EXCEPTION
> - REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.base.util.string.FlexibleStringExpander.expandString(Map,
> TimeZone, Locale)
> This method uses a try-catch block that catches Exception objects, but
> Exception is not thrown within the try block, and RuntimeException is not
> explicitly caught. It is a common bug pattern to say try { ... } catch
> (Exception e) { something } as a shorthand for catching a number of types of
> exception each of whose catch blocks is identical, but this construct also
> accidentally catches RuntimeException as well, masking potential bugs.
> A better approach is to either explicitly catch the specific exceptions that
> are thrown, or to explicitly catch RuntimeException exception, rethrow it,
> and then catch all non-Runtime Exceptions, as shown below:
> try {
> ...
> } catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
> ... deal with all non-runtime exceptions ...
> }
> FlexibleStringExpander.java:540, SE_NO_SERIALVERSIONID
> - SnVI:
> org.apache.ofbiz.base.util.string.FlexibleStringExpander$ConstSimpleElem is
> Serializable; consider declaring a serialVersionUID
> This class implements the Serializable interface, but does not define a
> serialVersionUID field. A change as simple as adding a reference to a .class
> object will add synthetic fields to the class, which will unfortunately
> change the implicit serialVersionUID (e.g., adding a reference to
> String.class will generate a static field class$java$lang$String). Also,
> different source code to bytecode compilers may use different naming
> conventions for synthetic variables generated for references to class objects
> or inner classes. To ensure interoperability of Serializable across versions,
> consider adding an explicit serialVersionUID.
> FlexibleStringExpander.java:567, SE_NO_SERIALVERSIONID
> - SnVI:
> org.apache.ofbiz.base.util.string.FlexibleStringExpander$ConstOffsetElem is
> Serializable; consider declaring a serialVersionUID
> This class implements the Serializable interface, but does not define a
> serialVersionUID field. A change as simple as adding a reference to a .class
> object will add synthetic fields to the class, which will unfortunately
> change the implicit serialVersionUID (e.g., adding a reference to
> String.class will generate a static field class$java$lang$String). Also,
> different source code to bytecode compilers may use different naming
> conventions for synthetic variables generated for references to class objects
> or inner classes. To ensure interoperability of Serializable across versions,
> consider adding an explicit serialVersionUID.
> FlexibleStringExpander.java:587, SE_NO_SERIALVERSIONID
> - SnVI: org.apache.ofbiz.base.util.string.FlexibleStringExpander$CurrElem is
> Serializable; consider declaring a serialVersionUID
> This class implements the Serializable interface, but does not define a
> serialVersionUID field. A change as simple as adding a reference to a .class
> object will add synthetic fields to the class, which will unfortunately
> change the implicit serialVersionUID (e.g., adding a reference to
> String.class will generate a static field class$java$lang$String). Also,
> different source code to bytecode compilers may use different naming
> conventions for synthetic variables generated for references to class objects
> or inner classes. To ensure interoperability of Serializable across versions,
> consider adding an explicit serialVersionUID.
> FlexibleStringExpander.java:619, SE_NO_SERIALVERSIONID
> - SnVI: org.apache.ofbiz.base.util.string.FlexibleStringExpander$Elements is
> Serializable; consider declaring a serialVersionUID
> This class i
[jira] [Assigned] (OFBIZ-9702) [FB] Package org.apache.ofbiz.widget.renderer.macro
[
https://issues.apache.org/jira/browse/OFBIZ-9702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl reassigned OFBIZ-9702:
Assignee: Michael Brohl
> [FB] Package org.apache.ofbiz.widget.renderer.macro
> ---
>
> Key: OFBIZ-9702
> URL: https://issues.apache.org/jira/browse/OFBIZ-9702
> Project: OFBiz
> Issue Type: Sub-task
> Components: ALL APPLICATIONS, ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Julian Leichert
>Assignee: Michael Brohl
>Priority: Minor
> Attachments:
> OFBIZ-9702_org.apache.ofbiz.widget.renderer.macro_bugfixes.patch
>
>
> MacroFormRenderer.java:237, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
> - RCN: Redundant nullcheck of fieldMap, which is known to be non-null in
> org.apache.ofbiz.widget.renderer.macro.MacroFormRenderer.renderDisplayField(Appendable,
> Map, ModelFormField$DisplayField)
> This method contains a redundant check of a known non-null value against the
> constant null.
> MacroFormRenderer.java:246, SBSC_USE_STRINGBUFFER_CONCATENATION
> - SBSC:
> org.apache.ofbiz.widget.renderer.macro.MacroFormRenderer.renderDisplayField(Appendable,
> Map, ModelFormField$DisplayField) concatenates strings using + in a loop
> The method seems to be building a String using concatenation in a loop. In
> each iteration, the String is converted to a StringBuffer/StringBuilder,
> appended to, and converted back to a String. This can lead to a cost
> quadratic in the number of iterations, as the growing string is recopied in
> each iteration.
> Better performance can be obtained by using a StringBuffer (or StringBuilder
> in Java 1.5) explicitly.
> For example:
> // This is bad
> String s = "";
> for (int i = 0; i < field.length; ++i) {
> s = s + field[i];
> }
> // This is better
> StringBuffer buf = new StringBuffer();
> for (int i = 0; i < field.length; ++i) {
> buf.append(field[i]);
> }
> String s = buf.toString();
> MacroFormRenderer.java:538, DM_BOXED_PRIMITIVE_FOR_PARSING
> - Bx: Boxing/unboxing to parse a primitive
> org.apache.ofbiz.widget.renderer.macro.MacroFormRenderer.renderDateTimeField(Appendable,
> Map, ModelFormField$DateTimeField)
> A boxed primitive is created from a String, just to extract the unboxed
> primitive value. It is more efficient to just call the static parseXXX method.
> MacroFormRenderer.java:1000, RV_RETURN_VALUE_IGNORED_NO_SIDE_EFFECT
> Return value of method without side effect is ignored
> This code calls a method and ignores the return value. However our analysis
> shows that the method (including its implementations in subclasses if any)
> does not produce any effect other than return value. Thus this call can be
> removed.
> We are trying to reduce the false positives as much as possible, but in some
> cases this warning might be wrong. Common false-positive cases include:
> - The method is designed to be overridden and produce a side effect in other
> projects which are out of the scope of the analysis.
> - The method is called to trigger the class loading which may have a side
> effect.
> - The method is called just to get some exception.
> If you feel that our assumption is incorrect, you can use a @CheckReturnValue
> annotation to instruct FindBugs that ignoring the return value of this method
> is acceptable.
> MacroFormRenderer.java:1062, RV_RETURN_VALUE_IGNORED_NO_SIDE_EFFECT,
> Priorität: Normal
> Return value of method without side effect is ignored
> This code calls a method and ignores the return value. However our analysis
> shows that the method (including its implementations in subclasses if any)
> does not produce any effect other than return value. Thus this call can be
> removed.
> We are trying to reduce the false positives as much as possible, but in some
> cases this warning might be wrong. Common false-positive cases include:
> - The method is designed to be overridden and produce a side effect in other
> projects which are out of the scope of the analysis.
> - The method is called to trigger the class loading which may have a side
> effect.
> - The method is called just to get some exception.
> If you feel that our assumption is incorrect, you can use a @CheckReturnValue
> annotation to instruct FindBugs that ignoring the return value of this method
> is acceptable.
> MacroFormRenderer.java:1275, DM_CONVERT_CASE, Priorität: Niedrig
> Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in
> org.apache.ofbiz.widget.renderer.macro.MacroFormRenderer.renderFieldTitle(Appendable,
> Map, ModelFormField)
> A String is being converted to upper or lowercase, using the platform's
> default encoding. This may result in improper conversions when used with
> international characters. Use the
> String.toUpperCase( Locale l )
> String.
[jira] [Assigned] (OFBIZ-9695) [FB] Package org.apache.ofbiz.widget.cache
[ https://issues.apache.org/jira/browse/OFBIZ-9695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl reassigned OFBIZ-9695: Assignee: Michael Brohl > [FB] Package org.apache.ofbiz.widget.cache > -- > > Key: OFBIZ-9695 > URL: https://issues.apache.org/jira/browse/OFBIZ-9695 > Project: OFBiz > Issue Type: Sub-task > Components: framework >Affects Versions: Trunk >Reporter: Dennis Balkir >Assignee: Michael Brohl >Priority: Minor > Attachments: OFBIZ-9695_org.apache.ofbiz.widget.cache_bugfixes.patch > > > - WidgetContextCacheKey.java:140, WMI_WRONG_MAP_ITERATOR > WMI: org.apache.ofbiz.widget.cache.WidgetContextCacheKey.toString() makes > inefficient use of keySet iterator instead of entrySet iterator > This method accesses the value of a Map entry, using a key that was retrieved > from a keySet iterator. It is more efficient to use an iterator on the > entrySet of the map, to avoid the Map.get(key) lookup. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OFBIZ-9706) [FB] Package org.apache.ofbiz.entity.test
[
https://issues.apache.org/jira/browse/OFBIZ-9706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl reassigned OFBIZ-9706:
Assignee: Michael Brohl
> [FB] Package org.apache.ofbiz.entity.test
> -
>
> Key: OFBIZ-9706
> URL: https://issues.apache.org/jira/browse/OFBIZ-9706
> Project: OFBiz
> Issue Type: Sub-task
> Components: ALL APPLICATIONS, ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Julian Leichert
>Assignee: Michael Brohl
>Priority: Minor
> Attachments: OFBIZ-9706_org.apache.ofbiz.entity.test_bugfixes.patch
>
>
> EntityQueryTestSuite.java:313, REC_CATCH_EXCEPTION
> - REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.entity.test.EntityQueryTestSuite.testQueryIterator()
> This method uses a try-catch block that catches Exception objects, but
> Exception is not thrown within the try block, and RuntimeException is not
> explicitly caught. It is a common bug pattern to say try { ... } catch
> (Exception e) { something } as a shorthand for catching a number of types of
> exception each of whose catch blocks is identical, but this construct also
> accidentally catches RuntimeException as well, masking potential bugs.
> A better approach is to either explicitly catch the specific exceptions that
> are thrown, or to explicitly catch RuntimeException exception, rethrow it,
> and then catch all non-Runtime Exceptions, as shown below:
> try {
> ...
> } catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
> ... deal with all non-runtime exceptions ...
> }
> EntityQueryTestSuite.java:348, REC_CATCH_EXCEPTION
> - REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.entity.test.EntityQueryTestSuite.testCursorForwardOnly()
> This method uses a try-catch block that catches Exception objects, but
> Exception is not thrown within the try block, and RuntimeException is not
> explicitly caught. It is a common bug pattern to say try { ... } catch
> (Exception e) { something } as a shorthand for catching a number of types of
> exception each of whose catch blocks is identical, but this construct also
> accidentally catches RuntimeException as well, masking potential bugs.
> A better approach is to either explicitly catch the specific exceptions that
> are thrown, or to explicitly catch RuntimeException exception, rethrow it,
> and then catch all non-Runtime Exceptions, as shown below:
> try {
> ...
> } catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
> ... deal with all non-runtime exceptions ...
> }
> EntityQueryTestSuite.java:383, REC_CATCH_EXCEPTION
> - REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.entity.test.EntityQueryTestSuite.testCursorScrollSensitive()
> This method uses a try-catch block that catches Exception objects, but
> Exception is not thrown within the try block, and RuntimeException is not
> explicitly caught. It is a common bug pattern to say try { ... } catch
> (Exception e) { something } as a shorthand for catching a number of types of
> exception each of whose catch blocks is identical, but this construct also
> accidentally catches RuntimeException as well, masking potential bugs.
> A better approach is to either explicitly catch the specific exceptions that
> are thrown, or to explicitly catch RuntimeException exception, rethrow it,
> and then catch all non-Runtime Exceptions, as shown below:
> try {
> ...
> } catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
> ... deal with all non-runtime exceptions ...
> }
> EntityQueryTestSuite.java:418, REC_CATCH_EXCEPTION
> - REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.entity.test.EntityQueryTestSuite.testCursorScrollInSensitive()
> This method uses a try-catch block that catches Exception objects, but
> Exception is not thrown within the try block, and RuntimeException is not
> explicitly caught. It is a common bug pattern to say try { ... } catch
> (Exception e) { something } as a shorthand for catching a number of types of
> exception each of whose catch blocks is identical, but this construct also
> accidentally catches RuntimeException as well, masking potential bugs.
> A better approach is to either explicitly catch the specific exceptions that
> are thrown, or to explicitly catch RuntimeException exception, rethrow it,
> and then catch all non-Runtime Exceptions, as shown below:
> try {
> ...
> } catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
> ... deal with all non-runtime exceptions ...
> }
> EntityTestSuite.java:462, DM_STRING_TOSTRING
> - Dm: org.apache.ofbiz.entity.test.EntityTestSuite.testCountViews() invokes
> toString() method on
[jira] [Assigned] (OFBIZ-9709) [FB] Package org.apache.ofbiz.service.job
[ https://issues.apache.org/jira/browse/OFBIZ-9709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl reassigned OFBIZ-9709: Assignee: Michael Brohl > [FB] Package org.apache.ofbiz.service.job > - > > Key: OFBIZ-9709 > URL: https://issues.apache.org/jira/browse/OFBIZ-9709 > Project: OFBiz > Issue Type: Sub-task > Components: framework >Affects Versions: Trunk >Reporter: Dennis Balkir >Assignee: Michael Brohl >Priority: Minor > Attachments: OFBIZ-9709_org.apache.ofbiz.service.job_bugfixes.patch > > > - AbstractJob.java:116, EI_EXPOSE_REP > EI: org.apache.ofbiz.service.job.AbstractJob.getStartTime() may expose > internal representation by returning AbstractJob.startTime > Returning a reference to a mutable object value stored in one of the object's > fields exposes the internal representation of the object. If instances are > accessed by untrusted code, and unchecked changes to the mutable object would > compromise security or other important properties, you will need to do > something different. Returning a new copy of the object is better approach in > many situations. > - GenericServiceJob.java:-1, SE_TRANSIENT_FIELD_NOT_RESTORED > Se: The field org.apache.ofbiz.service.job.GenericServiceJob.dctx is > transient but isn't set by deserialization > This class contains a field that is updated at multiple places in the class, > thus it seems to be part of the state of the class. However, since the field > is marked as transient and not set in readObject or readResolve, it will > contain the default value in any deserialized instance of the class. > - GenericServiceJob.java:-1, SE_TRANSIENT_FIELD_NOT_RESTORED > Se: The field org.apache.ofbiz.service.job.GenericServiceJob.requester is > transient but isn't set by deserialization > This class contains a field that is updated at multiple places in the class, > thus it seems to be part of the state of the class. However, since the field > is marked as transient and not set in readObject or readResolve, it will > contain the default value in any deserialized instance of the class. > - GenericServiceJob.java:37, SE_NO_SERIALVERSIONID > SnVI: org.apache.ofbiz.service.job.GenericServiceJob is Serializable; > consider declaring a serialVersionUID > This class implements the Serializable interface, but does not define a > serialVersionUID field. A change as simple as adding a reference to a .class > object will add synthetic fields to the class, which will unfortunately > change the implicit serialVersionUID (e.g., adding a reference to > String.class will generate a static field class$java$lang$String). Also, > different source code to bytecode compilers may use different naming > conventions for synthetic variables generated for references to class objects > or inner classes. To ensure interoperability of Serializable across versions, > consider adding an explicit serialVersionUID. > - GenericServiceJob.java:37, SE_NO_SUITABLE_CONSTRUCTOR > Se: org.apache.ofbiz.service.job.GenericServiceJob is Serializable but its > superclass doesn't define an accessible void constructor > This class implements the Serializable interface and its superclass does not. > When such an object is deserialized, the fields of the superclass need to be > initialized by invoking the void constructor of the superclass. Since the > superclass does not have one, serialization and deserialization will fail at > runtime. > - JobManager.java:564, DM_NUMBER_CTOR > Bx: org.apache.ofbiz.service.job.JobManager.schedule(String, String, String, > String, long, int, int, int, long, int) invokes inefficient new Long(long) > constructor; use Long.valueOf(long) instead > Using new Integer(int) is guaranteed to always result in a new object whereas > Integer.valueOf(int) allows caching of values to be done by the compiler, > class library, or JVM. Using of cached values avoids object allocation and > the code will be faster. > Values between -128 and 127 are guaranteed to have corresponding cached > instances and using valueOf is approximately 3.5 times faster than using > constructor. For values outside the constant range the performance of both > styles is the same. > Unless the class must be compatible with JVMs predating Java 1.5, use either > autoboxing or the valueOf() method when creating instances of Long, Integer, > Short, Character, and Byte. > - PersistedServiceJob.java:-1, SE_TRANSIENT_FIELD_NOT_RESTORED > Se: The field org.apache.ofbiz.service.job.PersistedServiceJob.delegator is > transient but isn't set by deserialization > This class contains a field that is updated at multiple places in the class, > thus it seems to be part of the state of the class. However, since the field > is marked as transient and not set in readObjec
[jira] [Assigned] (OFBIZ-9705) [FB] Package org.apache.ofbiz.entity.serialize
[ https://issues.apache.org/jira/browse/OFBIZ-9705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl reassigned OFBIZ-9705: Assignee: Michael Brohl > [FB] Package org.apache.ofbiz.entity.serialize > -- > > Key: OFBIZ-9705 > URL: https://issues.apache.org/jira/browse/OFBIZ-9705 > Project: OFBiz > Issue Type: Sub-task > Components: ALL APPLICATIONS, ALL COMPONENTS >Affects Versions: Trunk >Reporter: Julian Leichert >Assignee: Michael Brohl >Priority: Minor > Attachments: > OFBIZ-9705_org.apache.ofbiz.entity.serialize_bugfixes.patch > > > XmlSerializer.java:134, NP_LOAD_OF_KNOWN_NULL_VALUE > - NP: Load of known null value in > org.apache.ofbiz.entity.serialize.XmlSerializer.serializeSingle(Object, > Document) > The variable referenced at this point is known to be null due to an earlier > check against null. Although this is valid, it might be a mistake (perhaps > you intended to refer to a different variable, or perhaps the earlier check > to see if the variable is null should have been a check to see if it was > non-null). > XmlSerializer.java:494, LI_LAZY_INIT_STATIC > - LI: Incorrect lazy initialization of static field > org.apache.ofbiz.entity.serialize.XmlSerializer.simpleDateFormatter in > org.apache.ofbiz.entity.serialize.XmlSerializer.getDateFormat() > This method contains an unsynchronized lazy initialization of a non-volatile > static field. Because the compiler or processor may reorder instructions, > threads are not guaranteed to see a completely initialized object, if the > method can be called by multiple threads. You can make the field volatile to > correct the problem. For more information, see the Java Memory Model web site. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OFBIZ-9704) [FB] Package org.apache.ofbiz.widget.renderer
[
https://issues.apache.org/jira/browse/OFBIZ-9704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl reassigned OFBIZ-9704:
Assignee: Michael Brohl
> [FB] Package org.apache.ofbiz.widget.renderer
> -
>
> Key: OFBIZ-9704
> URL: https://issues.apache.org/jira/browse/OFBIZ-9704
> Project: OFBiz
> Issue Type: Sub-task
> Components: ALL APPLICATIONS, ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Julian Leichert
>Assignee: Michael Brohl
>Priority: Minor
> Attachments:
> OFBIZ-9704_org.apache.ofbiz.widget.renderer_bugfixes.patch
>
>
> FormRenderer.java:149, SF_SWITCH_NO_DEFAULT
> - SF: Switch statement found in
> org.apache.ofbiz.widget.renderer.FormRenderer.getHiddenIgnoredFields(Map,
> Set, List, int) where default case is missing
> This method contains a switch statement where default case is missing.
> Usually you need to provide a default case.
> Because the analysis only looks at the generated bytecode, this warning can
> be incorrect triggered if the default case is at the end of the switch
> statement and the switch statement doesn't contain break statements for other
> cases.
> FormRenderer.java:507, SF_SWITCH_NO_DEFAULT
> - SF: Switch statement found in
> org.apache.ofbiz.widget.renderer.FormRenderer.renderHiddenIgnoredFields(Appendable,
> Map, FormStringRenderer, List) where default case is missing
> This method contains a switch statement where default case is missing.
> Usually you need to provide a default case.
> Because the analysis only looks at the generated bytecode, this warning can
> be incorrect triggered if the default case is at the end of the switch
> statement and the switch statement doesn't contain break statements for other
> cases.
> FormRenderer.java:1063, DLS_DEAD_LOCAL_STORE
> - DLS: Dead store to lastFormField in
> org.apache.ofbiz.widget.renderer.FormRenderer.renderSingleFormString(Appendable,
> Map, int)
> This instruction assigns a value to a local variable, but the value is not
> read or used in any subsequent instruction. Often, this indicates an error,
> because the value computed is never used.
> Note that Sun's javac compiler often generates dead stores for final local
> variables. Because FindBugs is a bytecode-based tool, there is no easy way to
> eliminate these false positives.
> FormRenderer.java:1101, NP_NULL_ON_SOME_PATH
> - NP: Possible null pointer dereference of currentFormField in
> org.apache.ofbiz.widget.renderer.FormRenderer.renderSingleFormString(Appendable,
> Map, int)
> There is a branch of statement that, if executed, guarantees that a null
> value will be dereferenced, which would generate a NullPointerException when
> the code is executed. Of course, the problem might be that the branch or
> statement is infeasible and that the null pointer exception can't ever be
> executed; deciding that is beyond the ability of FindBugs.
> FormRenderer.java:1146, UCF_USELESS_CONTROL_FLOW
> - UCF: Useless control flow in
> org.apache.ofbiz.widget.renderer.FormRenderer.renderSingleFormString(Appendable,
> Map, int)
> This method contains a useless control flow statement, where control flow
> continues onto the same place regardless of whether or not the branch is
> taken. For example, this is caused by having an empty statement block for an
> if statement:
> if (argv.length == 0) {
> // TODO: handle this case
> }
> MenuWrapTransform.java:72, MS_PKGPROTECT
> - MS: org.apache.ofbiz.widget.renderer.MenuWrapTransform.upSaveKeyNames
> should be package protected
> A mutable static field could be changed by malicious code or by accident. The
> field could be made package protected to avoid this vulnerability.
> MenuWrapTransform.java:73, MS_PKGPROTECT
> - MS: org.apache.ofbiz.widget.renderer.MenuWrapTransform.saveKeyNames should
> be package protected
> A mutable static field could be changed by malicious code or by accident. The
> field could be made package protected to avoid this vulnerability.
> MenuWrapTransform.java:149, SIC_INNER_SHOULD_BE_STATIC_ANON, Priorität:
> Niedrig
> SIC: The class org.apache.ofbiz.widget.renderer.MenuWrapTransform$1 could be
> refactored into a named _static_ inner class
> This class is an inner class, but does not use its embedded reference to the
> object which created it. This reference makes the instances of the class
> larger, and may keep the reference to the creator object alive longer than
> necessary. If possible, the class should be made into a static inner class.
> Since anonymous inner classes cannot be marked as static, doing this will
> require refactoring the inner class so that it is a named inner class.
> MenuWrapTransform.java:189, RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
> - RCN: Redundant nullcheck of menuWrapper, which is known
[jira] [Assigned] (OFBIZ-9703) [FB] Package org.apache.ofbiz.workeffort.workeffort
[
https://issues.apache.org/jira/browse/OFBIZ-9703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl reassigned OFBIZ-9703:
Assignee: Michael Brohl
> [FB] Package org.apache.ofbiz.workeffort.workeffort
> ---
>
> Key: OFBIZ-9703
> URL: https://issues.apache.org/jira/browse/OFBIZ-9703
> Project: OFBiz
> Issue Type: Sub-task
> Components: workeffort
>Affects Versions: Trunk
>Reporter: Julian Leichert
>Assignee: Michael Brohl
>Priority: Minor
> Attachments:
> OFBIZ-9703_org.apache.ofbiz.workeffort.workeffort_bugfixes.patch
>
>
> ICalConverter.java:229, DM_FP_NUMBER_CTOR
> - Bx:
> org.apache.ofbiz.workeffort.workeffort.ICalConverter.fromDuration(PropertyList)
> invokes inefficient new Double(double) constructor; use
> Double.valueOf(double) instead
> Using new Double(double) is guaranteed to always result in a new object
> whereas Double.valueOf(double) allows caching of values to be done by the
> compiler, class library, or JVM. Using of cached values avoids object
> allocation and the code will be faster.
> Unless the class must be compatible with JVMs predating Java 1.5, use either
> autoboxing or the valueOf() method when creating instances of Double and
> Float.
> ICalConverter.java:261, DM_NUMBER_CTOR
> - Bx:
> org.apache.ofbiz.workeffort.workeffort.ICalConverter.fromPercentComplete(PropertyList)
> invokes inefficient new Long(long) constructor; use Long.valueOf(long)
> instead
> Using new Integer(int) is guaranteed to always result in a new object whereas
> Integer.valueOf(int) allows caching of values to be done by the compiler,
> class library, or JVM. Using of cached values avoids object allocation and
> the code will be faster.
> Values between -128 and 127 are guaranteed to have corresponding cached
> instances and using valueOf is approximately 3.5 times faster than using
> constructor. For values outside the constant range the performance of both
> styles is the same.
> Unless the class must be compatible with JVMs predating Java 1.5, use either
> autoboxing or the valueOf() method when creating instances of Long, Integer,
> Short, Character, and Byte.
> ICalConverter.java:269, DM_FP_NUMBER_CTOR
> - Bx:
> org.apache.ofbiz.workeffort.workeffort.ICalConverter.fromPriority(PropertyList)
> invokes inefficient new Double(double) constructor; use
> Double.valueOf(double) instead
> Using new Double(double) is guaranteed to always result in a new object
> whereas Double.valueOf(double) allows caching of values to be done by the
> compiler, class library, or JVM. Using of cached values avoids object
> allocation and the code will be faster.
> Unless the class must be compatible with JVMs predating Java 1.5, use either
> autoboxing or the valueOf() method when creating instances of Double and
> Float.
> ICalConverter.java:479, REC_CATCH_EXCEPTION
> - REC: Exception is caught when Exception is not thrown in
> org.apache.ofbiz.workeffort.workeffort.ICalConverter.invokeService(String,
> Map, Map)
> This method uses a try-catch block that catches Exception objects, but
> Exception is not thrown within the try block, and RuntimeException is not
> explicitly caught. It is a common bug pattern to say try { ... } catch
> (Exception e) { something } as a shorthand for catching a number of types of
> exception each of whose catch blocks is identical, but this construct also
> accidentally catches RuntimeException as well, masking potential bugs.
> A better approach is to either explicitly catch the specific exceptions that
> are thrown, or to explicitly catch RuntimeException exception, rethrow it,
> and then catch all non-Runtime Exceptions, as shown below:
> try {
> ...
> } catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
> ... deal with all non-runtime exceptions ...
> }
> ICalConverter.java:506, RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE
> - RCN: Nullcheck of partyAssign at line 516 of value previously dereferenced
> in
> org.apache.ofbiz.workeffort.workeffort.ICalConverter.loadPartyAssignment(Property,
> GenericValue, Map)
> A value is checked here to see whether it is null, but this value can't be
> null because it was previously dereferenced and if it were null a null
> pointer exception would have occurred at the earlier dereference.
> Essentially, this code and the previous dereference disagree as to whether
> this value is allowed to be null. Either the check is redundant or the
> previous dereference is erroneous.
> ICalConverter.java:789, DM_CONVERT_CASE
> - Dm: Use of non-localized String.toUpperCase() or String.toLowerCase() in
> org.apache.ofbiz.workeffort.workeffort.ICalConverter.storePartyAssignments(String,
> Component, Map)
> A String is being converted to upper or lowercase,
[jira] [Assigned] (OFBIZ-9707) [FB] Package org.apache.ofbiz.entity.transaction
[
https://issues.apache.org/jira/browse/OFBIZ-9707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl reassigned OFBIZ-9707:
Assignee: Michael Brohl
> [FB] Package org.apache.ofbiz.entity.transaction
>
>
> Key: OFBIZ-9707
> URL: https://issues.apache.org/jira/browse/OFBIZ-9707
> Project: OFBiz
> Issue Type: Sub-task
> Components: ALL APPLICATIONS, ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Julian Leichert
>Assignee: Michael Brohl
>Priority: Minor
> Attachments:
> OFBIZ-9707_org.apache.ofbiz.entity.transaction_bugfixes.patch
>
>
> DumbTransactionFactory.java:50, SIC_INNER_SHOULD_BE_STATIC_ANON
> - SIC: The class org.apache.ofbiz.entity.transaction.DumbTransactionFactory$1
> could be refactored into a named _static_ inner class
> This class is an inner class, but does not use its embedded reference to the
> object which created it. This reference makes the instances of the class
> larger, and may keep the reference to the creator object alive longer than
> necessary. If possible, the class should be made into a static inner class.
> Since anonymous inner classes cannot be marked as static, doing this will
> require refactoring the inner class so that it is a named inner class.
> DumbTransactionFactory.java:84, SIC_INNER_SHOULD_BE_STATIC_ANON
> - SIC: The class org.apache.ofbiz.entity.transaction.DumbTransactionFactory$2
> could be refactored into a named _static_ inner class
> This class is an inner class, but does not use its embedded reference to the
> object which created it. This reference makes the instances of the class
> larger, and may keep the reference to the creator object alive longer than
> necessary. If possible, the class should be made into a static inner class.
> Since anonymous inner classes cannot be marked as static, doing this will
> require refactoring the inner class so that it is a named inner class.
> GenericXaResource.java:210, ICAST_INTEGER_MULTIPLY_CAST_TO_LONG
> - ICAST: Result of integer multiplication cast to long in
> org.apache.ofbiz.entity.transaction.GenericXaResource.run()
> This code performs integer multiply and then converts the result to a long,
> as in:
> long convertDaysToMilliseconds(int days) { return 1000*3600*24*days; }
> If the multiplication is done using long arithmetic, you can avoid the
> possibility that the result will overflow. For example, you could fix the
> above code to:
> long convertDaysToMilliseconds(int days) { return 1000L*3600*24*days; }
> or
> static final long MILLISECONDS_PER_DAY = 24L*3600*1000;
> long convertDaysToMilliseconds(int days) { return days *
> MILLISECONDS_PER_DAY; }
> JNDITransactionFactory.java:56, MS_SHOULD_BE_FINAL
> - MS: org.apache.ofbiz.entity.transaction.JNDITransactionFactory.dsCache
> isn't final but should be
> This static field public but not final, and could be changed by malicious
> code or by accident from another package. The field could be made final to
> avoid this vulnerability.
> JNDITransactionFactory.java:59, DC_DOUBLECHECK
> - DC: Possible doublecheck on
> org.apache.ofbiz.entity.transaction.JNDITransactionFactory.transactionManager
> in
> org.apache.ofbiz.entity.transaction.JNDITransactionFactory.getTransactionManager()
> This method may contain an instance of double-checked locking. This idiom is
> not correct according to the semantics of the Java memory model. For more
> information, see the web page
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html.
> JNDITransactionFactory.java:74, ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD
> - ST: Write to static field
> org.apache.ofbiz.entity.transaction.JNDITransactionFactory.transactionManager
> from instance method
> org.apache.ofbiz.entity.transaction.JNDITransactionFactory.getTransactionManager()
> This instance method writes to a static field. This is tricky to get correct
> if multiple instances are being manipulated, and generally bad practice.
> JNDITransactionFactory.java:95, DC_DOUBLECHECK
> - DC: Possible doublecheck on
> org.apache.ofbiz.entity.transaction.JNDITransactionFactory.userTransaction in
> org.apache.ofbiz.entity.transaction.JNDITransactionFactory.getUserTransaction()
> This method may contain an instance of double-checked locking. This idiom is
> not correct according to the semantics of the Java memory model. For more
> information, see the web page
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html.
> JNDITransactionFactory.java:109, ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD
> - ST: Write to static field
> org.apache.ofbiz.entity.transaction.JNDITransactionFactory.userTransaction
> from instance method
> org.apache.ofbiz.entity.transaction.JNDITransactionFactory.getUserTransaction()
> This ins
[jira] [Closed] (OFBIZ-9695) [FB] Package org.apache.ofbiz.widget.cache
[ https://issues.apache.org/jira/browse/OFBIZ-9695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl closed OFBIZ-9695. Resolution: Implemented Fix Version/s: Upcoming Release Thanks Dennis, your patch is in trunk r1812164. > [FB] Package org.apache.ofbiz.widget.cache > -- > > Key: OFBIZ-9695 > URL: https://issues.apache.org/jira/browse/OFBIZ-9695 > Project: OFBiz > Issue Type: Sub-task > Components: framework >Affects Versions: Trunk >Reporter: Dennis Balkir >Assignee: Michael Brohl >Priority: Minor > Fix For: Upcoming Release > > Attachments: OFBIZ-9695_org.apache.ofbiz.widget.cache_bugfixes.patch > > > - WidgetContextCacheKey.java:140, WMI_WRONG_MAP_ITERATOR > WMI: org.apache.ofbiz.widget.cache.WidgetContextCacheKey.toString() makes > inefficient use of keySet iterator instead of entrySet iterator > This method accesses the value of a Map entry, using a key that was retrieved > from a keySet iterator. It is more efficient to use an iterator on the > entrySet of the map, to avoid the Map.get(key) lookup. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
