[jira] [Closed] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy closed OFBIZ-12836. -- Resolution: Fixed > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor-3.groovy, > EntitySQLProcessor-4.groovy, EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-4.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-5.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750132#comment-17750132 ] Paul Foxworthy commented on OFBIZ-12836: Committed to trunk in c04d699dfc56f6b577c72469f0b18581b868d562 and 1e96dd11bfa73a35dac518e74e0bf29e204ddf1f > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor-3.groovy, > EntitySQLProcessor-4.groovy, EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-4.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-5.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750052#comment-17750052 ] Paul Foxworthy commented on OFBIZ-12836: One more patch relative to Jacques' commit 663dd3d for OFBIZ-12813. > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor-3.groovy, > EntitySQLProcessor-4.groovy, EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-4.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-5.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-12836: --- Attachment: Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-5.patch EntitySQLProcessor-4.groovy > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor-3.groovy, > EntitySQLProcessor-4.groovy, EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-4.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-5.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748471#comment-17748471 ] Paul Foxworthy commented on OFBIZ-12836: [~deepak] I think we can't always rely on isAfterLast - it might not work depending on which database backend you're using. For our simple situation we should just ignore it. > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor-3.groovy, > EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-4.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748467#comment-17748467 ] Paul Foxworthy commented on OFBIZ-12836: [~jleroux] I did another lap, the space is there now. I have also added a package statement and rerolled the patch for the new location now OFBIZ-12813 has been committed > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor-3.groovy, > EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-4.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748442#comment-17748442 ] Paul Foxworthy edited comment on OFBIZ-12836 at 7/28/23 8:00 AM: - [~jleroux] wrote: ??I get this message "The 'isAfterLast' method is only allowed on scroll cursors." Is that normal ? Actually why did you change resultMessage content??? I thought we could save a variable by just asking the resultset if it was after the last row or not. But it appears that isAfterLast only works if you have set the ResultSet type to TYPE_SCROLL_INSENSITIVE or TYPE_SCROLL_SENSITIVE, and not if it's TYPE_FORWARD_ONLY. For what we are doing, it's overkill to fuss about the type of the resultset. I have reverted to the previous code where we used an additional variable to track whether or not we reached the end of the results. was (Author: paul_foxworthy): [~jleroux] wrote: ??I get this message "The 'isAfterLast' method is only allowed on scroll cursors." Is that normal ? Actually why did you change resultMessage content??? I thought we could save a variable by just asking the resultset if it was after the last row or not. But it appears that isAfterLast only works if you have set the ResultSet type to TYPE_SCROLL_INSENSITIVE or TYPE_SCROLL_SENSITIVE, and not if it's TYPE_FORWARD_ONLY. For what we are doing, it's overkill to fuss about the type of the resultset. I have reverted to the previous code where we used an additional variable to track whether or not we reached the end of the results. I have also added a package and rerolled the patch for the new location now OFBIZ-12813 has been committed > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor-3.groovy, > EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-4.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-12836: --- Attachment: Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-4.patch EntitySQLProcessor-3.groovy > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor-3.groovy, > EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-4.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-12836: --- Attachment: (was: EntitySQLProcessor-3.groovy) > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748442#comment-17748442 ] Paul Foxworthy edited comment on OFBIZ-12836 at 7/28/23 7:57 AM: - [~jleroux] wrote: ??I get this message "The 'isAfterLast' method is only allowed on scroll cursors." Is that normal ? Actually why did you change resultMessage content??? I thought we could save a variable by just asking the resultset if it was after the last row or not. But it appears that isAfterLast only works if you have set the ResultSet type to TYPE_SCROLL_INSENSITIVE or TYPE_SCROLL_SENSITIVE, and not if it's TYPE_FORWARD_ONLY. For what we are doing, it's overkill to fuss about the type of the resultset. I have reverted to the previous code where we used an additional variable to track whether or not we reached the end of the results. I have also added a package and rerolled the patch for the new location now OFBIZ-12813 has been committed was (Author: paul_foxworthy): [~jleroux] wrote: ??I get this message "The 'isAfterLast' method is only allowed on scroll cursors." Is that normal ? Actually why did you change resultMessage content??? I thought we could save a variable by just asking the resultset if it was after the last row or not. But it appears that isAfterLast only works if you have set the ResultSet type to TYPE_SCROLL_INSENSITIVE or TYPE_SCROLL_SENSITIVE, and not if it's TYPE_FORWARD_ONLY. For what we are doing, it's overkill to fuss about the type of the resultset. I have reverted to the previous code where we used an additional variable to track whether or not we reached the end of the results. > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-12836: --- Attachment: (was: Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-4.patch) > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-12836: --- Attachment: Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-4.patch EntitySQLProcessor-3.groovy > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor-3.groovy, > EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-4.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-12836: --- Attachment: (was: EntitySQLProcessor-3.groovy) > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-12836: --- Attachment: (was: Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-4.patch) > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748442#comment-17748442 ] Paul Foxworthy edited comment on OFBIZ-12836 at 7/28/23 7:22 AM: - [~jleroux] wrote: ??I get this message "The 'isAfterLast' method is only allowed on scroll cursors." Is that normal ? Actually why did you change resultMessage content??? I thought we could save a variable by just asking the resultset if it was after the last row or not. But it appears that isAfterLast only works if you have set the ResultSet type to TYPE_SCROLL_INSENSITIVE or TYPE_SCROLL_SENSITIVE, and not if it's TYPE_FORWARD_ONLY. For what we are doing, it's overkill to fuss about the type of the resultset. I have reverted to the previous code where we used an additional variable to track whether or not we reached the end of the results. was (Author: paul_foxworthy): [~jleroux] wrote: ??I get this message "The 'isAfterLast' method is only allowed on scroll cursors." Is that normal ? Actually why did you change resultMessage content??? I thought we could save a variable by just asking the resultset if it was after the last row or not. But it appears that isAfterLast only works if you have set the ResultSet type to TYPE_SCROLL_INSENSITIVE or TYPE_SCROLL_SENSITIVE, and not if it's TYPE_FORWARD_ONLY. For what we are doing, it's overkill to fuss about the type of the resultset. I will revert to the previous code where we used an additional variable to track whether or not we reached the end of the results. > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor-3.groovy, > EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-4.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-12836: --- Attachment: Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-4.patch EntitySQLProcessor-3.groovy > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor-3.groovy, > EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-4.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748442#comment-17748442 ] Paul Foxworthy commented on OFBIZ-12836: [~jleroux] wrote: ??I get this message "The 'isAfterLast' method is only allowed on scroll cursors." Is that normal ? Actually why did you change resultMessage content??? I thought we could save a variable by just asking the resultset if it was after the last row or not. But it appears that isAfterLast only works if you have set the ResultSet type to TYPE_SCROLL_INSENSITIVE or TYPE_SCROLL_SENSITIVE, and not if it's TYPE_FORWARD_ONLY. For what we are doing, it's overkill to fuss about the type of the resultset. I will revert to the previous code where we used an additional variable to track whether or not we reached the end of the results. > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-12836: --- Attachment: EntitySQLProcessor-2.groovy Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17746035#comment-17746035 ] Paul Foxworthy commented on OFBIZ-12836: Hi [~jleroux] That table name is ORDER_HEADER! PARTY is easier to type for a basic test :). I have changed the script to just use selgroup and rowlimit from the context. That's working for me. Using the request and not the context for sqlCommand came from https://github.com/apache/ofbiz-framework/commit/c9bfd92ad0b60901caed1f3401ffd4d757ac07f7 to fix OFBIZ-6567, which was a problem with encoding percent characters. I have changed the style for the try as you suggested. > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OFBIZ-12837) Log SQL statement in exceptions in EntitySQLProcessor
[
https://issues.apache.org/jira/browse/OFBIZ-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Foxworthy updated OFBIZ-12837:
---
Affects Version/s: 22.01
> Log SQL statement in exceptions in EntitySQLProcessor
> -
>
> Key: OFBIZ-12837
> URL: https://issues.apache.org/jira/browse/OFBIZ-12837
> Project: OFBiz
> Issue Type: Bug
> Components: framework/entity
>Affects Versions: 22.01
>Reporter: Paul Foxworthy
>Assignee: Paul Foxworthy
>Priority: Minor
> Attachments:
> OFBIZ-12837_log_sql_statement_in_exceptions_in_EntitySQLProcessor-1.patch,
> OFBIZ-12837_log_sql_statement_in_exceptions_in_EntitySQLProcessor.patch
>
>
> The combination of OFBIZ-11926 and OFBIZ-12386 means the field
>
> {{SQLProcessor.sql}}
>
> is never set, but it is assumed to be there in several catches - see the
> patch.
>
> If an exception occurs, you'll get a "null" and not the statement that caused
> the exception.
>
> I had a bit to say about how the problem arose in a comment on OFBIZ-11926.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (OFBIZ-12837) Log SQL statement in exceptions in EntitySQLProcessor
[
https://issues.apache.org/jira/browse/OFBIZ-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Foxworthy closed OFBIZ-12837.
--
Resolution: Fixed
> Log SQL statement in exceptions in EntitySQLProcessor
> -
>
> Key: OFBIZ-12837
> URL: https://issues.apache.org/jira/browse/OFBIZ-12837
> Project: OFBiz
> Issue Type: Bug
> Components: framework/entity
>Affects Versions: 22.01
>Reporter: Paul Foxworthy
>Assignee: Paul Foxworthy
>Priority: Minor
> Attachments:
> OFBIZ-12837_log_sql_statement_in_exceptions_in_EntitySQLProcessor-1.patch,
> OFBIZ-12837_log_sql_statement_in_exceptions_in_EntitySQLProcessor.patch
>
>
> The combination of OFBIZ-11926 and OFBIZ-12386 means the field
>
> {{SQLProcessor.sql}}
>
> is never set, but it is assumed to be there in several catches - see the
> patch.
>
> If an exception occurs, you'll get a "null" and not the statement that caused
> the exception.
>
> I had a bit to say about how the problem arose in a comment on OFBIZ-11926.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OFBIZ-12837) Log SQL statement in exceptions in EntitySQLProcessor
[
https://issues.apache.org/jira/browse/OFBIZ-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744826#comment-17744826
]
Paul Foxworthy edited comment on OFBIZ-12837 at 7/22/23 7:29 AM:
-
Committed to trunk in 404cb9fd0260778c801f6b7edaf7d810e4324fec
Committed to release22.01 in 4ba4b965994ce39a0b64e08c40940a00bc5ff2c0
Problem was introduced after v18.12, no need for a fix there
was (Author: paul_foxworthy):
Yes, I'll commit
> Log SQL statement in exceptions in EntitySQLProcessor
> -
>
> Key: OFBIZ-12837
> URL: https://issues.apache.org/jira/browse/OFBIZ-12837
> Project: OFBiz
> Issue Type: Bug
> Components: framework/entity
>Reporter: Paul Foxworthy
>Assignee: Paul Foxworthy
>Priority: Minor
> Attachments:
> OFBIZ-12837_log_sql_statement_in_exceptions_in_EntitySQLProcessor-1.patch,
> OFBIZ-12837_log_sql_statement_in_exceptions_in_EntitySQLProcessor.patch
>
>
> The combination of OFBIZ-11926 and OFBIZ-12386 means the field
>
> {{SQLProcessor.sql}}
>
> is never set, but it is assumed to be there in several catches - see the
> patch.
>
> If an exception occurs, you'll get a "null" and not the statement that caused
> the exception.
>
> I had a bit to say about how the problem arose in a comment on OFBIZ-11926.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745876#comment-17745876 ] Paul Foxworthy edited comment on OFBIZ-12836 at 7/22/23 6:55 AM: - [~deepak] you're right re rowLimit and selGroup. I did it for similarity with line 22, but I now think the idea is you can optionally supply a query to run using the sqlCommand. I have updated the patch. was (Author: paul_foxworthy): [~deepak] you're right. I did it for similarity with line 22, but I now think the idea is you can optionally supply a query to run iusing the sqlCommand. I have updated the patch. > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-12836: --- Attachment: EntitySQLProcessor-1.groovy Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745876#comment-17745876 ] Paul Foxworthy commented on OFBIZ-12836: [~deepak] you're right. I did it for similarity with line 22, but I now think the idea is you can optionally supply a query to run iusing the sqlCommand. I have updated the patch. > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12837) Log SQL statement in exceptions in EntitySQLProcessor
[
https://issues.apache.org/jira/browse/OFBIZ-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744826#comment-17744826
]
Paul Foxworthy commented on OFBIZ-12837:
Yes, I'll commit
> Log SQL statement in exceptions in EntitySQLProcessor
> -
>
> Key: OFBIZ-12837
> URL: https://issues.apache.org/jira/browse/OFBIZ-12837
> Project: OFBiz
> Issue Type: Bug
> Components: framework/entity
>Reporter: Paul Foxworthy
>Assignee: Paul Foxworthy
>Priority: Minor
> Attachments:
> OFBIZ-12837_log_sql_statement_in_exceptions_in_EntitySQLProcessor-1.patch,
> OFBIZ-12837_log_sql_statement_in_exceptions_in_EntitySQLProcessor.patch
>
>
> The combination of OFBIZ-11926 and OFBIZ-12386 means the field
>
> {{SQLProcessor.sql}}
>
> is never set, but it is assumed to be there in several catches - see the
> patch.
>
> If an exception occurs, you'll get a "null" and not the statement that caused
> the exception.
>
> I had a bit to say about how the problem arose in a comment on OFBIZ-11926.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744811#comment-17744811 ] Paul Foxworthy edited comment on OFBIZ-12836 at 7/19/23 11:58 PM: -- New patch uploaded. The changes are substantial so I've attached the complete script file as well. was (Author: paul_foxworthy): OK, I will change it to use explicit types. > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-12836: --- Attachment: Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch EntitySQLProcessor.groovy > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744811#comment-17744811 ] Paul Foxworthy commented on OFBIZ-12836: OK, I will change it to use explicit types. > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (OFBIZ-11167) Use Codenarc to test Groovy code
[
https://issues.apache.org/jira/browse/OFBIZ-11167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561935#comment-17561935
]
Paul Foxworthy edited comment on OFBIZ-11167 at 7/19/23 10:35 PM:
--
I wrote a little script to extract the rules in order of occurrence. I will
launch an email to the dev list to discuss about the rules to be respected, and
the implied changes.
There are the results :
||Number of occurence||Rule name and details||
|9883|UnnecessaryGString - String objects should be created with single quotes,
and GString objects created with double quotes. Creating normal String objects
with double quotes is confusing to readers.|
|4569|DuplicateStringLiteral - Code containing duplicate String literals can
usually be improved by declaring the String as a constant field. The
ignoreStrings property () can optionally specify a comma-separated list of
Strings to ignore.|
|4209|SpaceAroundMapEntryColon - Check for configured formatting of whitespace
around colons for literal Map entries. The characterBeforeColonRegex and
characterAfterColonRegex properties specify a regular expression that must
match the character before/after the colon.|
|1448|LineLength - Checks the maximum length for each line of source code. It
checks for number of characters, so lines that include tabs may appear longer
than the allowed number when viewing the file. The maximum line length can be
configured by setting the length property, which defaults to 120.|
|885|UnnecessaryGetter - Checks for explicit calls to getter/accessor methods
which can, for the most part, be replaced by property access. A getter is
defined as a method call that matches get[A-Z] but not getClass() or
get[A-Z][A-Z] such as getURL(). Getters do not take method arguments. The
ignoreMethodNames property (null) can specify method names that should be
ignored, optionally containing wildcard characters ('*' or '?').|
|601|NoDef - def should not be used. You should replace it with concrete type.|
|485|MethodReturnTypeRequired - Checks that method return types are not
dynamic, that is they are explicitly stated and different than def.|
|484|Indentation - Check indentation for class and method declarations, and
initial statements.|
|482|UnnecessaryReturnKeyword - In Groovy, the return keyword is often
optional. If a statement is the last line in a method or closure then you do
not need to have the return keyword.|
|407|UnnecessaryObjectReferences - Violations are triggered when an excessive
set of consecutive statements all reference the same variable. This can be made
more readable by using a with or identity block.|
|345|CompileStatic - Check that classes are explicitely annotated with either
@GrailsCompileStatic, @CompileStatic or @CompileDynamic|
|320|ExplicitCallToEqualsMethod - This rule detects when the equals(Object)
method is called directly in code instead of using the == or != operator. A
groovier way to express this: a.equals(b) is this: a == b and a groovier way to
express : !a.equals(b) is : a != b|
|235|IfStatementBraces - Use braces for if statements, even for a single
statement.|
|235|SpaceAroundOperator - Check that there is at least one space (blank) or
whitespace around each binary operator.|
|211|NestedBlockDepth - Checks for blocks or closures nested more than
maxNestedBlockDepth (5) levels deep.|
|201|TrailingWhitespace - Checks that no lines of source code end with
whitespace characters.|
|190|DuplicateNumberLiteral - Code containing number String literals can
usually be improved by declaring the number as a constant field. The
ignoreNumbers property (0,1) can optionally specify a comma-separated list of
numbers to ignore.|
|190|NoWildcardImports - Wildcard imports, static or otherwise, should not be
used.|
|173|TrailingComma - Check whether list and map literals contain optional
trailing comma.|
|167|InvertedCondition - An inverted condition is one where a constant
expression is used on the left hand side of the equals comparision. Such
conditions can be confusing especially when used in assertions where the
expected value is by convention placed on the right hand side of the
comparision.|
|167|JavadocEmptyReturnTag - Checks for empty @return tags within javadoc.|
|164|UnnecessarySetter - Checks for explicit calls to setter methods which can,
for the most part, be replaced by assignment to property. A setter is defined
as a method call that matches set[A-Z] but not set[A-Z][A-Z] such as setURL().
Setters take one method argument.|
|146|CouldBeElvis - Catch an if block that could be written as an elvis
expression.|
|142|UnusedImport - Imports for a class that is never referenced within the
source file is unnecessary.|
|141|AbcMetric - Checks the ABC size metric for methods/classes. A method (or
"closure field") with an ABC score greater than the maxMethodAbcScore property
(60) causes a
[jira] [Comment Edited] (OFBIZ-11167) Use Codenarc to test Groovy code
[
https://issues.apache.org/jira/browse/OFBIZ-11167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561935#comment-17561935
]
Paul Foxworthy edited comment on OFBIZ-11167 at 7/19/23 10:32 PM:
--
I wrote a little script to extract the rules in order of occurrence. I will
launch an email to the dev list to discuss about the rules to be respected, and
the implied changes.
There are the results :
||Number of occurence||Rule name and details||
|9883|UnnecessaryGString - String objects should be created with single quotes,
and GString objects created with double quotes. Creating normal String objects
with double quotes is confusing to readers.|
|4569|DuplicateStringLiteral - Code containing duplicate String literals can
usually be improved by declaring the String as a constant field. The
ignoreStrings property () can optionally specify a comma-separated list of
Strings to ignore.|
|4209|SpaceAroundMapEntryColon - Check for configured formatting of whitespace
around colons for literal Map entries. The characterBeforeColonRegex and
characterAfterColonRegex properties specify a regular expression that must
match the character before/after the colon.|
|1448|LineLength - Checks the maximum length for each line of source code. It
checks for number of characters, so lines that include tabs may appear longer
than the allowed number when viewing the file. The maximum line length can be
configured by setting the length property, which defaults to 120.|
|885|UnnecessaryGetter - Checks for explicit calls to getter/accessor methods
which can, for the most part, be replaced by property access. A getter is
defined as a method call that matches get[A-Z] but not getClass() or
get[A-Z][A-Z] such as getURL(). Getters do not take method arguments. The
ignoreMethodNames property (null) can specify method names that should be
ignored, optionally containing wildcard characters ('*' or '?').|
|601|NoDef - def should not be used. You should replace it with concrete type.|
|485|MethodReturnTypeRequired - Checks that method return types are not
dynamic, that is they are explicitly stated and different than def.|
|484|Indentation - Check indentation for class and method declarations, and
initial statements.|
|482|UnnecessaryReturnKeyword - In Groovy, the return keyword is often
optional. If a statement is the last line in a method or closure then you do
not need to have the return keyword.|
|407|UnnecessaryObjectReferences - Violations are triggered when an excessive
set of consecutive statements all reference the same variable. This can be made
more readable by using a with or identity block.|
|345|CompileStatic - Check that classes are explicitely annotated with either
@GrailsCompileStatic, @CompileStatic or @CompileDynamic|
|320|ExplicitCallToEqualsMethod - This rule detects when the equals(Object)
method is called directly in code instead of using the == or != operator. A
groovier way to express this: a.equals(b) is this: a == b and a groovier way to
express : !a.equals(b) is : a != b|
|235|IfStatementBraces - Use braces for if statements, even for a single
statement.|
|235|SpaceAroundOperator - Check that there is at least one space (blank) or
whitespace around each binary operator.|
|211|NestedBlockDepth - Checks for blocks or closures nested more than
maxNestedBlockDepth (5) levels deep.|
|201|TrailingWhitespace - Checks that no lines of source code end with
whitespace characters.|
|190|DuplicateNumberLiteral - Code containing number String literals can
usually be improved by declaring the number as a constant field. The
ignoreNumbers property (0,1) can optionally specify a comma-separated list of
numbers to ignore.|
|190|NoWildcardImports - Wildcard imports, static or otherwise, should not be
used.|
|173|TrailingComma - Check whether list and map literals contain optional
trailing comma.|
|167|InvertedCondition - An inverted condition is one where a constant
expression is used on the left hand side of the equals comparision. Such
conditions can be confusing especially when used in assertions where the
expected value is by convention placed on the right hand side of the
comparision.|
|167|JavadocEmptyReturnTag - Checks for empty @return tags within javadoc.|
|164|UnnecessarySetter - Checks for explicit calls to setter methods which can,
for the most part, be replaced by assignment to property. A setter is defined
as a method call that matches set[A-Z] but not set[A-Z][A-Z] such as setURL().
Setters take one method argument.|
|146|CouldBeElvis - Catch an if block that could be written as an elvis
expression.|
|142|UnusedImport - Imports for a class that is never referenced within the
source file is unnecessary.|
|141|AbcMetric - Checks the ABC size metric for methods/classes. A method (or
"closure field") with an ABC score greater than the maxMethodAbcScore property
(60) causes a
[jira] [Commented] (OFBIZ-12837) Log SQL statement in exceptions in EntitySQLProcessor
[
https://issues.apache.org/jira/browse/OFBIZ-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743591#comment-17743591
]
Paul Foxworthy commented on OFBIZ-12837:
Thanks Jacques,
Yes, I have revised the patch.
> Log SQL statement in exceptions in EntitySQLProcessor
> -
>
> Key: OFBIZ-12837
> URL: https://issues.apache.org/jira/browse/OFBIZ-12837
> Project: OFBiz
> Issue Type: Bug
> Components: framework/entity
>Reporter: Paul Foxworthy
>Assignee: Paul Foxworthy
>Priority: Minor
> Attachments:
> OFBIZ-12837_log_sql_statement_in_exceptions_in_EntitySQLProcessor-1.patch,
> OFBIZ-12837_log_sql_statement_in_exceptions_in_EntitySQLProcessor.patch
>
>
> The combination of OFBIZ-11926 and OFBIZ-12386 means the field
>
> {{SQLProcessor.sql}}
>
> is never set, but it is assumed to be there in several catches - see the
> patch.
>
> If an exception occurs, you'll get a "null" and not the statement that caused
> the exception.
>
> I had a bit to say about how the problem arose in a comment on OFBIZ-11926.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OFBIZ-12837) Log SQL statement in exceptions in EntitySQLProcessor
[
https://issues.apache.org/jira/browse/OFBIZ-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Foxworthy updated OFBIZ-12837:
---
Attachment:
OFBIZ-12837_log_sql_statement_in_exceptions_in_EntitySQLProcessor-1.patch
> Log SQL statement in exceptions in EntitySQLProcessor
> -
>
> Key: OFBIZ-12837
> URL: https://issues.apache.org/jira/browse/OFBIZ-12837
> Project: OFBiz
> Issue Type: Bug
> Components: framework/entity
>Reporter: Paul Foxworthy
>Assignee: Paul Foxworthy
>Priority: Minor
> Attachments:
> OFBIZ-12837_log_sql_statement_in_exceptions_in_EntitySQLProcessor-1.patch,
> OFBIZ-12837_log_sql_statement_in_exceptions_in_EntitySQLProcessor.patch
>
>
> The combination of OFBIZ-11926 and OFBIZ-12386 means the field
>
> {{SQLProcessor.sql}}
>
> is never set, but it is assumed to be there in several catches - see the
> patch.
>
> If an exception occurs, you'll get a "null" and not the statement that caused
> the exception.
>
> I had a bit to say about how the problem arose in a comment on OFBIZ-11926.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OFBIZ-11926) Checkstyle: Variable name must match pattern
[
https://issues.apache.org/jira/browse/OFBIZ-11926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742991#comment-17742991
]
Paul Foxworthy edited comment on OFBIZ-11926 at 7/14/23 5:32 AM:
-
For the record, this change introduced a bug.
See the changes to SQLProcessor.java at line 80 in
[https://github.com/apache/ofbiz-framework/commit/f357b997c0ba2d1459055088d962a5168eee5c4d#]
The field _sql was renamed to sql. Trouble is, there was a local variable also
named sql in one of the overloaded prepareStatement methods, so the result was
a no-op
{{sql = sql;}}
at
[https://github.com/apache/ofbiz-framework/blob/dbaed189b17b34da9133a52f569e09e2e07ae6f9/framework/entity/src/main/java/org/apache/ofbiz/entity/jdbc/SQLProcessor.java#L376]
The line should read
{{this.sql = sql;}}
OFBIZ-12386 then deleted the no-op, see
[https://github.com/apache/ofbiz-framework/commit/997cf16ed317a92dea18e2b661a366c72f4bf5ae#diff-8d94a7797abfc769581da44dcc951e6a51fba95678a5bfd851a9aa44b13ea63e]
The fix is in OFBIZ-12837.
I grepped through all the changes in OFBIZ-11926 and couldn't find any other
incidence of a "fred = fred" line, so I think this was the only problem.
I'd like to suggest some things that might avoid similar problems in future.
I suspect the changes in OFBIZ-11926 were done with a dumb text
search-and-replace. A refactoring tool would given a warning that the field
would be hidden by a local variable of the same name. So I suggest we use
refactoring tools for style improvements.
The commit made 1,714 additions and 988 deletions over 88 files. That's a lot
to review. Can we keep commits smaller than that?
was (Author: paul_foxworthy):
For the record, this change introduced a bug.
See the changes to SQLProcessor.java at line 80 in
[https://github.com/apache/ofbiz-framework/commit/f357b997c0ba2d1459055088d962a5168eee5c4d#]
The field _sql was renamed to sql. Trouble is, there was a local variable also
named sql in one of the overloaded prepareStatement methods, so the result was
a no-op
{{sql = sql;}}
at
[https://github.com/apache/ofbiz-framework/blob/dbaed189b17b34da9133a52f569e09e2e07ae6f9/framework/entity/src/main/java/org/apache/ofbiz/entity/jdbc/SQLProcessor.java#L376]
The line should read
{{this.sql = sql;}}
OFBIZ-12386 then deleted the no-op, see
[https://github.com/apache/ofbiz-framework/commit/997cf16ed317a92dea18e2b661a366c72f4bf5ae#diff-8d94a7797abfc769581da44dcc951e6a51fba95678a5bfd851a9aa44b13ea63e]
I will post another Jira for the fix.
I grepped through all the changes in OFBIZ-11926 and couldn't find any other
incidence of a "fred = fred" line, so I think this was the only problem.
I'd like to suggest some things that might avoid similar problems in future.
I suspect the changes in OFBIZ-11926 were done with a dumb text
search-and-replace. A refactoring tool would given a warning that the field
would be hidden by a local variable of the same name. So I suggest we use
refactoring tools for style improvements.
The commit made 1,714 additions and 988 deletions over 88 files. That's a lot
to review. Can we keep commits smaller than that?
> Checkstyle: Variable name must match pattern
>
>
> Key: OFBIZ-11926
> URL: https://issues.apache.org/jira/browse/OFBIZ-11926
> Project: OFBiz
> Issue Type: Sub-task
> Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Suraj Khurana
>Assignee: Suraj Khurana
>Priority: Major
> Attachments: JsLanguageFilesMapping.patch, OFBIZ-11926-plugins.patch,
> OFBIZ-11926.patch
>
>
> All final data members of the class must match this naming pattern
> '^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$'
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OFBIZ-12386) Fix some bugs SpotBugs reports
[ https://issues.apache.org/jira/browse/OFBIZ-12386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446575#comment-17446575 ] Paul Foxworthy edited comment on OFBIZ-12386 at 7/14/23 5:29 AM: - Commit 997cf16ed317a92dea18e2b661a366c72f4bf5ae in ofbiz-framework's branch refs/heads/trunk from Jacques Le Roux [ [https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=997cf16] ] Improved: Fix some bugs Spotbugs reports (OFBIZ-12386) Useless self assignment Note added by Paul Foxworthy: OFBIZ-11926 caused this. The statement really should be there. See OFBIZ-12837. was (Author: jira-bot): Commit 997cf16ed317a92dea18e2b661a366c72f4bf5ae in ofbiz-framework's branch refs/heads/trunk from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=997cf16 ] Improved: Fix some bugs Spotbugs reports (OFBIZ-12386) Useless self assignment > Fix some bugs SpotBugs reports > -- > > Key: OFBIZ-12386 > URL: https://issues.apache.org/jira/browse/OFBIZ-12386 > Project: OFBiz > Issue Type: Bug > Components: ALL COMPONENTS >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OFBIZ-12837) Log SQL statement in exceptions in EntitySQLProcessor
[
https://issues.apache.org/jira/browse/OFBIZ-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Foxworthy updated OFBIZ-12837:
---
Description:
The combination of OFBIZ-11926 and OFBIZ-12386 means the field
{{SQLProcessor.sql}}
is never set, but it is assumed to be there in several catches - see the patch.
If an exception occurs, you'll get a "null" and not the statement that caused
the exception.
I had a bit to say about how the problem arose in a comment on OFBIZ-11926.
was:
The combination of OFBIZ-11926 and OFBIZ-12386 means the field
{{SQLProcessor.sql}}
is never set, but it is assumed to be there is several catches - see the patch.
If an exception occurs, you'll get a "null" and not the statement that caused
the exception.
I had a bit to say about how the problem arose in a comment on OFBIZ-11926.
> Log SQL statement in exceptions in EntitySQLProcessor
> -
>
> Key: OFBIZ-12837
> URL: https://issues.apache.org/jira/browse/OFBIZ-12837
> Project: OFBiz
> Issue Type: Bug
> Components: framework/entity
>Reporter: Paul Foxworthy
>Assignee: Paul Foxworthy
>Priority: Minor
> Attachments:
> OFBIZ-12837_log_sql_statement_in_exceptions_in_EntitySQLProcessor.patch
>
>
> The combination of OFBIZ-11926 and OFBIZ-12386 means the field
>
> {{SQLProcessor.sql}}
>
> is never set, but it is assumed to be there in several catches - see the
> patch.
>
> If an exception occurs, you'll get a "null" and not the statement that caused
> the exception.
>
> I had a bit to say about how the problem arose in a comment on OFBIZ-11926.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OFBIZ-12837) Log SQL statement in exceptions in EntitySQLProcessor
[
https://issues.apache.org/jira/browse/OFBIZ-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Foxworthy updated OFBIZ-12837:
---
Description:
The combination of OFBIZ-11926 and OFBIZ-12386 means the field
{{SQLProcessor.sql}}
is never set, but it is assumed to be there is several catches - see the patch.
If an exception occurs, you'll get a "null" and not the statement that caused
the exception.
I had a bit to say about how the problem arose in a comment on OFBIZ-11926.
was:
The combination of OFBIZ-11926 and OFBIZ-12386 means the field
{{SQLProcessor.sql}}
is never set, but it is assumed to be there is several catches - see the patch.
I had a bit to say about how the problem arose in a
[comment|https://issues.apache.org/jira/browse/OFBIZ-11926?focusedCommentId=17742991=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17742991]
on OFBIZ-11926.
> Log SQL statement in exceptions in EntitySQLProcessor
> -
>
> Key: OFBIZ-12837
> URL: https://issues.apache.org/jira/browse/OFBIZ-12837
> Project: OFBiz
> Issue Type: Bug
> Components: framework/entity
>Reporter: Paul Foxworthy
>Assignee: Paul Foxworthy
>Priority: Minor
> Attachments:
> OFBIZ-12837_log_sql_statement_in_exceptions_in_EntitySQLProcessor.patch
>
>
> The combination of OFBIZ-11926 and OFBIZ-12386 means the field
>
> {{SQLProcessor.sql}}
>
> is never set, but it is assumed to be there is several catches - see the
> patch.
>
> If an exception occurs, you'll get a "null" and not the statement that caused
> the exception.
>
> I had a bit to say about how the problem arose in a comment on OFBIZ-11926.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OFBIZ-12837) Log SQL statement in exceptions in EntitySQLProcessor
[
https://issues.apache.org/jira/browse/OFBIZ-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Foxworthy updated OFBIZ-12837:
---
Attachment:
OFBIZ-12837_log_sql_statement_in_exceptions_in_EntitySQLProcessor.patch
> Log SQL statement in exceptions in EntitySQLProcessor
> -
>
> Key: OFBIZ-12837
> URL: https://issues.apache.org/jira/browse/OFBIZ-12837
> Project: OFBiz
> Issue Type: Bug
> Components: framework/entity
>Reporter: Paul Foxworthy
>Assignee: Paul Foxworthy
>Priority: Minor
> Attachments:
> OFBIZ-12837_log_sql_statement_in_exceptions_in_EntitySQLProcessor.patch
>
>
> The combination of OFBIZ-11926 and OFBIZ-12386 means the field
>
> {{SQLProcessor.sql}}
>
> is never set, but it is assumed to be there is several catches - see the
> patch.
>
> I had a bit to say about how the problem arose in a
> [comment|https://issues.apache.org/jira/browse/OFBIZ-11926?focusedCommentId=17742991=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17742991]
> on OFBIZ-11926.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OFBIZ-12837) Log SQL statement in exceptions in EntitySQLProcessor
Paul Foxworthy created OFBIZ-12837:
--
Summary: Log SQL statement in exceptions in EntitySQLProcessor
Key: OFBIZ-12837
URL: https://issues.apache.org/jira/browse/OFBIZ-12837
Project: OFBiz
Issue Type: Bug
Components: framework/entity
Reporter: Paul Foxworthy
Assignee: Paul Foxworthy
The combination of OFBIZ-11926 and OFBIZ-12386 means the field
{{SQLProcessor.sql}}
is never set, but it is assumed to be there is several catches - see the patch.
I had a bit to say about how the problem arose in a
[comment|https://issues.apache.org/jira/browse/OFBIZ-11926?focusedCommentId=17742991=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17742991]
on OFBIZ-11926.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OFBIZ-11926) Checkstyle: Variable name must match pattern
[
https://issues.apache.org/jira/browse/OFBIZ-11926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742991#comment-17742991
]
Paul Foxworthy commented on OFBIZ-11926:
For the record, this change introduced a bug.
See the changes to SQLProcessor.java at line 80 in
[https://github.com/apache/ofbiz-framework/commit/f357b997c0ba2d1459055088d962a5168eee5c4d#]
The field _sql was renamed to sql. Trouble is, there was a local variable also
named sql in one of the overloaded prepareStatement methods, so the result was
a no-op
{{sql = sql;}}
at
[https://github.com/apache/ofbiz-framework/blob/dbaed189b17b34da9133a52f569e09e2e07ae6f9/framework/entity/src/main/java/org/apache/ofbiz/entity/jdbc/SQLProcessor.java#L376]
The line should read
{{this.sql = sql;}}
OFBIZ-12386 then deleted the no-op, see
[https://github.com/apache/ofbiz-framework/commit/997cf16ed317a92dea18e2b661a366c72f4bf5ae#diff-8d94a7797abfc769581da44dcc951e6a51fba95678a5bfd851a9aa44b13ea63e]
I will post another Jira for the fix.
I grepped through all the changes in OFBIZ-11926 and couldn't find any other
incidence of a "fred = fred" line, so I think this was the only problem.
I'd like to suggest some things that might avoid similar problems in future.
I suspect the changes in OFBIZ-11926 were done with a dumb text
search-and-replace. A refactoring tool would given a warning that the field
would be hidden by a local variable of the same name. So I suggest we use
refactoring tools for style improvements.
The commit made 1,714 additions and 988 deletions over 88 files. That's a lot
to review. Can we keep commits smaller than that?
> Checkstyle: Variable name must match pattern
>
>
> Key: OFBIZ-11926
> URL: https://issues.apache.org/jira/browse/OFBIZ-11926
> Project: OFBiz
> Issue Type: Sub-task
> Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Suraj Khurana
>Assignee: Suraj Khurana
>Priority: Major
> Attachments: JsLanguageFilesMapping.patch, OFBIZ-11926-plugins.patch,
> OFBIZ-11926.patch
>
>
> All final data members of the class must match this naming pattern
> '^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$'
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-12836: --- Attachment: Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
Paul Foxworthy created OFBIZ-12836: -- Summary: Resource leaks in EntitySQLProcessor.groovy Key: OFBIZ-12836 URL: https://issues.apache.org/jira/browse/OFBIZ-12836 Project: OFBiz Issue Type: Bug Components: webtools Reporter: Paul Foxworthy Assignee: Paul Foxworthy In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line 35 [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] it creates an SQLProcessor. SQLProcessor has a Close method and implements AutoCloseable, but we're not using try-with-resources, nor directly calling the Close method. Similarly, [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] obtains a java.sql.Resultset, which will be closed when everything works, but would leak if there was an exception. Again, we should be using try-with-resources. Note that according to [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] "Calling the method close on a ResultSet object that is already closed is a no-op.", if you obtain a ResultSet from the SQLProcessor and directly close that ResultSet, it's not a problem when the SQLProcessor.close also attempts to close the ResultSet. The problem is minor, most of the time. The groovy script is in the webtools, so used for developer tinkering and not production use. When you're doing a SELECT, the script is closing the ResultSet, so the important resources are cleaned up (assuming no exception occurred). However, if you are doing INSERT, UPDATE or DELETE, the script creates a prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OFBIZ-9592) Order Item "Remaining" duplicates "Outstanding"
[ https://issues.apache.org/jira/browse/OFBIZ-9592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-9592: -- Description: In the quantities relating to order items, there are two numbers presented: "remaining" and "outstanding". The calculations for these two numbers are identical. Compare [https://github.com/apache/ofbiz-framework/blame/trunk/applications/order/template/order/OrderItems.ftl#L250] for a purchase order item (and two lines below for a sales order item) with [https://github.com/apache/ofbiz-framework/blame/trunk/applications/order/template/order/OrderItems.ftl#L302] for a purchases order item (and two lines below for a sales order item) The only difference I can see between the Remaining and Outstanding numbers is the extra test the second time to force the outstanding number to zero for a status of ITEM_COMPLETED. -As the comment says, some goods won't need a- -shipment. In that case, it seems confusing and ridiculous to say some items- -are "remaining" but none are "outstanding". In other words, the calculation- -for outstanding is slightly better.- -I propose we should remove "remaining".- I have worked out why there are two different numbers: the original intent was that Remaining is the quantity after any cancellations, so in the common situation where there have been no cancellations, Remaining should be the same as the original quantity ordered. A bug was introduced in a commit a long time ago, where "Remaining" was changed so it replicates "Outstanding". was: In the quantities relating to order items, there are two numbers presented: "remaining" and "outstanding". The calculations for these two numbers are identical. Compare https://github.com/apache/ofbiz-framework/blame/trunk/applications/order/template/order/OrderItems.ftl#L250 for a purchase order item (and two lines below for a sales order item) with https://github.com/apache/ofbiz-framework/blame/trunk/applications/order/template/order/OrderItems.ftl#L302 for a purchases order item (and two lines below for a sales order item) The only difference I can see between the Remaining and Outstanding numbers is the extra test the second time to force the outstanding number to zero for a status of ITEM_COMPLETED. As the comment says, some goods won't need a shipment. In that case, it seems confusing and ridiculous to say some items are "remaining" but none are "outstanding". In other words, the calculation for outstanding is slightly better. I propose we should remove "remaining". > Order Item "Remaining" duplicates "Outstanding" > > > Key: OFBIZ-9592 > URL: https://issues.apache.org/jira/browse/OFBIZ-9592 > Project: OFBiz > Issue Type: Improvement > Components: order >Affects Versions: Trunk, Upcoming Branch >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Major > Labels: order, order_item > > In the quantities relating to order items, there are two numbers presented: > "remaining" and "outstanding". The calculations for these two numbers are > identical. > Compare > [https://github.com/apache/ofbiz-framework/blame/trunk/applications/order/template/order/OrderItems.ftl#L250] > for a purchase order item (and two lines below for a sales order item) > with > [https://github.com/apache/ofbiz-framework/blame/trunk/applications/order/template/order/OrderItems.ftl#L302] > for a purchases order item (and two lines below for a sales order item) > The only difference I can see between the Remaining and Outstanding numbers > is the extra test the second time to force the outstanding number to zero for > a > status of ITEM_COMPLETED. -As the comment says, some goods won't need a- > -shipment. In that case, it seems confusing and ridiculous to say some items- > -are "remaining" but none are "outstanding". In other words, the calculation- > -for outstanding is slightly better.- > -I propose we should remove "remaining".- > I have worked out why there are two different numbers: the original intent > was that Remaining is the quantity after any cancellations, so in the common > situation where there have been no cancellations, Remaining should be the > same as the original quantity ordered. > A bug was introduced in a commit a long time ago, where "Remaining" was > changed so it replicates "Outstanding". > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OFBIZ-12021) "description" and "comment" datatypes unnecessarily limited to 255 char
[ https://issues.apache.org/jira/browse/OFBIZ-12021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-12021: --- Summary: "description" and "comment" datatypes unnecessarily limited to 255 char (was: "description" and "comment" datatypes unnecicairly limited to 255 char ) > "description" and "comment" datatypes unnecessarily limited to 255 char > - > > Key: OFBIZ-12021 > URL: https://issues.apache.org/jira/browse/OFBIZ-12021 > Project: OFBiz > Issue Type: Improvement > Components: datamodel, framework/entity >Reporter: ddev >Priority: Minor > Attachments: field-types-with-longer-comments-and-descriptions.diff > > Original Estimate: 10m > Remaining Estimate: 10m > > "description" and "comment" fields are restricted to 255 char. However after > some research I found that all the supported databases support longer then > 255 char > I would expect users to want to write more then 255 char in a comment (I know > I personally can). > > I have included diff of my proposed solution as a attachment (I am > unfamiliar with the procedures for submitting patches here) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-12021) "description" and "comment" datatypes unnecicairly limited to 255 char
[ https://issues.apache.org/jira/browse/OFBIZ-12021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200561#comment-17200561 ] Paul Foxworthy commented on OFBIZ-12021: Good idea. In the case of Microsoft SQL Server, the text datatype was deprecated long ago and will probably be removed one day ([https://docs.microsoft.com/en-us/sql/database-engine/deprecated-database-engine-features-in-sql-server-2016?view=sql-server-ver15|https://docs.microsoft.com/en-us/sql/database-engine/deprecated-database-engine-features-in-sql-server-2016?view=sql-server-ver15).]). The replacement is VARCHAR(MAX) . > "description" and "comment" datatypes unnecicairly limited to 255 char > > > Key: OFBIZ-12021 > URL: https://issues.apache.org/jira/browse/OFBIZ-12021 > Project: OFBiz > Issue Type: Improvement > Components: datamodel, framework/entity >Reporter: ddev >Priority: Minor > Attachments: field-types-with-longer-comments-and-descriptions.diff > > Original Estimate: 10m > Remaining Estimate: 10m > > "description" and "comment" fields are restricted to 255 char. However after > some research I found that all the supported databases support longer then > 255 char > I would expect users to want to write more then 255 char in a comment (I know > I personally can). > > I have included diff of my proposed solution as a attachment (I am > unfamiliar with the procedures for submitting patches here) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-12021) "description" and "comment" datatypes unnecessarily limited to 255 char
[ https://issues.apache.org/jira/browse/OFBIZ-12021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-12021: --- Summary: "description" and "comment" datatypes unnecessarily limited to 255 char (was: "description" and "comment" datatypes unnecessarily limited to 255 char ) > "description" and "comment" datatypes unnecessarily limited to 255 char > > > Key: OFBIZ-12021 > URL: https://issues.apache.org/jira/browse/OFBIZ-12021 > Project: OFBiz > Issue Type: Improvement > Components: datamodel, framework/entity >Reporter: ddev >Priority: Minor > Attachments: field-types-with-longer-comments-and-descriptions.diff > > Original Estimate: 10m > Remaining Estimate: 10m > > "description" and "comment" fields are restricted to 255 char. However after > some research I found that all the supported databases support longer then > 255 char > I would expect users to want to write more then 255 char in a comment (I know > I personally can). > > I have included diff of my proposed solution as a attachment (I am > unfamiliar with the procedures for submitting patches here) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11229) Merge UrlRegexpTransform and OfbizUrlTransform classes
[
https://issues.apache.org/jira/browse/OFBIZ-11229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050707#comment-17050707
]
Paul Foxworthy commented on OFBIZ-11229:
Back in OFBIZ-5312 [~jleroux] asked:
{quote}Good, clean URLs are beneficial for all of OFBiz, not just e-commerce,
not just product information.
{quote}
??Do you think we need to apply the same scheme everywhere? Even in backend???
Yes. It would certainly help for RESTful services. I'll repeat what I said
earlier: URLs are for people, not just computers.
{quote}The solution is to add a canonical URL link
([https://en.wikipedia.org/wiki/Canonical_link_element]) to the content, to
make clear the primary URL and to make clear alternative URLs are just that,
alternative paths to the same thing.
{quote}
??That's quite a good idea, have you an idea on how to implement that in
OFBiz???
Most OFBiz pages will have only one URL, so no canonical URL element is
necessary. So we can restrict it to entities that might have duplicate URLs.
The prime example is Product. So if we add a canonical for that using the OFBiz
productId, that might be all that is needed.
Down the track, URLs like mybiz.com/employee/1234 and mybiz.com/customer/1234
might be interesting, but that can wait until after products.
> Merge UrlRegexpTransform and OfbizUrlTransform classes
> --
>
> Key: OFBIZ-11229
> URL: https://issues.apache.org/jira/browse/OFBIZ-11229
> Project: OFBiz
> Issue Type: Bug
> Components: framework, product
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Michael Brohl
>Priority: Minor
> Attachments: OFBIZ-11229-mergeUrlRegexpTransform.patch,
> OfbizUrlTransform vs UrlRegexpTransform.patch
>
>
> This improvemnt follows Paul's suggestion and this discussion which contains
> other references:
> https://markmail.org/message/bobj2uhnkzjddrtt.
> Globally can be summarised by my comment in this thread:
> bq. I suggest that UrlRegexpTransform (with maybe some changes) could be used
> it everywhere. Now there are maybe few features in OfbizUrlTransform that are
> not in UrlRegexpTransform. That needs to be checked. If we can merge
> OfbizUrlTransform in UrlRegexpTransform then the later could be used
> everywhere.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (OFBIZ-11229) Merge UrlRegexpTransform and OfbizUrlTransform classes
[
https://issues.apache.org/jira/browse/OFBIZ-11229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050707#comment-17050707
]
Paul Foxworthy edited comment on OFBIZ-11229 at 3/4/20 2:33 AM:
Back in OFBIZ-5312 [~jleroux] asked:
{quote}Good, clean URLs are beneficial for all of OFBiz, not just e-commerce,
not just product information.
{quote}
??Do you think we need to apply the same scheme everywhere? Even in backend???
Yes. It would certainly help for RESTful services. I'll repeat what I said
earlier: URLs are for people, not just computers.
{quote}The solution is to add a canonical URL link
([https://en.wikipedia.org/wiki/Canonical_link_element]) to the content, to
make clear the primary URL and to make clear alternative URLs are just that,
alternative paths to the same thing.
{quote}
??That's quite a good idea, have you an idea on how to implement that in
OFBiz???
Most OFBiz pages will have only one URL, so no canonical URL element is
necessary. So we can restrict it to entities that might have duplicate URLs.
The prime example is Product. So if we add a canonical for that using the OFBiz
productId, that might be all that is needed.
Down the track, URLs like mybiz.com/employee/1234 and mybiz.com/customer/1234
might be interesting, but that can wait until after products.
was (Author: paul_foxworthy):
Back in OFBIZ-5312 [~jleroux] asked:
{quote}Good, clean URLs are beneficial for all of OFBiz, not just e-commerce,
not just product information.
{quote}
??Do you think we need to apply the same scheme everywhere? Even in backend???
Yes. It would certainly help for RESTful services. I'll repeat what I said
earlier: URLs are for people, not just computers.
{quote}The solution is to add a canonical URL link
([https://en.wikipedia.org/wiki/Canonical_link_element]) to the content, to
make clear the primary URL and to make clear alternative URLs are just that,
alternative paths to the same thing.
{quote}
??That's quite a good idea, have you an idea on how to implement that in
OFBiz???
Most OFBiz pages will have only one URL, so no canonical URL element is
necessary. So we can restrict it to entities that might have duplicate URLs.
The prime example is Product. So if we add a canonical for that using the OFBiz
productId, that might be all that is needed.
Down the track, URLs like mybiz.com/employee/1234 and mybiz.com/customer/1234
might be interesting, but that can wait until after products.
> Merge UrlRegexpTransform and OfbizUrlTransform classes
> --
>
> Key: OFBIZ-11229
> URL: https://issues.apache.org/jira/browse/OFBIZ-11229
> Project: OFBiz
> Issue Type: Bug
> Components: framework, product
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Michael Brohl
>Priority: Minor
> Attachments: OFBIZ-11229-mergeUrlRegexpTransform.patch,
> OfbizUrlTransform vs UrlRegexpTransform.patch
>
>
> This improvemnt follows Paul's suggestion and this discussion which contains
> other references:
> https://markmail.org/message/bobj2uhnkzjddrtt.
> Globally can be summarised by my comment in this thread:
> bq. I suggest that UrlRegexpTransform (with maybe some changes) could be used
> it everywhere. Now there are maybe few features in OfbizUrlTransform that are
> not in UrlRegexpTransform. That needs to be checked. If we can merge
> OfbizUrlTransform in UrlRegexpTransform then the later could be used
> everywhere.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method
[
https://issues.apache.org/jira/browse/OFBIZ-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Foxworthy closed OFBIZ-3847.
-
Resolution: Fixed
> Entity ECAs not triggered correctly when using Delegator.storeAll() method
> --
>
> Key: OFBIZ-3847
> URL: https://issues.apache.org/jira/browse/OFBIZ-3847
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Release Branch 10.04
>Reporter: Martin Kreidenweis
>Assignee: Paul Foxworthy
>Priority: Major
> Attachments: GenericDelegator.java.diff,
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch,
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch
>
>
> The conditions don't work when updating (not creating) entities using the
> Delegator.storeAll() method. E.g. the following condition does not work:
> {code}
>
> value="N"/>
> value-attr="productInstance"/>
>
> {code}
> The indexProductKeywords service is called anyway when the product is updated
> and the autoCreateKeywords was "N" and stays "N". It works correctly for
> newly created products.
> The problem is in the method GenericDelegator.storeAll(), where unchanged
> field values are not passed down to the store() method. The store method
> calls the ECA engine, which does not receive the unchanged values at all and
> thus cannot evaluate the EECA conditions correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method
[
https://issues.apache.org/jira/browse/OFBIZ-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Foxworthy reopened OFBIZ-3847:
---
I set resolution to "Cannot Reproduce", but that's misleading because the
original issue was fixed
> Entity ECAs not triggered correctly when using Delegator.storeAll() method
> --
>
> Key: OFBIZ-3847
> URL: https://issues.apache.org/jira/browse/OFBIZ-3847
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Release Branch 10.04
>Reporter: Martin Kreidenweis
>Assignee: Paul Foxworthy
>Priority: Major
> Attachments: GenericDelegator.java.diff,
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch,
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch
>
>
> The conditions don't work when updating (not creating) entities using the
> Delegator.storeAll() method. E.g. the following condition does not work:
> {code}
>
> value="N"/>
> value-attr="productInstance"/>
>
> {code}
> The indexProductKeywords service is called anyway when the product is updated
> and the autoCreateKeywords was "N" and stays "N". It works correctly for
> newly created products.
> The problem is in the method GenericDelegator.storeAll(), where unchanged
> field values are not passed down to the store() method. The store method
> calls the ECA engine, which does not receive the unchanged values at all and
> thus cannot evaluate the EECA conditions correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method
[
https://issues.apache.org/jira/browse/OFBIZ-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Foxworthy closed OFBIZ-3847.
-
Resolution: Cannot Reproduce
> Entity ECAs not triggered correctly when using Delegator.storeAll() method
> --
>
> Key: OFBIZ-3847
> URL: https://issues.apache.org/jira/browse/OFBIZ-3847
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Release Branch 10.04
>Reporter: Martin Kreidenweis
>Assignee: Paul Foxworthy
>Priority: Major
> Attachments: GenericDelegator.java.diff,
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch,
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch
>
>
> The conditions don't work when updating (not creating) entities using the
> Delegator.storeAll() method. E.g. the following condition does not work:
> {code}
>
> value="N"/>
> value-attr="productInstance"/>
>
> {code}
> The indexProductKeywords service is called anyway when the product is updated
> and the autoCreateKeywords was "N" and stays "N". It works correctly for
> newly created products.
> The problem is in the method GenericDelegator.storeAll(), where unchanged
> field values are not passed down to the store() method. The store method
> calls the ECA engine, which does not receive the unchanged values at all and
> thus cannot evaluate the EECA conditions correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method
[
https://issues.apache.org/jira/browse/OFBIZ-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Foxworthy updated OFBIZ-3847:
--
Fix Version/s: (was: 17.12.01)
> Entity ECAs not triggered correctly when using Delegator.storeAll() method
> --
>
> Key: OFBIZ-3847
> URL: https://issues.apache.org/jira/browse/OFBIZ-3847
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Release Branch 10.04
>Reporter: Martin Kreidenweis
>Assignee: Paul Foxworthy
>Priority: Major
> Attachments: GenericDelegator.java.diff,
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch,
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch
>
>
> The conditions don't work when updating (not creating) entities using the
> Delegator.storeAll() method. E.g. the following condition does not work:
> {code}
>
> value="N"/>
> value-attr="productInstance"/>
>
> {code}
> The indexProductKeywords service is called anyway when the product is updated
> and the autoCreateKeywords was "N" and stays "N". It works correctly for
> newly created products.
> The problem is in the method GenericDelegator.storeAll(), where unchanged
> field values are not passed down to the store() method. The store method
> calls the ECA engine, which does not receive the unchanged values at all and
> thus cannot evaluate the EECA conditions correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method
[
https://issues.apache.org/jira/browse/OFBIZ-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027926#comment-17027926
]
Paul Foxworthy commented on OFBIZ-3847:
---
Thanks [~mbrohl] . Yes, I'm inclined to close this issue again. Gareth did say
they had directly removed rows in Postgres, which might have confused OFBiz.
I'll close this if there are no objections in the near future.
> Entity ECAs not triggered correctly when using Delegator.storeAll() method
> --
>
> Key: OFBIZ-3847
> URL: https://issues.apache.org/jira/browse/OFBIZ-3847
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Release Branch 10.04
>Reporter: Martin Kreidenweis
>Assignee: Paul Foxworthy
>Priority: Major
> Fix For: 17.12.01
>
> Attachments: GenericDelegator.java.diff,
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch,
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch
>
>
> The conditions don't work when updating (not creating) entities using the
> Delegator.storeAll() method. E.g. the following condition does not work:
> {code}
>
> value="N"/>
> value-attr="productInstance"/>
>
> {code}
> The indexProductKeywords service is called anyway when the product is updated
> and the autoCreateKeywords was "N" and stays "N". It works correctly for
> newly created products.
> The problem is in the method GenericDelegator.storeAll(), where unchanged
> field values are not passed down to the store() method. The store method
> calls the ECA engine, which does not receive the unchanged values at all and
> thus cannot evaluate the EECA conditions correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11315) Add “--graph” option
[
https://issues.apache.org/jira/browse/OFBIZ-11315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008456#comment-17008456
]
Paul Foxworthy commented on OFBIZ-11315:
Hi all,
Should this be a separate utility or plugin rather than a part of OFBiz itself?
I don't see a production use for it, but it will add additional code and
increase build times. We have done several "slim down" things, is this going in
the other direction?
Thanks
Paul Foxworthy
> Add “--graph” option
>
>
> Key: OFBIZ-11315
> URL: https://issues.apache.org/jira/browse/OFBIZ-11315
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Affects Versions: Trunk
>Reporter: Mathieu Lirzin
>Assignee: Mathieu Lirzin
>Priority: Minor
> Attachments: 0001-Implemented-Add-graph-option.patch,
> OFBIZ-11315-complete.patch,
> OFBIZ-11315_standard-no-prefix-format_0001-Implemented-Add-graph-option.patch,
> ofbiz.dot
>
>
> In order to inspect what components are loaded by OFBiz and their dependency
> relationship, it is convenient to have a visual graph representation.
> {code}
> gradlew "ofbiz --graph"
> {code}
> will output a {{ofbiz.dot}} file that can be processed with Graphviz:
> {code}
> cat ofbiz.dot | dot -T png -o ofbiz.png
> {code}
> Currently there is no dependency relationship specified by components but to
> check the kind of graph is produced it is possible to revert commit
> aae1c8a8f5fed7de717290c938297be62c0460fa
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-10239) Improve GeneralLedgerServices to set AcctgTrans's transition date as payment's effective date
[
https://issues.apache.org/jira/browse/OFBIZ-10239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848335#comment-16848335
]
Paul Foxworthy commented on OFBIZ-10239:
Hi [~rishisolankii] and [~manna1234].
Which test is failing?
> Improve GeneralLedgerServices to set AcctgTrans's transition date as
> payment's effective date
> -
>
> Key: OFBIZ-10239
> URL: https://issues.apache.org/jira/browse/OFBIZ-10239
> Project: OFBiz
> Issue Type: Improvement
> Components: accounting
>Reporter: Aishwary Shrivastava
>Assignee: Rishi Solanki
>Priority: Minor
> Attachments: OFBIZ-10239.patch,
> OFBIZ-10239_SetAccountingTransactionDates.patch
>
>
> Whenever user applies a payment, the {color:#008000}transactionDate
> {color}set on AcctgTransEntries is set by
> {color:#80}now-timestamp{color}, this can result in wrong accounting
> reports, if the payment was received earlier but applied later.
> For example, if someone receives a payment on 28 of Dec and applies the
> payment on 3rd of Jan, the yearly accounting reports will show that
> transaction in the new year, rather than in the previous year.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10932) Updating an OrderItem loses supplierProductId
[ https://issues.apache.org/jira/browse/OFBIZ-10932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821681#comment-16821681 ] Paul Foxworthy commented on OFBIZ-10932: Thanks [~swapnilmmane] > Updating an OrderItem loses supplierProductId > - > > Key: OFBIZ-10932 > URL: https://issues.apache.org/jira/browse/OFBIZ-10932 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk, 17.12.01, 18.12.01 >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Labels: order, order_item > Fix For: Trunk, 17.12.01, 18.12.01 > > Attachments: > OFBIZ-10932_Preserve_supplierProductId_when_updating_OrderItem.patch > > > When you edit on order item, the details are reloaded into a shopping cart > and after editing the order is updated from the cart. At present the > supplierProductId for the order item is not read into the cart. > > Try this in the demo site: > Product GZ-1000 has several suppliers, including BigSupplier > Order-Order Entry > In Purchase Order, choose BigSupplier, click Continue > In "Enter Order, Agreements and Ship Dates", click Continue > In Create Purchase Order, enter Product ID of GZ-1000 and Quantity of 500 > Click Finalize Order > Click Continue several times to reach Purchase Order: Order Confirmation > Click Create Order > Note Purchase Order number. When I did this, it was 1 > Applications - Web Tools > Click Entity Data Maintenance > In Filter by Entity Name, choose OrderItem, click Apply > Click OrderItem in the Entity Name column > Enter Purchase Order number, e.g. 1 > Scroll down and click Search > Observe that the OrderItem has a SupplierProductId of BKGZ_1000 as you'd > expect > Applications - Order - Find Order > Enter Order ID (e.g. 1) and click Find > In Actions, click Edit Items > Change Unit Price from 3.75 to 4.00, check checkbox next to Unit Price, and > click Update Selected Items > Return to Entity Data Maintenance in the Web Tools, and find the OrderItem > for the purchase order again > You'll see that the SupplierProductId has been lost > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10932) Updating an OrderItem loses supplierProductId
[ https://issues.apache.org/jira/browse/OFBIZ-10932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821680#comment-16821680 ] Paul Foxworthy commented on OFBIZ-10932: Fixed in trunk in r1857781. Fixed in 17.12 in r1857783. Fixed in 18.12 in r1857784. > Updating an OrderItem loses supplierProductId > - > > Key: OFBIZ-10932 > URL: https://issues.apache.org/jira/browse/OFBIZ-10932 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk, 17.12.01, 18.12.01 >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Labels: order, order_item > Fix For: Trunk, 17.12.01, 18.12.01 > > Attachments: > OFBIZ-10932_Preserve_supplierProductId_when_updating_OrderItem.patch > > > When you edit on order item, the details are reloaded into a shopping cart > and after editing the order is updated from the cart. At present the > supplierProductId for the order item is not read into the cart. > > Try this in the demo site: > Product GZ-1000 has several suppliers, including BigSupplier > Order-Order Entry > In Purchase Order, choose BigSupplier, click Continue > In "Enter Order, Agreements and Ship Dates", click Continue > In Create Purchase Order, enter Product ID of GZ-1000 and Quantity of 500 > Click Finalize Order > Click Continue several times to reach Purchase Order: Order Confirmation > Click Create Order > Note Purchase Order number. When I did this, it was 1 > Applications - Web Tools > Click Entity Data Maintenance > In Filter by Entity Name, choose OrderItem, click Apply > Click OrderItem in the Entity Name column > Enter Purchase Order number, e.g. 1 > Scroll down and click Search > Observe that the OrderItem has a SupplierProductId of BKGZ_1000 as you'd > expect > Applications - Order - Find Order > Enter Order ID (e.g. 1) and click Find > In Actions, click Edit Items > Change Unit Price from 3.75 to 4.00, check checkbox next to Unit Price, and > click Update Selected Items > Return to Entity Data Maintenance in the Web Tools, and find the OrderItem > for the purchase order again > You'll see that the SupplierProductId has been lost > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10932) Updating an OrderItem loses supplierProductId
[ https://issues.apache.org/jira/browse/OFBIZ-10932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-10932: --- Fix Version/s: Trunk 18.12.01 17.12.01 > Updating an OrderItem loses supplierProductId > - > > Key: OFBIZ-10932 > URL: https://issues.apache.org/jira/browse/OFBIZ-10932 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk, 17.12.01, 18.12.01 >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Labels: order, order_item > Fix For: Trunk, 17.12.01, 18.12.01 > > Attachments: > OFBIZ-10932_Preserve_supplierProductId_when_updating_OrderItem.patch > > > When you edit on order item, the details are reloaded into a shopping cart > and after editing the order is updated from the cart. At present the > supplierProductId for the order item is not read into the cart. > > Try this in the demo site: > Product GZ-1000 has several suppliers, including BigSupplier > Order-Order Entry > In Purchase Order, choose BigSupplier, click Continue > In "Enter Order, Agreements and Ship Dates", click Continue > In Create Purchase Order, enter Product ID of GZ-1000 and Quantity of 500 > Click Finalize Order > Click Continue several times to reach Purchase Order: Order Confirmation > Click Create Order > Note Purchase Order number. When I did this, it was 1 > Applications - Web Tools > Click Entity Data Maintenance > In Filter by Entity Name, choose OrderItem, click Apply > Click OrderItem in the Entity Name column > Enter Purchase Order number, e.g. 1 > Scroll down and click Search > Observe that the OrderItem has a SupplierProductId of BKGZ_1000 as you'd > expect > Applications - Order - Find Order > Enter Order ID (e.g. 1) and click Find > In Actions, click Edit Items > Change Unit Price from 3.75 to 4.00, check checkbox next to Unit Price, and > click Update Selected Items > Return to Entity Data Maintenance in the Web Tools, and find the OrderItem > for the purchase order again > You'll see that the SupplierProductId has been lost > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10932) Updating an OrderItem loses supplierProductId
[ https://issues.apache.org/jira/browse/OFBIZ-10932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-10932: --- Description: When you edit on order item, the details are reloaded into a shopping cart and after editing the order is updated from the cart. At present the supplierProductId for the order item is not read into the cart. Try this in the demo site: Product GZ-1000 has several suppliers, including BigSupplier Order-Order Entry In Purchase Order, choose BigSupplier, click Continue In "Enter Order, Agreements and Ship Dates", click Continue In Create Purchase Order, enter Product ID of GZ-1000 and Quantity of 500 Click Finalize Order Click Continue several times to reach Purchase Order: Order Confirmation Click Create Order Note Purchase Order number. When I did this, it was 1 Applications - Web Tools Click Entity Data Maintenance In Filter by Entity Name, choose OrderItem, click Apply Click OrderItem in the Entity Name column Enter Purchase Order number, e.g. 1 Scroll down and click Search Observe that the OrderItem has a SupplierProductId of BKGZ_1000 as you'd expect Applications - Order - Find Order Enter Order ID (e.g. 1) and click Find In Actions, click Edit Items Change Unit Price from 3.75 to 4.00, check checkbox next to Unit Price, and click Update Selected Items Return to Entity Data Maintenance in the Web Tools, and find the OrderItem for the purchase order again You'll see that the SupplierProductId has been lost was: When you edit on order item, the details are reloaded into a shopping cart and efter editing the order is updated from the cart. At present the supplierProductId for the order item is not read into the cart. Try this in the demo site: Product GZ-1000 has several suppliers, including BigSupplier Order-Order Entry In Purchase Order, choose BigSupplier, click Continue In "Enter Order, Agreements and Ship Dates", click Continue In Create Purchase Order, enter Product ID of GZ-1000 and Quantity of 500 Click Finalize Order Click Continue several times to reach Purchase Order: Order Confirmation Click Create Order Note Purchase Order number. When I did this, it was 1 Applications - Web Tools Click Entity Data Maintenance In Filter by Entity Name, choose OrderItem, click Apply Click OrderItem in the Entity Name column Enter Purchase Order number, e.g. 1 Scroll down and click Search Observe that the OrderItem has a SupplierProductId of BKGZ_1000 as you'd expect Applications - Order - Find Order Enter Order ID (e.g. 1) and click Find In Actions, click Edit Items Change Unit Price from 3.75 to 4.00, check checkbox next to Unit Price, and click Update Selected Items Return to Entity Data Maintenance in the Web Tools, and find the OrderItem for the purchase order again You'll see that the SupplierProductId has been lost > Updating an OrderItem loses supplierProductId > - > > Key: OFBIZ-10932 > URL: https://issues.apache.org/jira/browse/OFBIZ-10932 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk, 17.12.01, 18.12.01 >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Labels: order, order_item > Attachments: > OFBIZ-10932_Preserve_supplierProductId_when_updating_OrderItem.patch > > > When you edit on order item, the details are reloaded into a shopping cart > and after editing the order is updated from the cart. At present the > supplierProductId for the order item is not read into the cart. > > Try this in the demo site: > Product GZ-1000 has several suppliers, including BigSupplier > Order-Order Entry > In Purchase Order, choose BigSupplier, click Continue > In "Enter Order, Agreements and Ship Dates", click Continue > In Create Purchase Order, enter Product ID of GZ-1000 and Quantity of 500 > Click Finalize Order > Click Continue several times to reach Purchase Order: Order Confirmation > Click Create Order > Note Purchase Order number. When I did this, it was 1 > Applications - Web Tools > Click Entity Data Maintenance > In Filter by Entity Name, choose OrderItem, click Apply > Click OrderItem in the Entity Name column > Enter Purchase Order number, e.g. 1 > Scroll down and click Search > Observe that the OrderItem has a SupplierProductId of BKGZ_1000 as you'd > expect > Applications - Order - Find Order > Enter Order ID (e.g. 1) and click Find > In Actions, click Edit Items > Change Unit Price from 3.75 to 4.00, check checkbox next to Unit Price, and > click Update Selected Items > Return to Entity Data Maintenance in the Web Tools, and find the OrderItem > for the purchase order again > You'll see that the SupplierProductId has been lost > -- This message was
[jira] [Updated] (OFBIZ-10932) Updating an OrderItem loses supplierProductId
[ https://issues.apache.org/jira/browse/OFBIZ-10932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-10932: --- Attachment: OFBIZ-10932_Preserve_supplierProductId_when_updating_OrderItem.patch > Updating an OrderItem loses supplierProductId > - > > Key: OFBIZ-10932 > URL: https://issues.apache.org/jira/browse/OFBIZ-10932 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk, 17.12.01, 18.12.01 >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Labels: order, order_item > Attachments: > OFBIZ-10932_Preserve_supplierProductId_when_updating_OrderItem.patch > > > When you edit on order item, the details are reloaded into a shopping cart > and efter editing the order is updated from the cart. At present the > supplierProductId for the order item is not read into the cart. > > Try this in the demo site: > Product GZ-1000 has several suppliers, including BigSupplier > Order-Order Entry > In Purchase Order, choose BigSupplier, click Continue > In "Enter Order, Agreements and Ship Dates", click Continue > In Create Purchase Order, enter Product ID of GZ-1000 and Quantity of 500 > Click Finalize Order > Click Continue several times to reach Purchase Order: Order Confirmation > Click Create Order > Note Purchase Order number. When I did this, it was 1 > Applications - Web Tools > Click Entity Data Maintenance > In Filter by Entity Name, choose OrderItem, click Apply > Click OrderItem in the Entity Name column > Enter Purchase Order number, e.g. 1 > Scroll down and click Search > Observe that the OrderItem has a SupplierProductId of BKGZ_1000 as you'd > expect > Applications - Order - Find Order > Enter Order ID (e.g. 1) and click Find > In Actions, click Edit Items > Change Unit Price from 3.75 to 4.00, check checkbox next to Unit Price, and > click Update Selected Items > Return to Entity Data Maintenance in the Web Tools, and find the OrderItem > for the purchase order again > You'll see that the SupplierProductId has been lost > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OFBIZ-10932) Updating an OrderItem loses supplierProductId
Paul Foxworthy created OFBIZ-10932: -- Summary: Updating an OrderItem loses supplierProductId Key: OFBIZ-10932 URL: https://issues.apache.org/jira/browse/OFBIZ-10932 Project: OFBiz Issue Type: Bug Components: order Affects Versions: Trunk, 17.12.01, 18.12.01 Reporter: Paul Foxworthy Assignee: Paul Foxworthy When you edit on order item, the details are reloaded into a shopping cart and efter editing the order is updated from the cart. At present the supplierProductId for the order item is not read into the cart. Try this in the demo site: Product GZ-1000 has several suppliers, including BigSupplier Order-Order Entry In Purchase Order, choose BigSupplier, click Continue In "Enter Order, Agreements and Ship Dates", click Continue In Create Purchase Order, enter Product ID of GZ-1000 and Quantity of 500 Click Finalize Order Click Continue several times to reach Purchase Order: Order Confirmation Click Create Order Note Purchase Order number. When I did this, it was 1 Applications - Web Tools Click Entity Data Maintenance In Filter by Entity Name, choose OrderItem, click Apply Click OrderItem in the Entity Name column Enter Purchase Order number, e.g. 1 Scroll down and click Search Observe that the OrderItem has a SupplierProductId of BKGZ_1000 as you'd expect Applications - Order - Find Order Enter Order ID (e.g. 1) and click Find In Actions, click Edit Items Change Unit Price from 3.75 to 4.00, check checkbox next to Unit Price, and click Update Selected Items Return to Entity Data Maintenance in the Web Tools, and find the OrderItem for the purchase order again You'll see that the SupplierProductId has been lost -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10921) Marital Status not managed properly in Person entity
[ https://issues.apache.org/jira/browse/OFBIZ-10921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818753#comment-16818753 ] Paul Foxworthy commented on OFBIZ-10921: Thanks Pierre. I agree implementers may well change this to suit their own needs. Changing marital status to an enum will facilitate customisation, so I'd be happy for Suraj to proceed with that. And I'm happy with attached patches for different use cases. After that, there should probably be some default demonstration data as there is for many other entities. Some implementers will not care much about this and won't change from the defaults. So I'd prefer that our demonstration data should be minimal and lowest common denominator. When a new OFBiz developer uses the standard demo data, we should keep it simple and minimise the chance of embarrassment, distraction and objections from potential clients. > Marital Status not managed properly in Person entity > > > Key: OFBIZ-10921 > URL: https://issues.apache.org/jira/browse/OFBIZ-10921 > Project: OFBiz > Issue Type: Improvement > Components: party >Affects Versions: Trunk >Reporter: Suraj Khurana >Assignee: Suraj Khurana >Priority: Major > > Currently, *maritalStatus* is managed as an indicator (Y/N) in *Person* > entity. I think we can enhance it and make it derived from *Enumeration* > pattern. > > *Classification of legal marital status* > > - 1 - Married (and not separated) ... > - 2 - Widowed (including living common law) ... > - 3 - Separated (and not Divorced) ... > - 4 - Divorced (including living common law) ... > - 5 - Single (including living common law) > Please refer discussion over ML: > [https://markmail.org/message/5b33qm3osy76if24] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10921) Marital Status not managed properly in Person entity
[ https://issues.apache.org/jira/browse/OFBIZ-10921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818726#comment-16818726 ] Paul Foxworthy commented on OFBIZ-10921: Of course how this attribute will be used will vary from one OFBiz implementation to another. It may be necessary and appropriate to ask this question and expect one of these answers for a specific system. But I am uncomfortable about the assumptions and intrusiveness of this list. There are situations such as employment where it is discriminatory and illegal to ask this sort of question. I don't think the detailed legal status of a customer's relationship is relevant to a business trying to sell goods or services. Some indication of household status might be useful for demographics and marketing. If it's clearer to a customer what you want to know and why, they would be more likely to answer the question. So I suggest standard OFBiz demonstrates a different list along these lines: Single (never married, separated, divorced, widowed) Partnered (married or de facto) Rather Not Say > Marital Status not managed properly in Person entity > > > Key: OFBIZ-10921 > URL: https://issues.apache.org/jira/browse/OFBIZ-10921 > Project: OFBiz > Issue Type: Improvement > Components: party >Affects Versions: Trunk >Reporter: Suraj Khurana >Assignee: Suraj Khurana >Priority: Major > > Currently, *maritalStatus* is managed as an indicator (Y/N) in *Person* > entity. I think we can enhance it and make it derived from *Enumeration* > pattern. > > *Classification of legal marital status* > > - 1 - Married (and not separated) ... > - 2 - Widowed (including living common law) ... > - 3 - Separated (and not Divorced) ... > - 4 - Divorced (including living common law) ... > - 5 - Single (including living common law) > Please refer discussion over ML: > [https://markmail.org/message/5b33qm3osy76if24] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-9677) In packing, only use reservations with stock on hand
[ https://issues.apache.org/jira/browse/OFBIZ-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743077#comment-16743077 ] Paul Foxworthy commented on OFBIZ-9677: --- There was a problem with a boundary condition when there is single reservation and its quantity exactly matches the quantity to pack. The tests now pass locally. Committed in r1851353. > In packing, only use reservations with stock on hand > > > Key: OFBIZ-9677 > URL: https://issues.apache.org/jira/browse/OFBIZ-9677 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Trunk >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Major > Labels: pack, reservation > Fix For: Trunk > > Attachments: OFBIZ-9677_PackingIgnoreBackorderReservations.patch, > OFBIZ-9677_PackingIgnoreBackorderReservations.patch > > > During packing, OFBiz looks for reservations (OrderItemShipGrpInvRes) for the > order item. Some reservations are for back ordered items not on hand. These > reservations should not be used during packing, but they are. > The attached patch fixes this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-9677) In packing, only use reservations with stock on hand
[ https://issues.apache.org/jira/browse/OFBIZ-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741454#comment-16741454 ] Paul Foxworthy commented on OFBIZ-9677: --- Thanks Jacques. Sorry I didn't get to this. I will commit with backports in future. > In packing, only use reservations with stock on hand > > > Key: OFBIZ-9677 > URL: https://issues.apache.org/jira/browse/OFBIZ-9677 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Trunk >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Major > Labels: pack, reservation > Fix For: Trunk > > Attachments: OFBIZ-9677_PackingIgnoreBackorderReservations.patch, > OFBIZ-9677_PackingIgnoreBackorderReservations.patch > > > During packing, OFBiz looks for reservations (OrderItemShipGrpInvRes) for the > order item. Some reservations are for back ordered items not on hand. These > reservations should not be used during packing, but they are. > The attached patch fixes this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10239) Improve GeneralLedgerServices to set AcctgTrans's transition date as payment's effective date
[
https://issues.apache.org/jira/browse/OFBIZ-10239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Foxworthy updated OFBIZ-10239:
---
Attachment: OFBIZ-10239_SetAccountingTransactionDates.patch
> Improve GeneralLedgerServices to set AcctgTrans's transition date as
> payment's effective date
> -
>
> Key: OFBIZ-10239
> URL: https://issues.apache.org/jira/browse/OFBIZ-10239
> Project: OFBiz
> Issue Type: Improvement
> Components: accounting
>Reporter: Aishwary Shrivastava
>Assignee: Rishi Solanki
>Priority: Minor
> Attachments: OFBIZ-10239.patch,
> OFBIZ-10239_SetAccountingTransactionDates.patch
>
>
> Whenever user applies a payment, the {color:#008000}transactionDate
> {color}set on AcctgTransEntries is set by
> {color:#80}now-timestamp{color}, this can result in wrong accounting
> reports, if the payment was received earlier but applied later.
> For example, if someone receives a payment on 28 of Dec and applies the
> payment on 3rd of Jan, the yearly accounting reports will show that
> transaction in the new year, rather than in the previous year.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10239) Improve GeneralLedgerServices to set AcctgTrans's transition date as payment's effective date
[
https://issues.apache.org/jira/browse/OFBIZ-10239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739002#comment-16739002
]
Paul Foxworthy commented on OFBIZ-10239:
Hi [~rishisolankii] and [~aishwary],
I have encountered this issue and I think your fix is on the right track.
The transaction date is already being set for a Sales Invoice
([https://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml?view=markup#l2345)]
and an Incoming Payment
([https://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml?view=markup#l1818).]
and all we are trying to do is add an explicit date for other accounting
transactions as well.
[~jacopoc] made a similar change for Purchase Invoices in r1658662
[https://svn.apache.org/viewvc?view=revision=1658662] in 2015.
In addition, I believe a similar change should be done for Shipment Receipts
and Customer Refund Payment Applications. I have attached a new patch. What do
you think?
I gather a unit test was failing on buildbot so you reverted your change. Which
test? I think there might be a bug in the test.
> Improve GeneralLedgerServices to set AcctgTrans's transition date as
> payment's effective date
> -
>
> Key: OFBIZ-10239
> URL: https://issues.apache.org/jira/browse/OFBIZ-10239
> Project: OFBiz
> Issue Type: Improvement
> Components: accounting
>Reporter: Aishwary Shrivastava
>Assignee: Rishi Solanki
>Priority: Minor
> Attachments: OFBIZ-10239.patch
>
>
> Whenever user applies a payment, the {color:#008000}transactionDate
> {color}set on AcctgTransEntries is set by
> {color:#80}now-timestamp{color}, this can result in wrong accounting
> reports, if the payment was received earlier but applied later.
> For example, if someone receives a payment on 28 of Dec and applies the
> payment on 3rd of Jan, the yearly accounting reports will show that
> transaction in the new year, rather than in the previous year.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (OFBIZ-9677) In packing, only use reservations with stock on hand
[ https://issues.apache.org/jira/browse/OFBIZ-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy closed OFBIZ-9677. - > In packing, only use reservations with stock on hand > > > Key: OFBIZ-9677 > URL: https://issues.apache.org/jira/browse/OFBIZ-9677 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Trunk >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Major > Labels: pack, reservation > Fix For: Trunk > > Attachments: OFBIZ-9677_PackingIgnoreBackorderReservations.patch, > OFBIZ-9677_PackingIgnoreBackorderReservations.patch > > > During packing, OFBiz looks for reservations (OrderItemShipGrpInvRes) for the > order item. Some reservations are for back ordered items not on hand. These > reservations should not be used during packing, but they are. > The attached patch fixes this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-9677) In packing, only use reservations with stock on hand
[ https://issues.apache.org/jira/browse/OFBIZ-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16738959#comment-16738959 ] Paul Foxworthy commented on OFBIZ-9677: --- Committed in r1850914. > In packing, only use reservations with stock on hand > > > Key: OFBIZ-9677 > URL: https://issues.apache.org/jira/browse/OFBIZ-9677 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Trunk >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Major > Labels: pack, reservation > Attachments: OFBIZ-9677_PackingIgnoreBackorderReservations.patch, > OFBIZ-9677_PackingIgnoreBackorderReservations.patch > > > During packing, OFBiz looks for reservations (OrderItemShipGrpInvRes) for the > order item. Some reservations are for back ordered items not on hand. These > reservations should not be used during packing, but they are. > The attached patch fixes this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-6807) UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema with publicId [null] and the file/resource is [web-app_3_0.xsd]
[
https://issues.apache.org/jira/browse/OFBIZ-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16722653#comment-16722653
]
Paul Foxworthy commented on OFBIZ-6807:
---
Hi Jacques,
Yes, I agree proper use of XML namespaces should be a separate issue. The
Eclipse catalogs may not work for other IDEs, so we may need to maintain
several versions. It shouldn't be too hard because we won't be defining new XML
schemas and namespaces very often. Mostly we'd just change details within them,
and that won't affect the catalog or catalogs.
> UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema with
> publicId [null] and the file/resource is [web-app_3_0.xsd]
>
>
> Key: OFBIZ-6807
> URL: https://issues.apache.org/jira/browse/OFBIZ-6807
> Project: OFBiz
> Issue Type: Bug
>Affects Versions: Release Branch 14.12, Trunk, Release Branch 15.12
>Reporter: Deepak Dixit
>Assignee: Jacques Le Roux
>Priority: Trivial
>
> System throws following exception on server start:
> {code}
> [java] 2016-01-16 15:04:50,942 |catalina-startup-2 |UtilXml
> |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL
> DTD/Schema with publicId [null] and the file/resource is [web-app_3_0.xsd]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-6882) Extend the PostalAddress entity with additional elements
[ https://issues.apache.org/jira/browse/OFBIZ-6882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16420011#comment-16420011 ] Paul Foxworthy commented on OFBIZ-6882: --- Hi [~pfm.smits], I am not suggesting we blindly follow Google, far from it. Nor am I suggesting Google's data model will do everything we want. Their model could be too big, unwieldy and overly complex. Or it might be too limited and not capture everything we want. What I am saying is when we decide we want to incorporate an item in our own data model, we should try to name that item consistently with other organisations. To my mind, the Universal Postal Union names are more important than Google's, but they both have some relevance. UPU S42 is trying to set up standard templates for addresses for different countries. So while there is variation in the components and the ordering of those components within a postal address, the template for a country defines what the components are for a well-formed address. In general, we should be informed by standards like this and attempt to follow them. Inventing our own arbitrary names will lead to confusion and the danger we might need to rename them in future. Specifically, street number and street name are common components of addresses in many places in the world. Because they are well known and widely used, we should choose names for these items with care. Cheers Paul Foxworthy > Extend the PostalAddress entity with additional elements > > > Key: OFBIZ-6882 > URL: https://issues.apache.org/jira/browse/OFBIZ-6882 > Project: OFBiz > Issue Type: Improvement > Components: party >Affects Versions: Trunk >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > Labels: 3rdParty, Shipment, integration > Fix For: 16.11.01 > > Attachments: OFBIZ-6882-party-PostalAddress.patch > > > Various modern day 3rd party delivery solutions (e.g. PostNL in The > Netherlands) require that elements are delivered separately, so that > addresses can be checked more easily. > Current definition of the PostalAddress doesn't have separation of: > * street name > * house number > * house number addition or extension -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-6882) Extend the PostalAddress entity with additional elements
[ https://issues.apache.org/jira/browse/OFBIZ-6882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413347#comment-16413347 ] Paul Foxworthy commented on OFBIZ-6882: --- Hi all, The Universal Postal Union has a project to standardise exchange of postal addresses, UPU S42. ([http://www.upu.int/uploads/tx_sbdownloader/sheetAddressingS42InternationalAddressingStandardsFactSheetEn.pdf).] The name, in English, for the number component is "street number" or "street no" for short. Google geocoding uses "street_number" ([https://developers.google.com/maps/documentation/javascript/geocoding#GeocodingAddressTypes).] > Extend the PostalAddress entity with additional elements > > > Key: OFBIZ-6882 > URL: https://issues.apache.org/jira/browse/OFBIZ-6882 > Project: OFBiz > Issue Type: Improvement > Components: party >Affects Versions: Trunk >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > Labels: 3rdParty, Shipment, integration > Fix For: 16.11.01 > > Attachments: OFBIZ-6882-party-PostalAddress.patch > > > Various modern day 3rd party delivery solutions (e.g. PostNL in The > Netherlands) require that elements are delivered separately, so that > addresses can be checked more easily. > Current definition of the PostalAddress doesn't have separation of: > * street name > * house number > * house number addition or extension -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-9677) In packing, only use reservations with stock on hand
[ https://issues.apache.org/jira/browse/OFBIZ-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16407530#comment-16407530 ] Paul Foxworthy commented on OFBIZ-9677: --- Updated patch that fixes nasty problem when there was only one reservation - it was packing quantity from the reservation, not the quantity the user asked for. > In packing, only use reservations with stock on hand > > > Key: OFBIZ-9677 > URL: https://issues.apache.org/jira/browse/OFBIZ-9677 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Trunk >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Major > Labels: pack, reservation > Attachments: OFBIZ-9677_PackingIgnoreBackorderReservations.patch, > OFBIZ-9677_PackingIgnoreBackorderReservations.patch > > > During packing, OFBiz looks for reservations (OrderItemShipGrpInvRes) for the > order item. Some reservations are for back ordered items not on hand. These > reservations should not be used during packing, but they are. > The attached patch fixes this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-9677) In packing, only use reservations with stock on hand
[ https://issues.apache.org/jira/browse/OFBIZ-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-9677: -- Attachment: OFBIZ-9677_PackingIgnoreBackorderReservations.patch > In packing, only use reservations with stock on hand > > > Key: OFBIZ-9677 > URL: https://issues.apache.org/jira/browse/OFBIZ-9677 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Trunk >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Major > Labels: pack, reservation > Attachments: OFBIZ-9677_PackingIgnoreBackorderReservations.patch, > OFBIZ-9677_PackingIgnoreBackorderReservations.patch > > > During packing, OFBiz looks for reservations (OrderItemShipGrpInvRes) for the > order item. Some reservations are for back ordered items not on hand. These > reservations should not be used during packing, but they are. > The attached patch fixes this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-9492) Tax Authorities need two GL accounts for sales and purchases
[ https://issues.apache.org/jira/browse/OFBIZ-9492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-9492: -- Description: In jurisdictions with Value Added Tax, you need to track tax you have paid on purchases, and tax you have collected with sales. When you report to a tax authority, you pay them the difference between the two, i.e. you pay tax on the value added, not on your inputs. OFBiz has an entity, TaxAuthorityGlAccount (TAGLA), which currently assumes the GL account is for a sale. We need to extend OFBiz so it is possible to find two GL accounts for a tax authority, one for sales and one for purchases. I propose: - add new attributes to the TaxAuthorityGlAccount entity: acctgTransTypeId (one of SALES_INVOICE, PURCHASE_INVOICE and CUST_RTN_INVOICE) and taxAuthorityRateTypeId (values might be for example VAT_TAX, GST). The new attributes should be included in the primary key. - Add a new service in TaxAuthorityServices named getTaxAuthorityGlAccountId which looks up a TAGLA given primary key values, including the transaction type - There are two places in TaxAuthorityServices that would call getTaxAuthorityGlAccountId: getTaxAdjustments and getItemTaxAdjustments, one for orders, and the other for invoice item types. The transaction type can be inferred from the order type or the invoice item type - createAcctgTransForPurchaseInvoice and createAcctgTransForCustomerReturnInvoice should use getTaxAuthorityGlAccountId - createAcctgTransactionForSalesInvoice should be rewritten to use getTaxAuthorityGlAccountId. I am working on a patch to do this, but I'd like your thoughts on my proposal was: In jurisdictions with Value Added Tax, you need to track tax you have paid on purchases, and tax you have collected with sales. When you report to a tax authority, you pay them the difference between the two, i.e. you pay tax on the value added, not on your inputs. OFBiz has an entity, TaxAuthorityGlAccount (TAGLA), which currently assumes the GL account is for a sale. We need to extend OFBiz so it is possible to find two GL accounts for a tax authority, one for sales and one for purchases. I propose: - add new attributes to the TaxAuthorityGlAccount entity: acctgTransTypeId (one of SALES_INVOICE, PURCHASE_INVOICE and CUST_RTN_INVOICE) and taxAuthorityRateTypeId (values might be for example VAT_TAX, GST). The new attributes should be included in the primary key. - Add a new service in TaxAuthorityServices named getTaxAuthorityGlAccountId which looks up a TAGLA given primary key values, including the direction - There are two places in TaxAuthorityServices that would call getTaxAuthorityGlAccountId: getTaxAdjustments and getItemTaxAdjustments, one for orders, and the other for invoice item types. The transaction type can be inferred from the order type or the invoice item type - createAcctgTransForPurchaseInvoice and createAcctgTransForCustomerReturnInvoice should use getTaxAuthorityGlAccountId - createAcctgTransactionForSalesInvoice should be rewritten to use getTaxAuthorityGlAccountId. I am working on a patch to do this, but I'd like your thoughts on my proposal > Tax Authorities need two GL accounts for sales and purchases > > > Key: OFBIZ-9492 > URL: https://issues.apache.org/jira/browse/OFBIZ-9492 > Project: OFBiz > Issue Type: Improvement > Components: accounting >Affects Versions: Trunk >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Major > Labels: accounting, vat > > In jurisdictions with Value Added Tax, you need to track tax you have paid on > purchases, and tax you have collected with sales. When you report to a tax > authority, you pay them the difference between the two, i.e. you pay tax on > the value added, not on your inputs. > OFBiz has an entity, TaxAuthorityGlAccount (TAGLA), which currently assumes > the GL account is for a sale. > We need to extend OFBiz so it is possible to find two GL accounts for a tax > authority, one for sales and one for purchases. > I propose: > - add new attributes to the TaxAuthorityGlAccount entity: acctgTransTypeId > (one of SALES_INVOICE, PURCHASE_INVOICE and CUST_RTN_INVOICE) and > taxAuthorityRateTypeId (values might be for example VAT_TAX, GST). The new > attributes should be included in the primary key. > - Add a new service in TaxAuthorityServices named getTaxAuthorityGlAccountId > which > looks up a TAGLA given primary key values, including the transaction type > - There are two places in TaxAuthorityServices that would call > getTaxAuthorityGlAccountId: getTaxAdjustments and getItemTaxAdjustments, one > for orders, and the other for invoice item types. The transaction type can be > inferred from the
[jira] [Commented] (OFBIZ-9492) Tax Authorities need two GL accounts for sales and purchases
[ https://issues.apache.org/jira/browse/OFBIZ-9492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16370010#comment-16370010 ] Paul Foxworthy commented on OFBIZ-9492: --- Revised description based on the discussion. > Tax Authorities need two GL accounts for sales and purchases > > > Key: OFBIZ-9492 > URL: https://issues.apache.org/jira/browse/OFBIZ-9492 > Project: OFBiz > Issue Type: Improvement > Components: accounting >Affects Versions: Trunk >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Major > Labels: accounting, vat > > In jurisdictions with Value Added Tax, you need to track tax you have paid on > purchases, and tax you have collected with sales. When you report to a tax > authority, you pay them the difference between the two, i.e. you pay tax on > the value added, not on your inputs. > OFBiz has an entity, TaxAuthorityGlAccount (TAGLA), which currently assumes > the GL account is for a sale. > We need to extend OFBiz so it is possible to find two GL accounts for a tax > authority, one for sales and one for purchases. > I propose: > - add new attributes to the TaxAuthorityGlAccount entity: acctgTransTypeId > (one of SALES_INVOICE, PURCHASE_INVOICE and CUST_RTN_INVOICE) and > taxAuthorityRateTypeId (values might be for example VAT_TAX, GST). The new > attributes should be included in the primary key. > - Add a new service in TaxAuthorityServices named getTaxAuthorityGlAccountId > which > looks up a TAGLA given primary key values, including the direction > - There are two places in TaxAuthorityServices that would call > getTaxAuthorityGlAccountId: getTaxAdjustments and getItemTaxAdjustments, one > for orders, and the other for invoice item types. The transaction type can be > inferred from the order type or the invoice item type > - createAcctgTransForPurchaseInvoice and > createAcctgTransForCustomerReturnInvoice > should use getTaxAuthorityGlAccountId > - createAcctgTransactionForSalesInvoice should be rewritten to use > getTaxAuthorityGlAccountId. > I am working on a patch to do this, but I'd like your thoughts on my proposal -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-9492) Tax Authorities need two GL accounts for sales and purchases
[ https://issues.apache.org/jira/browse/OFBIZ-9492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-9492: -- Description: In jurisdictions with Value Added Tax, you need to track tax you have paid on purchases, and tax you have collected with sales. When you report to a tax authority, you pay them the difference between the two, i.e. you pay tax on the value added, not on your inputs. OFBiz has an entity, TaxAuthorityGlAccount (TAGLA), which currently assumes the GL account is for a sale. We need to extend OFBiz so it is possible to find two GL accounts for a tax authority, one for sales and one for purchases. I propose: - add new attributes to the TaxAuthorityGlAccount entity: acctgTransTypeId (one of SALES_INVOICE, PURCHASE_INVOICE and CUST_RTN_INVOICE) and taxAuthorityRateTypeId (values might be for example VAT_TAX, GST). The new attributes should be included in the primary key. - Add a new service in TaxAuthorityServices named getTaxAuthorityGlAccountId which looks up a TAGLA given primary key values, including the direction - There are two places in TaxAuthorityServices that would call getTaxAuthorityGlAccountId: getTaxAdjustments and getItemTaxAdjustments, one for orders, and the other for invoice item types. The transaction type can be inferred from the order type or the invoice item type - createAcctgTransForPurchaseInvoice and createAcctgTransForCustomerReturnInvoice should use getTaxAuthorityGlAccountId - createAcctgTransactionForSalesInvoice should be rewritten to use getTaxAuthorityGlAccountId. I am working on a patch to do this, but I'd like your thoughts on my proposal was: In jurisdictions with Value Added Tax, you need to track tax you have paid on purchases, and tax you have collected with sales. When you report to a tax authority, you pay them the difference between the two, i.e. you pay tax on the value added, not on your inputs. OFBiz has an entity, TaxAuthorityGlAccount (TAGLA), which currently assumes the GL account is for a sale. We need to extend OFBiz so it is possible to find two GL accounts for a tax authority, one for sales and one for purchases. I propose: - add new attributes to the TaxAuthorityGlAccount entity: acctgTransTypeId(one of The new attribute should be included in the primary key. - Add a new service in TaxAuthorityServices named getTaxAuthorityGlAccountId which looks up a TAGLA given primary key values, including the direction - There are two places in TaxAuthorityServices that would call getTaxAuthorityGlAccountId: getTaxAdjustments and getItemTaxAdjustments, one for orders, and the other for invoice item types. The direction can be inferred from the order type or the invoice item type - createAcctgTransForPurchaseInvoice and createAcctgTransForCustomerReturnInvoice should use getTaxAuthorityGlAccountId - createAcctgTransactionForSalesInvoice should be rewritten to use getTaxAuthorityGlAccountId. I am working on a patch to do this, but I'd like your thoughts on my proposal > Tax Authorities need two GL accounts for sales and purchases > > > Key: OFBIZ-9492 > URL: https://issues.apache.org/jira/browse/OFBIZ-9492 > Project: OFBiz > Issue Type: Improvement > Components: accounting >Affects Versions: Trunk >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Major > Labels: accounting, vat > > In jurisdictions with Value Added Tax, you need to track tax you have paid on > purchases, and tax you have collected with sales. When you report to a tax > authority, you pay them the difference between the two, i.e. you pay tax on > the value added, not on your inputs. > OFBiz has an entity, TaxAuthorityGlAccount (TAGLA), which currently assumes > the GL account is for a sale. > We need to extend OFBiz so it is possible to find two GL accounts for a tax > authority, one for sales and one for purchases. > I propose: > - add new attributes to the TaxAuthorityGlAccount entity: acctgTransTypeId > (one of SALES_INVOICE, PURCHASE_INVOICE and CUST_RTN_INVOICE) and > taxAuthorityRateTypeId (values might be for example VAT_TAX, GST). The new > attributes should be included in the primary key. > - Add a new service in TaxAuthorityServices named getTaxAuthorityGlAccountId > which > looks up a TAGLA given primary key values, including the direction > - There are two places in TaxAuthorityServices that would call > getTaxAuthorityGlAccountId: getTaxAdjustments and getItemTaxAdjustments, one > for orders, and the other for invoice item types. The transaction type can be > inferred from the order type or the invoice item type > - createAcctgTransForPurchaseInvoice and > createAcctgTransForCustomerReturnInvoice > should use
[jira] [Closed] (OFBIZ-4514) Taxes are not handled correctly when creating accounting transactions from purchase invoices
[ https://issues.apache.org/jira/browse/OFBIZ-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy closed OFBIZ-4514. - > Taxes are not handled correctly when creating accounting transactions from > purchase invoices > > > Key: OFBIZ-4514 > URL: https://issues.apache.org/jira/browse/OFBIZ-4514 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: Trunk >Reporter: Martin Kreidenweis >Assignee: Paul Foxworthy >Priority: Trivial > Labels: VAT, tax > Fix For: 17.12.01, 16.11.05, Upcoming Branch > > Attachments: OFBIZ-4514.patch, OFBIZ-4514_combined.patch > > > Taxes are not handled correctly when creating accounting transactions from > purchase invoices in GeneralLedgerServices#createAcctgTransForPurchaseInvoice -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-4514) Taxes are not handled correctly when creating accounting transactions from purchase invoices
[ https://issues.apache.org/jira/browse/OFBIZ-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369053#comment-16369053 ] Paul Foxworthy commented on OFBIZ-4514: --- I've committed a fix for OFBIZ-6330 which fixes this. > Taxes are not handled correctly when creating accounting transactions from > purchase invoices > > > Key: OFBIZ-4514 > URL: https://issues.apache.org/jira/browse/OFBIZ-4514 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: Trunk >Reporter: Martin Kreidenweis >Assignee: Paul Foxworthy >Priority: Trivial > Labels: VAT, tax > Attachments: OFBIZ-4514.patch, OFBIZ-4514_combined.patch > > > Taxes are not handled correctly when creating accounting transactions from > purchase invoices in GeneralLedgerServices#createAcctgTransForPurchaseInvoice -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-5936) Invoice transactions for purchase order sale tax not supported
[ https://issues.apache.org/jira/browse/OFBIZ-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy closed OFBIZ-5936. - > Invoice transactions for purchase order sale tax not supported > -- > > Key: OFBIZ-5936 > URL: https://issues.apache.org/jira/browse/OFBIZ-5936 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: Trunk >Reporter: Christian Carlow >Priority: Major > Attachments: MissingTaxEntry.pdf, TransacationNotGettingPosted.pdf > > > Invoice transactions for sales tax adjustments manually added to purchase > orders are not supported leading to an error when attempting to change the > invoice status to "Ready for Posting". > GeneralLedgerServices.xml#createAcctgTransForPurchaseInvoice does not include > logic to set the glAccountTypeId for purchase invoices for item type > PITM_SALES_TAX. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-6330) The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice service
[
https://issues.apache.org/jira/browse/OFBIZ-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Foxworthy closed OFBIZ-6330.
-
> The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice
> service
>
>
> Key: OFBIZ-6330
> URL: https://issues.apache.org/jira/browse/OFBIZ-6330
> Project: OFBiz
> Issue Type: Bug
> Components: accounting
>Affects Versions: Trunk
>Reporter: Kongrath Suankaewmanee
>Assignee: Paul Foxworthy
>Priority: Major
> Labels: tax, vat
> Fix For: 17.12.01, 16.11.05, Upcoming Branch
>
> Attachments: GL.PNG, GeneralLedgerServices.patch, JORTAXAUTH.PNG,
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns-alternative.patch,
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch,
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch,
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns_inline.patch,
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns_inline.patch, pic01.PNG,
> pic02.png
>
>
> Hi All,
> Scenario: The sum of debit and credit in InvoiceAcctgTransEntriesPdf of
> purchase invoice are not equal.
> Question: I'm not sure why the createAcctgTransForPurchaseInvoice service did
> not call the method to get invoiceTaxTotal.
> {code}
> class-name="org.ofbiz.accounting.invoice.InvoiceWorker"
> ret-field="invoiceTaxTotal">
>
>
> {code}
> And the invoiceTaxTotal value needs to add to totalAmountFromInvoice via code
> below:
> {code}
> decimal-scale="${ledgerDecimals}" rounding-mode="${roundingMode}">
>
>
>
>
>
> {code}
> That it should work like the createAcctgTransForSalesInvoice service of the
> sales invoice.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-6330) The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice service
[
https://issues.apache.org/jira/browse/OFBIZ-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369047#comment-16369047
]
Paul Foxworthy commented on OFBIZ-6330:
---
Committed to:
trunk in r1824740, release16.11 in r1824742, release17.12 in r1824743.
> The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice
> service
>
>
> Key: OFBIZ-6330
> URL: https://issues.apache.org/jira/browse/OFBIZ-6330
> Project: OFBiz
> Issue Type: Bug
> Components: accounting
>Affects Versions: Trunk
>Reporter: Kongrath Suankaewmanee
>Assignee: Paul Foxworthy
>Priority: Major
> Labels: tax, vat
> Attachments: GL.PNG, GeneralLedgerServices.patch, JORTAXAUTH.PNG,
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns-alternative.patch,
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch,
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch,
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns_inline.patch,
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns_inline.patch, pic01.PNG,
> pic02.png
>
>
> Hi All,
> Scenario: The sum of debit and credit in InvoiceAcctgTransEntriesPdf of
> purchase invoice are not equal.
> Question: I'm not sure why the createAcctgTransForPurchaseInvoice service did
> not call the method to get invoiceTaxTotal.
> {code}
> class-name="org.ofbiz.accounting.invoice.InvoiceWorker"
> ret-field="invoiceTaxTotal">
>
>
> {code}
> And the invoiceTaxTotal value needs to add to totalAmountFromInvoice via code
> below:
> {code}
> decimal-scale="${ledgerDecimals}" rounding-mode="${roundingMode}">
>
>
>
>
>
> {code}
> That it should work like the createAcctgTransForSalesInvoice service of the
> sales invoice.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-6330) The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice service
[
https://issues.apache.org/jira/browse/OFBIZ-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16365371#comment-16365371
]
Paul Foxworthy commented on OFBIZ-6330:
---
I've made a minor change to the patch, adding a few comments. If there are no
objections I'll commit this.
> The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice
> service
>
>
> Key: OFBIZ-6330
> URL: https://issues.apache.org/jira/browse/OFBIZ-6330
> Project: OFBiz
> Issue Type: Bug
> Components: accounting
>Affects Versions: Trunk
>Reporter: Kongrath Suankaewmanee
>Assignee: Paul Foxworthy
>Priority: Major
> Labels: tax, vat
> Attachments: GL.PNG, GeneralLedgerServices.patch, JORTAXAUTH.PNG,
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns-alternative.patch,
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch,
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch,
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns_inline.patch,
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns_inline.patch, pic01.PNG,
> pic02.png
>
>
> Hi All,
> Scenario: The sum of debit and credit in InvoiceAcctgTransEntriesPdf of
> purchase invoice are not equal.
> Question: I'm not sure why the createAcctgTransForPurchaseInvoice service did
> not call the method to get invoiceTaxTotal.
> {code}
> class-name="org.ofbiz.accounting.invoice.InvoiceWorker"
> ret-field="invoiceTaxTotal">
>
>
> {code}
> And the invoiceTaxTotal value needs to add to totalAmountFromInvoice via code
> below:
> {code}
> decimal-scale="${ledgerDecimals}" rounding-mode="${roundingMode}">
>
>
>
>
>
> {code}
> That it should work like the createAcctgTransForSalesInvoice service of the
> sales invoice.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OFBIZ-6330) The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice service
[
https://issues.apache.org/jira/browse/OFBIZ-6330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Foxworthy updated OFBIZ-6330:
--
Attachment: OFBIZ-6330_TaxAccountingOnPurchasesAndReturns_inline.patch
> The invoiceTaxTotal value is missing from createAcctgTransForPurchaseInvoice
> service
>
>
> Key: OFBIZ-6330
> URL: https://issues.apache.org/jira/browse/OFBIZ-6330
> Project: OFBiz
> Issue Type: Bug
> Components: accounting
>Affects Versions: Trunk
>Reporter: Kongrath Suankaewmanee
>Assignee: Paul Foxworthy
>Priority: Major
> Labels: tax, vat
> Attachments: GL.PNG, GeneralLedgerServices.patch, JORTAXAUTH.PNG,
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns-alternative.patch,
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch,
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns.patch,
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns_inline.patch,
> OFBIZ-6330_TaxAccountingOnPurchasesAndReturns_inline.patch, pic01.PNG,
> pic02.png
>
>
> Hi All,
> Scenario: The sum of debit and credit in InvoiceAcctgTransEntriesPdf of
> purchase invoice are not equal.
> Question: I'm not sure why the createAcctgTransForPurchaseInvoice service did
> not call the method to get invoiceTaxTotal.
> {code}
> class-name="org.ofbiz.accounting.invoice.InvoiceWorker"
> ret-field="invoiceTaxTotal">
>
>
> {code}
> And the invoiceTaxTotal value needs to add to totalAmountFromInvoice via code
> below:
> {code}
> decimal-scale="${ledgerDecimals}" rounding-mode="${roundingMode}">
>
>
>
>
>
> {code}
> That it should work like the createAcctgTransForSalesInvoice service of the
> sales invoice.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-7754) The big problem when load seed.
[ https://issues.apache.org/jira/browse/OFBIZ-7754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16357697#comment-16357697 ] Paul Foxworthy commented on OFBIZ-7754: --- Hi [~arunpati] and all, Please not "NULL-FIELD". >From https://issues.apache.org/jira/browse/OFBIZ-4602: There is a canonical way from the XML standards to express that an XML element is null. Rather than reserving a special value for the data within the element, there's a special *attribute* xsi:nil. Schemas can define a corresponding nillable attribute to say it is possible for an element to use the xsi:nil attribute. See [http://www.w3.org/TR/xmlschema-0/#Nils] and [http://docstore.mik.ua/orelly/xml/schema/ch11_03.htm] . Thanks Paul > The big problem when load seed. > --- > > Key: OFBIZ-7754 > URL: https://issues.apache.org/jira/browse/OFBIZ-7754 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Kongrath Suankaewmanee >Priority: Major > Attachments: OFBIZ-7754-SystemProperties.patch, OFBIZ-7754.patch > > > Hi All, > Regarding, [OFBIZ-7112|https://issues.apache.org/jira/browse/OFBIZ-7112] > That's good for who start on use the ofbiz with initial setup, but not for > the site that already online and has to update the OFBiz core. Because when > has update OFBiz core they will use command load-seed for update. > The problem is if we use load-seed mean the configuration data that's already > exists will be replaced by the data from this file, > *CommonSystemPropertyData.xml* > So, for my suggestion should change the reader from *seed* to *seed-initial* > or remove systemPropertyValue from the data file. > Thank you, > Kongrath -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-6722) Service createAcctgTransForPurchaseInvoice doesn't work as that I expected
[ https://issues.apache.org/jira/browse/OFBIZ-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16357658#comment-16357658 ] Paul Foxworthy commented on OFBIZ-6722: --- Hi [~kongrath] , Once again I find you're ahead of me looking into the mysteries of GL transactions in OFBiz. The thread at [http://ofbiz.135035.n4.nabble.com/Invoice-Item-type-copied-into-GL-Account-type-td4702167.html] discussed this issue. It is true that an invoice item type is being copied into a GL account type ([https://github.com/apache/ofbiz-framework/blob/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml#L2174).] That is sort-of fixed in getGlAccountFromAccountType: at [https://github.com/apache/ofbiz-framework/blob/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml#L533|https://github.com/apache/ofbiz-framework/blob/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml#L533,] So you can think of the glAccountTypeId parameter as being overloaded, or if you like misnamed. For some transactions, it carries a GL account type, but for sales and purchase invoices, it has an invoice item type instead. The fundamental problem is that the services to create accounting entries are building arrays of AcctgTransEntry records to pass to getGlAccountFromAccountType . getGlAccountFromAccountType needs more inputs, in particular the invoice item type, to make its decisions. Those inputs are not in AcctgTransEntry - its glAccount is set as the result of getGlAccountFromAccountType. So AcctgTransEntry is an output of getGlAccountFromAccountType. The fix is to broaden the communication to getGlAccountFromAccountType. Possibilities I see are: # add an attribute to AcctgTransEntry for the invoice item type. I really don't like this idea. It's redundant, the invoice item type is only one input into getGlAccountFromAccountType's decision making, and many transactions are not sales and purchases and do not have invoice item types # Populate and pass a parallel array of additional data beside the AcctgTransEntry array. While other places in OFBiz do this, there's poor cohesion. I don't like this much either # Make the array into a simple array of maps, and not AcctgTransEntry GenericValues. Then we can add any extra inputs we like. There are some risks because we won't have the error checking on attribute you normally get from a GenericValue. I still think this is the best option. # Make sure getGlAccountFromAccountType can fetch and read the invoice item including its invoice item type, and not pass an invoice item type at all. I haven't investigated this, but it seems feasible and will probably be a smaller change than option 3. There would be a slight performance hit from re-fetching the invoice item. What does everyone think? Paul Foxworthy > Service createAcctgTransForPurchaseInvoice doesn't work as that I expected > -- > > Key: OFBIZ-6722 > URL: https://issues.apache.org/jira/browse/OFBIZ-6722 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: Trunk >Reporter: Kongrath Suankaewmanee >Assignee: Paul Foxworthy >Priority: Major > > The problem, I want to link the glAccountId to the transaction when the > status invoice has set to "Ready to Post" and the transaction will create > automatically. > Can someone help me to check or give the reason about > createAcctgTransForPurchaseInvoice service, why we need to use this : > from-field="invoiceItem.invoiceItemTypeId"/> > It looks very strange because glAccountTypeId and invoiceItemTypeId filed > didn't link to each other. > And how we can get the glAccountId for this simple-method? > short-description="Gets ProductGlAccount on the basis of primary key" > > value-field="productGlAccount" use-cache="true"/> > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (OFBIZ-6722) Service createAcctgTransForPurchaseInvoice doesn't work as that I expected
[ https://issues.apache.org/jira/browse/OFBIZ-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy reassigned OFBIZ-6722: - Assignee: Paul Foxworthy > Service createAcctgTransForPurchaseInvoice doesn't work as that I expected > -- > > Key: OFBIZ-6722 > URL: https://issues.apache.org/jira/browse/OFBIZ-6722 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: Trunk >Reporter: Kongrath Suankaewmanee >Assignee: Paul Foxworthy >Priority: Major > > The problem, I want to link the glAccountId to the transaction when the > status invoice has set to "Ready to Post" and the transaction will create > automatically. > Can someone help me to check or give the reason about > createAcctgTransForPurchaseInvoice service, why we need to use this : > from-field="invoiceItem.invoiceItemTypeId"/> > It looks very strange because glAccountTypeId and invoiceItemTypeId filed > didn't link to each other. > And how we can get the glAccountId for this simple-method? > short-description="Gets ProductGlAccount on the basis of primary key" > > value-field="productGlAccount" use-cache="true"/> > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (OFBIZ-6722) Service createAcctgTransForPurchaseInvoice doesn't work as that I expected
[ https://issues.apache.org/jira/browse/OFBIZ-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy reopened OFBIZ-6722: --- This *is* an issue that requires attention. > Service createAcctgTransForPurchaseInvoice doesn't work as that I expected > -- > > Key: OFBIZ-6722 > URL: https://issues.apache.org/jira/browse/OFBIZ-6722 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: Trunk >Reporter: Kongrath Suankaewmanee >Assignee: Paul Foxworthy >Priority: Major > > The problem, I want to link the glAccountId to the transaction when the > status invoice has set to "Ready to Post" and the transaction will create > automatically. > Can someone help me to check or give the reason about > createAcctgTransForPurchaseInvoice service, why we need to use this : > from-field="invoiceItem.invoiceItemTypeId"/> > It looks very strange because glAccountTypeId and invoiceItemTypeId filed > didn't link to each other. > And how we can get the glAccountId for this simple-method? > short-description="Gets ProductGlAccount on the basis of primary key" > > value-field="productGlAccount" use-cache="true"/> > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-10158) Find Employee Position does not allow "don't care" for boolean fields
[ https://issues.apache.org/jira/browse/OFBIZ-10158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy closed OFBIZ-10158. -- > Find Employee Position does not allow "don't care" for boolean fields > - > > Key: OFBIZ-10158 > URL: https://issues.apache.org/jira/browse/OFBIZ-10158 > Project: OFBiz > Issue Type: Bug > Components: humanres >Affects Versions: Trunk >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Fix For: Trunk > > Attachments: OFBIZ-10158_FindEmplPosition_booleans.patch > > > In the demo app, go to > https://demo-stable.ofbiz.apache.org/humanres/control/FindEmplPositions, > click on New Employee Position, and toggle one of the four flags, e.g. set > Temporary Flag to N. > Now on the Find screen, there is no way to find all employee positions: it > insists on a Yes or No for the flags. This patch allows a blank "don't care" > option. > Thanks to Larissa Zanoni at Blockfreight for discovering this issue. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-10158) Find Employee Position does not allow "don't care" for boolean fields
[ https://issues.apache.org/jira/browse/OFBIZ-10158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16323630#comment-16323630 ] Paul Foxworthy commented on OFBIZ-10158: Fixed in r1820949 > Find Employee Position does not allow "don't care" for boolean fields > - > > Key: OFBIZ-10158 > URL: https://issues.apache.org/jira/browse/OFBIZ-10158 > Project: OFBiz > Issue Type: Bug > Components: humanres >Affects Versions: Trunk >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: OFBIZ-10158_FindEmplPosition_booleans.patch > > > In the demo app, go to > https://demo-stable.ofbiz.apache.org/humanres/control/FindEmplPositions, > click on New Employee Position, and toggle one of the four flags, e.g. set > Temporary Flag to N. > Now on the Find screen, there is no way to find all employee positions: it > insists on a Yes or No for the flags. This patch allows a blank "don't care" > option. > Thanks to Larissa Zanoni at Blockfreight for discovering this issue. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OFBIZ-10158) Find Employee Position does not allow "don't care" for boolean fields
[ https://issues.apache.org/jira/browse/OFBIZ-10158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-10158: --- Description: In the demo app, go to https://demo-stable.ofbiz.apache.org/humanres/control/FindEmplPositions, click on New Employee Position, and toggle one of the four flags, e.g. set Temporary Flag to N. Now on the Find screen, there is no way to find all employee positions: it insists on a Yes or No for the flags. This patch allows a blank "don't care" option. Thanks to Larissa Zanoni at Blockfreight for discovering this issue. was: In the demo app, go to https://demo-stable.ofbiz.apache.org/humanres/control/FindEmplPositions, click on New Employee Position, and toggle one of the four flags, e.g. set Temporary Flag to N. Now on the Find screen, there is no way to find all employee positions: it insists on a Yes or No for the flags. This patch allows a blank "don't care" option. > Find Employee Position does not allow "don't care" for boolean fields > - > > Key: OFBIZ-10158 > URL: https://issues.apache.org/jira/browse/OFBIZ-10158 > Project: OFBiz > Issue Type: Bug > Components: humanres >Affects Versions: Trunk >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > > In the demo app, go to > https://demo-stable.ofbiz.apache.org/humanres/control/FindEmplPositions, > click on New Employee Position, and toggle one of the four flags, e.g. set > Temporary Flag to N. > Now on the Find screen, there is no way to find all employee positions: it > insists on a Yes or No for the flags. This patch allows a blank "don't care" > option. > Thanks to Larissa Zanoni at Blockfreight for discovering this issue. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OFBIZ-10158) Find Employee Position does not allow "don't care" for boolean fields
Paul Foxworthy created OFBIZ-10158: -- Summary: Find Employee Position does not allow "don't care" for boolean fields Key: OFBIZ-10158 URL: https://issues.apache.org/jira/browse/OFBIZ-10158 Project: OFBiz Issue Type: Bug Components: humanres Affects Versions: Trunk Reporter: Paul Foxworthy Assignee: Paul Foxworthy Priority: Minor In the demo app, go to https://demo-stable.ofbiz.apache.org/humanres/control/FindEmplPositions, click on New Employee Position, and toggle one of the four flags, e.g. set Temporary Flag to N. Now on the Find screen, there is no way to find all employee positions: it insists on a Yes or No for the flags. This patch allows a blank "don't care" option. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OFBIZ-9464) Accounting quantity transfer should not be zero while transferring inventory from one facility to another
[ https://issues.apache.org/jira/browse/OFBIZ-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16302622#comment-16302622 ] Paul Foxworthy commented on OFBIZ-9464: --- Hi Vaibhav, I think the two are independent of each other. You might use FIFO for inventory, to minimise customers getting old and stale stock, but LIFO for accounting, to ensure you get a higher amount into your Cost Of Goods Sold account. The whole point of COGS_FIFO and COGS_LIFO is that for a given inventory item, the quantity for the purposes of *valuation* of stock can vary from the quantity of *actual* stock. In contrast, the inventory reservation sets a policy on which inventory to reserve for an order. You are reserving actual stock from an actual inventory item in an actual place in your warehouse. createAcctgTransForSalesShipmentIssuance looks for other inventory items for the same product, and may adjust the accountingQuantity on them, and not the accountingQuantity for the inventory item that was shipped. I think all that's necessary is to split out the part of createAcctgTransForSalesShipmentIssuance that deals with adjusting accounting quantity, and use it for your transfer service as well. Hope that helps. > Accounting quantity transfer should not be zero while transferring inventory > from one facility to another > - > > Key: OFBIZ-9464 > URL: https://issues.apache.org/jira/browse/OFBIZ-9464 > Project: OFBiz > Issue Type: Bug >Affects Versions: Trunk >Reporter: Vaibhav Jain >Assignee: Vaibhav Jain > Labels: inventory, stock, valuation > Fix For: 16.11.04 > > Attachments: OFBIZ_9464.patch > > > when we transfer inventory, the accountingQuantityTotal field of > _InventoryItem_ entity is always ZERO. There is no reflection of ATP/QOH in > accountingQuantityTotal. > This will create following issues in the system. > # Accounting quantity total will mismatch with the original quantity in the > facility which shows the wrong result when we calculate facility specific > inventory valuation. > # Inventory reservation also throws an error in some specific case like when > AQT of respective product is zero in the specific facility from when > reservation happens. > As we manage 5 different statuses of inventory transfer in OFBiz and > according to my current understanding these processes are associated with the > respective statuses, which are as show below > Requested: As inventory transfer is requested for another facility. > a)ATP, QOH and AQT should decrease from the inventory item of From Facility > and QOH of To Facility should increase. > b)ATP and AQT should be Zero in To Facility as inventory is not transferred > yet. But QOH should increase at To Facility because QOH shows the > xferquantity later. At the time of the completion of the transfer > ATP = ATP + (QOH - ATP) (Adjustment in case of backorder) > AQT = QOH > b)AQT should not decrease because AQT is used for accounting purpose and as > of now quantity is still in From Facility as the transfer is not done yet. > which shows the xferQuantity later > Scheduled: As inventory transfer is Scheduled for another facility. ATP, QOH > and AQT should not affect in both From Facility and To Facility. > En-route: As inventory is routed to reach at To Facility. Even in this case > ATP, QOH and AQT should not affect in both From Facility and To Facility. > Complete: As inventory transfer is completed > a)ATP, QOH and AQT should not affect at From Facility. > b)QOH will be same but ATP and AQT should affect respectively > ATP = ATP + (QOH - ATP) > AQT = QOH > Cancelled: As inventory transfer is cancelled and inventory item record is > already created so > a) ATP, QOH and AQT should decrease from old inventory item and ATP, QOH and > AQT should increase in the newly created inventory item. > Key points: > If the whole ATP and QOH is moved then new inventory item will not create. > Only Facility and location are changed for existing inventory item. > Before Changes:- > As I know there are following processes are associated with respective > statuses > **Note: ATP-> Available to promiseQOH-> Quantity on handAQT-> > Accounting quantity total > 1. Requested:- > ATP =0QOH=Transferred quantity >AQT=0 > 2. Scheduled:- > ATP =0QOH=Transferred quantity >AQT=0 > 3.En-Route:- > ATP =0QOH=Transferred quantity >AQT=0 > 4.Complete:- > If the partial quantity of any inventory item is transferred. > ATP =Transferred quantity QOH=Transferred quantity AQT=0 > If the whole quantity is
[jira] [Updated] (OFBIZ-9500) Maintain accountingQuantity for all COGS valuation methods
[ https://issues.apache.org/jira/browse/OFBIZ-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-9500: -- Description: >From >http://ofbiz.135035.n4.nabble.com/AccountingQuantity-COGS-method-and-inventory-valuation-td4700867.html *Why accounting quantity?* When inventory is shipped, there's an accounting transaction that debits the inventory on hand value and credits Cost of Goods Sold (COGS). There's more than one way of deciding what value is added to COGS. First and most obvious is the actual cost of the inventory item. But companies may prefer other strategies. OFBiz has the option of three others: average cost, first-in-first-out or last-in-first-out. There's a nice survey of _why_ you might choose one of these at http://www.dummies.com/business/operations-management/choosing-an-accounting-method-for-the-cost-of-goods-sold-expense/, http://www.dummies.com/business/accounting/the-fifo-method-for-cost-of-goods-sold/, http://www.dummies.com/business/accounting/the-lifo-method-for-cost-of-goods-sold/ Note that if you choose anything other than inventory item cost, the money amount transferred to the COGS account may be *different* to the cost price of the inventory items being shipped. When you choose FIFO or LIFO, the amount may have originated from a different inventory item, received at a different time. *Current situation in OFBiz* The cogsMethodId field in the PartyAcctgPreference entity is a enum with four possible values: COGS_INV_COST, COGS_AVG_COST, COGS_FIFO, COGS_LIFO.. The accountingQuantity field in the InventoryItem entity and accountingQuantityDiff in the InventoryItemDetail entity track the quantity of an item still "live" for the purpose of inventory valuation and COGS. In the service createAcctgTransForShipmentReceipt implemented in /applications/accounting/minilang/ledger/GeneralLedgerServices.xml (http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml?view=markup#l1306) the accountingQuantity is always set to the same value as the quantity received (i.e. the same as the quantityOnHand) for a newly received inventory item regardless of the COGS method. When items are shipped, the service createAcctgTransForSalesShipmentIssuance will only reduce the accounting quantity if the COGS method is FIFO or LIFO (http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml?view=markup#l1127). With FIFO, when an item is shipped, inventory items for the product with a non-zero accounting quantity are found sorted from earliest to latest received. The quantity of the item shipped must be decremented from the accounting quantities, starting with the earliest. Similarly, with LIFO, items are sorted from latest to earliest, and the latest item or items are decremented. In other words, if you have chosen a COGS method of COGS_INV_COST or COGS_AVG_COST, the accounting quantity is meaningless and in OFBiz as of now, should be ignored. And yet, the Inventory Valuation report uses accounting quantity, regardless of the the COGS method (http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/widget/ReportFinancialSummaryForms.xml?view=markup#l535). In other words, the Inventory Valuation report is broken for COGS methods of COGS_INV_COST or COGS_AVG_COST. *What should happen* The Inventory Valuation report, and anybody else who cares, should always be able to trust the accounting quantity. For COGS_INV_COST and COGS_AVG_COST, maintaining the accounting quantity is simple - createAcctgTransForSalesShipmentIssuance should just adjust it to match the remaining quantity on hand for the InventoryItem. So shipping an InventoryItem may cause adjustments to accounting quantities in other items for FIFO and LIFO, but when the COGS method is actual or average cost, the adjustment is always in-place - the actual InventoryItem being shipped. No matter what the COGS method, the total accounting quantity for a product across all inventory items should always be equal to the total QOH. was: >From >http://ofbiz.135035.n4.nabble.com/AccountingQuantity-COGS-method-and-inventory-valuation-td4700867.html *Why accounting quantity?* When inventory is shipped, there's an accounting transaction that debits the inventory on hand value and credits Cost of Goods Sold (COGS). There's more than one way of deciding what value is added to COGS. First and most obvious is the actual cost of the inventory item. But companies may prefer other strategies. OFBiz has the option of three others: average cost, first-in-first-out or last-in-first-out. There's a nice survey of _why_ you might choose one of these at
[jira] [Updated] (OFBIZ-9500) Maintain accountingQuantity for all COGS valuation methods
[ https://issues.apache.org/jira/browse/OFBIZ-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-9500: -- Description: >From >http://ofbiz.135035.n4.nabble.com/AccountingQuantity-COGS-method-and-inventory-valuation-td4700867.html *Why accounting quantity?* When inventory is shipped, there's an accounting transaction that debits the inventory on hand value and credits Cost of Goods Sold (COGS). There's more than one way of deciding what value is added to COGS. First and most obvious is the actual cost of the inventory item. But companies may prefer other strategies. OFBiz has the option of three others: average cost, first-in-first-out or last-in-first-out. There's a nice survey of _why_ you might choose one of these at http://www.dummies.com/business/operations-management/choosing-an-accounting-method-for-the-cost-of-goods-sold-expense/, http://www.dummies.com/business/accounting/the-fifo-method-for-cost-of-goods-sold/, http://www.dummies.com/business/accounting/the-lifo-method-for-cost-of-goods-sold/ Note that if you choose anything other than inventory item cost, the money amount transferred to the COGS account may be *different* to the cost price of the inventory items being shipped. When you choose FIFO or LIFO, the amount may have originated from a different inventory item, received at a different time. *Current situation in OFBiz* The cogsMethodId field in the PartyAcctgPreference entity is a enum with four possible values: COGS_INV_COST, COGS_AVG_COST, COGS_FIFO, COGS_LIFO.. The accountingQuantity field in the InventoryItem entity and accountingQuantityDiff in the InventoryItemDetail entity track the quantity of an item still "live" for the purpose of inventory valuation and COGS. In the service createAcctgTransForShipmentReceipt implemented in /applications/accounting/minilang/ledger/GeneralLedgerServices.xml (http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml?view=markup#l1306) the accountingQuantity is always set to the same value as the quantity received (i.e. the same as the quantityOnHand) for a newly received inventory item regardless of the COGS method. When items are shipped, the service createAcctgTransForSalesShipmentIssuance will only reduce the accounting quantity if the COGS method is FIFO or LIFO (http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml?view=markup#l1127). With FIFO, when an item is shipped, inventory items for the product with a non-zero accounting quantity are found sorted from earliest to latest received. The quantity of the item shipped must be decremented from the accounting quantities, starting with the earliest. Similarly, with LIFO, items are sorted from latest to earliest, and the latest item or items are decremented. In other words, if you have chosen a COGS method of COGS_INV_COST or COGS_AVG_COST, the accounting quantity is meaningless and in OFBiz as of now, should be ignored. And yet, the Inventory Valuation report uses accounting quantity, regardless of the the COGS method (http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/widget/ReportFinancialSummaryForms.xml?view=markup#l535). In other words, the Inventory Valuation report is broken for COGS methods of COGS_INV_COST or COGS_AVG_COST. *What should happen* The Inventory Valuation report, and anybody else who cares, should always be able to trust the accounting quantity. For COGS_INV_COST and COGS_AVG_COST, maintaining the accounting quantity is simple - createAcctgTransForSalesShipmentIssuanceit should just adjust it to match the remaining quantity on hand. No matter what the COGS method, the total accounting quantity for a product across all inventory items should always be equal to the total QOH. was: >From >http://ofbiz.135035.n4.nabble.com/AccountingQuantity-COGS-method-and-inventory-valuation-td4700867.html *Why accounting quantity?* When inventory is shipped, there's an accounting transaction that debits the inventory on hand value and credits Cost of Goods Sold (COGS). There's more than one way of deciding what value is added to COGS. First and most obvious is the actual cost of the inventory item. But companies may prefer other strategies. OFBiz has the option of three others: average cost, first-in-first-out or last-in-first-out. There's a nice survey of _why_ you might choose one of these at http://www.dummies.com/business/operations-management/choosing-an-accounting-method-for-the-cost-of-goods-sold-expense/, http://www.dummies.com/business/accounting/the-fifo-method-for-cost-of-goods-sold/, http://www.dummies.com/business/accounting/the-lifo-method-for-cost-of-goods-sold/ Note that if you choose anything other than inventory item cost,
[jira] [Updated] (OFBIZ-9500) Maintain accountingQuantity for all COGS valuation methods
[ https://issues.apache.org/jira/browse/OFBIZ-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-9500: -- Description: >From >http://ofbiz.135035.n4.nabble.com/AccountingQuantity-COGS-method-and-inventory-valuation-td4700867.html *Why accounting quantity?* When inventory is shipped, there's an accounting transaction that debits the inventory on hand value and credits Cost of Goods Sold (COGS). There's more than one way of deciding what value is added to COGS. First and most obvious is the actual cost of the inventory item. But companies may prefer other strategies. OFBiz has the option of three others: average cost, first-in-first-out or last-in-first-out. There's a nice survey of _why_ you might choose one of these at http://www.dummies.com/business/operations-management/choosing-an-accounting-method-for-the-cost-of-goods-sold-expense/, http://www.dummies.com/business/accounting/the-fifo-method-for-cost-of-goods-sold/, http://www.dummies.com/business/accounting/the-lifo-method-for-cost-of-goods-sold/ Note that if you choose anything other than inventory item cost, the money amount transferred to the COGS account may be *different* to the cost price of the inventory items being shipped. When you choose FIFO or LIFO, the amount may have originated from a different inventory item, received at a different time. *Current situation in OFBiz* The cogsMethodId field in the PartyAcctgPreference entity is a enum with four possible values: COGS_INV_COST, COGS_AVG_COST, COGS_FIFO, COGS_LIFO.. The accountingQuantity field in the InventoryItem entity and accountingQuantityDiff in the InventoryItemDetail entity track the quantity of an item still "live" for the purpose of inventory valuation and COGS. In the service createAcctgTransForShipmentReceipt implemented in /applications/accounting/minilang/ledger/GeneralLedgerServices.xml (http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml?view=markup#l1306) the accountingQuantity is always set to the same value as the quantity received (i.e. the same as the quantityOnHand) for a newly received inventory item regardless of the COGS method. When items are shipped, the service createAcctgTransForSalesShipmentIssuance will only reduce the accounting quantity if the COGS method is FIFO or LIFO (http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml?view=markup#l1127). With FIFO, when an item is shipped, inventory items for the product with a non-zero accounting quantity are found sorted from earliest to latest received. The quantity of the item shipped must be decremented from the accounting quantities, starting with the earliest. Similarly, with LIFO, items are sorted from latest to earliest, and the latest item or items are decremented. In other words, if you have chosen a COGS method of COGS_INV_COST or COGS_AVG_COST, the accounting quantity is meaningless and in OFBiz as of now, should be ignored. And yet, the Inventory Valuation report uses accounting quantity, regardless of the the COGS method (http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/widget/ReportFinancialSummaryForms.xml?view=markup#l535). In other words, the Inventory Valuation report is broken for COGS methods of COGS_INV_COST or COGS_AVG_COST. *What should happen* The Inventory Valuation report, and anybody else who cares, should always be able to trust the accounting quantity. For COGS_INV_COST and COGS_AVG_COST, maintaining the accounting quantity is simple - createAcctgTransForSalesShipmentIssuanceit should just adjust it to match the remaining quantity on hand. No matter what the COGS method, the total accounting quantity for a product across all inventory items should always be equal to the total QOH. was: >From >http://ofbiz.135035.n4.nabble.com/AccountingQuantity-COGS-method-and-inventory-valuation-td4700867.html *Why accounting quantity?* When inventory is shipped, there's an accounting transaction that debits the inventory on hand value and credits Cost of Goods Sold (COGS). There's more than one way of deciding what value is added to COGS. First and most obvious is the actual cost of the inventory item. But companies may prefer other strategies. OFBiz has the option of three others: average cost, first-in-first-out or last-in-first-out. There's a nice survey of _why_ you might choose one of these at http://www.dummies.com/business/operations-management/choosing-an-accounting-method-for-the-cost-of-goods-sold-expense/, http://www.dummies.com/business/accounting/the-fifo-method-for-cost-of-goods-sold/, http://www.dummies.com/business/accounting/the-lifo-method-for-cost-of-goods-sold/ Note that if you choose anything other than inventory item cost, the money amount
[jira] [Assigned] (OFBIZ-9500) Maintain accountingQuantity for all COGS valuation methods
[ https://issues.apache.org/jira/browse/OFBIZ-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy reassigned OFBIZ-9500: - Assignee: Paul Foxworthy > Maintain accountingQuantity for all COGS valuation methods > -- > > Key: OFBIZ-9500 > URL: https://issues.apache.org/jira/browse/OFBIZ-9500 > Project: OFBiz > Issue Type: Improvement > Components: accounting, order, product >Affects Versions: Trunk >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy > Labels: accounting, inventory, stock, valuation > > From > http://ofbiz.135035.n4.nabble.com/AccountingQuantity-COGS-method-and-inventory-valuation-td4700867.html > *Why accounting quantity?* > When inventory is shipped, there's an accounting transaction that debits the > inventory on hand value and credits Cost of Goods Sold (COGS). > There's more than one way of deciding what value is added to COGS. > First and most obvious is the actual cost of the inventory item. But > companies may prefer other strategies. OFBiz has the option of three others: > average cost, first-in-first-out or last-in-first-out. There's a nice survey > of _why_ you might choose one of these at > http://www.dummies.com/business/operations-management/choosing-an-accounting-method-for-the-cost-of-goods-sold-expense/, > > http://www.dummies.com/business/accounting/the-fifo-method-for-cost-of-goods-sold/, > > http://www.dummies.com/business/accounting/the-lifo-method-for-cost-of-goods-sold/ > > Note that if you choose anything other than inventory item cost, the money > amount transferred to the COGS account may be *different* to the cost price > of the inventory items being shipped. When you choose FIFO or LIFO, the > amount may have originated from a different inventory item, received at a > different time. > *Current situation in OFBiz* > The cogsMethodId field in the PartyAcctgPreference entity is a enum with four > possible values: COGS_INV_COST, COGS_AVG_COST, COGS_FIFO, COGS_LIFO.. > The accountingQuantity field in the InventoryItem entity and > accountingQuantityDiff in the InventoryItemDetail entity track the quantity > of an item still "live" for the purpose of inventory valuation and COGS. > In the service createAcctgTransForShipmentReceipt implemented in > /applications/accounting/minilang/ledger/GeneralLedgerServices.xml > (http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml?view=markup#l1306) > > the accountingQuantity is always set to the same value as the quantity > received (i.e. the same as the quantityOnHand) for a newly received inventory > item regardless of the COGS method. > When items are shipped, the service createAcctgTransForSalesShipmentIssuance > will only reduce the accounting quantity if the COGS method is FIFO or LIFO > (http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml?view=markup#l1127). > With FIFO, when an item is shipped, inventory items for the product with a > non-zero accounting quantity are found sorted from earliest to latest > received. The quantity of the item shipped must be decremented from the > accounting quantities, starting with the earliest. Similarly, with LIFO, > items are sorted from latest to earliest, and the latest item or items are > decremented. > In other words, if you have chosen a COGS method of COGS_INV_COST or > COGS_AVG_COST, the accounting quantity is meaningless and in OFBiz as of > now, should be ignored. > And yet, the Inventory Valuation report uses accounting quantity, regardless > of the the COGS method > (http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/widget/ReportFinancialSummaryForms.xml?view=markup#l535). > In other words, the Inventory Valuation report is broken for COGS methods of > COGS_INV_COST or COGS_AVG_COST. > *What should happen* > The Inventory Valuation report, and anybody else who cares, should always be > able to trust the accounting quantity. For COGS_INV_COST and COGS_AVG_COST, > maintaining the accounting quantity is simple - > createAcctgTransForSalesShipmentIssuanceit should just adjust it to match the > remaining quantity on hand. > No matter what the COGS method, the total accounting quantity for a product > across all inventory items should always be equal to the total QOH. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OFBIZ-9677) In packing, only use reservations with stock on hand
[ https://issues.apache.org/jira/browse/OFBIZ-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-9677: -- Description: During packing, OFBiz looks for reservations (OrderItemShipGrpInvRes) for the order item. Some reservations are for back ordered items not on hand. These reservations should not be used during packing, but they are. The attached patch fixes this. was: During packing, OFBiz looks for reservations (OrderItemShipGrpInvRes) for the order item. Some reserevations are for back ordered items not on hand. These reservations should not be used during packing, but they are. The attached patch fixes this. > In packing, only use reservations with stock on hand > > > Key: OFBIZ-9677 > URL: https://issues.apache.org/jira/browse/OFBIZ-9677 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Trunk >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy > Labels: pack, reservation > Attachments: OFBIZ-9677_PackingIgnoreBackorderReservations.patch > > > During packing, OFBiz looks for reservations (OrderItemShipGrpInvRes) for the > order item. Some reservations are for back ordered items not on hand. These > reservations should not be used during packing, but they are. > The attached patch fixes this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OFBIZ-9677) In packing, only use reservations with stock on hand
[ https://issues.apache.org/jira/browse/OFBIZ-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-9677: -- Attachment: OFBIZ-9677_PackingIgnoreBackorderReservations.patch > In packing, only use reservations with stock on hand > > > Key: OFBIZ-9677 > URL: https://issues.apache.org/jira/browse/OFBIZ-9677 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Trunk >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy > Labels: pack, reservation > Attachments: OFBIZ-9677_PackingIgnoreBackorderReservations.patch > > > During packing, OFBiz looks for reservations (OrderItemShipGrpInvRes) for the > order item. Some reserevations are for back ordered items not on hand. These > reservations should not be used during packing, but they are. > The attached patch fixes this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OFBIZ-9677) In packing, only use reservations with stock on hand
[ https://issues.apache.org/jira/browse/OFBIZ-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-9677: -- Summary: In packing, only use reservations with stock on hand (was: Backorder reservations used in packing) > In packing, only use reservations with stock on hand > > > Key: OFBIZ-9677 > URL: https://issues.apache.org/jira/browse/OFBIZ-9677 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Trunk >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy > Labels: pack, reservation > > During packing, OFBiz looks for reservations (OrderItemShipGrpInvRes) for the > order item. Some reserevations are for back ordered items not on hand. These > reservations should not be used during packing, but they are. > The attached patch fixes this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
