[jira] Commented: (OFBIZ-2141) Update UPSServices.java to pass UPS Certification Requirements
[
https://issues.apache.org/jira/browse/OFBIZ-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668943#action_12668943
]
Leon Torres commented on OFBIZ-2141:
This has no impact on current labels, it just fixes the way the response files
are saved in the filesystem.
What would be nice to have is to show the high value report if it exists, but
we can consider this an enhancement issue separate from this one. The high
value report is just an HTML file that serves as a checklist to segregate the
high value shipments from the ordinary ones. It's useful to print if the
organization has a large number of shipments.
Update UPSServices.java to pass UPS Certification Requirements
--
Key: OFBIZ-2141
URL: https://issues.apache.org/jira/browse/OFBIZ-2141
Project: OFBiz
Issue Type: Improvement
Components: product
Affects Versions: SVN trunk
Reporter: Leon Torres
Assignee: Jacques Le Roux
Fix For: SVN trunk
Attachments: ups-certification.patch
UPS Certification requires the response documents to be saved in a certain
format. This patch modifies UPSServices.java to meet these requirements.
Specifically:
1. Label images must be saved as label${trackingNumber}.gif to the filesystem
2. The high Value report HTML document must be saved to the filesystem.
Additionally, this HTML document is saved in
ShipmentRouteSegment.upsHighValue report for reference (simplest change
possible without introducing normalized carrier tables).
With this patch, all required documents for the UPS certification process can
be generated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-2141) Update UPSServices.java to pass UPS Certification Requirements
[
https://issues.apache.org/jira/browse/OFBIZ-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leon Torres updated OFBIZ-2141:
---
Attachment: ups-certification.patch
Update UPSServices.java to pass UPS Certification Requirements
--
Key: OFBIZ-2141
URL: https://issues.apache.org/jira/browse/OFBIZ-2141
Project: OFBiz
Issue Type: Improvement
Components: product
Affects Versions: SVN trunk
Reporter: Leon Torres
Attachments: ups-certification.patch
UPS Certification requires the response documents to be saved in a certain
format. This patch modifies UPSServices.java to meet these requirements.
Specifically:
1. Label images must be saved as label${trackingNumber}.gif to the filesystem
2. The high Value report HTML document must be saved to the filesystem.
Additionally, this HTML document is saved in
ShipmentRouteSegment.upsHighValue report for reference (simplest change
possible without introducing normalized carrier tables).
With this patch, all required documents for the UPS certification process can
be generated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-2141) Update UPSServices.java to pass UPS Certification Requirements
Update UPSServices.java to pass UPS Certification Requirements
--
Key: OFBIZ-2141
URL: https://issues.apache.org/jira/browse/OFBIZ-2141
Project: OFBiz
Issue Type: Improvement
Components: product
Affects Versions: SVN trunk
Reporter: Leon Torres
Attachments: ups-certification.patch
UPS Certification requires the response documents to be saved in a certain
format. This patch modifies UPSServices.java to meet these requirements.
Specifically:
1. Label images must be saved as label${trackingNumber}.gif to the filesystem
2. The high Value report HTML document must be saved to the filesystem.
Additionally, this HTML document is saved in ShipmentRouteSegment.upsHighValue
report for reference (simplest change possible without introducing normalized
carrier tables).
With this patch, all required documents for the UPS certification process can
be generated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2141) Update UPSServices.java to pass UPS Certification Requirements
[
https://issues.apache.org/jira/browse/OFBIZ-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12667355#action_12667355
]
Leon Torres commented on OFBIZ-2141:
For reference, this is to meet the requirements for UPS OnLine Tools. The
document in which you can find the certification process and requirements is
the Shipping XML Tool Developers Gude. You will need an account with UPS to
access the documentation. The section in the PDF should be under UPS Label
Certification
Update UPSServices.java to pass UPS Certification Requirements
--
Key: OFBIZ-2141
URL: https://issues.apache.org/jira/browse/OFBIZ-2141
Project: OFBiz
Issue Type: Improvement
Components: product
Affects Versions: SVN trunk
Reporter: Leon Torres
Attachments: ups-certification.patch
UPS Certification requires the response documents to be saved in a certain
format. This patch modifies UPSServices.java to meet these requirements.
Specifically:
1. Label images must be saved as label${trackingNumber}.gif to the filesystem
2. The high Value report HTML document must be saved to the filesystem.
Additionally, this HTML document is saved in
ShipmentRouteSegment.upsHighValue report for reference (simplest change
possible without introducing normalized carrier tables).
With this patch, all required documents for the UPS certification process can
be generated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1187) Leaving out rel-field-name in keymap causes NPE
[ https://issues.apache.org/jira/browse/OFBIZ-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590254#action_12590254 ] Leon Torres commented on OFBIZ-1187: Sure I agree it should check field name if rel-field-name is missing. I never had a patch, this bug was just a report. Fixing it should be trivial if someone wants to give it a shot. Leaving out rel-field-name in keymap causes NPE --- Key: OFBIZ-1187 URL: https://issues.apache.org/jira/browse/OFBIZ-1187 Project: OFBiz Issue Type: Bug Components: order Affects Versions: SVN trunk Reporter: Leon Torres Fix For: SVN trunk If you leave out the rel-field-name for a keymap that requires it, DatabaseUtil.java will crash with a NPE when trying to create it. To reproduce, add the following to an entityengine.xml, extend-entity entity-name=OrderAdjustment field name=orderAdjustmentSubTypeId type=id/ relation type=one fk-name=ORDER_ADJ_SUBTYPE rel-entity-name=OrderAdjustmentType key-map field-name=orderAdjustmentSubTypeId / /relation /extend-entity Note that the key-map is missing a rel-field-name=orderAdjustmentTypeId. Do an ant run-install to create the key. It should crash with a NPE pointing to line 2150 in DatabaseUtil.java: ModelField relField = relModelEntity.getField(keyMap.getRelFieldName()); I believe it should be testing that getRelFieldName() is null, and if so then log a warning and skip the key. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1592) Database spikes lead to permanent user privilege loss
[ https://issues.apache.org/jira/browse/OFBIZ-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562158#action_12562158 ] Leon Torres commented on OFBIZ-1592: Sorry Adrian, that patch you proposed does exactly the same thing. Can someone else review it? I'm not on the dev list at the moment, further comments should be on this issue. Database spikes lead to permanent user privilege loss - Key: OFBIZ-1592 URL: https://issues.apache.org/jira/browse/OFBIZ-1592 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Leon Torres Assignee: Si Chen Priority: Critical Fix For: SVN trunk Attachments: OFBizSecurity.patch, permanent-security-loss.patch We found a critical bug in OFBiz security where temporary database spikes can lead to permanent privilege loss for users trying to log in or do something during the spike. The loss lasts until a cache refresh or a restart. A symptom is customers not being able to log in to do a checkout, not being able to create new accounts, and backend users not being able to perform their duties due to privilege loss. The reason for the bug was found to be in the caching of UserLoginSecurityGroup in OFBizSecurity. When there's an SQL exception, such as during a lag spike, an empty list will be stored in the cache. Subsequent security checks will retrieve this empty list and never ask the database again what the actual security groups are. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1592) Database spikes lead to permanent user privilege loss
[ https://issues.apache.org/jira/browse/OFBIZ-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561923#action_12561923 ] Leon Torres commented on OFBIZ-1592: Also note if the user doesn't have any security groups, an empty list is returned and cached. So it avoids DB hits for the case you stated Adrian. :) Database spikes lead to permanent user privilege loss - Key: OFBIZ-1592 URL: https://issues.apache.org/jira/browse/OFBIZ-1592 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Leon Torres Assignee: Si Chen Priority: Critical Fix For: SVN trunk Attachments: permanent-security-loss.patch We found a critical bug in OFBiz security where temporary database spikes can lead to permanent privilege loss for users trying to log in or do something during the spike. The loss lasts until a cache refresh or a restart. A symptom is customers not being able to log in to do a checkout, not being able to create new accounts, and backend users not being able to perform their duties due to privilege loss. The reason for the bug was found to be in the caching of UserLoginSecurityGroup in OFBizSecurity. When there's an SQL exception, such as during a lag spike, an empty list will be stored in the cache. Subsequent security checks will retrieve this empty list and never ask the database again what the actual security groups are. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1592) Database spikes lead to permanent user privilege loss
[ https://issues.apache.org/jira/browse/OFBIZ-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561922#action_12561922 ] Leon Torres commented on OFBIZ-1592: Trying to avoid database hits lead to the problem in the first place. We should rely on the database's native caching ability. Database spikes lead to permanent user privilege loss - Key: OFBIZ-1592 URL: https://issues.apache.org/jira/browse/OFBIZ-1592 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Leon Torres Assignee: Si Chen Priority: Critical Fix For: SVN trunk Attachments: permanent-security-loss.patch We found a critical bug in OFBiz security where temporary database spikes can lead to permanent privilege loss for users trying to log in or do something during the spike. The loss lasts until a cache refresh or a restart. A symptom is customers not being able to log in to do a checkout, not being able to create new accounts, and backend users not being able to perform their duties due to privilege loss. The reason for the bug was found to be in the caching of UserLoginSecurityGroup in OFBizSecurity. When there's an SQL exception, such as during a lag spike, an empty list will be stored in the cache. Subsequent security checks will retrieve this empty list and never ask the database again what the actual security groups are. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-1592) Database spikes lead to permanent user privilege loss
Database spikes lead to permanent user privilege loss - Key: OFBIZ-1592 URL: https://issues.apache.org/jira/browse/OFBIZ-1592 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Leon Torres Priority: Critical Fix For: SVN trunk Attachments: permanent-security-loss.patch We found a critical bug in OFBiz security where temporary database spikes can lead to permanent privilege loss for users trying to log in or do something during the spike. The loss lasts until a cache refresh or a restart. A symptom is customers not being able to log in to do a checkout, not being able to create new accounts, and backend users not being able to perform their duties due to privilege loss. The reason for the bug was found to be in the caching of UserLoginSecurityGroup in OFBizSecurity. When there's an SQL exception, such as during a lag spike, an empty list will be stored in the cache. Subsequent security checks will retrieve this empty list and never ask the database again what the actual security groups are. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-1592) Database spikes lead to permanent user privilege loss
[ https://issues.apache.org/jira/browse/OFBIZ-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leon Torres updated OFBIZ-1592: --- Attachment: permanent-security-loss.patch This patch is known to fix the issue completely. Database spikes lead to permanent user privilege loss - Key: OFBIZ-1592 URL: https://issues.apache.org/jira/browse/OFBIZ-1592 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Leon Torres Priority: Critical Fix For: SVN trunk Attachments: permanent-security-loss.patch We found a critical bug in OFBiz security where temporary database spikes can lead to permanent privilege loss for users trying to log in or do something during the spike. The loss lasts until a cache refresh or a restart. A symptom is customers not being able to log in to do a checkout, not being able to create new accounts, and backend users not being able to perform their duties due to privilege loss. The reason for the bug was found to be in the caching of UserLoginSecurityGroup in OFBizSecurity. When there's an SQL exception, such as during a lag spike, an empty list will be stored in the cache. Subsequent security checks will retrieve this empty list and never ask the database again what the actual security groups are. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1415) Thread freeze when executing PreparedStatement with PosgreSQL
[ https://issues.apache.org/jira/browse/OFBIZ-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545346 ] Leon Torres commented on OFBIZ-1415: Scott, thanks! That seems to be it. My debugger points to a similar socket reading hangup and I did not suspect it could be the terminal cause. I won't be able to continue investigating as the feature I was working on that led me to this was canceled, but I could supply the code to reproduce it. From the thread Scott linked, we might have to consider refining the entity engine a little if we get more reports of this happening. Thread freeze when executing PreparedStatement with PosgreSQL - Key: OFBIZ-1415 URL: https://issues.apache.org/jira/browse/OFBIZ-1415 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Leon Torres I'm getting a hard freeze in a thread when it attempts to executeQuery() using the postgresql Jdbc3 Prepared Statement. It affects the OrderServices.createPaymentPreference() method. After extensive probing of the issue, I can't figure out why. Here's a verbose log of what happens. The thread stops after the last line and never resumes, causing the browser to remain loading indefinitely. I suspect something is going on with BigDecimal or the nature of the insert. Any ideas? 2007-11-20 12:22:05,985 (http-0.0.0.0-8443-Processor3) [ ServiceDispatcher.java:347:INFO ] ### Invoking Sync Service [createOrderPaymentPreference] 2007-11-20 12:22:06,003 (http-0.0.0.0-8443-Processor3) [ SequenceUtil.java:258:INFO ] Got bank of sequenced IDs for [OrderPaymentPreference]; curSeqId=10220, maxSeqId=10230, bankSize=10 2007-11-20 12:22:06,006 (http-0.0.0.0-8443-Processor3) [ GenericEntity.java:389:WARN ] In entity field [OrderPaymentPreference.maxAmount] set the value passed in [java.math.BigDecimal] is not compatible with the Java type of the fi eld [Double] 2007-11-20 12:22:06,008 (http-0.0.0.0-8443-Processor3) [ GenericDAO.java:168:INFO ] ### saving fields [EMAIL PROTECTED], [EMAIL PROTECTED], ModelEntity[OrderP [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], ModelEntity[OrderPaymentPreferenc [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], ModelEntity[OrderPaymen [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Mode [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], ModelEntity[OrderPaymentPrefer [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] from entity [GenericEntity:OrderPaymentPreference][createdByUserLogin,DemoSalesManager(java.lang.String)][cr eatedDate,2007-11-20 12:22:06.007(java.sql.Timestamp)][createdStamp,2007-11-20 12:22:06.007(java.sql.Timestamp)][createdTxStamp,2007-11-20 12:22:05.187(java.sql.Timestamp)][lastUpdatedStamp,2007-11-20 12:22:06.007(java.sql.Timestamp)][l astUpdatedTxStamp,2007-11-20 12:22:05.187(java.sql.Timestamp)][maxAmount,25.07(java.math.BigDecimal)][orderId,WS1(java.lang.String)][orderPaymentPreferenceId,10220(java.lang.String)][paymentMethodId,1(java.lang.String)][paymentM ethodTypeId,CREDIT_CARD(java.lang.String)] 2007-11-20 12:22:06,009 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [orderPaymentPreferenceId] of type [String] and fieldtype [1] to [10220] 2007-11-20 12:22:06,011 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [orderId] of type [String] and fieldtype [1] to [WS1] 2007-11-20 12:22:06,012 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [orderItemSeqId] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,013 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [productPricePurposeId] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,014 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [paymentMethodTypeId] of type [String] and fieldtype [1] to [CREDIT_CARD] 2007-11-20 12:22:06,015 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [paymentMethodId] of type [String] and fieldtype [1] to [1] 2007-11-20 12:22:06,016 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [finAccountId] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,017 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [securityCode] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,025 (http-0.0.0.0-8443-Processor3) [
[jira] Created: (OFBIZ-1415) Thread freeze when executing PreparedStatement with PosgreSQL
Thread freeze when executing PreparedStatement with PosgreSQL - Key: OFBIZ-1415 URL: https://issues.apache.org/jira/browse/OFBIZ-1415 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Leon Torres I'm getting a hard freeze in a thread when it attempts to executeQuery() using the postgresql Jdbc3 Prepared Statement. It affects the OrderServices.createPaymentPreference() method. After extensive probing of the issue, I can't figure out why. Here's a verbose log of what happens. The thread stops after the last line and never resumes, causing the browser to remain loading indefinitely. I suspect something is going on with BigDecimal or the nature of the insert. Any ideas? 2007-11-20 12:22:05,985 (http-0.0.0.0-8443-Processor3) [ ServiceDispatcher.java:347:INFO ] ### Invoking Sync Service [createOrderPaymentPreference] 2007-11-20 12:22:06,003 (http-0.0.0.0-8443-Processor3) [ SequenceUtil.java:258:INFO ] Got bank of sequenced IDs for [OrderPaymentPreference]; curSeqId=10220, maxSeqId=10230, bankSize=10 2007-11-20 12:22:06,006 (http-0.0.0.0-8443-Processor3) [ GenericEntity.java:389:WARN ] In entity field [OrderPaymentPreference.maxAmount] set the value passed in [java.math.BigDecimal] is not compatible with the Java type of the fi eld [Double] 2007-11-20 12:22:06,008 (http-0.0.0.0-8443-Processor3) [ GenericDAO.java:168:INFO ] ### saving fields [EMAIL PROTECTED], [EMAIL PROTECTED], ModelEntity[OrderP [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], ModelEntity[OrderPaymentPreferenc [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], ModelEntity[OrderPaymen [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Mode [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], ModelEntity[OrderPaymentPrefer [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] from entity [GenericEntity:OrderPaymentPreference][createdByUserLogin,DemoSalesManager(java.lang.String)][cr eatedDate,2007-11-20 12:22:06.007(java.sql.Timestamp)][createdStamp,2007-11-20 12:22:06.007(java.sql.Timestamp)][createdTxStamp,2007-11-20 12:22:05.187(java.sql.Timestamp)][lastUpdatedStamp,2007-11-20 12:22:06.007(java.sql.Timestamp)][l astUpdatedTxStamp,2007-11-20 12:22:05.187(java.sql.Timestamp)][maxAmount,25.07(java.math.BigDecimal)][orderId,WS1(java.lang.String)][orderPaymentPreferenceId,10220(java.lang.String)][paymentMethodId,1(java.lang.String)][paymentM ethodTypeId,CREDIT_CARD(java.lang.String)] 2007-11-20 12:22:06,009 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [orderPaymentPreferenceId] of type [String] and fieldtype [1] to [10220] 2007-11-20 12:22:06,011 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [orderId] of type [String] and fieldtype [1] to [WS1] 2007-11-20 12:22:06,012 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [orderItemSeqId] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,013 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [productPricePurposeId] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,014 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [paymentMethodTypeId] of type [String] and fieldtype [1] to [CREDIT_CARD] 2007-11-20 12:22:06,015 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [paymentMethodId] of type [String] and fieldtype [1] to [1] 2007-11-20 12:22:06,016 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [finAccountId] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,017 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [securityCode] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,025 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [presentFlag] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,026 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [overflowFlag] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,027 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [maxAmount] of type [java.math.BigDecimal] and fieldtype [9] to [25.07] 2007-11-20 12:22:06,028 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [processAttempt] of type [Long] and fieldtype [6] to [null] 2007-11-20 12:22:06,029 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field
[jira] Commented: (OFBIZ-1415) Thread freeze when executing PreparedStatement with PosgreSQL
[ https://issues.apache.org/jira/browse/OFBIZ-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544053 ] Leon Torres commented on OFBIZ-1415: I just noticed it's missing statusId = PAYMENT_NOT_AUTH, which I just added and it's still crashing. I'm going to look into what's happening at the database level next. Thread freeze when executing PreparedStatement with PosgreSQL - Key: OFBIZ-1415 URL: https://issues.apache.org/jira/browse/OFBIZ-1415 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Leon Torres I'm getting a hard freeze in a thread when it attempts to executeQuery() using the postgresql Jdbc3 Prepared Statement. It affects the OrderServices.createPaymentPreference() method. After extensive probing of the issue, I can't figure out why. Here's a verbose log of what happens. The thread stops after the last line and never resumes, causing the browser to remain loading indefinitely. I suspect something is going on with BigDecimal or the nature of the insert. Any ideas? 2007-11-20 12:22:05,985 (http-0.0.0.0-8443-Processor3) [ ServiceDispatcher.java:347:INFO ] ### Invoking Sync Service [createOrderPaymentPreference] 2007-11-20 12:22:06,003 (http-0.0.0.0-8443-Processor3) [ SequenceUtil.java:258:INFO ] Got bank of sequenced IDs for [OrderPaymentPreference]; curSeqId=10220, maxSeqId=10230, bankSize=10 2007-11-20 12:22:06,006 (http-0.0.0.0-8443-Processor3) [ GenericEntity.java:389:WARN ] In entity field [OrderPaymentPreference.maxAmount] set the value passed in [java.math.BigDecimal] is not compatible with the Java type of the fi eld [Double] 2007-11-20 12:22:06,008 (http-0.0.0.0-8443-Processor3) [ GenericDAO.java:168:INFO ] ### saving fields [EMAIL PROTECTED], [EMAIL PROTECTED], ModelEntity[OrderP [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], ModelEntity[OrderPaymentPreferenc [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], ModelEntity[OrderPaymen [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Mode [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], ModelEntity[OrderPaymentPrefer [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] from entity [GenericEntity:OrderPaymentPreference][createdByUserLogin,DemoSalesManager(java.lang.String)][cr eatedDate,2007-11-20 12:22:06.007(java.sql.Timestamp)][createdStamp,2007-11-20 12:22:06.007(java.sql.Timestamp)][createdTxStamp,2007-11-20 12:22:05.187(java.sql.Timestamp)][lastUpdatedStamp,2007-11-20 12:22:06.007(java.sql.Timestamp)][l astUpdatedTxStamp,2007-11-20 12:22:05.187(java.sql.Timestamp)][maxAmount,25.07(java.math.BigDecimal)][orderId,WS1(java.lang.String)][orderPaymentPreferenceId,10220(java.lang.String)][paymentMethodId,1(java.lang.String)][paymentM ethodTypeId,CREDIT_CARD(java.lang.String)] 2007-11-20 12:22:06,009 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [orderPaymentPreferenceId] of type [String] and fieldtype [1] to [10220] 2007-11-20 12:22:06,011 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [orderId] of type [String] and fieldtype [1] to [WS1] 2007-11-20 12:22:06,012 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [orderItemSeqId] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,013 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [productPricePurposeId] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,014 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [paymentMethodTypeId] of type [String] and fieldtype [1] to [CREDIT_CARD] 2007-11-20 12:22:06,015 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [paymentMethodId] of type [String] and fieldtype [1] to [1] 2007-11-20 12:22:06,016 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [finAccountId] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,017 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [securityCode] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,025 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [presentFlag] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,026 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [overflowFlag] of type [String] and fieldtype [1] to [null]
[jira] Commented: (OFBIZ-1415) Thread freeze when executing PreparedStatement with PosgreSQL
[ https://issues.apache.org/jira/browse/OFBIZ-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544068 ] Leon Torres commented on OFBIZ-1415: When I run the service from the bsh terminal, it doesn't freeze. When I replace the service call in my code with a direct entity.create() operation, it freezes. This leads me to think there is some kind of database deadlock going on. This code is being implemented inside a ccRefund payment processor service. There's so much stuff going on in the payment gateway code, it's difficult to know what the context of database and thread usage is. Any ideas? Thread freeze when executing PreparedStatement with PosgreSQL - Key: OFBIZ-1415 URL: https://issues.apache.org/jira/browse/OFBIZ-1415 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Leon Torres I'm getting a hard freeze in a thread when it attempts to executeQuery() using the postgresql Jdbc3 Prepared Statement. It affects the OrderServices.createPaymentPreference() method. After extensive probing of the issue, I can't figure out why. Here's a verbose log of what happens. The thread stops after the last line and never resumes, causing the browser to remain loading indefinitely. I suspect something is going on with BigDecimal or the nature of the insert. Any ideas? 2007-11-20 12:22:05,985 (http-0.0.0.0-8443-Processor3) [ ServiceDispatcher.java:347:INFO ] ### Invoking Sync Service [createOrderPaymentPreference] 2007-11-20 12:22:06,003 (http-0.0.0.0-8443-Processor3) [ SequenceUtil.java:258:INFO ] Got bank of sequenced IDs for [OrderPaymentPreference]; curSeqId=10220, maxSeqId=10230, bankSize=10 2007-11-20 12:22:06,006 (http-0.0.0.0-8443-Processor3) [ GenericEntity.java:389:WARN ] In entity field [OrderPaymentPreference.maxAmount] set the value passed in [java.math.BigDecimal] is not compatible with the Java type of the fi eld [Double] 2007-11-20 12:22:06,008 (http-0.0.0.0-8443-Processor3) [ GenericDAO.java:168:INFO ] ### saving fields [EMAIL PROTECTED], [EMAIL PROTECTED], ModelEntity[OrderP [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], ModelEntity[OrderPaymentPreferenc [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], ModelEntity[OrderPaymen [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Mode [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], ModelEntity[OrderPaymentPrefer [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] from entity [GenericEntity:OrderPaymentPreference][createdByUserLogin,DemoSalesManager(java.lang.String)][cr eatedDate,2007-11-20 12:22:06.007(java.sql.Timestamp)][createdStamp,2007-11-20 12:22:06.007(java.sql.Timestamp)][createdTxStamp,2007-11-20 12:22:05.187(java.sql.Timestamp)][lastUpdatedStamp,2007-11-20 12:22:06.007(java.sql.Timestamp)][l astUpdatedTxStamp,2007-11-20 12:22:05.187(java.sql.Timestamp)][maxAmount,25.07(java.math.BigDecimal)][orderId,WS1(java.lang.String)][orderPaymentPreferenceId,10220(java.lang.String)][paymentMethodId,1(java.lang.String)][paymentM ethodTypeId,CREDIT_CARD(java.lang.String)] 2007-11-20 12:22:06,009 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [orderPaymentPreferenceId] of type [String] and fieldtype [1] to [10220] 2007-11-20 12:22:06,011 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [orderId] of type [String] and fieldtype [1] to [WS1] 2007-11-20 12:22:06,012 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [orderItemSeqId] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,013 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [productPricePurposeId] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,014 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [paymentMethodTypeId] of type [String] and fieldtype [1] to [CREDIT_CARD] 2007-11-20 12:22:06,015 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [paymentMethodId] of type [String] and fieldtype [1] to [1] 2007-11-20 12:22:06,016 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [finAccountId] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,017 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [securityCode] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,025 (http-0.0.0.0-8443-Processor3)
[jira] Commented: (OFBIZ-1415) Thread freeze when executing PreparedStatement with PosgreSQL
[ https://issues.apache.org/jira/browse/OFBIZ-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544092 ] Leon Torres commented on OFBIZ-1415: Sure, but before I go poking at the postgres JDBC, is there any knowledge of deadlocking happening? Thread freeze when executing PreparedStatement with PosgreSQL - Key: OFBIZ-1415 URL: https://issues.apache.org/jira/browse/OFBIZ-1415 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Leon Torres I'm getting a hard freeze in a thread when it attempts to executeQuery() using the postgresql Jdbc3 Prepared Statement. It affects the OrderServices.createPaymentPreference() method. After extensive probing of the issue, I can't figure out why. Here's a verbose log of what happens. The thread stops after the last line and never resumes, causing the browser to remain loading indefinitely. I suspect something is going on with BigDecimal or the nature of the insert. Any ideas? 2007-11-20 12:22:05,985 (http-0.0.0.0-8443-Processor3) [ ServiceDispatcher.java:347:INFO ] ### Invoking Sync Service [createOrderPaymentPreference] 2007-11-20 12:22:06,003 (http-0.0.0.0-8443-Processor3) [ SequenceUtil.java:258:INFO ] Got bank of sequenced IDs for [OrderPaymentPreference]; curSeqId=10220, maxSeqId=10230, bankSize=10 2007-11-20 12:22:06,006 (http-0.0.0.0-8443-Processor3) [ GenericEntity.java:389:WARN ] In entity field [OrderPaymentPreference.maxAmount] set the value passed in [java.math.BigDecimal] is not compatible with the Java type of the fi eld [Double] 2007-11-20 12:22:06,008 (http-0.0.0.0-8443-Processor3) [ GenericDAO.java:168:INFO ] ### saving fields [EMAIL PROTECTED], [EMAIL PROTECTED], ModelEntity[OrderP [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], ModelEntity[OrderPaymentPreferenc [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], ModelEntity[OrderPaymen [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Mode [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], ModelEntity[OrderPaymentPrefer [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] from entity [GenericEntity:OrderPaymentPreference][createdByUserLogin,DemoSalesManager(java.lang.String)][cr eatedDate,2007-11-20 12:22:06.007(java.sql.Timestamp)][createdStamp,2007-11-20 12:22:06.007(java.sql.Timestamp)][createdTxStamp,2007-11-20 12:22:05.187(java.sql.Timestamp)][lastUpdatedStamp,2007-11-20 12:22:06.007(java.sql.Timestamp)][l astUpdatedTxStamp,2007-11-20 12:22:05.187(java.sql.Timestamp)][maxAmount,25.07(java.math.BigDecimal)][orderId,WS1(java.lang.String)][orderPaymentPreferenceId,10220(java.lang.String)][paymentMethodId,1(java.lang.String)][paymentM ethodTypeId,CREDIT_CARD(java.lang.String)] 2007-11-20 12:22:06,009 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [orderPaymentPreferenceId] of type [String] and fieldtype [1] to [10220] 2007-11-20 12:22:06,011 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [orderId] of type [String] and fieldtype [1] to [WS1] 2007-11-20 12:22:06,012 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [orderItemSeqId] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,013 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [productPricePurposeId] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,014 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [paymentMethodTypeId] of type [String] and fieldtype [1] to [CREDIT_CARD] 2007-11-20 12:22:06,015 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [paymentMethodId] of type [String] and fieldtype [1] to [1] 2007-11-20 12:22:06,016 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [finAccountId] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,017 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [securityCode] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,025 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [presentFlag] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,026 (http-0.0.0.0-8443-Processor3) [ SqlJdbcUtil.java:704:INFO ] ### setting field [overflowFlag] of type [String] and fieldtype [1] to [null] 2007-11-20 12:22:06,027 (http-0.0.0.0-8443-Processor3) [
[jira] Created: (OFBIZ-1266) EntityOperator.IN will crash on some databases with empty list
EntityOperator.IN will crash on some databases with empty list
--
Key: OFBIZ-1266
URL: https://issues.apache.org/jira/browse/OFBIZ-1266
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Environment: derby, unkown other databases
Reporter: Leon Torres
If you use the following entity exr,
new EntityExpr(orderId, EntityOperator.IN, new ArrayList());
It will crash on at least Derby. The reason is that this condition evaluates
to the keyword FALSE, which apparently is not supported on Derby. The problem
code is in EntityComparisonOperator.java:
// if this is an IN operator and the rhs Object isEmpty, add FALSE
instead of the normal SQL
if (this.idInt == EntityOperator.ID_IN UtilValidate.isEmpty(rhs)) {
sql.append(FALSE);
return;
}
Perhaps this is over engineered? What happens if we just leave this out and
let it generate an IN () SQL?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-1205) Use facility of cart when creating PO from requirements
Use facility of cart when creating PO from requirements --- Key: OFBIZ-1205 URL: https://issues.apache.org/jira/browse/OFBIZ-1205 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: SVN trunk Reporter: Leon Torres Priority: Minor Right now when creating a PO from requirements, the ShoppingCart chooses a random facility to associate with the order. Instead, it should just be using the facilityId set for the cart, and setting this facilityId should be the responsibility of the requirement event method ShoppingCartHelper.addToCartBulkRequirements(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-1205) Use facility of cart when creating PO from requirements
[ https://issues.apache.org/jira/browse/OFBIZ-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leon Torres updated OFBIZ-1205: --- Attachment: createPOFromRequirementsFacility.patch Here's a simple and straightforward fix: 1. The requirement screen passes the facilityId 2. addToCartBulkRequirements() will do cart.setFacilityId() 3. default options uses this facilityId, otherwise it does not create any shipping (that is, do not use a random facility, it just surprises the users) To test this, 1. create a sales order for GZ-1005 or whatever product creates requirements. 2. Approve the requirements 3. view the requirements by vendor, select a facility 4. create the PO 5. Notice that the ship to address is for the selected facility 6. Don't create the order, instead go back to step #3 and choose a different facility, then repeat test to make sure the facility address is correct Use facility of cart when creating PO from requirements --- Key: OFBIZ-1205 URL: https://issues.apache.org/jira/browse/OFBIZ-1205 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: SVN trunk Reporter: Leon Torres Priority: Minor Attachments: createPOFromRequirementsFacility.patch Right now when creating a PO from requirements, the ShoppingCart chooses a random facility to associate with the order. Instead, it should just be using the facilityId set for the cart, and setting this facilityId should be the responsibility of the requirement event method ShoppingCartHelper.addToCartBulkRequirements(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-1187) Leaving out rel-field-name in keymap causes NPE
Leaving out rel-field-name in keymap causes NPE --- Key: OFBIZ-1187 URL: https://issues.apache.org/jira/browse/OFBIZ-1187 Project: OFBiz Issue Type: Bug Reporter: Leon Torres If you leave out the rel-field-name for a keymap that requires it, DatabaseUtil.java will crash with a NPE when trying to create it. To reproduce, add the following to an entityengine.xml, extend-entity entity-name=OrderAdjustment field name=orderAdjustmentSubTypeId type=id/ relation type=one fk-name=ORDER_ADJ_SUBTYPE rel-entity-name=OrderAdjustmentType key-map field-name=orderAdjustmentSubTypeId / /relation /extend-entity Note that the key-map is missing a rel-field-name=orderAdjustmentTypeId. Do an ant run-install to create the key. It should crash with a NPE pointing to line 2150 in DatabaseUtil.java: ModelField relField = relModelEntity.getField(keyMap.getRelFieldName()); I believe it should be testing that getRelFieldName() is null, and if so then log a warning and skip the key. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1187) Leaving out rel-field-name in keymap causes NPE
[ https://issues.apache.org/jira/browse/OFBIZ-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518247 ] Leon Torres commented on OFBIZ-1187: I made this major because once the crash happens, all keys after this one are not created. For someone not familiar with how the entity engine works, this can be very mysterious, so we should at least log a warning. Leaving out rel-field-name in keymap causes NPE --- Key: OFBIZ-1187 URL: https://issues.apache.org/jira/browse/OFBIZ-1187 Project: OFBiz Issue Type: Bug Reporter: Leon Torres If you leave out the rel-field-name for a keymap that requires it, DatabaseUtil.java will crash with a NPE when trying to create it. To reproduce, add the following to an entityengine.xml, extend-entity entity-name=OrderAdjustment field name=orderAdjustmentSubTypeId type=id/ relation type=one fk-name=ORDER_ADJ_SUBTYPE rel-entity-name=OrderAdjustmentType key-map field-name=orderAdjustmentSubTypeId / /relation /extend-entity Note that the key-map is missing a rel-field-name=orderAdjustmentTypeId. Do an ant run-install to create the key. It should crash with a NPE pointing to line 2150 in DatabaseUtil.java: ModelField relField = relModelEntity.getField(keyMap.getRelFieldName()); I believe it should be testing that getRelFieldName() is null, and if so then log a warning and skip the key. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-203) Freemarker postal address formatter macro
[ https://issues.apache.org/jira/browse/OFBIZ-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516855 ] Leon Torres commented on OFBIZ-203: --- Actually, I came up with a much better idea. It mixes the best ideas in this thread and uses nothing but FTL. Why don't we close this and post the alternative ideas as separate issues? I'll post mine later on once I verify it works. Then we can reference this issue to the new ones to keep track of the ideas. Freemarker postal address formatter macro - Key: OFBIZ-203 URL: https://issues.apache.org/jira/browse/OFBIZ-203 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Reporter: Leon Torres Priority: Minor Attachments: ofbizPostalAddress.patch, test.bsh, test.ftl Define a macro @ofbizPostalAddress address=inputMapOrGenericValue/ to format postal addresses in a consistent, flexible way with attention to country postal formats. The output should support both HTML and Text formats. It should be easily extensible, with future XSL:Fo support in mind. I created an implementation as an exercise to learn the freemarker template system. It was designed with future macros in mind. Currently implemented are rules for generating US, German and Royal Mail format postal addresses. (The address country determines the format.) Also provided are test.bsh and test.ftl so people may try them out. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1169) Eliminate redundant log messages in screen widgets
[ https://issues.apache.org/jira/browse/OFBIZ-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515080 ] Leon Torres commented on OFBIZ-1169: Oh yeah, I forgot to mention that BshUtil.java is a little noisy, because it both logs the exception and throws it, causing redundant messages. I just shut it off in debug.properties: log4r.logger.org.ofbiz.base.util=OFF Try this patch with this logger setting and it should be more concise. :-) Eliminate redundant log messages in screen widgets -- Key: OFBIZ-1169 URL: https://issues.apache.org/jira/browse/OFBIZ-1169 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Leon Torres Assignee: Si Chen Fix For: SVN trunk Attachments: screen-render-exception.patch, screenwidget-log-fix.patch Currently, if you have a typo or minor bug in a bsh or ftl file that is part of a screen widget definition, the resulting error message in the log and on screen can be overwhelming. This causes a serious usability issue with developers and new users. I decided to spend some personal time to see what the source of the log explosion is and how it can be fixed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-1169) Eliminate redundant log messages in screen widgets
Eliminate redundant log messages in screen widgets -- Key: OFBIZ-1169 URL: https://issues.apache.org/jira/browse/OFBIZ-1169 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Leon Torres Fix For: SVN trunk Currently, if you have a typo or minor bug in a bsh or ftl file that is part of a screen widget definition, the resulting error message in the log and on screen can be overwhelming. This causes a serious usability issue with developers and new users. I decided to spend some personal time to see what the source of the log explosion is and how it can be fixed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-1169) Eliminate redundant log messages in screen widgets
[ https://issues.apache.org/jira/browse/OFBIZ-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leon Torres updated OFBIZ-1169: --- Attachment: screenwidget-log-fix.patch This patch provides two major improvements to the readability of screen widget logs. 1. The render screen function is recursive in nature, and each render step will log every error. Most of these errors get thrown up to the previous render function, which causes them to get logged again. This is the primary reason that the log file explodes with messages. To fix it, I introduced a special exception called ScreenRenderException which tells the rendering function that the particular error was already caught and logged, so it can just pass it up the chain. 2. HtmlWidget.java was throwing a RuntimeException, which pollutes the user's screen with a lot of error information. Instead of throwing RuntimeException, just render the error message directly to the screen. This is much more useful as it prints exactly what the error was and nothing more, allowing you to fix typos in the FTL much faster. Eliminate redundant log messages in screen widgets -- Key: OFBIZ-1169 URL: https://issues.apache.org/jira/browse/OFBIZ-1169 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Leon Torres Fix For: SVN trunk Attachments: screenwidget-log-fix.patch Currently, if you have a typo or minor bug in a bsh or ftl file that is part of a screen widget definition, the resulting error message in the log and on screen can be overwhelming. This causes a serious usability issue with developers and new users. I decided to spend some personal time to see what the source of the log explosion is and how it can be fixed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-1169) Eliminate redundant log messages in screen widgets
[ https://issues.apache.org/jira/browse/OFBIZ-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leon Torres updated OFBIZ-1169: --- Attachment: screen-render-exception.patch Oops, forgot to svn add the ScreenRenderException so I can diff it. The second patch contains the new exception file, which is simply a subclass of GeneralException. Eliminate redundant log messages in screen widgets -- Key: OFBIZ-1169 URL: https://issues.apache.org/jira/browse/OFBIZ-1169 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Leon Torres Fix For: SVN trunk Attachments: screen-render-exception.patch, screenwidget-log-fix.patch Currently, if you have a typo or minor bug in a bsh or ftl file that is part of a screen widget definition, the resulting error message in the log and on screen can be overwhelming. This causes a serious usability issue with developers and new users. I decided to spend some personal time to see what the source of the log explosion is and how it can be fixed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-1010) RequestHandler can crash when URI has ~ in path
[
https://issues.apache.org/jira/browse/OFBIZ-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leon Torres updated OFBIZ-1010:
---
Attachment: requestHandlerTilda.patch
requestHandlerTilda.patch fixes the issue.
Originally, it would parse the uri
/ordermgr/~category_id=XXX/~pcategory=YYY/LookupPartyName and decide that the
result is null/LookupPartyName. This is of course wrong.
This fix corrects the problem by checking for null.
RequestHandler can crash when URI has ~ in path
---
Key: OFBIZ-1010
URL: https://issues.apache.org/jira/browse/OFBIZ-1010
Project: OFBiz (The Open for Business Project)
Issue Type: Bug
Components: framework
Affects Versions: Release Branch 4.0
Reporter: Leon Torres
Attachments: requestHandlerTilda.patch
If you add a lookup popup to a page that uses the catalog browse system where
the URIs are like
/ordermgr/control/category/~category_id=201/~pcategory=200, and you click
on the lookup image to get the popup, then the reqeuest handler will crash
or do really weird things like render the whole appliccation in the popup.
The error is: The requested resource (/ordermgr/null/LookupPartyName) is not
available
I've traced the error to the RequestHandler.getNextPageUri() method and
found a fix that should introduce no complications.
Steps to reproduce:
1) In ordermgr's orderHeaderInfo.ftl, add the following small form (intent
is to change the order party):
form name=setOrderParty action=@ofbizUrlsetOrderParty/@ofbizUrl
method=post
input type='text' class='inputBox' name='partyId'
value='${partyMap.person.partyId?if_exists}'/
a
href=javascript:call_fieldlookup2(document.setOrderParty.partyId,'LookupPartyName');
img src='/images/fieldlookup.gif' width='15' height='14' border='0'
alt='Click here For Field Lookup'/
/a
/form
2) Create an order and browse the categories in the left bar to bring up the
category [Small Widgets] or whatever. The URI should have a ~pcategory in
it.
3) Click on the LookupPartyName button to get the popup.
4) Observe that a popup with the above noted error appears.
5) Browse [Small Widgets] or wherever you are and click on a product . Add
it to the cart.
6) Click on the LookupPartyName button again. This time the entire OFBiz
will be rendered inside the popup!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1010) RequestHandler can crash when URI has ~ in path
[
https://issues.apache.org/jira/browse/OFBIZ-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498031
]
Leon Torres commented on OFBIZ-1010:
The patch doesn't fix the second error where the OFBiz application is rendered
in the popup. I'll be attaching a fix for that part.
RequestHandler can crash when URI has ~ in path
---
Key: OFBIZ-1010
URL: https://issues.apache.org/jira/browse/OFBIZ-1010
Project: OFBiz (The Open for Business Project)
Issue Type: Bug
Components: framework
Affects Versions: Release Branch 4.0
Reporter: Leon Torres
Attachments: requestHandlerTilda.patch
If you add a lookup popup to a page that uses the catalog browse system where
the URIs are like
/ordermgr/control/category/~category_id=201/~pcategory=200, and you click
on the lookup image to get the popup, then the reqeuest handler will crash
or do really weird things like render the whole appliccation in the popup.
The error is: The requested resource (/ordermgr/null/LookupPartyName) is not
available
I've traced the error to the RequestHandler.getNextPageUri() method and
found a fix that should introduce no complications.
Steps to reproduce:
1) In ordermgr's orderHeaderInfo.ftl, add the following small form (intent
is to change the order party):
form name=setOrderParty action=@ofbizUrlsetOrderParty/@ofbizUrl
method=post
input type='text' class='inputBox' name='partyId'
value='${partyMap.person.partyId?if_exists}'/
a
href=javascript:call_fieldlookup2(document.setOrderParty.partyId,'LookupPartyName');
img src='/images/fieldlookup.gif' width='15' height='14' border='0'
alt='Click here For Field Lookup'/
/a
/form
2) Create an order and browse the categories in the left bar to bring up the
category [Small Widgets] or whatever. The URI should have a ~pcategory in
it.
3) Click on the LookupPartyName button to get the popup.
4) Observe that a popup with the above noted error appears.
5) Browse [Small Widgets] or wherever you are and click on a product . Add
it to the cart.
6) Click on the LookupPartyName button again. This time the entire OFBiz
will be rendered inside the popup!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1010) RequestHandler can crash when URI has ~ in path
[
https://issues.apache.org/jira/browse/OFBIZ-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498033
]
Leon Torres commented on OFBIZ-1010:
The second error occurs because the request is /additem/LookupPartyName.
It will attempt to call additem reequest, which has no data, so it results in
error. Then it somehow renders the error page in the LookupPartyName popup.
That is why the OFBiz application is rendered in th popup.
This seems to be a completely different problem requiring a separate solution,
although it is related to the issue of handling mutliple URI requests. I
cannot fix it now due to time constraints and the lack of an obvious solution.
RequestHandler can crash when URI has ~ in path
---
Key: OFBIZ-1010
URL: https://issues.apache.org/jira/browse/OFBIZ-1010
Project: OFBiz (The Open for Business Project)
Issue Type: Bug
Components: framework
Affects Versions: Release Branch 4.0
Reporter: Leon Torres
Attachments: requestHandlerTilda.patch
If you add a lookup popup to a page that uses the catalog browse system where
the URIs are like
/ordermgr/control/category/~category_id=201/~pcategory=200, and you click
on the lookup image to get the popup, then the reqeuest handler will crash
or do really weird things like render the whole appliccation in the popup.
The error is: The requested resource (/ordermgr/null/LookupPartyName) is not
available
I've traced the error to the RequestHandler.getNextPageUri() method and
found a fix that should introduce no complications.
Steps to reproduce:
1) In ordermgr's orderHeaderInfo.ftl, add the following small form (intent
is to change the order party):
form name=setOrderParty action=@ofbizUrlsetOrderParty/@ofbizUrl
method=post
input type='text' class='inputBox' name='partyId'
value='${partyMap.person.partyId?if_exists}'/
a
href=javascript:call_fieldlookup2(document.setOrderParty.partyId,'LookupPartyName');
img src='/images/fieldlookup.gif' width='15' height='14' border='0'
alt='Click here For Field Lookup'/
/a
/form
2) Create an order and browse the categories in the left bar to bring up the
category [Small Widgets] or whatever. The URI should have a ~pcategory in
it.
3) Click on the LookupPartyName button to get the popup.
4) Observe that a popup with the above noted error appears.
5) Browse [Small Widgets] or wherever you are and click on a product . Add
it to the cart.
6) Click on the LookupPartyName button again. This time the entire OFBiz
will be rendered inside the popup!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1010) RequestHandler can crash when URI has ~ in path
[
https://issues.apache.org/jira/browse/OFBIZ-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498034
]
Leon Torres commented on OFBIZ-1010:
A workaround to the problem where OFBiz is rendered in the popup is to change
additem request so that it does request-redirect to orderentry. This
changes the behavior of additem so it stays in the product page after adding
the product, but the popup issue is avoided.
RequestHandler can crash when URI has ~ in path
---
Key: OFBIZ-1010
URL: https://issues.apache.org/jira/browse/OFBIZ-1010
Project: OFBiz (The Open for Business Project)
Issue Type: Bug
Components: framework
Affects Versions: Release Branch 4.0
Reporter: Leon Torres
Attachments: requestHandlerTilda.patch
If you add a lookup popup to a page that uses the catalog browse system where
the URIs are like
/ordermgr/control/category/~category_id=201/~pcategory=200, and you click
on the lookup image to get the popup, then the reqeuest handler will crash
or do really weird things like render the whole appliccation in the popup.
The error is: The requested resource (/ordermgr/null/LookupPartyName) is not
available
I've traced the error to the RequestHandler.getNextPageUri() method and
found a fix that should introduce no complications.
Steps to reproduce:
1) In ordermgr's orderHeaderInfo.ftl, add the following small form (intent
is to change the order party):
form name=setOrderParty action=@ofbizUrlsetOrderParty/@ofbizUrl
method=post
input type='text' class='inputBox' name='partyId'
value='${partyMap.person.partyId?if_exists}'/
a
href=javascript:call_fieldlookup2(document.setOrderParty.partyId,'LookupPartyName');
img src='/images/fieldlookup.gif' width='15' height='14' border='0'
alt='Click here For Field Lookup'/
/a
/form
2) Create an order and browse the categories in the left bar to bring up the
category [Small Widgets] or whatever. The URI should have a ~pcategory in
it.
3) Click on the LookupPartyName button to get the popup.
4) Observe that a popup with the above noted error appears.
5) Browse [Small Widgets] or wherever you are and click on a product . Add
it to the cart.
6) Click on the LookupPartyName button again. This time the entire OFBiz
will be rendered inside the popup!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-1007) Set decimal places to show for ofbizCurrencyTransform
Set decimal places to show for ofbizCurrencyTransform - Key: OFBIZ-1007 URL: https://issues.apache.org/jira/browse/OFBIZ-1007 Project: OFBiz (The Open for Business Project) Issue Type: Improvement Components: framework Affects Versions: Release Branch 4.0 Reporter: Leon Torres Priority: Minor Some users may wish to have 3 or 4 decimal places of precision in currency amounts. This is easily configurable with the fieldtype XML files. The problem is that the @ofbizCurrencyTransform macro will truncate the numbers because the decimal places is determined from the Locale object, and there is no way to tell it that the decimal places should be 3 or 4 or whatever. Additionally, these users often have the desire to right pad the numbers with zeroes. For instance, an amount of $3.04 should be displayed as $3.0400 for a 4 decimal place requirement. Currently the UtilFormatOut.formatCurrency() methods have no way to support this right-filling of zeros in this manner. I have implemented a fairly elegant way of solving both related issues with minimal impact. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-1007) Set decimal places to show for ofbizCurrencyTransform
[ https://issues.apache.org/jira/browse/OFBIZ-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leon Torres updated OFBIZ-1007: --- Attachment: currency-decimal-places.patch The currency-decimal-places.patch file contains my proposed solution. It allows the user to define the number of decimal places to display in the context that requires it. An improvement on this patch would be to have a configurable property value to use by default. Ideally, we would also have some kind of rounding mode and scale setting, so the numbers could be rounded properly. Currently that detail is being delegated to the com.ibm.icu.NumberFormatter class. - Leon Set decimal places to show for ofbizCurrencyTransform - Key: OFBIZ-1007 URL: https://issues.apache.org/jira/browse/OFBIZ-1007 Project: OFBiz (The Open for Business Project) Issue Type: Improvement Components: framework Affects Versions: Release Branch 4.0 Reporter: Leon Torres Priority: Minor Attachments: currency-decimal-places.patch Some users may wish to have 3 or 4 decimal places of precision in currency amounts. This is easily configurable with the fieldtype XML files. The problem is that the @ofbizCurrencyTransform macro will truncate the numbers because the decimal places is determined from the Locale object, and there is no way to tell it that the decimal places should be 3 or 4 or whatever. Additionally, these users often have the desire to right pad the numbers with zeroes. For instance, an amount of $3.04 should be displayed as $3.0400 for a 4 decimal place requirement. Currently the UtilFormatOut.formatCurrency() methods have no way to support this right-filling of zeros in this manner. I have implemented a fairly elegant way of solving both related issues with minimal impact. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-837) EntityFunction.UPPER will crash if its argument contains apostrophes
EntityFunction.UPPER will crash if its argument contains apostrophes
Key: OFBIZ-837
URL: https://issues.apache.org/jira/browse/OFBIZ-837
Project: OFBiz (The Open for Business Project)
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Leon Torres
Priority: Blocker
If one makes a LIKE condition such as the following,
EntityExpr(firstName, true, EntityOperator.LIKE, O'Donnell, true);
It gets mapped into an SQL expression:
FIRST_NAME LIKE UPPER('O'Donnell')
Which crashes because the apostrophe in O'Donnell was not escaped.
The reason for this is that when the condition is created by
EntityFunction.UPPER, it bypasses the usual string escaping that is performed
by the JDBC. That is, the entity engine is constructing the UPPER('O'Donnell')
string by hand and inserting it directly into an SQL instruction, rather than
using a safer prepared statement technique.
This bug crashes a bunch of screens all over that use the LIKE operation. It
also permits SQL injection attacks, which is the reason I made this a blocker
issue.
This issue was discovered on a client site running an older version of ofbiz
and has been confirmed in SVN. You can try it by searching for O'Donnell or
anything with an apostrophe in the party manager's find party screen.
I have a very simple fix which I'll attach after this that can be applied to
OFBiz since 3.0 at least.
Those of us who have older versions in production should probably consider
fixing this bug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-812) multi-form select boxes broken
[ https://issues.apache.org/jira/browse/OFBIZ-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480528 ] Leon Torres commented on OFBIZ-812: --- Are there related revisions related to 516317? I reverted it in my instance and now the checkboxes show up, but the select all button still does not work. multi-form select boxes broken -- Key: OFBIZ-812 URL: https://issues.apache.org/jira/browse/OFBIZ-812 Project: OFBiz (The Open for Business Project) Issue Type: Bug Components: framework Reporter: Si Chen Priority: Blocker Something happened last week and the multi-select form select boxes of the form widget are no longer showing up. This is a critical problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-789) Allow naming the attachment PDF in sendMailFromScreen
Allow naming the attachment PDF in sendMailFromScreen - Key: OFBIZ-789 URL: https://issues.apache.org/jira/browse/OFBIZ-789 Project: OFBiz (The Open for Business Project) Issue Type: Improvement Reporter: Leon Torres Priority: Minor Right now the sendMailFromScreen service names all PDF attachments it generates Details.pdf. This is hardcoded in the Java method. What we'd like is the ability to name this attachment via a service parameter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-789) Allow naming the attachment PDF in sendMailFromScreen
[ https://issues.apache.org/jira/browse/OFBIZ-789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leon Torres updated OFBIZ-789: -- Attachment: name-pdf-attachment.patch This patch is a simple and effective solution. Allow naming the attachment PDF in sendMailFromScreen - Key: OFBIZ-789 URL: https://issues.apache.org/jira/browse/OFBIZ-789 Project: OFBiz (The Open for Business Project) Issue Type: Improvement Reporter: Leon Torres Priority: Minor Attachments: name-pdf-attachment.patch Right now the sendMailFromScreen service names all PDF attachments it generates Details.pdf. This is hardcoded in the Java method. What we'd like is the ability to name this attachment via a service parameter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-309) If a service is implemented as an interface, its settings for optional attributes are ignored!
[ https://issues.apache.org/jira/browse/OFBIZ-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471807 ] Leon Torres commented on OFBIZ-309: --- This is still an issue, it was never fixed. Do we understand what the issue is? It's very simple, if you use implements to include the attributes of another service definition, the included attributes will not retain whether the attribute is optional or not. If a service is implemented as an interface, its settings for optional attributes are ignored! -- Key: OFBIZ-309 URL: https://issues.apache.org/jira/browse/OFBIZ-309 Project: OFBiz (The Open for Business Project) Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Leon Torres Priority: Critical This is bad: If a service has some attributes with optional=false and is implemented with implements service=, the settings for optional are ignored and default to true instead. As an example, look up the service definition for upsRateEstimate in webtools and compare to the service that it implements, calcShipmentEstimateInterface. The interface defines a few optional fields as false, which show up correctly for calcShipmentEstimateInterface but are all set to true in upsRateEstimate. It used to work, something must have broken it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-686) Key violation when generating WorkEffortKeywords
Key violation when generating WorkEffortKeywords Key: OFBIZ-686 URL: https://issues.apache.org/jira/browse/OFBIZ-686 Project: OFBiz (The Open for Business Project) Issue Type: Bug Components: workeffort Reporter: Leon Torres Priority: Minor When I try creating a work effort content using createWorkEffortContent service, I get the following error, 2007-02-05 11:28:07,826 (http-0.0.0.0-8443-Processor4) [ CallObjectMethod.java:166:ERROR] exception report -- Method in call method operation threw an exception Exception: org.ofbiz.entity.GenericEntityException Message: Exception while inserting the following entity: [GenericEntity:WorkEffortKeyword][createdStamp,2007-02-05 11:28:07.775(java.sql.Timestamp)][createdTxStamp,2007-02-05 11:28:06.751(java.sql.Timestamp)][keyword,host=falseloc=myevitebrand=eviteenum=70transactionid=1089079009tile=1089079009subid=falsesite=eviteadsize=1x1pagepos=118(java.lang.String)][lastUpdatedStamp,2007-02-05 11:28:07.775(java.sql.Timestamp)][lastUpdatedTxStamp,2007-02-05 11:28:06.751(java.sql.Timestamp)][relevancyWeight,1(java.lang.Long)][workEffortId,10116(java.lang.String)] (while inserting: [GenericEntity:WorkEffortKeyword][createdStamp,2007-02-05 11:28:07.775(java.sql.Timestamp)][createdTxStamp,2007-02-05 11:28:06.751(java.sql.Timestamp)][keyword,host=falseloc=myevitebrand=eviteenum=70transactionid=1089079009tile=1089079009subid=falsesite=eviteadsize=1x1pagepos=118(java.lang.String)][lastUpdatedStamp,2007-02-05 11:28:07.775(java.sql.Timestamp)][lastUpdatedTxStamp,2007-02-05 11:28:06.751(java.sql.Timestamp)][relevancyWeight,1(java.lang.Long)][workEffortId,10116(java.lang.String)] (SQL Exception while executing the following:INSERT INTO WORK_EFFORT_KEYWORD (WORK_EFFORT_ID, KEYWORD, RELEVANCY_WEIGHT, LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP) VALUES (?, ?, ?, ?, ?, ?, ?) (Duplicate key or integrity constraint violation message from server: Duplicate entry '10116-host=falseloc=myevitebrand=eviteenum=70transactionid=1' for key 1))) stack trace --- org.ofbiz.entity.GenericEntityException: Exception while inserting the following entity: [GenericEntity:WorkEffortKeyword][createdStamp,2007-02-05 11:28:07.775(java.sql.Timestamp)][createdTxStamp,2007-02-05 11:28:06.751(java.sql.Timestamp)][keyword,host=falseloc=myevitebrand=eviteenum=70transactionid=1089079009tile=1089079009subid=falsesite=eviteadsize=1x1pagepos=118(java.lang.String)][lastUpdatedStamp,2007-02-05 11:28:07.775(java.sql.Timestamp)][lastUpdatedTxStamp,2007-02-05 11:28:06.751(java.sql.Timestamp)][relevancyWeight,1(java.lang.Long)][workEffortId,10116(java.lang.String)] (while inserting: [GenericEntity:WorkEffortKeyword][createdStamp,2007-02-05 11:28:07.775(java.sql.Timestamp)][createdTxStamp,2007-02-05 11:28:06.751(java.sql.Timestamp)][keyword,host=falseloc=myevitebrand=eviteenum=70transactionid=1089079009tile=1089079009subid=falsesite=eviteadsize=1x1pagepos=118(java.lang.String)][lastUpdatedStamp,2007-02-05 11:28:07.775(java.sql.Timestamp)][lastUpdatedTxStamp,2007-02-05 11:28:06.751(java.sql.Timestamp)][relevancyWeight,1(java.lang.Long)][workEffortId,10116(java.lang.String)] (SQL Exception while executing the following:INSERT INTO WORK_EFFORT_KEYWORD (WORK_EFFORT_ID, KEYWORD, RELEVANCY_WEIGHT, LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP) VALUES (?, ?, ?, ?, ?, ?, ?) (Duplicate key or integrity constraint violation message from server: Duplicate entry '10116-host=falseloc=myevitebrand=eviteenum=70transactionid=1' for key 1))) org.ofbiz.entity.datasource.GenericDAO.insert(GenericDAO.java:116) org.ofbiz.entity.datasource.GenericHelperDAO.create(GenericHelperDAO.java:65) org.ofbiz.entity.GenericDelegator.create(GenericDelegator.java:559) org.ofbiz.entity.GenericDelegator.storeAll(GenericDelegator.java:1097) org.ofbiz.entity.GenericDelegator.storeAll(GenericDelegator.java:1047) org.ofbiz.entity.GenericDelegator.storeAll(GenericDelegator.java:1032) org.ofbiz.workeffort.workeffort.WorkEffortKeywordIndex.indexKeywords(WorkEffortKeywordIndex.java:132) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:324) org.ofbiz.minilang.method.callops.CallObjectMethod.callMethod(CallObjectMethod.java:138) org.ofbiz.minilang.method.callops.CallClassMethod.exec(CallClassMethod.java:90) org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:929) org.ofbiz.minilang.SimpleMethod.exec(SimpleMethod.java:568)
[jira] Commented: (OFBIZ-644) Pagination in https://host_name:8443/ordermgr/control/orderlist needed
[ https://issues.apache.org/jira/browse/OFBIZ-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467485 ] Leon Torres commented on OFBIZ-644: --- Yeah sorry, this patch was against r 463793. I'm short on time to update it for the changes to orderlist, but it should be relatively straightforward to fix. I'm just putting this on the table in case Jacques or anyone wants to take a crack at it now. Pagination in https://host_name:8443/ordermgr/control/orderlist needed -- Key: OFBIZ-644 URL: https://issues.apache.org/jira/browse/OFBIZ-644 Project: OFBiz (The Open for Business Project) Issue Type: Improvement Components: order Affects Versions: SVN trunk Environment: All Reporter: Walter Vaughan Assigned To: Jacques Le Roux Fix For: SVN trunk Attachments: orderliststate.patch There is no pagination in https://host_name:8443/ordermgr/control/orderlist. If a status like sent' is chosen, thousands or millions of rows will be returned if there is that many in the database. Some sort of pagination system like we have in https://host_name:8443/partymgr/control/findparty with some sort of higher limit like 100 records or so might be good, as to not break behavior for most existing users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-644) Pagination in https://host_name:8443/ordermgr/control/orderlist needed
[ https://issues.apache.org/jira/browse/OFBIZ-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leon Torres updated OFBIZ-644: -- Attachment: orderliststate-svn.patch Hi, I just updated my code and now it works against ofbiz SVN. It actually works pretty well, the only thing left to do is polish it by adding the ability to configure the view size in a config property, maybe change the @paginate macro to make it more user friendly (insert links to specific pages if the list is large, such as on forums), and add an indicator for what page it is at. There's some debugging code in there to help track the state of the form. Also, I guess those extra checkbox fields will have to be added in at some point. Pagination in https://host_name:8443/ordermgr/control/orderlist needed -- Key: OFBIZ-644 URL: https://issues.apache.org/jira/browse/OFBIZ-644 Project: OFBiz (The Open for Business Project) Issue Type: Improvement Components: order Affects Versions: SVN trunk Environment: All Reporter: Walter Vaughan Assigned To: Jacques Le Roux Fix For: SVN trunk Attachments: orderliststate-svn.patch, orderliststate.patch There is no pagination in https://host_name:8443/ordermgr/control/orderlist. If a status like sent' is chosen, thousands or millions of rows will be returned if there is that many in the database. Some sort of pagination system like we have in https://host_name:8443/partymgr/control/findparty with some sort of higher limit like 100 records or so might be good, as to not break behavior for most existing users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-644) Pagination in https://host_name:8443/ordermgr/control/orderlist needed
[ https://issues.apache.org/jira/browse/OFBIZ-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leon Torres updated OFBIZ-644: -- Attachment: orderliststate.patch I created a paginated version of the page awhile back, against r 463793. It's not a trivial thing to do because it is an ftl file and has a lot of state to keep track of. Please try this out and let us know if it works or not. :-) Pagination in https://host_name:8443/ordermgr/control/orderlist needed -- Key: OFBIZ-644 URL: https://issues.apache.org/jira/browse/OFBIZ-644 Project: Apache OFBiz (The Open for Business Project) Issue Type: Improvement Components: order Affects Versions: SVN trunk Environment: All Reporter: Walter Vaughan Fix For: SVN trunk Attachments: orderliststate.patch There is no pagination in https://host_name:8443/ordermgr/control/orderlist. If a status like sent' is chosen, thousands or millions of rows will be returned if there is that many in the database. Some sort of pagination system like we have in https://host_name:8443/partymgr/control/findparty with some sort of higher limit like 100 records or so might be good, as to not break behavior for most existing users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-644) Pagination in https://host_name:8443/ordermgr/control/orderlist needed
[ https://issues.apache.org/jira/browse/OFBIZ-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467194 ] Leon Torres commented on OFBIZ-644: --- Also, I wanted to note that this patch contains an exploraiton on how to handle similar complex lists that require pagination. There is a Java classs in it that is stored in the session, which is responsible for tracking the state of the list. The idea is to use this object instead of passing around dozens of url parameters. If it works well, we can generalize the approach and use it as a design pattern for similar lists. Pagination in https://host_name:8443/ordermgr/control/orderlist needed -- Key: OFBIZ-644 URL: https://issues.apache.org/jira/browse/OFBIZ-644 Project: Apache OFBiz (The Open for Business Project) Issue Type: Improvement Components: order Affects Versions: SVN trunk Environment: All Reporter: Walter Vaughan Fix For: SVN trunk Attachments: orderliststate.patch There is no pagination in https://host_name:8443/ordermgr/control/orderlist. If a status like sent' is chosen, thousands or millions of rows will be returned if there is that many in the database. Some sort of pagination system like we have in https://host_name:8443/partymgr/control/findparty with some sort of higher limit like 100 records or so might be good, as to not break behavior for most existing users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-628) Change ProductCategory dropdowns to lookup windows
[ https://issues.apache.org/jira/browse/OFBIZ-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465310 ] Leon Torres commented on OFBIZ-628: --- Ok thanks for the update and clarification. Hopefully we'll get it in by today. :-) Change ProductCategory dropdowns to lookup windows -- Key: OFBIZ-628 URL: https://issues.apache.org/jira/browse/OFBIZ-628 Project: Apache OFBiz (The Open for Business Project) Issue Type: Improvement Components: product Affects Versions: SVN trunk Environment: All Reporter: Walter Vaughan Assigned To: Si Chen Fix For: SVN trunk Attachments: patch_category_lookup, patch_category_lookup2 There are several places in ofBiz where a drop down window is used to select a ProductCategory. However, in installations with a significant number of categories, the overhead of a sequential scan query causes severe slowdowns in the performance of ofBiz, and overloads the browser client. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
