[jira] [Created] (OFBIZ-7899) createDataResource will sometimes fail when uploading Excel documents due to missing libraries
Forrest Rae created OFBIZ-7899: -- Summary: createDataResource will sometimes fail when uploading Excel documents due to missing libraries Key: OFBIZ-7899 URL: https://issues.apache.org/jira/browse/OFBIZ-7899 Project: OFBiz Issue Type: Bug Components: content Affects Versions: Release Branch 15.12, Trunk Reporter: Forrest Rae createDataResource calls org.ofbiz.content.data.DataResourceWorker.getMimeTypeWithByteBuffer(). getMimeTypeWithByteBuffer calls into the Tika library to detect the mime type of the file. Tika will try to detect the file format, leveraging a number of detectors, one of which is Apache POI. Apache POI's detector will try to call routines in jar files that are not included in with the content application, leading to the following exception: java.lang.IllegalAccessError: tried to access method org.apache.poi.util.POILogger.log(ILjava/lang/Object;)V from class org.apache.poi.openxml4j.opc.PackageRelationshipCollection The missing jar files can be found here: https://archive.apache.org/dist/poi/release/bin/poi-bin-3.13-20150929.zip The missing jars are: poi-ooxml poi-ooxml-schemas Might be good to update to the latest version of POI as well: http://poi.apache.org/download.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-7041) Upgrade freemarker jar to 2.3.24
[ https://issues.apache.org/jira/browse/OFBIZ-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15314846#comment-15314846 ] Forrest Rae commented on OFBIZ-7041: This new version of FreeMarker includes [auto-escaping and output formats|http://freemarker.org/docs/dgui_misc_autoescaping.html]. The <#escape> directive has been deprecated. Notice the comment at the very end of this page: "FreeMarker automatically escapes all values printed ... if it's properly configured (that's the responsibility of the programmers; [see here how|http://freemarker.org/docs/pgui_config_outputformatsautoesc.html])." Would be good to turn autoescaping on, and set the configuration to match .ftl as HTML and .fo.ftl as XML. Thoughts? > Upgrade freemarker jar to 2.3.24 > > > Key: OFBIZ-7041 > URL: https://issues.apache.org/jira/browse/OFBIZ-7041 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Deepak Dixit >Assignee: Deepak Dixit > Fix For: Upcoming Branch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-7072) DataResource.dataResourceName field should be at least 255 Chars
[ https://issues.apache.org/jira/browse/OFBIZ-7072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15293962#comment-15293962 ] Forrest Rae commented on OFBIZ-7072: I think it's a bug. Though, I think most of the field definitions are way too short. :P > DataResource.dataResourceName field should be at least 255 Chars > > > Key: OFBIZ-7072 > URL: https://issues.apache.org/jira/browse/OFBIZ-7072 > Project: OFBiz > Issue Type: Bug > Components: content >Affects Versions: Release Branch 13.07, Release Branch 14.12, Release > Branch 15.12 >Reporter: Forrest Rae >Assignee: Ashish Vijaywargiya > Attachments: OFBIZ-7072.patch > > > Most major operating systems limit the length of a file name to 255 chars. > When sending an email with file attachments, the attachments get saved as > DataResources associated with a CommunicationEvent, with the filename being > saved in the DataResource.dataResourceName field. Currently, this field is > set to name, which is limited to 100 chars. These two limitations don't add > up, and the field should be increased to 255 chars. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-7072) DataResource.dataResourceName field should be at least 255 Chars
[ https://issues.apache.org/jira/browse/OFBIZ-7072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-7072: --- Attachment: OFBIZ-7072.patch > DataResource.dataResourceName field should be at least 255 Chars > > > Key: OFBIZ-7072 > URL: https://issues.apache.org/jira/browse/OFBIZ-7072 > Project: OFBiz > Issue Type: Bug > Components: content >Affects Versions: Release Branch 13.07, Release Branch 14.12, Release > Branch 15.12 >Reporter: Forrest Rae > Attachments: OFBIZ-7072.patch > > > Most major operating systems limit the length of a file name to 255 chars. > When sending an email with file attachments, the attachments get saved as > DataResources associated with a CommunicationEvent, with the filename being > saved in the DataResource.dataResourceName field. Currently, this field is > set to name, which is limited to 100 chars. These two limitations don't add > up, and the field should be increased to 255 chars. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-7072) DataResource.dataResourceName field should be at least 255 Chars
[ https://issues.apache.org/jira/browse/OFBIZ-7072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-7072: --- Attachment: (was: OFBIZ-7072.patch) > DataResource.dataResourceName field should be at least 255 Chars > > > Key: OFBIZ-7072 > URL: https://issues.apache.org/jira/browse/OFBIZ-7072 > Project: OFBiz > Issue Type: Bug > Components: content >Affects Versions: Release Branch 13.07, Release Branch 14.12, Release > Branch 15.12 >Reporter: Forrest Rae > > Most major operating systems limit the length of a file name to 255 chars. > When sending an email with file attachments, the attachments get saved as > DataResources associated with a CommunicationEvent, with the filename being > saved in the DataResource.dataResourceName field. Currently, this field is > set to name, which is limited to 100 chars. These two limitations don't add > up, and the field should be increased to 255 chars. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-7072) DataResource.dataResourceName field should be at least 255 Chars
[ https://issues.apache.org/jira/browse/OFBIZ-7072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-7072: --- Attachment: OFBIZ-7072.patch > DataResource.dataResourceName field should be at least 255 Chars > > > Key: OFBIZ-7072 > URL: https://issues.apache.org/jira/browse/OFBIZ-7072 > Project: OFBiz > Issue Type: Bug > Components: content >Affects Versions: Release Branch 13.07, Release Branch 14.12, Release > Branch 15.12 >Reporter: Forrest Rae > Attachments: OFBIZ-7072.patch > > > Most major operating systems limit the length of a file name to 255 chars. > When sending an email with file attachments, the attachments get saved as > DataResources associated with a CommunicationEvent, with the filename being > saved in the DataResource.dataResourceName field. Currently, this field is > set to name, which is limited to 100 chars. These two limitations don't add > up, and the field should be increased to 255 chars. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-7072) DataResource.dataResourceName field should be at least 255 Chars
Forrest Rae created OFBIZ-7072: -- Summary: DataResource.dataResourceName field should be at least 255 Chars Key: OFBIZ-7072 URL: https://issues.apache.org/jira/browse/OFBIZ-7072 Project: OFBiz Issue Type: Bug Components: content Affects Versions: Release Branch 15.12, Release Branch 14.12, Release Branch 13.07 Reporter: Forrest Rae Attachments: OFBIZ-7072.patch Most major operating systems limit the length of a file name to 255 chars. When sending an email with file attachments, the attachments get saved as DataResources associated with a CommunicationEvent, with the filename being saved in the DataResource.dataResourceName field. Currently, this field is set to name, which is limited to 100 chars. These two limitations don't add up, and the field should be increased to 255 chars. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6993) Cannot find the declaration of element 'web-app' in version 3.0 files.
[
https://issues.apache.org/jira/browse/OFBIZ-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15232323#comment-15232323
]
Forrest Rae commented on OFBIZ-6993:
I'll do a little bit of digging and report back. Perhaps reopen this bug and
assign to me?
> Cannot find the declaration of element 'web-app' in version 3.0 files.
> --
>
> Key: OFBIZ-6993
> URL: https://issues.apache.org/jira/browse/OFBIZ-6993
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Trunk, Release Branch 15.12
> Environment: Been seeing the error below in the logs. Strangely,
> I've not been able to catch the exception in a debugger, but was able to
> isolate it to the definition of the web-app with version 3.0. The error
> disapears when you change the definition from
> {code:xml}
>
> {code}
> to this:
> {code:xml}
> xmlns="http://java.sun.com/xml/ns/javaee";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd";>
> {code}
> I only tested on 15.12 and Trunk, but it probably affects any release running
> Tomcat 7.0.48 or higher. Here is the error:
> {noformat}
> [java] Apr 07, 2016 4:06:29 PM org.apache.tomcat.util.digester.Digester
> error
> [java] SEVERE: Parse Error at line 22 column 24: cvc-elt.1.a: Cannot
> find the declaration of element 'web-app'.
> [java] org.xml.sax.SAXParseException; lineNumber: 22; columnNumber: 24;
> cvc-elt.1.a: Cannot find the declaration of element 'web-app'.
> [java] at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)
> [java] at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElementAfterName(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> [java] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)
> [java] at
> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> [java] at
> org.apache.tomcat.util.digester.Digester.parse(Digester.java:1555)
> [java] at
> org.ofbiz.webapp.WebAppUtil.parseWebXmlFile(WebAppUtil.java:160)
> [java] at org.ofbiz.webapp.WebAppUtil.getWebXml(WebAppUtil.java:131)
> [java] at
> org.ofbiz.webapp.WebAppUtil.getControlServletPath(WebAppUtil.java:67)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(Method.java:498)
> [java] at
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1458)
> [java] at
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:71)
> [java] at freemarker.core.MethodCall._eval(MethodCall.java:62)
> [java] at freemarker.core.Expression.eval(Expression.java:78)
> [java] at freemarker.core.Assignment.accept(Assignment.java:70)
> [java] at freemarker.core.Environment.visit(Environment.java:312)
> [java] at freemarker.core.MixedContent.accept(MixedContent.java:62)
> [java] at
> freemarker.core.Environment.visitByHiddingParent(Environment.java:333)
> [java] at
> freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:148)
> [java] at
> freemarker.core.Environment.visitIteratorBlock(Environment.java:559)
> [java] at freemarker.core.IteratorBlock.accept(IteratorB
[jira] [Commented] (OFBIZ-6993) Cannot find the declaration of element 'web-app' in version 3.0 files.
[
https://issues.apache.org/jira/browse/OFBIZ-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15231671#comment-15231671
]
Forrest Rae commented on OFBIZ-6993:
Deekpak, I read that in the other thread and it really doesn't have anything to
do with this bug.
If you review the error I pasted above, the issue is that the SAXParser is
having trouble parsing these web.xml files because it can't validate them, so
complains that it doesn't know what is. It's likely that the fix is
simply to download http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd and put it
in the right spot in the framework so that the parser picks it up.
> Cannot find the declaration of element 'web-app' in version 3.0 files.
> --
>
> Key: OFBIZ-6993
> URL: https://issues.apache.org/jira/browse/OFBIZ-6993
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Trunk, Release Branch 15.12
> Environment: Been seeing the error below in the logs. Strangely,
> I've not been able to catch the exception in a debugger, but was able to
> isolate it to the definition of the web-app with version 3.0. The error
> disapears when you change the definition from
> {code:xml}
>
> {code}
> to this:
> {code:xml}
> xmlns="http://java.sun.com/xml/ns/javaee";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd";>
> {code}
> I only tested on 15.12 and Trunk, but it probably affects any release running
> Tomcat 7.0.48 or higher. Here is the error:
> {noformat}
> [java] Apr 07, 2016 4:06:29 PM org.apache.tomcat.util.digester.Digester
> error
> [java] SEVERE: Parse Error at line 22 column 24: cvc-elt.1.a: Cannot
> find the declaration of element 'web-app'.
> [java] org.xml.sax.SAXParseException; lineNumber: 22; columnNumber: 24;
> cvc-elt.1.a: Cannot find the declaration of element 'web-app'.
> [java] at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)
> [java] at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElementAfterName(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> [java] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)
> [java] at
> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> [java] at
> org.apache.tomcat.util.digester.Digester.parse(Digester.java:1555)
> [java] at
> org.ofbiz.webapp.WebAppUtil.parseWebXmlFile(WebAppUtil.java:160)
> [java] at org.ofbiz.webapp.WebAppUtil.getWebXml(WebAppUtil.java:131)
> [java] at
> org.ofbiz.webapp.WebAppUtil.getControlServletPath(WebAppUtil.java:67)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(Method.java:498)
> [java] at
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1458)
> [java] at
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:71)
> [java] at freemarker.core.MethodCall._eval(MethodCall.java:62)
> [java] at freemarker.core.Expression.eval(Expression.java:78)
> [java] at freemarker.core.Assignment.accept(Assignment.java:70)
> [java] at freemarker.core.Environment.visit(Environment.java:312)
> [java] at freemarker.core.Mi
[jira] [Commented] (OFBIZ-6993) Cannot find the declaration of element 'web-app' in version 3.0 files.
[
https://issues.apache.org/jira/browse/OFBIZ-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15231644#comment-15231644
]
Forrest Rae commented on OFBIZ-6993:
Okay, no, this doesn't doesn't duplicate OFBIZ-6807, it's actually introduced
by OFBIZ-6807.
Repo:
ant start-debug (watch console)
Visit webtools in browser: /webtools/control/main
See error message.
> Cannot find the declaration of element 'web-app' in version 3.0 files.
> --
>
> Key: OFBIZ-6993
> URL: https://issues.apache.org/jira/browse/OFBIZ-6993
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Trunk, Release Branch 15.12
> Environment: Been seeing the error below in the logs. Strangely,
> I've not been able to catch the exception in a debugger, but was able to
> isolate it to the definition of the web-app with version 3.0. The error
> disapears when you change the definition from
> {code:xml}
>
> {code}
> to this:
> {code:xml}
> xmlns="http://java.sun.com/xml/ns/javaee";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd";>
> {code}
> I only tested on 15.12 and Trunk, but it probably affects any release running
> Tomcat 7.0.48 or higher. Here is the error:
> {noformat}
> [java] Apr 07, 2016 4:06:29 PM org.apache.tomcat.util.digester.Digester
> error
> [java] SEVERE: Parse Error at line 22 column 24: cvc-elt.1.a: Cannot
> find the declaration of element 'web-app'.
> [java] org.xml.sax.SAXParseException; lineNumber: 22; columnNumber: 24;
> cvc-elt.1.a: Cannot find the declaration of element 'web-app'.
> [java] at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)
> [java] at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElementAfterName(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> [java] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)
> [java] at
> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> [java] at
> org.apache.tomcat.util.digester.Digester.parse(Digester.java:1555)
> [java] at
> org.ofbiz.webapp.WebAppUtil.parseWebXmlFile(WebAppUtil.java:160)
> [java] at org.ofbiz.webapp.WebAppUtil.getWebXml(WebAppUtil.java:131)
> [java] at
> org.ofbiz.webapp.WebAppUtil.getControlServletPath(WebAppUtil.java:67)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(Method.java:498)
> [java] at
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1458)
> [java] at
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:71)
> [java] at freemarker.core.MethodCall._eval(MethodCall.java:62)
> [java] at freemarker.core.Expression.eval(Expression.java:78)
> [java] at freemarker.core.Assignment.accept(Assignment.java:70)
> [java] at freemarker.core.Environment.visit(Environment.java:312)
> [java] at freemarker.core.MixedContent.accept(MixedContent.java:62)
> [java] at
> freemarker.core.Environment.visitByHiddingParent(Environment.java:333)
> [java] at
> freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:148)
> [java] at
> freemarker.core.Environm
[jira] [Updated] (OFBIZ-6993) Cannot find the declaration of element 'web-app' in version 3.0 files.
[
https://issues.apache.org/jira/browse/OFBIZ-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Forrest Rae updated OFBIZ-6993:
---
Attachment: web-app.patch
> Cannot find the declaration of element 'web-app' in version 3.0 files.
> --
>
> Key: OFBIZ-6993
> URL: https://issues.apache.org/jira/browse/OFBIZ-6993
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Trunk, Release Branch 15.12
> Environment: Been seeing the error below in the logs. Strangely,
> I've not been able to catch the exception in a debugger, but was able to
> isolate it to the definition of the web-app with version 3.0. The error
> disapears when you change the definition from
> {code:xml}
>
> {code}
> to this:
> {code:xml}
> xmlns="http://java.sun.com/xml/ns/javaee";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd";>
> {code}
> I only tested on 15.12 and Trunk, but it probably affects any release running
> Tomcat 7.0.48 or higher. Here is the error:
> {noformat}
> [java] Apr 07, 2016 4:06:29 PM org.apache.tomcat.util.digester.Digester
> error
> [java] SEVERE: Parse Error at line 22 column 24: cvc-elt.1.a: Cannot
> find the declaration of element 'web-app'.
> [java] org.xml.sax.SAXParseException; lineNumber: 22; columnNumber: 24;
> cvc-elt.1.a: Cannot find the declaration of element 'web-app'.
> [java] at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)
> [java] at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElementAfterName(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> [java] at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
> [java] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> [java] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)
> [java] at
> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> [java] at
> org.apache.tomcat.util.digester.Digester.parse(Digester.java:1555)
> [java] at
> org.ofbiz.webapp.WebAppUtil.parseWebXmlFile(WebAppUtil.java:160)
> [java] at org.ofbiz.webapp.WebAppUtil.getWebXml(WebAppUtil.java:131)
> [java] at
> org.ofbiz.webapp.WebAppUtil.getControlServletPath(WebAppUtil.java:67)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(Method.java:498)
> [java] at
> freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1458)
> [java] at
> freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:71)
> [java] at freemarker.core.MethodCall._eval(MethodCall.java:62)
> [java] at freemarker.core.Expression.eval(Expression.java:78)
> [java] at freemarker.core.Assignment.accept(Assignment.java:70)
> [java] at freemarker.core.Environment.visit(Environment.java:312)
> [java] at freemarker.core.MixedContent.accept(MixedContent.java:62)
> [java] at
> freemarker.core.Environment.visitByHiddingParent(Environment.java:333)
> [java] at
> freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:148)
> [java] at
> freemarker.core.Environment.visitIteratorBlock(Environment.java:559)
> [java] at freemarker.core.IteratorBlock.accept(IteratorBlock.java:67)
> [java] at freemarker.core.Environment.visit(Environment.java:312)
> [java] at freemarker.co
[jira] [Created] (OFBIZ-6993) Cannot find the declaration of element 'web-app' in version 3.0 files.
Forrest Rae created OFBIZ-6993:
--
Summary: Cannot find the declaration of element 'web-app' in
version 3.0 files.
Key: OFBIZ-6993
URL: https://issues.apache.org/jira/browse/OFBIZ-6993
Project: OFBiz
Issue Type: Bug
Components: ALL COMPONENTS
Affects Versions: Release Branch 15.12, Trunk
Environment: Been seeing the error below in the logs. Strangely, I've
not been able to catch the exception in a debugger, but was able to isolate it
to the definition of the web-app with version 3.0. The error disapears when
you change the definition from
{code:xml}
{code}
to this:
{code:xml}
http://java.sun.com/xml/ns/javaee";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd";>
{code}
I only tested on 15.12 and Trunk, but it probably affects any release running
Tomcat 7.0.48 or higher. Here is the error:
{noformat}
[java] Apr 07, 2016 4:06:29 PM org.apache.tomcat.util.digester.Digester
error
[java] SEVERE: Parse Error at line 22 column 24: cvc-elt.1.a: Cannot find
the declaration of element 'web-app'.
[java] org.xml.sax.SAXParseException; lineNumber: 22; columnNumber: 24;
cvc-elt.1.a: Cannot find the declaration of element 'web-app'.
[java] at
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
Source)
[java] at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
Source)
[java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
Source)
[java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
Source)
[java] at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
Source)
[java] at
org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown Source)
[java] at
org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
[java] at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElementAfterName(Unknown
Source)
[java] at
org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
Source)
[java] at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
[java] at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
[java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
Source)
[java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
Source)
[java] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
[java] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
Source)
[java] at
org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
[java] at
org.apache.tomcat.util.digester.Digester.parse(Digester.java:1555)
[java] at
org.ofbiz.webapp.WebAppUtil.parseWebXmlFile(WebAppUtil.java:160)
[java] at org.ofbiz.webapp.WebAppUtil.getWebXml(WebAppUtil.java:131)
[java] at
org.ofbiz.webapp.WebAppUtil.getControlServletPath(WebAppUtil.java:67)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[java] at java.lang.reflect.Method.invoke(Method.java:498)
[java] at
freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1458)
[java] at
freemarker.ext.beans.SimpleMethodModel.exec(SimpleMethodModel.java:71)
[java] at freemarker.core.MethodCall._eval(MethodCall.java:62)
[java] at freemarker.core.Expression.eval(Expression.java:78)
[java] at freemarker.core.Assignment.accept(Assignment.java:70)
[java] at freemarker.core.Environment.visit(Environment.java:312)
[java] at freemarker.core.MixedContent.accept(MixedContent.java:62)
[java] at
freemarker.core.Environment.visitByHiddingParent(Environment.java:333)
[java] at
freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:148)
[java] at
freemarker.core.Environment.visitIteratorBlock(Environment.java:559)
[java] at freemarker.core.IteratorBlock.accept(IteratorBlock.java:67)
[java] at freemarker.core.Environment.visit(Environment.java:312)
[java] at freemarker.core.MixedContent.accept(MixedContent.java:62)
[java] at
freemarker.core.Environment.visitByHiddingParent(Environment.java:333)
[java] at
freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:48)
[java] at freemarker.core.Environment.visit(Environment.java:312)
[java] at freemarker.core.Mix
[jira] [Commented] (OFBIZ-6218) Unit tests throw exception in DBCP
[ https://issues.apache.org/jira/browse/OFBIZ-6218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15183234#comment-15183234 ] Forrest Rae commented on OFBIZ-6218: It's very likely that these strange errors are related to groovy scripts throwing exceptions that don't have error messages. One strong possibility is java.util.ConcurrentModificationException. I ran into this issue and ended up tracking it down to the lack of exception reporting in the GroovyScriptEngine: OFBIZ-6888. > Unit tests throw exception in DBCP > -- > > Key: OFBIZ-6218 > URL: https://issues.apache.org/jira/browse/OFBIZ-6218 > Project: OFBiz > Issue Type: Bug >Reporter: Adrian Crum > Attachments: OFBIZ-6218.patch > > > Details in comments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6918) ApplicationDecorator Entity-One Screen Action Incomplete Primary Key
[ https://issues.apache.org/jira/browse/OFBIZ-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6918: --- Attachment: OFBIZ-6918.patch > ApplicationDecorator Entity-One Screen Action Incomplete Primary Key > > > Key: OFBIZ-6918 > URL: https://issues.apache.org/jira/browse/OFBIZ-6918 > Project: OFBiz > Issue Type: Bug > Components: ALL APPLICATIONS >Affects Versions: Trunk, Release Branch 15.12 >Reporter: Forrest Rae > Attachments: OFBIZ-6918.patch > > > ApplicationDecorator entity-one screen action supplies an incomplete primary > key. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6918) ApplicationDecorator Entity-One Screen Action Incomplete Primary Key
Forrest Rae created OFBIZ-6918: -- Summary: ApplicationDecorator Entity-One Screen Action Incomplete Primary Key Key: OFBIZ-6918 URL: https://issues.apache.org/jira/browse/OFBIZ-6918 Project: OFBiz Issue Type: Bug Components: ALL APPLICATIONS Affects Versions: Release Branch 15.12, Trunk Reporter: Forrest Rae ApplicationDecorator entity-one screen action supplies an incomplete primary key. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6888) GroovyEngine.serviceInvoker masks Groovy script exceptions in some cases
[ https://issues.apache.org/jira/browse/OFBIZ-6888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6888: --- Attachment: OFBIZ-6888.patch Patch to fix issue. > GroovyEngine.serviceInvoker masks Groovy script exceptions in some cases > > > Key: OFBIZ-6888 > URL: https://issues.apache.org/jira/browse/OFBIZ-6888 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Release Branch 13.07, Release Branch 14.12, Trunk, > Release Branch 15.12 >Reporter: Forrest Rae > Labels: errorhandling > Attachments: OFBIZ-6888.patch > > > If GroovyEngine.serviceInvoker catches an exception in a Groovy script, it > would mask the exception in some cases. An exception's detailMessage can be > null. If it is null, the exception won't be properly returned and logged, > and that will make spotting problems very difficult. This was the case for > me while trying to track down a problem with a > java.util.ConcurrentModificationException error in a Groovy script. I > suspect that this choice to mask exceptions and only return the message has > cause bugs to not be spotted. > Disabling this for now in favor of returning a proper exception. > GroovyEngine.serviceInvoker() should throw GenericServiceException if error, > rather than returning ServiceUtil.returnError(e.getMessage()) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6888) GroovyEngine.serviceInvoker masks Groovy script exceptions in some cases
Forrest Rae created OFBIZ-6888: -- Summary: GroovyEngine.serviceInvoker masks Groovy script exceptions in some cases Key: OFBIZ-6888 URL: https://issues.apache.org/jira/browse/OFBIZ-6888 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 15.12, Trunk, Release Branch 14.12, Release Branch 13.07 Reporter: Forrest Rae If GroovyEngine.serviceInvoker catches an exception in a Groovy script, it would mask the exception in some cases. An exception's detailMessage can be null. If it is null, the exception won't be properly returned and logged, and that will make spotting problems very difficult. This was the case for me while trying to track down a problem with a java.util.ConcurrentModificationException error in a Groovy script. I suspect that this choice to mask exceptions and only return the message has cause bugs to not be spotted. Disabling this for now in favor of returning a proper exception. GroovyEngine.serviceInvoker() should throw GenericServiceException if error, rather than returning ServiceUtil.returnError(e.getMessage()) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6766) Secure HTTP headers
[ https://issues.apache.org/jira/browse/OFBIZ-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058368#comment-15058368 ] Forrest Rae commented on OFBIZ-6766: Jacques, In the spirit of secure by default I'd like to throw my vote in for HttpHeaderSecurityFilter being enabled by default moving forward. hstsEnabled is an absolute must, do this over the other two. A work around if you leverage the mod_ajpproxy setup of Apache server in front of Tomcat, there is a really awesome Apache config found in the Better Crypto Guide that enables HSTS here: https://bettercrypto.org blockContentTypeSniffingEnabled would really help in situations where file uploads are replayed back to another user's web browser to prevent arbitrary HTML and JavaScript being executed in the SAMEORIGIN. More info: http://security.stackexchange.com/questions/12896/does-x-content-type-options-really-prevent-content-sniffing-attacks Clickjacking can be more severe than you think, and any counter measures you can provide would be great for users. > Secure HTTP headers > --- > > Key: OFBIZ-6766 > URL: https://issues.apache.org/jira/browse/OFBIZ-6766 > Project: OFBiz > Issue Type: Sub-task > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux > Fix For: Upcoming Branch > > > I have created a wiki page for this > https://cwiki.apache.org/confluence/display/OFBIZ/How+to+Secure+HTTP+Headers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6766) Secure HTTP headers
[ https://issues.apache.org/jira/browse/OFBIZ-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058394#comment-15058394 ] Forrest Rae commented on OFBIZ-6766: Two useful sites besides CheckYourHeaders: https://securityheaders.io/ https://report-uri.io/ > Secure HTTP headers > --- > > Key: OFBIZ-6766 > URL: https://issues.apache.org/jira/browse/OFBIZ-6766 > Project: OFBiz > Issue Type: Sub-task > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux > Fix For: Upcoming Branch > > > I have created a wiki page for this > https://cwiki.apache.org/confluence/display/OFBIZ/How+to+Secure+HTTP+Headers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6766) Secure HTTP headers
[ https://issues.apache.org/jira/browse/OFBIZ-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058472#comment-15058472 ] Forrest Rae commented on OFBIZ-6766: Jacques, apologies for the questions if they weren't applicable, I didn't have any background info. I thought you were suggesting not enabling protections, but I see you're accomplishing it in another manner. Can you link me to RequestHandler? I've not seen any info on it. > Secure HTTP headers > --- > > Key: OFBIZ-6766 > URL: https://issues.apache.org/jira/browse/OFBIZ-6766 > Project: OFBiz > Issue Type: Sub-task > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux > Fix For: Upcoming Branch > > > I have created a wiki page for this > https://cwiki.apache.org/confluence/display/OFBIZ/How+to+Secure+HTTP+Headers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6766) Secure HTTP headers
[ https://issues.apache.org/jira/browse/OFBIZ-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058376#comment-15058376 ] Forrest Rae commented on OFBIZ-6766: One more thing, are any of these going to be backported? > Secure HTTP headers > --- > > Key: OFBIZ-6766 > URL: https://issues.apache.org/jira/browse/OFBIZ-6766 > Project: OFBiz > Issue Type: Sub-task > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux > Fix For: Upcoming Branch > > > I have created a wiki page for this > https://cwiki.apache.org/confluence/display/OFBIZ/How+to+Secure+HTTP+Headers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6766) Secure HTTP headers
[ https://issues.apache.org/jira/browse/OFBIZ-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058373#comment-15058373 ] Forrest Rae commented on OFBIZ-6766: Also, definitely enable support for CORS, there is a great write-up here: https://scotthelme.co.uk/content-security-policy-an-introduction/ > Secure HTTP headers > --- > > Key: OFBIZ-6766 > URL: https://issues.apache.org/jira/browse/OFBIZ-6766 > Project: OFBiz > Issue Type: Sub-task > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux > Fix For: Upcoming Branch > > > I have created a wiki page for this > https://cwiki.apache.org/confluence/display/OFBIZ/How+to+Secure+HTTP+Headers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6770) createCustRequestContent Hasn't worked in 6 years and 7 months
[ https://issues.apache.org/jira/browse/OFBIZ-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6770: --- Description: This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] disabled the mimeTypeId argument in applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide "various fixes". I wonder how many people have been frustrated by this when looking for example code on how to upload documents. The issue is that mimeTypeId field that was commented out from [applications/order/widget/ordermgr/CustRequestForms.xml|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/widget/ordermgr/CustRequestForms.xml?r=1686674#to608], is a required parameter by [createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23]. Lines 52-54 check it's value for the following: Line [52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]: if-compare is "Does the web browser's choice of mimeTypeId equal what the user thinks the mimeTypeId is?" Line [53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]: if-compare is "Did the user select anything at all in the mimeTypeId dropdown?" (Before the mimeTypeId field was commented out.) Line [54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]: if-compare is "Did the user submit mimeTypeId form field, but remove the value, submitting a blank form field?" This is the weird case, as really this should be a is-null check. My question is why are we even doing any of this when the event just goes on to set the mimeType to what the web browser decided it was, and then to call createContentFromUploadedFile service? Also, if mimeTypeId is in fact empty, the call to createContentFromUploadedFile calls createDataResource, which at applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway. Why not just let tika handle the mimeType? Anyway, I dunno enough about the Content component to make the decision here. I've attached three different patches. Reproduce: # Grab a sample PDF file from [here|http://www.indire.it/wp-content/uploads/2015/08/pdf-sample.pdf] # Visit http://demo-stable-ofbiz.apache.org/ordermgr/control/createCustRequestContent?custRequestId=9000 # Select the PDF file to upload, leave all other fields default # Click Create # Notice the error message: Upload file type not match your selected. was: This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] disabled the mimeTypeId argument in applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide "various fixes". I wonder how many people have been frustrated by this when looking for example code on how to upload documents. The issue is that mimeTypeId field that was commented out from [applications/order/widget/ordermgr/CustRequestForms.xml|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/widget/ordermgr/CustRequestForms.xml?r=1686674#to608], is a required parameter by [createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23]. Lines 52-54 check it's value for the following: Line [52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]: if-compare is "Does the web browser's choice of mimeTypeId equal what the user thinks the mimeTypeId is?" Line [53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]: if-compare is "Did the user select anything at all in the mimeTypeId dropdown?" (Before the mimeTypeId field was commented out.) Line [54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]: if-compare is "Did the user submit mimeTypeId form field, but remove the value, submitting a blank form field?" This is the weird case, as really this should be a is-null check. My question is why are we even doing any of this when the event just goes on to set the mimeType to what the web browser decided it was, and then to call createContentFromUploadedFile service? Also, if mimeTypeId is in fact empty, the call to createContentFromUploadedFile calls createDataResource, which at applications/con
[jira] [Commented] (OFBIZ-6770) createCustRequestContent Hasn't worked in 6 years and 7 months
[ https://issues.apache.org/jira/browse/OFBIZ-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058319#comment-15058319 ] Forrest Rae commented on OFBIZ-6770: Sorry, I didn't mean to leave out important details, and sorry for all the emails to the Dev mailing list while trying to correct the description. You click anywhere outside of the description and it saves. > createCustRequestContent Hasn't worked in 6 years and 7 months > -- > > Key: OFBIZ-6770 > URL: https://issues.apache.org/jira/browse/OFBIZ-6770 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Release Branch 11.04, Release Branch 12.04, Release > Branch 13.07, Release Branch 14.12, Trunk >Reporter: Forrest Rae > Attachments: OFBIZ-6770-option1.patch, OFBIZ-6770-option2.patch, > OFBIZ-6770-option3.patch > > > This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] > disabled the mimeTypeId argument in > applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide > "various fixes". I wonder how many people have been frustrated by this when > looking for example code on how to upload documents. > The issue is that mimeTypeId field that was commented out from > [applications/order/widget/ordermgr/CustRequestForms.xml|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/widget/ordermgr/CustRequestForms.xml?r=1686674#to608], > is a required parameter by > [createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23]. > Lines 52-54 check it's value for the following: > Line > [52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]: > if-compare is "Does the web browser's choice of mimeTypeId equal what the > user thinks the mimeTypeId is?" > Line > [53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]: > if-compare is "Did the user select anything at all in the mimeTypeId > dropdown?" (Before the mimeTypeId field was commented out.) > Line > [54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]: > if-compare is "Did the user submit mimeTypeId form field, but remove the > value, submitting a blank form field?" This is the weird case, as really > this should be a is-null check. > My question is why are we even doing any of this when the event just goes on > to set the mimeType to what the web browser decided it was, and then to call > createContentFromUploadedFile service? Also, if mimeTypeId is in fact empty, > the call to createContentFromUploadedFile calls createDataResource, which at > applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls > org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway. Why not > just let tika handle the mimeType? > Anyway, I dunno enough about the Content component to make the decision here. > I've attached three different patches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6770) createCustRequestContent Hasn't worked in 6 years and 7 months
[ https://issues.apache.org/jira/browse/OFBIZ-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6770: --- Description: This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] disabled the mimeTypeId argument in applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide "various fixes". I wonder how many people have been frustrated by this when looking for example code on how to upload documents. The issue is that mimeTypeId field that was commented out, is a required parameter by [createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23]. Lines 52-54 check it's value for the following: Line [52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]: if-compare is "Does the web browser's choice of mimeTypeId equal what the user thinks the mimeTypeId is?" Line [53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]: if-compare is "Did the user select anything at all in the mimeTypeId dropdown?" (Before the mimeTypeId field was commented out.) Line [54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]: if-compare is "Did the user submit mimeTypeId form field, but remove the value, submitting a blank form field?" This is the weird case, as really this should be a is-null check. My question is why are we even doing any of this when the event just goes on to set the mimeType to what the web browser decided it was, and then to call createContentFromUploadedFile service? Also, if mimeTypeId is in fact empty, the call to createContentFromUploadedFile calls createDataResource, which at applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway. Why not just let tika handle the mimeType? Anyway, I dunno enough about the Content component to make the decision here. I've attached three different patches. was: This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] disabled the mimeTypeId argument in applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide "various fixes". I wonder how many people have been frustrated by this when looking for example code on how to upload documents. The issue is that mimeTypeId field that was commented out, is a required parameter by [createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23]. Lines 52-54 check it's value for the following: Line [52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]: if-compare is "Does the web browser's choice of mimeTypeId equal what the user thinks the mimeTypeId is?" Line [53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]: if-compare is "Did the user select anything at all in the mimeTypeId dropdown?" (Before the mimeTypeId field was commented out.) Line [54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]: if-compare is "Did the user submit mimeTypeId form field, but remove the value, submitting a blank form field?" This is the weird case, as really this should be a is-null check. The issue lies in the seemly arbitrary check of the mimeTypeId parameter in applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml, lines 52-54. My question is why are we even doing any of this when the event just goes on to set the mimeType to what the web browser decided it was, and then to call createContentFromUploadedFile service? Also, if mimeTypeId is in fact empty, the call to createContentFromUploadedFile calls createDataResource, which at applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway. Why not just let tika handle the mimeType? Anyway, I dunno enough about the Content component to make the decision here. I've attached three different patches. > createCustRequestContent Hasn't worked in 6 years and 7 months > -- > > Key: OFBIZ-6770 > URL: https://issues.apache.org/jira/browse/OFBIZ-6770 > Project: OFBiz > Issue Type: Bug >
[jira] [Updated] (OFBIZ-6770) createCustRequestContent Hasn't worked in 6 years and 7 months
[ https://issues.apache.org/jira/browse/OFBIZ-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6770: --- Description: This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] disabled the mimeTypeId argument in applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide "various fixes". I wonder how many people have been frustrated by this when looking for example code on how to upload documents. The issue is that mimeTypeId field that was commented out from [applications/order/widget/ordermgr/CustRequestForms.xml|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/widget/ordermgr/CustRequestForms.xml?r=1686674#to608], is a required parameter by [createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23]. Lines 52-54 check it's value for the following: Line [52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]: if-compare is "Does the web browser's choice of mimeTypeId equal what the user thinks the mimeTypeId is?" Line [53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]: if-compare is "Did the user select anything at all in the mimeTypeId dropdown?" (Before the mimeTypeId field was commented out.) Line [54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]: if-compare is "Did the user submit mimeTypeId form field, but remove the value, submitting a blank form field?" This is the weird case, as really this should be a is-null check. My question is why are we even doing any of this when the event just goes on to set the mimeType to what the web browser decided it was, and then to call createContentFromUploadedFile service? Also, if mimeTypeId is in fact empty, the call to createContentFromUploadedFile calls createDataResource, which at applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway. Why not just let tika handle the mimeType? Anyway, I dunno enough about the Content component to make the decision here. I've attached three different patches. was: This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] disabled the mimeTypeId argument in applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide "various fixes". I wonder how many people have been frustrated by this when looking for example code on how to upload documents. The issue is that mimeTypeId field that was commented out, is a required parameter by [createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23]. Lines 52-54 check it's value for the following: Line [52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]: if-compare is "Does the web browser's choice of mimeTypeId equal what the user thinks the mimeTypeId is?" Line [53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]: if-compare is "Did the user select anything at all in the mimeTypeId dropdown?" (Before the mimeTypeId field was commented out.) Line [54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]: if-compare is "Did the user submit mimeTypeId form field, but remove the value, submitting a blank form field?" This is the weird case, as really this should be a is-null check. My question is why are we even doing any of this when the event just goes on to set the mimeType to what the web browser decided it was, and then to call createContentFromUploadedFile service? Also, if mimeTypeId is in fact empty, the call to createContentFromUploadedFile calls createDataResource, which at applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway. Why not just let tika handle the mimeType? Anyway, I dunno enough about the Content component to make the decision here. I've attached three different patches. > createCustRequestContent Hasn't worked in 6 years and 7 months > -- > > Key: OFBIZ-6770 > URL: https://issues.apache.org/jira/browse/OFBIZ-6770 > Project: OFBi
[jira] [Commented] (OFBIZ-6770) createCustRequestContent Hasn't worked in 6 years and 7 months
[ https://issues.apache.org/jira/browse/OFBIZ-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058335#comment-15058335 ] Forrest Rae commented on OFBIZ-6770: Pierre, While it seems that in trunk createContentFromUploadedFile has been replaced by a more modular design, createCustRequestContent event seems to still be available in trunk. > createCustRequestContent Hasn't worked in 6 years and 7 months > -- > > Key: OFBIZ-6770 > URL: https://issues.apache.org/jira/browse/OFBIZ-6770 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Release Branch 11.04, Release Branch 12.04, Release > Branch 13.07, Release Branch 14.12, Trunk >Reporter: Forrest Rae > Attachments: OFBIZ-6770-option1.patch, OFBIZ-6770-option2.patch, > OFBIZ-6770-option3.patch > > > This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] > disabled the mimeTypeId argument in > applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide > "various fixes". I wonder how many people have been frustrated by this when > looking for example code on how to upload documents. > The issue is that mimeTypeId field that was commented out from > [applications/order/widget/ordermgr/CustRequestForms.xml|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/widget/ordermgr/CustRequestForms.xml?r=1686674#to608], > is a required parameter by > [createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23]. > Lines 52-54 check it's value for the following: > Line > [52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]: > if-compare is "Does the web browser's choice of mimeTypeId equal what the > user thinks the mimeTypeId is?" > Line > [53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]: > if-compare is "Did the user select anything at all in the mimeTypeId > dropdown?" (Before the mimeTypeId field was commented out.) > Line > [54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]: > if-compare is "Did the user submit mimeTypeId form field, but remove the > value, submitting a blank form field?" This is the weird case, as really > this should be a is-null check. > My question is why are we even doing any of this when the event just goes on > to set the mimeType to what the web browser decided it was, and then to call > createContentFromUploadedFile service? Also, if mimeTypeId is in fact empty, > the call to createContentFromUploadedFile calls createDataResource, which at > applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls > org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway. Why not > just let tika handle the mimeType? > Anyway, I dunno enough about the Content component to make the decision here. > I've attached three different patches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6770) createCustRequestContent Hasn't worked in 6 years and 7 months
[ https://issues.apache.org/jira/browse/OFBIZ-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6770: --- Description: This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] disabled the mimeTypeId argument in applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide "various fixes". I wonder how many people have been frustrated by this when looking for example code on how to upload documents. The issue is that mimeTypeId field that was commented out, is a required parameter by [createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23]. Lines 52-54 check it's value for the following: Line [52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]: if-compare is "Does the web browser's choice of mimeTypeId equal what the user thinks the mimeTypeId is?" Line [53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]: if-compare is "Did the user select anything at all in the mimeTypeId dropdown?" (Before the mimeTypeId field was commented out.) Line [54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]: if-compare is "Did the user submit mimeTypeId form field, but remove the value, submitting a blank form field?" This is the weird case, as really this should be a is-null check. The issue lies in the seemly arbitrary check of the mimeTypeId parameter in applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml, lines 52-54. My question is why are we even doing any of this when the event just goes on to set the mimeType to what the web browser decided it was, and then to call createContentFromUploadedFile service? Also, if mimeTypeId is in fact empty, the call to createContentFromUploadedFile calls createDataResource, which at applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway. Why not just let tika handle the mimeType? Anyway, I dunno enough about the Content component to make the decision here. I've attached three different patches. was: This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] disabled the mimeTypeId argument in applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide "various fixes". I wonder how many people have been frustrated by this when looking for example code on how to upload documents. The issue is that mimeTypeId field that was commented out, is a required parameter by [createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23]. Lines 52-54 check it's value for the following: Line [52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]: if-compare is "Does the web browser's choice of mimeTypeId equal what the user thinks the mimeTypeId is?" Line [53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]: if-compare is "Did the user select anything at all in the mimeTypeId dropdown?" (Before the mimeTypeId field was commented out.) Line [54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]: if-compare is "Did the user submit mimeTypeId form field, but remove the value, submitting a blank form field?" This is the weird case, as really this should be a if-null The issue lies in the seemly arbitrary check of the mimeTypeId parameter in applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml, lines 52-54. My question is why are we even doing any of this when the event just goes on to set the mimeType to what the web browser decided it was, and then to call createContentFromUploadedFile service? Also, if mimeTypeId is in fact empty, the call to createContentFromUploadedFile calls createDataResource, which at applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway. Why not just let tika handle the mimeType? Anyway, I dunno enough about the Content component to make the decision here. I've attached three different patches. > createCustRequestContent Hasn't worked in 6 years and 7 months > -- > >
[jira] [Updated] (OFBIZ-6770) createCustRequestContent Hasn't worked in 6 years and 7 months
[ https://issues.apache.org/jira/browse/OFBIZ-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6770: --- Description: This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] disabled the mimeTypeId argument in applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide "various fixes". I wonder how many people have been frustrated by this when looking for example code on how to upload documents. The issue is that mimeTypeId field that was commented out, is a required parameter by [createCustRequestContent|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to23]. Lines 52-54 check it's value for the following: Line [52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]: if-compare is "Does the web browser's choice of mimeTypeId equal what the user thinks the mimeTypeId is?" Line [53|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to53]: if-compare is "Did the user select anything at all in the mimeTypeId dropdown?" (Before the mimeTypeId field was commented out.) Line [54|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to54]: if-compare is "Did the user submit mimeTypeId form field, but remove the value, submitting a blank form field?" This is the weird case, as really this should be a if-null The issue lies in the seemly arbitrary check of the mimeTypeId parameter in applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml, lines 52-54. My question is why are we even doing any of this when the event just goes on to set the mimeType to what the web browser decided it was, and then to call createContentFromUploadedFile service? Also, if mimeTypeId is in fact empty, the call to createContentFromUploadedFile calls createDataResource, which at applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway. Why not just let tika handle the mimeType? Anyway, I dunno enough about the Content component to make the decision here. I've attached three different patches. was: This commit disabled the mimeTypeId argument in applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide "various fixes" https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661 I wonder how many people have been frustrated by this when looking for example code on how to upload documents. The issue is that mimeTypeId is required by createCustRequestContent. Lines [52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]-54 check it's value: This patch isn't really a fix, but more of a work around. The issue lies in the seemly arbitrary check of the mimeTypeId parameter in applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml, lines 52-54. First if-compare is "Does the web browser's choice of mimeTypeId equal what the user thinks the mimeTypeId is?" Second if-compare is "Did the user select anything at all in the mimeTypeId dropdown?" Third choice is "Did the user submit mimeTypeId form field, but remove the value, submitting a blank form field?" My question is why are we even doing any of this when the event just goes on to set the mimeType to what the web browser decided it was, and then to call createContentFromUploadedFile service? Also, if mimeTypeId is in fact empty, the call to createContentFromUploadedFile calls createDataResource, which at applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway. Why not just let tika handle the mimeType? Anyway, I dunno enough about the Content component to make the decision here. I've attached three different patches. > createCustRequestContent Hasn't worked in 6 years and 7 months > -- > > Key: OFBIZ-6770 > URL: https://issues.apache.org/jira/browse/OFBIZ-6770 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Release Branch 11.04, Release Branch 12.04, Release > Branch 13.07, Release Branch 14.12, Trunk >Reporter: Forrest Rae > Attachments: OFBIZ-6770-option1.patch, OFBIZ-6770-option2.patch, > OFBIZ-6770-option3.patch > > > This [commit|https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661] > disabled the mimeTypeId argument in > applications/order/wid
[jira] [Updated] (OFBIZ-6770) createCustRequestContent Hasn't worked in 6 years and 7 months
[ https://issues.apache.org/jira/browse/OFBIZ-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6770: --- Description: This commit disabled the mimeTypeId argument in applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide "various fixes" https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661 I wonder how many people have been frustrated by this when looking for example code on how to upload documents. The issue is that mimeTypeId is required by createCustRequestContent. Lines [52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]-54 check it's value: This patch isn't really a fix, but more of a work around. The issue lies in the seemly arbitrary check of the mimeTypeId parameter in applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml, lines 52-54. First if-compare is "Does the web browser's choice of mimeTypeId equal what the user thinks the mimeTypeId is?" Second if-compare is "Did the user select anything at all in the mimeTypeId dropdown?" Third choice is "Did the user submit mimeTypeId form field, but remove the value, submitting a blank form field?" My question is why are we even doing any of this when the event just goes on to set the mimeType to what the web browser decided it was, and then to call createContentFromUploadedFile service? Also, if mimeTypeId is in fact empty, the call to createContentFromUploadedFile calls createDataResource, which at applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway. Why not just let tika handle the mimeType? Anyway, I dunno enough about the Content component to make the decision here. I've attached three different patches. was: This commit disabled the mimeTypeId argument in applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide "various fixes" https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661 I wonder how many people have been frustrated by this when looking for example code on how to upload documents. This patch isn't really a fix, but more of a work around. The issue lies in the seemly arbitrary check of the mimeTypeId parameter in applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml, lines 52-54. First if-compare is "Does the web browser's choice of mimeTypeId equal what the user thinks the mimeTypeId is?" Second if-compare is "Did the user select anything at all in the mimeTypeId dropdown?" Third choice is "Did the user submit mimeTypeId form field, but remove the value, submitting a blank form field?" My question is why are we even doing any of this when the event just goes on to set the mimeType to what the web browser decided it was, and then to call createContentFromUploadedFile service? Also, if mimeTypeId is in fact empty, the call to createContentFromUploadedFile calls createDataResource, which at applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway. Why not just let tika handle the mimeType? Anyway, I dunno enough about the Content component to make the decision here. I've attached three different patches. > createCustRequestContent Hasn't worked in 6 years and 7 months > -- > > Key: OFBIZ-6770 > URL: https://issues.apache.org/jira/browse/OFBIZ-6770 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Release Branch 11.04, Release Branch 12.04, Release > Branch 13.07, Release Branch 14.12, Trunk >Reporter: Forrest Rae > Attachments: OFBIZ-6770-option1.patch, OFBIZ-6770-option2.patch, > OFBIZ-6770-option3.patch > > > This commit disabled the mimeTypeId argument in > applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide > "various fixes" > https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661 > I wonder how many people have been frustrated by this when looking for > example code on how to upload documents. > The issue is that mimeTypeId is required by createCustRequestContent. Lines > [52|https://fisheye6.atlassian.com/browse/~br=trunk/ofbiz/trunk/applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml?r=1328827#to52]-54 > check it's value: > This patch isn't really a fix, but more of a work around. The issue lies in > the seemly arbitrary check of the mimeTypeId parameter in > applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml, > lines 52-54. > First if-compare is "Does the web browser's choice of mimeTypeId equal what > the user thinks the mimeTypeId is?" > Second if-compare is "Did the user sel
[jira] [Updated] (OFBIZ-6770) createCustRequestContent Hasn't worked in 6 years and 7 months
[ https://issues.apache.org/jira/browse/OFBIZ-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6770: --- Attachment: OFBIZ-6770-option3.patch OFBIZ-6770-option2.patch OFBIZ-6770-option1.patch > createCustRequestContent Hasn't worked in 6 years and 7 months > -- > > Key: OFBIZ-6770 > URL: https://issues.apache.org/jira/browse/OFBIZ-6770 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Release Branch 11.04, Release Branch 12.04, Release > Branch 13.07, Release Branch 14.12, Trunk >Reporter: Forrest Rae > Attachments: OFBIZ-6770-option1.patch, OFBIZ-6770-option2.patch, > OFBIZ-6770-option3.patch > > > This commit disabled the mimeTypeId argument in > applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide > "various fixes" > https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661 > I wonder how many people have been frustrated by this when looking for > example code on how to upload documents. > This patch isn't really a fix, but more of a work around. The issue lies in > the seemly arbitrary check of the mimeTypeId parameter in > applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml, > lines 52-54. > First if-compare is "Does the web browser's choice of mimeTypeId equal what > the user thinks the mimeTypeId is?" > Second if-compare is "Did the user select anything at all in the mimeTypeId > dropdown?" > Third choice is "Did the user submit mimeTypeId form field, but remove the > value, submitting a blank form field?" > My question is why are we even doing any of this when the event just goes on > to set the mimeType to what the web browser decided it was, and then to call > createContentFromUploadedFile service? Also, if mimeTypeId is in fact empty, > the call to createContentFromUploadedFile calls createDataResource, which at > applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls > org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway. Why not > just let tika handle the mimeType? > Anyway, I dunno enough about the Content component to make the decision here. > I've attached three different patches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6770) createCustRequestContent Hasn't worked in 6 years and 7 months
Forrest Rae created OFBIZ-6770: -- Summary: createCustRequestContent Hasn't worked in 6 years and 7 months Key: OFBIZ-6770 URL: https://issues.apache.org/jira/browse/OFBIZ-6770 Project: OFBiz Issue Type: Bug Components: order Affects Versions: Trunk, Release Branch 14.12, Release Branch 13.07, Release Branch 12.04, Release Branch 11.04 Reporter: Forrest Rae This commit disabled the mimeTypeId argument in applications/order/widget/ordermgr/CustRequestForms.xml, in order to provide "various fixes" https://fisheye6.atlassian.com/changelog/ofbiz?cs=768661 I wonder how many people have been frustrated by this when looking for example code on how to upload documents. This patch isn't really a fix, but more of a work around. The issue lies in the seemly arbitrary check of the mimeTypeId parameter in applications/order/script/org/ofbiz/order/request/CustRequestEvents.xml, lines 52-54. First if-compare is "Does the web browser's choice of mimeTypeId equal what the user thinks the mimeTypeId is?" Second if-compare is "Did the user select anything at all in the mimeTypeId dropdown?" Third choice is "Did the user submit mimeTypeId form field, but remove the value, submitting a blank form field?" My question is why are we even doing any of this when the event just goes on to set the mimeType to what the web browser decided it was, and then to call createContentFromUploadedFile service? Also, if mimeTypeId is in fact empty, the call to createContentFromUploadedFile calls createDataResource, which at applications/content/script/org/ofbiz/content/data/DataServices.xml:53 calls org.apache.tika.Tika#detect(byte[]) to detect the mimeType anyway. Why not just let tika handle the mimeType? Anyway, I dunno enough about the Content component to make the decision here. I've attached three different patches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-610) Remove all instances of 'required-permissions' usage in service definition files.
[
https://issues.apache.org/jira/browse/OFBIZ-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051460#comment-15051460
]
Forrest Rae edited comment on OFBIZ-610 at 12/10/15 6:56 PM:
-
I know this is quite old, but did you ever consider a case where you'd need to
do:
{code:xml}
{code}
I just spent weeks implementing something like this, and then stumbled across
this, showing that is deprecated.
was (Author: f...@14x.net):
I know this is quite old, but did you ever consider a case where you'd need to
do:
{code|borderStyle=solid}
{code}
I just spent weeks implementing something like this, and then stumbled across
this, showing that is deprecated.
> Remove all instances of 'required-permissions' usage in service definition
> files.
> -
>
> Key: OFBIZ-610
> URL: https://issues.apache.org/jira/browse/OFBIZ-610
> Project: OFBiz
> Issue Type: Sub-task
> Components: framework, order, product
>Reporter: Andrew Zeneski
>Assignee: Andrew Zeneski
> Fix For: Trunk
>
>
> There are currently 61 instances of service definitions which use the now
> deprecated tag. These definitions should all be
> updated and new permissions services implemented (as needed) to use the new
> tag.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-610) Remove all instances of 'required-permissions' usage in service definition files.
[
https://issues.apache.org/jira/browse/OFBIZ-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051460#comment-15051460
]
Forrest Rae commented on OFBIZ-610:
---
I know this is quite old, but did you ever consider a case where you'd need to
do:
{code|borderStyle=solid}
{code}
I just spent weeks implementing something like this, and then stumbled across
this, showing that is deprecated.
> Remove all instances of 'required-permissions' usage in service definition
> files.
> -
>
> Key: OFBIZ-610
> URL: https://issues.apache.org/jira/browse/OFBIZ-610
> Project: OFBiz
> Issue Type: Sub-task
> Components: framework, order, product
>Reporter: Andrew Zeneski
>Assignee: Andrew Zeneski
> Fix For: Trunk
>
>
> There are currently 61 instances of service definitions which use the now
> deprecated tag. These definitions should all be
> updated and new permissions services implemented (as needed) to use the new
> tag.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6721) org.ofbiz.common.login.LoginServices.userLogin causes stack track when username or password is incorrect
[ https://issues.apache.org/jira/browse/OFBIZ-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15005621#comment-15005621 ] Forrest Rae commented on OFBIZ-6721: Thanks Jacques, I'll take some time in the next month or so to improve the password checking code a bit in trunk, and put in support for PBKDF2 with rolling password hash upgrades for posix style password storage. > org.ofbiz.common.login.LoginServices.userLogin causes stack track when > username or password is incorrect > > > Key: OFBIZ-6721 > URL: https://issues.apache.org/jira/browse/OFBIZ-6721 > Project: OFBiz > Issue Type: Improvement > Components: commonext/setup >Affects Versions: Release Branch 11.04, Release Branch 12.04, Release > Branch 13.07, Release Branch 14.12, Trunk >Reporter: Forrest Rae >Assignee: Jacques Le Roux >Priority: Trivial > Labels: log, test-failure > Fix For: 14.12.01, 12.04.06, 13.07.03, Upcoming Branch > > Attachments: OFBIZ-6721.patch > > > org.ofbiz.common.login.LoginServices.userLogin is returning ERROR when a > username or password is incorrect. It should return FAILURE instead of > error. The error causes stack track to be printed to the log. The stack > trace makes watching the log for actual errors difficult. This is especially > hard when running and analyzing the log after a full test run, of in my case, > a custom set of test cases. > Stack trace: > [java] 2015-11-12 16:35:00,412 |ajp-bio-8009-exec-7 |LoginWorker > |I| Setting default delegator > [java] 2015-11-12 16:35:00,413 |ajp-bio-8009-exec-7 |LoginServices > |I| [LoginServices.userLogin] : Password Incorrect > [java] 2015-11-12 16:35:00,420 |ajp-bio-8009-exec-7 |ServiceDispatcher > |E| Error in Service [userLogin]: Password incorrect. > [java] 2015-11-12 16:35:00,420 |ajp-bio-8009-exec-7 |TransactionUtil > |E| [TransactionUtil.rollback] > [java] java.lang.Exception: Stack Trace > [java]at > org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:322) > [ofbiz-entity.jar:?] > [java]at > org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:299) > [ofbiz-entity.jar:?] > [java]at > org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:534) > [ofbiz-service.jar:?] > [java]at > org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:227) > [ofbiz-service.jar:?] > [java]at > org.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:88) > [ofbiz-service.jar:?] > [java]at > org.ofbiz.webapp.control.LoginWorker.login(LoginWorker.java:488) > [ofbiz-webapp.jar:?] > [java]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > ~[?:1.8.0_60] > [java]at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ~[?:1.8.0_60] > [java]at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ~[?:1.8.0_60] > [java]at java.lang.reflect.Method.invoke(Method.java:497) > ~[?:1.8.0_60] > [java]at > org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java:92) > [ofbiz-webapp.jar:?] > [java]at > org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java:78) > [ofbiz-webapp.jar:?] > [java]at > org.ofbiz.webapp.control.RequestHandler.runEvent(RequestHandler.java:759) > [ofbiz-webapp.jar:?] > [java]at > org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:476) > [ofbiz-webapp.jar:?] > [java]at > org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:213) > [ofbiz-webapp.jar:?] > [java]at > org.ofbiz.webapp.control.ControlServlet.doPost(ControlServlet.java:88) > [ofbiz-webapp.jar:?] > [java]at javax.servlet.http.HttpServlet.service(HttpServlet.java:646) > [servlet-api-3.0.jar:?] > [java]at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) > [servlet-api-3.0.jar:?] > [java]at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) > [tomcat-7.0.64-catalina.jar:7.0.64] > [java]at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > [tomcat-7.0.64-catalina.jar:7.0.64] > [java]at > org.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:323) > [ofbiz-webapp.jar:?] > [java]at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) > [tomcat-7.0.64-catalina.jar:7.0.64] > [java]at > org.apache.cat
[jira] [Comment Edited] (OFBIZ-6721) org.ofbiz.common.login.LoginServices.userLogin causes stack track when username or password is incorrect
[ https://issues.apache.org/jira/browse/OFBIZ-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15004547#comment-15004547 ] Forrest Rae edited comment on OFBIZ-6721 at 11/13/15 7:23 PM: -- I believe it is a bug. You have to consider how this is being used by people extending the framework. The difference between ERROR and FAILURE when it comes to authentication, especially when you need to rely on ignore-failure="false" ignore-error="false", is a blocker for me. I have a SECA on userLogin service, and I need to know if there was an ERROR, or there was a FAILURE. This prevents my ability to augment the authentication process. In my use case, I need to make sure OOTB authentication passes, and then I need to check the status of a series of relationships, and then I save some data to some custom entities. Here is my SECA: I considered building an external org.ofbiz.common.authentication.api.Authenticator, but the main issue is the external auth runs first, before the password check. This creates an opportunity to brute force usernames based on time inference, if the code has to do several operations before ever checking if the authentication details are correct, not to mention invalid data to custom entities. A SECA is more advantageous here. Perhaps the bug title and original description probably should have contained this info, but I'm trying not to disclose too much information. was (Author: f...@14x.net): I believe it is a bug. You have to consider how this is being used by people extending the framework. The difference between ERROR and FAILURE when it comes to authentication, especially when you need to rely on ignore-failure="false" ignore-error="false", is a blocker for me. I have a SECA on userLogin service, and I need to know if there was an ERROR, or there was a FAILURE. This prevents my ability to augment the authentication process. In my use case, I need to make sure OOTB authentication passes, and then I need to check the status of a series of relationships, and then I save some data to some custom entities. Here is my SECA: I considered building an external org.ofbiz.common.authentication.api.Authenticator, but the main issue is the external auth runs first, before the password check. This creates an opportunity to brute force usernames based on time inference, if the code has to do several operations before ever checking if the authentication details are correct, not to mention invalid data to custom entities. A SECA is more advantageous here. > org.ofbiz.common.login.LoginServices.userLogin causes stack track when > username or password is incorrect > > > Key: OFBIZ-6721 > URL: https://issues.apache.org/jira/browse/OFBIZ-6721 > Project: OFBiz > Issue Type: Improvement > Components: commonext/setup >Affects Versions: Release Branch 11.04, Release Branch 12.04, Release > Branch 13.07, Release Branch 14.12, Trunk >Reporter: Forrest Rae >Assignee: Jacques Le Roux >Priority: Trivial > Labels: log, test-failure > Fix For: Upcoming Branch > > Attachments: OFBIZ-6721.patch > > > org.ofbiz.common.login.LoginServices.userLogin is returning ERROR when a > username or password is incorrect. It should return FAILURE instead of > error. The error causes stack track to be printed to the log. The stack > trace makes watching the log for actual errors difficult. This is especially > hard when running and analyzing the log after a full test run, of in my case, > a custom set of test cases. > Stack trace: > [java] 2015-11-12 16:35:00,412 |ajp-bio-8009-exec-7 |LoginWorker > |I| Setting default delegator > [java] 2015-11-12 16:35:00,413 |ajp-bio-8009-exec-7 |LoginServices > |I| [LoginServices.userLogin] : Password Incorrect > [java] 2015-11-12 16:35:00,420 |ajp-bio-8009-exec-7 |ServiceDispatcher > |E| Error in Service [userLogin]: Password incorrect. > [java] 2015-11-12 16:35:00,420 |ajp-bio-8009-exec-7 |TransactionUtil > |E| [TransactionUtil.rollback] > [java] java.lang.Exception: Stack Trace > [java]at > org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:322) > [ofbiz-entity.jar:?] > [java]at > org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:299) > [ofbiz-entity.jar:?] > [java]at > org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:534) > [ofbiz-service.jar:?] > [java]at > org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:227) > [ofbiz-service.jar:?] > [java]at > org.ofbiz.service
[jira] [Commented] (OFBIZ-6721) org.ofbiz.common.login.LoginServices.userLogin causes stack track when username or password is incorrect
[ https://issues.apache.org/jira/browse/OFBIZ-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15004547#comment-15004547 ] Forrest Rae commented on OFBIZ-6721: I believe it is a bug. You have to consider how this is being used by people extending the framework. The difference between ERROR and FAILURE when it comes to authentication, especially when you need to rely on ignore-failure="false" ignore-error="false", is a blocker for me. I have a SECA on userLogin service, and I need to know if there was an ERROR, or there was a FAILURE. This prevents my ability to augment the authentication process. In my use case, I need to make sure OOTB authentication passes, and then I need to check the status of a series of relationships, and then I save some data to some custom entities. Here is my SECA: I considered building an external org.ofbiz.common.authentication.api.Authenticator, but the main issue is the external auth runs first, before the password check. This creates an opportunity to brute force usernames based on time inference, if the code has to do several operations before ever checking if the authentication details are correct, not to mention invalid data to custom entities. A SECA is more advantageous here. > org.ofbiz.common.login.LoginServices.userLogin causes stack track when > username or password is incorrect > > > Key: OFBIZ-6721 > URL: https://issues.apache.org/jira/browse/OFBIZ-6721 > Project: OFBiz > Issue Type: Improvement > Components: commonext/setup >Affects Versions: Release Branch 11.04, Release Branch 12.04, Release > Branch 13.07, Release Branch 14.12, Trunk >Reporter: Forrest Rae >Assignee: Jacques Le Roux >Priority: Trivial > Labels: log, test-failure > Fix For: Upcoming Branch > > Attachments: OFBIZ-6721.patch > > > org.ofbiz.common.login.LoginServices.userLogin is returning ERROR when a > username or password is incorrect. It should return FAILURE instead of > error. The error causes stack track to be printed to the log. The stack > trace makes watching the log for actual errors difficult. This is especially > hard when running and analyzing the log after a full test run, of in my case, > a custom set of test cases. > Stack trace: > [java] 2015-11-12 16:35:00,412 |ajp-bio-8009-exec-7 |LoginWorker > |I| Setting default delegator > [java] 2015-11-12 16:35:00,413 |ajp-bio-8009-exec-7 |LoginServices > |I| [LoginServices.userLogin] : Password Incorrect > [java] 2015-11-12 16:35:00,420 |ajp-bio-8009-exec-7 |ServiceDispatcher > |E| Error in Service [userLogin]: Password incorrect. > [java] 2015-11-12 16:35:00,420 |ajp-bio-8009-exec-7 |TransactionUtil > |E| [TransactionUtil.rollback] > [java] java.lang.Exception: Stack Trace > [java]at > org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:322) > [ofbiz-entity.jar:?] > [java]at > org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:299) > [ofbiz-entity.jar:?] > [java]at > org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:534) > [ofbiz-service.jar:?] > [java]at > org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:227) > [ofbiz-service.jar:?] > [java]at > org.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:88) > [ofbiz-service.jar:?] > [java]at > org.ofbiz.webapp.control.LoginWorker.login(LoginWorker.java:488) > [ofbiz-webapp.jar:?] > [java]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > ~[?:1.8.0_60] > [java]at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ~[?:1.8.0_60] > [java]at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ~[?:1.8.0_60] > [java]at java.lang.reflect.Method.invoke(Method.java:497) > ~[?:1.8.0_60] > [java]at > org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java:92) > [ofbiz-webapp.jar:?] > [java]at > org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java:78) > [ofbiz-webapp.jar:?] > [java]at > org.ofbiz.webapp.control.RequestHandler.runEvent(RequestHandler.java:759) > [ofbiz-webapp.jar:?] > [java]at > org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:476) > [ofbiz-webapp.jar:?] > [java]at > org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:213) > [ofbiz-webapp.jar:?] > [java]at > org.ofbiz.webapp.control.ControlServlet.doPost(ControlServlet.java:88)
[jira] [Updated] (OFBIZ-6721) org.ofbiz.common.login.LoginServices.userLogin causes stack track when username or password is incorrect
[ https://issues.apache.org/jira/browse/OFBIZ-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6721: --- Attachment: OFBIZ-6721.patch One line patch. > org.ofbiz.common.login.LoginServices.userLogin causes stack track when > username or password is incorrect > > > Key: OFBIZ-6721 > URL: https://issues.apache.org/jira/browse/OFBIZ-6721 > Project: OFBiz > Issue Type: Bug > Components: commonext/setup >Affects Versions: Release Branch 11.04, Release Branch 12.04, Release > Branch 13.07, Release Branch 14.12, Trunk >Reporter: Forrest Rae > Labels: log, test-failure > Attachments: OFBIZ-6721.patch > > > org.ofbiz.common.login.LoginServices.userLogin is returning ERROR when a > username or password is incorrect. It should return FAILURE instead of > error. The error causes stack track to be printed to the log. The stack > trace makes watching the log for actual errors difficult. This is especially > hard when running and analyzing the log after a full test run, of in my case, > a custom set of test cases. > Stack trace: > [java] 2015-11-12 16:35:00,412 |ajp-bio-8009-exec-7 |LoginWorker > |I| Setting default delegator > [java] 2015-11-12 16:35:00,413 |ajp-bio-8009-exec-7 |LoginServices > |I| [LoginServices.userLogin] : Password Incorrect > [java] 2015-11-12 16:35:00,420 |ajp-bio-8009-exec-7 |ServiceDispatcher > |E| Error in Service [userLogin]: Password incorrect. > [java] 2015-11-12 16:35:00,420 |ajp-bio-8009-exec-7 |TransactionUtil > |E| [TransactionUtil.rollback] > [java] java.lang.Exception: Stack Trace > [java]at > org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:322) > [ofbiz-entity.jar:?] > [java]at > org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:299) > [ofbiz-entity.jar:?] > [java]at > org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:534) > [ofbiz-service.jar:?] > [java]at > org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:227) > [ofbiz-service.jar:?] > [java]at > org.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:88) > [ofbiz-service.jar:?] > [java]at > org.ofbiz.webapp.control.LoginWorker.login(LoginWorker.java:488) > [ofbiz-webapp.jar:?] > [java]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > ~[?:1.8.0_60] > [java]at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ~[?:1.8.0_60] > [java]at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ~[?:1.8.0_60] > [java]at java.lang.reflect.Method.invoke(Method.java:497) > ~[?:1.8.0_60] > [java]at > org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java:92) > [ofbiz-webapp.jar:?] > [java]at > org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java:78) > [ofbiz-webapp.jar:?] > [java]at > org.ofbiz.webapp.control.RequestHandler.runEvent(RequestHandler.java:759) > [ofbiz-webapp.jar:?] > [java]at > org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:476) > [ofbiz-webapp.jar:?] > [java]at > org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:213) > [ofbiz-webapp.jar:?] > [java]at > org.ofbiz.webapp.control.ControlServlet.doPost(ControlServlet.java:88) > [ofbiz-webapp.jar:?] > [java]at javax.servlet.http.HttpServlet.service(HttpServlet.java:646) > [servlet-api-3.0.jar:?] > [java]at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) > [servlet-api-3.0.jar:?] > [java]at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) > [tomcat-7.0.64-catalina.jar:7.0.64] > [java]at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > [tomcat-7.0.64-catalina.jar:7.0.64] > [java]at > org.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:323) > [ofbiz-webapp.jar:?] > [java]at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) > [tomcat-7.0.64-catalina.jar:7.0.64] > [java]at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) > [tomcat-7.0.64-catalina.jar:7.0.64] > [java]at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) > [tomcat-7.0.64-catalina.jar:7.0.64] > [java]at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) > [tom
[jira] [Created] (OFBIZ-6721) org.ofbiz.common.login.LoginServices.userLogin causes stack track when username or password is incorrect
Forrest Rae created OFBIZ-6721: -- Summary: org.ofbiz.common.login.LoginServices.userLogin causes stack track when username or password is incorrect Key: OFBIZ-6721 URL: https://issues.apache.org/jira/browse/OFBIZ-6721 Project: OFBiz Issue Type: Bug Components: commonext/setup Affects Versions: Trunk, Release Branch 14.12, Release Branch 13.07, Release Branch 12.04, Release Branch 11.04 Reporter: Forrest Rae org.ofbiz.common.login.LoginServices.userLogin is returning ERROR when a username or password is incorrect. It should return FAILURE instead of error. The error causes stack track to be printed to the log. The stack trace makes watching the log for actual errors difficult. This is especially hard when running and analyzing the log after a full test run, of in my case, a custom set of test cases. Stack trace: [java] 2015-11-12 16:35:00,412 |ajp-bio-8009-exec-7 |LoginWorker |I| Setting default delegator [java] 2015-11-12 16:35:00,413 |ajp-bio-8009-exec-7 |LoginServices |I| [LoginServices.userLogin] : Password Incorrect [java] 2015-11-12 16:35:00,420 |ajp-bio-8009-exec-7 |ServiceDispatcher |E| Error in Service [userLogin]: Password incorrect. [java] 2015-11-12 16:35:00,420 |ajp-bio-8009-exec-7 |TransactionUtil |E| [TransactionUtil.rollback] [java] java.lang.Exception: Stack Trace [java] at org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:322) [ofbiz-entity.jar:?] [java] at org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:299) [ofbiz-entity.jar:?] [java] at org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:534) [ofbiz-service.jar:?] [java] at org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:227) [ofbiz-service.jar:?] [java] at org.ofbiz.service.GenericDispatcherFactory$GenericDispatcher.runSync(GenericDispatcherFactory.java:88) [ofbiz-service.jar:?] [java] at org.ofbiz.webapp.control.LoginWorker.login(LoginWorker.java:488) [ofbiz-webapp.jar:?] [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_60] [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_60] [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_60] [java] at java.lang.reflect.Method.invoke(Method.java:497) ~[?:1.8.0_60] [java] at org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java:92) [ofbiz-webapp.jar:?] [java] at org.ofbiz.webapp.event.JavaEventHandler.invoke(JavaEventHandler.java:78) [ofbiz-webapp.jar:?] [java] at org.ofbiz.webapp.control.RequestHandler.runEvent(RequestHandler.java:759) [ofbiz-webapp.jar:?] [java] at org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:476) [ofbiz-webapp.jar:?] [java] at org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:213) [ofbiz-webapp.jar:?] [java] at org.ofbiz.webapp.control.ControlServlet.doPost(ControlServlet.java:88) [ofbiz-webapp.jar:?] [java] at javax.servlet.http.HttpServlet.service(HttpServlet.java:646) [servlet-api-3.0.jar:?] [java] at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) [servlet-api-3.0.jar:?] [java] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) [tomcat-7.0.64-catalina.jar:7.0.64] [java] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) [tomcat-7.0.64-catalina.jar:7.0.64] [java] at org.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:323) [ofbiz-webapp.jar:?] [java] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) [tomcat-7.0.64-catalina.jar:7.0.64] [java] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) [tomcat-7.0.64-catalina.jar:7.0.64] [java] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) [tomcat-7.0.64-catalina.jar:7.0.64] [java] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) [tomcat-7.0.64-catalina.jar:7.0.64] [java] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505) [tomcat-7.0.64-catalina.jar:7.0.64] [java] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170) [tomcat-7.0.64-catalina.jar:7.0.64] [java] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) [tomcat-7.0.64-catalina.jar:7.0.64] [java] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) [tomcat-7.0.64-catalina.jar:7.0.64] [java] at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956) [tomcat-7.0.64-catalina.jar:7.0.64] [java]
[jira] [Updated] (OFBIZ-6662) PartyRelationship.securityGroupId not added when adding a PartyRelationship
[ https://issues.apache.org/jira/browse/OFBIZ-6662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6662: --- Attachment: OFBIZ-6662-partymgr.patch > PartyRelationship.securityGroupId not added when adding a PartyRelationship > --- > > Key: OFBIZ-6662 > URL: https://issues.apache.org/jira/browse/OFBIZ-6662 > Project: OFBiz > Issue Type: Bug > Components: party >Affects Versions: Release Branch 11.04, Release Branch 12.04, Release > Branch 13.07, Release Branch 14.12, Trunk >Reporter: Forrest Rae > Labels: patch > Attachments: OFBIZ-6662-partymgr.patch > > > When adding a PartyRelationship the value selected for SecurityGroupId is > ignored as createPartyRelationship service expects the parameter to be named > securityGroupId. The AddOtherPartyRelationship form incorrectly names the > field groupId causing the value to be missed in the set-nonpk-fields call in > applications/party/script/org/ofbiz/party/party/PartyServices.xml at line 821. > This bug can be traced back 7 years and 1 month to when the code was > originally committed, showing that it never worked in the first place :( > https://fisheye6.atlassian.com/changelog/ofbiz?cs=688484 > Repo: > 1) While adding a relationship, select something in the Security Group ID > select menu. > 2) Submit > 3) Webtools -> Entity Engine -> PartyRelationship -> Find > 4) Search for the PartyRelationship > 5) Not that the securityGroupId field is empty even though you selected one > in step 1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6662) PartyRelationship.securityGroupId not added when adding a PartyRelationship
Forrest Rae created OFBIZ-6662: -- Summary: PartyRelationship.securityGroupId not added when adding a PartyRelationship Key: OFBIZ-6662 URL: https://issues.apache.org/jira/browse/OFBIZ-6662 Project: OFBiz Issue Type: Bug Components: party Affects Versions: Trunk, Release Branch 14.12, Release Branch 13.07, Release Branch 12.04, Release Branch 11.04 Reporter: Forrest Rae When adding a PartyRelationship the value selected for SecurityGroupId is ignored as createPartyRelationship service expects the parameter to be named securityGroupId. The AddOtherPartyRelationship form incorrectly names the field groupId causing the value to be missed in the set-nonpk-fields call in applications/party/script/org/ofbiz/party/party/PartyServices.xml at line 821. This bug can be traced back 7 years and 1 month to when the code was originally committed, showing that it never worked in the first place :( https://fisheye6.atlassian.com/changelog/ofbiz?cs=688484 Repo: 1) While adding a relationship, select something in the Security Group ID select menu. 2) Submit 3) Webtools -> Entity Engine -> PartyRelationship -> Find 4) Search for the PartyRelationship 5) Not that the securityGroupId field is empty even though you selected one in step 1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6605) createQuoteRole, createContentRole, and createRequirementRole allow for adding Roles to a Party without permissions
Forrest Rae created OFBIZ-6605: -- Summary: createQuoteRole, createContentRole, and createRequirementRole allow for adding Roles to a Party without permissions Key: OFBIZ-6605 URL: https://issues.apache.org/jira/browse/OFBIZ-6605 Project: OFBiz Issue Type: Bug Components: content, order Affects Versions: Trunk, Release Branch 14.12, Release Branch 13.07, Release Branch 11.04 Reporter: Forrest Rae The following functions automatically add a PartyRole entry if the PartyRole does not exist. This is possible even when the userLogin doesn't have PARTYMGR_UPDATE or PARTYMGR_CREATE. createQuoteRole createContentRole createRequirementRole Repo: 1) Remove PARTYMGR_UPDATE or PARTYMGR_CREATE permissions from the ORDERENTRY group. 2) Login as DemoRepStore 3) Create a Quote 4) Add a QuoteRole with partyId of DemoRepStore and Role of your choosing. 5) View DemoRepStore roles. This is a security problem for anyone building component that leverages Role based security. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6493) doesn't support foreign key creation with
[ https://issues.apache.org/jira/browse/OFBIZ-6493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14581187#comment-14581187 ] Forrest Rae commented on OFBIZ-6493: I think this also includes functionality like "not-null" not being enforced. > doesn't support foreign key creation with > > > Key: OFBIZ-6493 > URL: https://issues.apache.org/jira/browse/OFBIZ-6493 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Release Branch 13.07, Trunk >Reporter: Christian Carlow >Priority: Minor > > http://ofbiz.135035.n4.nabble.com/Can-t-get-a-Relation-to-Create-a-FK-Constraint-td4669874.html > This worked for neither trunk nor 13.07. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6444) Postal Address PDF Formatter Screen Problems
[ https://issues.apache.org/jira/browse/OFBIZ-6444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575341#comment-14575341 ] Forrest Rae commented on OFBIZ-6444: Whoops, sorry. For number 1, just get a "Report" for a quote, and then look at your log file. For number 2, add an "General Coorespondence" address to a party that contains an ampersand, like "5th & Oak Street", create a quote for that Party, and then get the "Report" for that quote. > Postal Address PDF Formatter Screen Problems > > > Key: OFBIZ-6444 > URL: https://issues.apache.org/jira/browse/OFBIZ-6444 > Project: OFBiz > Issue Type: Bug > Components: party >Affects Versions: Release Branch 12.04, Release Branch 13.07, Release > Branch 14.12, Trunk >Reporter: Forrest Rae > Attachments: OFBIZ-6444.patch > > > A couple updates are needed to the postalAddressPdfFormatter screen: > First, the screen template is set to use the HTML renderer which results in > this error in the log: > [java] 2015-06-03 13:44:53,400 |0.0.0.0-8009-exec-13 |ModelScreenWidget > |W| In platform-dependent could not find template for xsl-fo, using the > one for html. > Second, the various PostalAddress.fo.ftl files do not escape XML > properly, and addresses with an & in them end up causing a FreeMarker > template error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6444) Postal Address PDF Formatter Screen Problems
[ https://issues.apache.org/jira/browse/OFBIZ-6444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6444: --- Attachment: OFBIZ-6444.patch Patch should work against all versions as it's fairly simple. > Postal Address PDF Formatter Screen Problems > > > Key: OFBIZ-6444 > URL: https://issues.apache.org/jira/browse/OFBIZ-6444 > Project: OFBiz > Issue Type: Bug > Components: party >Affects Versions: Release Branch 12.04, Release Branch 13.07, Release > Branch 14.12, Trunk >Reporter: Forrest Rae > Attachments: OFBIZ-6444.patch > > > A couple updates are needed to the postalAddressPdfFormatter screen: > First, the screen template is set to use the HTML renderer which results in > this error in the log: > [java] 2015-06-03 13:44:53,400 |0.0.0.0-8009-exec-13 |ModelScreenWidget > |W| In platform-dependent could not find template for xsl-fo, using the > one for html. > Second, the various PostalAddress.fo.ftl files do not escape XML > properly, and addresses with an & in them end up causing a FreeMarker > template error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6444) Postal Address PDF Formatter Screen Problems
Forrest Rae created OFBIZ-6444: -- Summary: Postal Address PDF Formatter Screen Problems Key: OFBIZ-6444 URL: https://issues.apache.org/jira/browse/OFBIZ-6444 Project: OFBiz Issue Type: Bug Components: party Affects Versions: Trunk, Release Branch 14.12, Release Branch 13.07, Release Branch 12.04 Reporter: Forrest Rae Attachments: OFBIZ-6444.patch A couple updates are needed to the postalAddressPdfFormatter screen: First, the screen template is set to use the HTML renderer which results in this error in the log: [java] 2015-06-03 13:44:53,400 |0.0.0.0-8009-exec-13 |ModelScreenWidget |W| In platform-dependent could not find template for xsl-fo, using the one for html. Second, the various PostalAddress.fo.ftl files do not escape XML properly, and addresses with an & in them end up causing a FreeMarker template error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6360) Form widget rendering broken for EmailServices.java
[ https://issues.apache.org/jira/browse/OFBIZ-6360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6360: --- Attachment: OFBIZ-6360-release13.07.patch I attached a patch for release13.07. Please updated the affected versions to also 14.12, and 13.07. > Form widget rendering broken for EmailServices.java > --- > > Key: OFBIZ-6360 > URL: https://issues.apache.org/jira/browse/OFBIZ-6360 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Christian Carlow > Fix For: Trunk > > Attachments: OFBIZ-6360-release13.07.patch, OFBIZ-6360.patch > > > Currently only FTL files are rendered by EmailServices.java because > formStringRenderer is null for > HtmlScreenRenderer.java#renderScreenletSubWidget which is supposed to be > extracted from the context parameter, previously from the request parameter, > which never exists for the emailing service. This issue was encountered when > testing the sendQuoteReportMail service for the form widget that replaced the > FTL for OFBIZ-6349. > EmailServices.java is still using the deprecated HtmlScreenRenderer and > FoScreenRenderer which should both be replaced by MacroScreenRenderer. This > made me realize I left out the new header rendering functionality for patch > OFBIZ-6354 for these two deprecated classes which probably need to be > provided along with the existing patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-6431) Error on Sending confirm email from newly created quote, Quote without Terms
[ https://issues.apache.org/jira/browse/OFBIZ-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae closed OFBIZ-6431. -- Resolution: Fixed > Error on Sending confirm email from newly created quote, Quote without Terms > > > Key: OFBIZ-6431 > URL: https://issues.apache.org/jira/browse/OFBIZ-6431 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Release Branch 13.07, Release Branch 14.12, Trunk > Environment: > http://demo-trunk-ofbiz.apache.org/ordermgr/control/sendQuoteReportMail >Reporter: Forrest Rae > > I cloned this bug, since I couldn't reopen. Create a quote with items and a > QuoteTerm, and try sending the quote by email. When you try to send the > report via email, you'll get a NullPointerException. I traced this done to > the fact that ListQuoteInfo use a . > org.ofbiz.widget.screen.ModelScreenWidget.Screenlet.renderWidgetString() > calls org.ofbiz.widget.html.HtmlScreenRenderer.renderScreenletBegin() which > calls org.ofbiz.base.util.UtilHttp.isJavaScriptEnabled(). The exception is > thrown because there is no Request or Response context, as these screens are > being generated via a service call. > === > Error on Sending confirm email from newly created quote > http://demo-trunk-ofbiz.apache.org/ordermgr/control/sendQuoteReportMail > The Following Errors Occurred: > Error rendering screen for email: > org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteSimple]: > org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteTemplate]: > org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: > org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: > java.lang.NullPointerException (null) (Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: > java.lang.NullPointerException (null)) (Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: > org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: > java.lang.NullPointerException (null) (Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: > java.lang.NullPointerException (null))) (Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteTemplate]: > org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: > org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: > java.lang.NullPointerException (null) (Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: > java.lang.NullPointerException (null)) (Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: > org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: > java.lang.NullPointerException (null) (Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: > java.lang.NullPointerException (null -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6431) Error on Sending confirm email from newly created quote, Quote without Terms
[ https://issues.apache.org/jira/browse/OFBIZ-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6431: --- Description: I cloned this bug, since I couldn't reopen. Create a quote with items and a QuoteTerm, and try sending the quote by email. When you try to send the report via email, you'll get a NullPointerException. I traced this done to the fact that ListQuoteInfo use a . org.ofbiz.widget.screen.ModelScreenWidget.Screenlet.renderWidgetString() calls org.ofbiz.widget.html.HtmlScreenRenderer.renderScreenletBegin() which calls org.ofbiz.base.util.UtilHttp.isJavaScriptEnabled(). The exception is thrown because there is no Request or Response context, as these screens are being generated via a service call. === Error on Sending confirm email from newly created quote http://demo-trunk-ofbiz.apache.org/ordermgr/control/sendQuoteReportMail The Following Errors Occurred: Error rendering screen for email: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteSimple]: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteTemplate]: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: java.lang.NullPointerException (null) (Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: java.lang.NullPointerException (null)) (Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: java.lang.NullPointerException (null) (Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: java.lang.NullPointerException (null))) (Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteTemplate]: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: java.lang.NullPointerException (null) (Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: java.lang.NullPointerException (null)) (Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: java.lang.NullPointerException (null) (Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: java.lang.NullPointerException (null was: Error on Sending confirm email from newly created quote http://demo-trunk-ofbiz.apache.org/ordermgr/control/sendQuoteReportMail The Following Errors Occurred: Error rendering screen for email: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteSimple]: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteTemplate]: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: java.lang.NullPointerException (null) (Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: java.lang.NullPointerException (null)) (Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: java.lang.NullPointerException (null) (Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: java.lang.NullPointerException (null))) (Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteTemplate]: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: java.lang.NullPointerException (null) (Error rendering scr
[jira] [Created] (OFBIZ-6431) Error on Sending confirm email from newly created quote, Quote without Terms
Forrest Rae created OFBIZ-6431: -- Summary: Error on Sending confirm email from newly created quote, Quote without Terms Key: OFBIZ-6431 URL: https://issues.apache.org/jira/browse/OFBIZ-6431 Project: OFBiz Issue Type: Bug Components: order Environment: http://demo-trunk-ofbiz.apache.org/ordermgr/control/sendQuoteReportMail Reporter: Forrest Rae Error on Sending confirm email from newly created quote http://demo-trunk-ofbiz.apache.org/ordermgr/control/sendQuoteReportMail The Following Errors Occurred: Error rendering screen for email: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteSimple]: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteTemplate]: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: java.lang.NullPointerException (null) (Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: java.lang.NullPointerException (null)) (Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: java.lang.NullPointerException (null) (Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: java.lang.NullPointerException (null))) (Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteTemplate]: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: java.lang.NullPointerException (null) (Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: java.lang.NullPointerException (null)) (Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: java.lang.NullPointerException (null) (Error rendering screen [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: java.lang.NullPointerException (null -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6431) Error on Sending confirm email from newly created quote, Quote without Terms
[ https://issues.apache.org/jira/browse/OFBIZ-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6431: --- Affects Version/s: Release Branch 13.07 Release Branch 14.12 Trunk > Error on Sending confirm email from newly created quote, Quote without Terms > > > Key: OFBIZ-6431 > URL: https://issues.apache.org/jira/browse/OFBIZ-6431 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Release Branch 13.07, Release Branch 14.12, Trunk > Environment: > http://demo-trunk-ofbiz.apache.org/ordermgr/control/sendQuoteReportMail >Reporter: Forrest Rae > > Error on Sending confirm email from newly created quote > http://demo-trunk-ofbiz.apache.org/ordermgr/control/sendQuoteReportMail > The Following Errors Occurred: > Error rendering screen for email: > org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteSimple]: > org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteTemplate]: > org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: > org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: > java.lang.NullPointerException (null) (Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: > java.lang.NullPointerException (null)) (Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: > org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: > java.lang.NullPointerException (null) (Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: > java.lang.NullPointerException (null))) (Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteTemplate]: > org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: > org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: > java.lang.NullPointerException (null) (Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: > java.lang.NullPointerException (null)) (Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ViewQuoteInfo]: > org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: > java.lang.NullPointerException (null) (Error rendering screen > [component://order/widget/ordermgr/QuoteScreens.xml#ListQuoteInfo]: > java.lang.NullPointerException (null -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[
https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14559968#comment-14559968
]
Forrest Rae commented on OFBIZ-6312:
1. I think this was a copy/paste error. I was following the format of the
code in the "TextField" class to guide me in adding the necessary code to the
"TextareaField". It should be:
{code:java}
Debug.logError("Could not parse the max-length value of the
text element: [" + maxlengthStr
+ "], setting to null; default of no maxlength will
be used", module);
{code}
2. Not sure, that same code exists for "TextArea" class as well. Perhaps both
areas (and others) need improvement.
3. Yea, probably a better Exception to catch.
> Catalog Manager's EditProduct screen HTML should place a limit on the size of
> text that can be entered in the Product Description box
> -
>
> Key: OFBIZ-6312
> URL: https://issues.apache.org/jira/browse/OFBIZ-6312
> Project: OFBiz
> Issue Type: Improvement
> Components: product
>Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01
>Reporter: Forrest Rae
>Assignee: Michael Brohl
> Fix For: Trunk
>
> Attachments: OFBIZ-6312.patch
>
>
> Catalog Manager's EditProduct and EditProductDup screens HTML should place a
> limit on the size of text that can be entered in the Product Description box.
> When more than 255 characters are entered an error is displayed. There is
> no easy way of knowing when you've hit the 255 character max without the HTML
> limiting it.
> The patch I'm including changes the TextArea to include the maxlength
> argument. This should be useful in other areas of the system.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6312: --- Comment: was deleted (was: I don't believe so. TextArea is used when the input can be large. No reason to apply defaults across everything. In my case, when creating new product content, I just wanted the HTML TextArea to reflect the limitations by the database field size.) > Catalog Manager's EditProduct screen HTML should place a limit on the size of > text that can be entered in the Product Description box > - > > Key: OFBIZ-6312 > URL: https://issues.apache.org/jira/browse/OFBIZ-6312 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 >Reporter: Forrest Rae >Assignee: Michael Brohl > Fix For: Trunk > > Attachments: OFBIZ-6312.patch > > > Catalog Manager's EditProduct and EditProductDup screens HTML should place a > limit on the size of text that can be entered in the Product Description box. > When more than 255 characters are entered an error is displayed. There is > no easy way of knowing when you've hit the 255 character max without the HTML > limiting it. > The patch I'm including changes the TextArea to include the maxlength > argument. This should be useful in other areas of the system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14559941#comment-14559941 ] Forrest Rae commented on OFBIZ-6312: I don't believe so. TextArea is used when the input can be large. No reason to apply defaults across everything. In my case, when creating new product content, I just wanted the HTML TextArea to reflect the limitations by the database field size. > Catalog Manager's EditProduct screen HTML should place a limit on the size of > text that can be entered in the Product Description box > - > > Key: OFBIZ-6312 > URL: https://issues.apache.org/jira/browse/OFBIZ-6312 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 >Reporter: Forrest Rae >Assignee: Michael Brohl > Fix For: Trunk > > Attachments: OFBIZ-6312.patch > > > Catalog Manager's EditProduct and EditProductDup screens HTML should place a > limit on the size of text that can be entered in the Product Description box. > When more than 255 characters are entered an error is displayed. There is > no easy way of knowing when you've hit the 255 character max without the HTML > limiting it. > The patch I'm including changes the TextArea to include the maxlength > argument. This should be useful in other areas of the system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14559942#comment-14559942 ] Forrest Rae commented on OFBIZ-6312: I don't believe so. TextArea is used when the input can be large. No reason to apply defaults across everything. In my case, when creating new product content, I just wanted the HTML TextArea to reflect the limitations by the database field size. > Catalog Manager's EditProduct screen HTML should place a limit on the size of > text that can be entered in the Product Description box > - > > Key: OFBIZ-6312 > URL: https://issues.apache.org/jira/browse/OFBIZ-6312 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 >Reporter: Forrest Rae >Assignee: Michael Brohl > Fix For: Trunk > > Attachments: OFBIZ-6312.patch > > > Catalog Manager's EditProduct and EditProductDup screens HTML should place a > limit on the size of text that can be entered in the Product Description box. > When more than 255 characters are entered an error is displayed. There is > no easy way of knowing when you've hit the 255 character max without the HTML > limiting it. > The patch I'm including changes the TextArea to include the maxlength > argument. This should be useful in other areas of the system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote
[ https://issues.apache.org/jira/browse/OFBIZ-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14528921#comment-14528921 ] Forrest Rae commented on OFBIZ-6207: I've read that and don't see anything about splitting patches into multiple files, unless I'm blind (there is always that possibility :P ). If you'd like me to do that, I will. I'll also update the wiki with instructions once I've been through the process. > Anyone can view any Request or Quote > > > Key: OFBIZ-6207 > URL: https://issues.apache.org/jira/browse/OFBIZ-6207 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk, 13.07.01 >Reporter: Forrest Rae >Assignee: Deepak Dixit >Priority: Critical > Labels: security > Fix For: 14.12.01, 13.07.02, Upcoming Branch > > Attachments: OFBIZ-6207-fourth-attempt.patch > > > This is a security bug in the ecommerce application. Anyone can view any > quote or request in the system regardless of the associated partyId. They > can do this via URL parameter manipulation. > Reproduction: > 1) Login to the ecommerce application as DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 > to view your own request. > 3) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 > to view DemoCustAgent's request. > 4) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 > to view DemoCustomer2's request. > Same goes for Quotes, although there are no quotes in the Demo data. The > attach patch fixes this issue. > Would like this issue back ported to release 13.07 please. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote
[ https://issues.apache.org/jira/browse/OFBIZ-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14528393#comment-14528393 ] Forrest Rae commented on OFBIZ-6207: I looked around on the wiki for guidelines on creating bugs/patches but didn't see anything. Is there guidelines on patch creation that I'm just not seeing? > Anyone can view any Request or Quote > > > Key: OFBIZ-6207 > URL: https://issues.apache.org/jira/browse/OFBIZ-6207 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk, 13.07.01 >Reporter: Forrest Rae >Assignee: Deepak Dixit >Priority: Critical > Labels: security > Fix For: 14.12.01, 13.07.02, Upcoming Branch > > Attachments: OFBIZ-6207-fourth-attempt.patch > > > This is a security bug in the ecommerce application. Anyone can view any > quote or request in the system regardless of the associated partyId. They > can do this via URL parameter manipulation. > Reproduction: > 1) Login to the ecommerce application as DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 > to view your own request. > 3) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 > to view DemoCustAgent's request. > 4) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 > to view DemoCustomer2's request. > Same goes for Quotes, although there are no quotes in the Demo data. The > attach patch fixes this issue. > Would like this issue back ported to release 13.07 please. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6323) LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than all the price types
[ https://issues.apache.org/jira/browse/OFBIZ-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14526654#comment-14526654 ] Forrest Rae commented on OFBIZ-6323: Fair enough. Thanks! > LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than > all the price types > - > > Key: OFBIZ-6323 > URL: https://issues.apache.org/jira/browse/OFBIZ-6323 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Release Branch 13.07, Release Branch 14.12, Trunk, > 14.12.01 >Reporter: Forrest Rae >Assignee: Jacques Le Roux > Attachments: OFBIZ-6323.patch > > > The LookUpProductPrice ajaxLookup leverages the same LookupDecorator screen > that is used for more advanced product queries. The results of the request > display all the different price types configured for a product This is > confusing for the user when adding an item to a quote. The attached patch > adds additional conditionalFields to the search criteria. > I've searched the code base for areas where this change might adversely > affect usability and didn't see any cases of that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-6323) LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than all the price types
[ https://issues.apache.org/jira/browse/OFBIZ-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14525351#comment-14525351 ] Forrest Rae edited comment on OFBIZ-6323 at 5/2/15 5:00 PM: This thing operates in two different modes. When you're adding an item to a quote, if you type two characters in to the productId field of the search form, a javascript event will fire that calls LookupProductPrice view with a URL parameter "ajaxLookup" set to true (Watch it in the Webtools in Chrome, on the Network tab). This parameter gets checked in the condition portion of the LookupDecorator, and if true, skips the widget and goes right to the fail-widget, which decorates the response as ajax. Now, if you click the little box to the right of the productId field, you're presented with a full search form where you can select from the different available critera, including the different productPriceType(s). I hope that makes sense. was (Author: f...@14x.net): This thing operates in two different modes. When you're adding an item to a quote, if you type two characters in to the productId field of the search form, a javascript event will fire that calls LookupProductPrice view with a URL parameter "ajaxLookup" set to true (Watch it in the Webtools in Chrome, on the Network tab). This condition gets checked in the LookupDecorator, and if true, calls back to the fail-widget, which decorates the response as ajax. Now, if you click the little box to the right of the productId field, you're presented with a full search form where you can select from the different available critera, including the different productPriceType(s). I hope that makes sense. > LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than > all the price types > - > > Key: OFBIZ-6323 > URL: https://issues.apache.org/jira/browse/OFBIZ-6323 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Release Branch 13.07, Release Branch 14.12, Trunk, > 14.12.01 >Reporter: Forrest Rae > Attachments: OFBIZ-6323.patch > > > The LookUpProductPrice ajaxLookup leverages the same LookupDecorator screen > that is used for more advanced product queries. The results of the request > display all the different price types configured for a product This is > confusing for the user when adding an item to a quote. The attached patch > adds additional conditionalFields to the search criteria. > I've searched the code base for areas where this change might adversely > affect usability and didn't see any cases of that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-6323) LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than all the price types
[ https://issues.apache.org/jira/browse/OFBIZ-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14525351#comment-14525351 ] Forrest Rae edited comment on OFBIZ-6323 at 5/2/15 4:59 PM: This thing operates in two different modes. When you're adding an item to a quote, if you type two characters in to the productId field of the search form, a javascript event will fire that calls LookupProductPrice view with a URL parameter "ajaxLookup" set to true (Watch it in the Webtools in Chrome, on the Network tab). This condition gets checked in the LookupDecorator, and if true, calls back to the fail-widget, which decorates the response as ajax. Now, if you click the little box to the right of the productId field, you're presented with a full search form where you can select from the different available critera, including the different productPriceType(s). I hope that makes sense. was (Author: f...@14x.net): This thing operates in two different modes. When you're adding an item to a quote, if you type two characters in to the productId field of the search form, a javascript event will fire that calls LookupProductPrice view with an "ajaxLookup" set to true. This condition gets checked in the LookupDecorator, and if true, calls back to the fail-widget, which decorates the response as ajax. Now, if you click the little box to the right of the productId field, you're presented with a full search form where you can select from the different available critera, including the different productPriceType(s). I hope that makes sense. > LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than > all the price types > - > > Key: OFBIZ-6323 > URL: https://issues.apache.org/jira/browse/OFBIZ-6323 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Release Branch 13.07, Release Branch 14.12, Trunk, > 14.12.01 >Reporter: Forrest Rae > Attachments: OFBIZ-6323.patch > > > The LookUpProductPrice ajaxLookup leverages the same LookupDecorator screen > that is used for more advanced product queries. The results of the request > display all the different price types configured for a product This is > confusing for the user when adding an item to a quote. The attached patch > adds additional conditionalFields to the search criteria. > I've searched the code base for areas where this change might adversely > affect usability and didn't see any cases of that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6323) LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than all the price types
[ https://issues.apache.org/jira/browse/OFBIZ-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14525351#comment-14525351 ] Forrest Rae commented on OFBIZ-6323: This thing operates in two different modes. When you're adding an item to a quote, if you type two characters in to the productId field of the search form, a javascript event will fire that calls LookupProductPrice view with an "ajaxLookup" set to true. This condition gets checked in the LookupDecorator, and if true, calls back to the fail-widget, which decorates the response as ajax. Now, if you click the little box to the right of the productId field, you're presented with a full search form where you can select from the different available critera, including the different productPriceType(s). I hope that makes sense. > LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than > all the price types > - > > Key: OFBIZ-6323 > URL: https://issues.apache.org/jira/browse/OFBIZ-6323 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Release Branch 13.07, Release Branch 14.12, Trunk, > 14.12.01 >Reporter: Forrest Rae > Attachments: OFBIZ-6323.patch > > > The LookUpProductPrice ajaxLookup leverages the same LookupDecorator screen > that is used for more advanced product queries. The results of the request > display all the different price types configured for a product This is > confusing for the user when adding an item to a quote. The attached patch > adds additional conditionalFields to the search criteria. > I've searched the code base for areas where this change might adversely > affect usability and didn't see any cases of that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6323) LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than all the price types
[ https://issues.apache.org/jira/browse/OFBIZ-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6323: --- Attachment: OFBIZ-6323.patch > LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than > all the price types > - > > Key: OFBIZ-6323 > URL: https://issues.apache.org/jira/browse/OFBIZ-6323 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Release Branch 13.07, Release Branch 14.12, Trunk, > 14.12.01 >Reporter: Forrest Rae > Attachments: OFBIZ-6323.patch > > > The LookUpProductPrice ajaxLookup leverages the same LookupDecorator screen > that is used for more advanced product queries. The results of the request > display all the different price types configured for a product This is > confusing for the user when adding an item to a quote. The attached patch > adds additional conditionalFields to the search criteria. > I've searched the code base for areas where this change might adversely > affect usability and didn't see any cases of that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6323) LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than all the price types
Forrest Rae created OFBIZ-6323: -- Summary: LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than all the price types Key: OFBIZ-6323 URL: https://issues.apache.org/jira/browse/OFBIZ-6323 Project: OFBiz Issue Type: Bug Components: product Affects Versions: Trunk, Release Branch 14.12, Release Branch 13.07, 14.12.01 Reporter: Forrest Rae The LookUpProductPrice ajaxLookup leverages the same LookupDecorator screen that is used for more advanced product queries. The results of the request display all the different price types configured for a product This is confusing for the user when adding an item to a quote. The attached patch adds additional conditionalFields to the search criteria. I've searched the code base for areas where this change might adversely affect usability and didn't see any cases of that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14518716#comment-14518716 ] Forrest Rae edited comment on OFBIZ-6312 at 4/29/15 4:53 AM: - OFBIZ-6312.patch won't work against any other releases except trunk. Backporting is proving to be a pain. It's not to hard on 14.10, but does require manual effort. 13.07 will be harder as the same files don't exist, and it looks like the Widget framework was revamped between 13.07 and 14.10. was (Author: f...@14x.net): OFBIZ-6312.patch won't work against any other releases except trunk. Backporting is proving to be a pain. It's not to hard on 14.10, but does require manual effort. I imagine 13.07 will be the same. > Catalog Manager's EditProduct screen HTML should place a limit on the size of > text that can be entered in the Product Description box > - > > Key: OFBIZ-6312 > URL: https://issues.apache.org/jira/browse/OFBIZ-6312 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 >Reporter: Forrest Rae > Attachments: OFBIZ-6312.patch > > > Catalog Manager's EditProduct and EditProductDup screens HTML should place a > limit on the size of text that can be entered in the Product Description box. > When more than 255 characters are entered an error is displayed. There is > no easy way of knowing when you've hit the 255 character max without the HTML > limiting it. > The patch I'm including changes the TextArea to include the maxlength > argument. This should be useful in other areas of the system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14518716#comment-14518716 ] Forrest Rae edited comment on OFBIZ-6312 at 4/29/15 4:51 AM: - OFBIZ-6312.patch won't work against any other releases except trunk. Backporting is proving to be a pain. It's not to hard on 14.10, but does require manual effort. I imagine 13.07 will be the same. was (Author: f...@14x.net): OFBIZ-6312.patch won't work against release13.07 branch. It will need a different patch. > Catalog Manager's EditProduct screen HTML should place a limit on the size of > text that can be entered in the Product Description box > - > > Key: OFBIZ-6312 > URL: https://issues.apache.org/jira/browse/OFBIZ-6312 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 >Reporter: Forrest Rae > Attachments: OFBIZ-6312.patch > > > Catalog Manager's EditProduct and EditProductDup screens HTML should place a > limit on the size of text that can be entered in the Product Description box. > When more than 255 characters are entered an error is displayed. There is > no easy way of knowing when you've hit the 255 character max without the HTML > limiting it. > The patch I'm including changes the TextArea to include the maxlength > argument. This should be useful in other areas of the system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14518716#comment-14518716 ] Forrest Rae commented on OFBIZ-6312: OFBIZ-6312.patch won't work against release13.07 branch. It will need a different patch. > Catalog Manager's EditProduct screen HTML should place a limit on the size of > text that can be entered in the Product Description box > - > > Key: OFBIZ-6312 > URL: https://issues.apache.org/jira/browse/OFBIZ-6312 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 >Reporter: Forrest Rae > Attachments: OFBIZ-6312.patch > > > Catalog Manager's EditProduct and EditProductDup screens HTML should place a > limit on the size of text that can be entered in the Product Description box. > When more than 255 characters are entered an error is displayed. There is > no easy way of knowing when you've hit the 255 character max without the HTML > limiting it. > The patch I'm including changes the TextArea to include the maxlength > argument. This should be useful in other areas of the system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6312: --- Comment: was deleted (was: I will need to also supply a patch for the Product Duplication form at the bottom of the screen as well.) > Catalog Manager's EditProduct screen HTML should place a limit on the size of > text that can be entered in the Product Description box > - > > Key: OFBIZ-6312 > URL: https://issues.apache.org/jira/browse/OFBIZ-6312 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 >Reporter: Forrest Rae > Attachments: OFBIZ-6312.patch > > > Catalog Manager's EditProduct and EditProductDup screens HTML should place a > limit on the size of text that can be entered in the Product Description box. > When more than 255 characters are entered an error is displayed. There is > no easy way of knowing when you've hit the 255 character max without the HTML > limiting it. > The patch I'm including changes the TextArea to include the maxlength > argument. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6312: --- Description: Catalog Manager's EditProduct and EditProductDup screens HTML should place a limit on the size of text that can be entered in the Product Description box. When more than 255 characters are entered an error is displayed. There is no easy way of knowing when you've hit the 255 character max without the HTML limiting it. The patch I'm including changes the TextArea to include the maxlength argument. This should be useful in other areas of the system. was: Catalog Manager's EditProduct and EditProductDup screens HTML should place a limit on the size of text that can be entered in the Product Description box. When more than 255 characters are entered an error is displayed. There is no easy way of knowing when you've hit the 255 character max without the HTML limiting it. The patch I'm including changes the TextArea to include the maxlength argument. > Catalog Manager's EditProduct screen HTML should place a limit on the size of > text that can be entered in the Product Description box > - > > Key: OFBIZ-6312 > URL: https://issues.apache.org/jira/browse/OFBIZ-6312 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 >Reporter: Forrest Rae > Attachments: OFBIZ-6312.patch > > > Catalog Manager's EditProduct and EditProductDup screens HTML should place a > limit on the size of text that can be entered in the Product Description box. > When more than 255 characters are entered an error is displayed. There is > no easy way of knowing when you've hit the 255 character max without the HTML > limiting it. > The patch I'm including changes the TextArea to include the maxlength > argument. This should be useful in other areas of the system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6312: --- Attachment: OFBIZ-6312.patch > Catalog Manager's EditProduct screen HTML should place a limit on the size of > text that can be entered in the Product Description box > - > > Key: OFBIZ-6312 > URL: https://issues.apache.org/jira/browse/OFBIZ-6312 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 >Reporter: Forrest Rae > Attachments: OFBIZ-6312.patch > > > Catalog Manager's EditProduct and EditProductDup screens HTML should place a > limit on the size of text that can be entered in the Product Description box. > When more than 255 characters are entered an error is displayed. There is > no easy way of knowing when you've hit the 255 character max without the HTML > limiting it. > The patch I'm including changes the TextArea to include the maxlength > argument. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6312: --- Description: Catalog Manager's EditProduct and EditProductDup screens HTML should place a limit on the size of text that can be entered in the Product Description box. When more than 255 characters are entered an error is displayed. There is no easy way of knowing when you've hit the 255 character max without the HTML limiting it. The patch I'm including changes the TextArea to include the maxlength argument. was:Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box. When more than 255 characters are entered an error is displayed. There is no easy way of knowing when you've hit the 255 character max without the HTML limiting it. > Catalog Manager's EditProduct screen HTML should place a limit on the size of > text that can be entered in the Product Description box > - > > Key: OFBIZ-6312 > URL: https://issues.apache.org/jira/browse/OFBIZ-6312 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 >Reporter: Forrest Rae > Attachments: OFBIZ-6312.patch > > > Catalog Manager's EditProduct and EditProductDup screens HTML should place a > limit on the size of text that can be entered in the Product Description box. > When more than 255 characters are entered an error is displayed. There is > no easy way of knowing when you've hit the 255 character max without the HTML > limiting it. > The patch I'm including changes the TextArea to include the maxlength > argument. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6312: --- Attachment: (was: OFBIZ-6312.patch) > Catalog Manager's EditProduct screen HTML should place a limit on the size of > text that can be entered in the Product Description box > - > > Key: OFBIZ-6312 > URL: https://issues.apache.org/jira/browse/OFBIZ-6312 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 >Reporter: Forrest Rae > > Catalog Manager's EditProduct screen HTML should place a limit on the size of > text that can be entered in the Product Description box. When more than 255 > characters are entered an error is displayed. There is no easy way of > knowing when you've hit the 255 character max without the HTML limiting it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14518398#comment-14518398 ] Forrest Rae commented on OFBIZ-6312: I will need to also supply a patch for the Product Duplication form at the bottom of the screen as well. > Catalog Manager's EditProduct screen HTML should place a limit on the size of > text that can be entered in the Product Description box > - > > Key: OFBIZ-6312 > URL: https://issues.apache.org/jira/browse/OFBIZ-6312 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 >Reporter: Forrest Rae > Attachments: OFBIZ-6312.patch > > > Catalog Manager's EditProduct screen HTML should place a limit on the size of > text that can be entered in the Product Description box. When more than 255 > characters are entered an error is displayed. There is no easy way of > knowing when you've hit the 255 character max without the HTML limiting it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6312: --- Attachment: OFBIZ-6312.patch > Catalog Manager's EditProduct screen HTML should place a limit on the size of > text that can be entered in the Product Description box > - > > Key: OFBIZ-6312 > URL: https://issues.apache.org/jira/browse/OFBIZ-6312 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 >Reporter: Forrest Rae > Attachments: OFBIZ-6312.patch > > > Catalog Manager's EditProduct screen HTML should place a limit on the size of > text that can be entered in the Product Description box. When more than 255 > characters are entered an error is displayed. There is no easy way of > knowing when you've hit the 255 character max without the HTML limiting it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
Forrest Rae created OFBIZ-6312: -- Summary: Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box Key: OFBIZ-6312 URL: https://issues.apache.org/jira/browse/OFBIZ-6312 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: 13.07.01, 12.04.05, Trunk, Release Branch 14.12 Reporter: Forrest Rae Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box. When more than 255 characters are entered an error is displayed. There is no easy way of knowing when you've hit the 255 character max without the HTML limiting it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6311) Order Manager ViewQuote screen should display party name and link to party manager
[ https://issues.apache.org/jira/browse/OFBIZ-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6311: --- Affects Version/s: Release Branch 14.12 > Order Manager ViewQuote screen should display party name and link to party > manager > -- > > Key: OFBIZ-6311 > URL: https://issues.apache.org/jira/browse/OFBIZ-6311 > Project: OFBiz > Issue Type: Improvement > Components: order >Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 >Reporter: Forrest Rae > Labels: patch > Attachments: OFBIZ-6311.patch > > > As a convenience, and to match the other applications, Order Manager > ViewQuote screen should display party name and link to party manager. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6311) Order Manager ViewQuote screen should display party name and link to party manager
[ https://issues.apache.org/jira/browse/OFBIZ-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6311: --- Attachment: OFBIZ-6311.patch Patch to include the party name and link to Party Manager. Might need some minor improvements to match the other applications. > Order Manager ViewQuote screen should display party name and link to party > manager > -- > > Key: OFBIZ-6311 > URL: https://issues.apache.org/jira/browse/OFBIZ-6311 > Project: OFBiz > Issue Type: Improvement > Components: order >Affects Versions: Trunk, 12.04.05, 13.07.01 >Reporter: Forrest Rae > Labels: patch > Attachments: OFBIZ-6311.patch > > > As a convenience, and to match the other applications, Order Manager > ViewQuote screen should display party name and link to party manager. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6311) Order Manager ViewQuote screen should display party name and link to party manager
Forrest Rae created OFBIZ-6311: -- Summary: Order Manager ViewQuote screen should display party name and link to party manager Key: OFBIZ-6311 URL: https://issues.apache.org/jira/browse/OFBIZ-6311 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: 13.07.01, 12.04.05, Trunk Reporter: Forrest Rae As a convenience, and to match the other applications, Order Manager ViewQuote screen should display party name and link to party manager. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6207) Anyone can view any Request or Quote
[ https://issues.apache.org/jira/browse/OFBIZ-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6207: --- Attachment: OFBIZ-6207-fourth-attempt.patch Fourth patch uses condition tag as suggested by Deepak. > Anyone can view any Request or Quote > > > Key: OFBIZ-6207 > URL: https://issues.apache.org/jira/browse/OFBIZ-6207 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk, 13.07.01 >Reporter: Forrest Rae >Assignee: Deepak Dixit >Priority: Critical > Labels: security > Attachments: OFBIZ-6207-fourth-attempt.patch > > > This is a security bug in the ecommerce application. Anyone can view any > quote or request in the system regardless of the associated partyId. They > can do this via URL parameter manipulation. > Reproduction: > 1) Login to the ecommerce application as DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 > to view your own request. > 3) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 > to view DemoCustAgent's request. > 4) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 > to view DemoCustomer2's request. > Same goes for Quotes, although there are no quotes in the Demo data. The > attach patch fixes this issue. > Would like this issue back ported to release 13.07 please. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6207) Anyone can view any Request or Quote
[ https://issues.apache.org/jira/browse/OFBIZ-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6207: --- Attachment: (was: OFBIZ-6207-third-attempt.patch) > Anyone can view any Request or Quote > > > Key: OFBIZ-6207 > URL: https://issues.apache.org/jira/browse/OFBIZ-6207 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk, 13.07.01 >Reporter: Forrest Rae >Assignee: Deepak Dixit >Priority: Critical > Labels: security > > This is a security bug in the ecommerce application. Anyone can view any > quote or request in the system regardless of the associated partyId. They > can do this via URL parameter manipulation. > Reproduction: > 1) Login to the ecommerce application as DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 > to view your own request. > 3) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 > to view DemoCustAgent's request. > 4) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 > to view DemoCustomer2's request. > Same goes for Quotes, although there are no quotes in the Demo data. The > attach patch fixes this issue. > Would like this issue back ported to release 13.07 please. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote
[ https://issues.apache.org/jira/browse/OFBIZ-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14380811#comment-14380811 ] Forrest Rae commented on OFBIZ-6207: If I wanted to leverage permission services in Request/Quote services such as custRequestPermissionCheck, it seems I would need to pass in a "fromPartyId" argument, but can't seem to figure out how to do that: errors: Error message: cvc-complex-type.3.2.2: Attribute 'fromPartyId' is not allowed to appear in element 'if-service-permission'. > Anyone can view any Request or Quote > > > Key: OFBIZ-6207 > URL: https://issues.apache.org/jira/browse/OFBIZ-6207 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk, 13.07.01 >Reporter: Forrest Rae >Assignee: Deepak Dixit >Priority: Critical > Labels: security > Attachments: OFBIZ-6207-third-attempt.patch > > > This is a security bug in the ecommerce application. Anyone can view any > quote or request in the system regardless of the associated partyId. They > can do this via URL parameter manipulation. > Reproduction: > 1) Login to the ecommerce application as DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 > to view your own request. > 3) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 > to view DemoCustAgent's request. > 4) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 > to view DemoCustomer2's request. > Same goes for Quotes, although there are no quotes in the Demo data. The > attach patch fixes this issue. > Would like this issue back ported to release 13.07 please. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote
[ https://issues.apache.org/jira/browse/OFBIZ-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14380808#comment-14380808 ] Forrest Rae commented on OFBIZ-6207: Thanks Adrian. I explored this quite a bit. The whole framework looks geared to Application level permissions rather than what I'm trying to address, which is entity level access control. > Anyone can view any Request or Quote > > > Key: OFBIZ-6207 > URL: https://issues.apache.org/jira/browse/OFBIZ-6207 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk, 13.07.01 >Reporter: Forrest Rae >Assignee: Deepak Dixit >Priority: Critical > Labels: security > Attachments: OFBIZ-6207-third-attempt.patch > > > This is a security bug in the ecommerce application. Anyone can view any > quote or request in the system regardless of the associated partyId. They > can do this via URL parameter manipulation. > Reproduction: > 1) Login to the ecommerce application as DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 > to view your own request. > 3) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 > to view DemoCustAgent's request. > 4) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 > to view DemoCustomer2's request. > Same goes for Quotes, although there are no quotes in the Demo data. The > attach patch fixes this issue. > Would like this issue back ported to release 13.07 please. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote
[ https://issues.apache.org/jira/browse/OFBIZ-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14380715#comment-14380715 ] Forrest Rae commented on OFBIZ-6207: I got it working using this suggestion, which I agree is much cleaner than dropping down to groovy via the 'set" tag. > Anyone can view any Request or Quote > > > Key: OFBIZ-6207 > URL: https://issues.apache.org/jira/browse/OFBIZ-6207 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk, 13.07.01 >Reporter: Forrest Rae >Assignee: Deepak Dixit >Priority: Critical > Labels: security > Attachments: OFBIZ-6207-third-attempt.patch > > > This is a security bug in the ecommerce application. Anyone can view any > quote or request in the system regardless of the associated partyId. They > can do this via URL parameter manipulation. > Reproduction: > 1) Login to the ecommerce application as DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 > to view your own request. > 3) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 > to view DemoCustAgent's request. > 4) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 > to view DemoCustomer2's request. > Same goes for Quotes, although there are no quotes in the Demo data. The > attach patch fixes this issue. > Would like this issue back ported to release 13.07 please. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote
[ https://issues.apache.org/jira/browse/OFBIZ-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14380034#comment-14380034 ] Forrest Rae commented on OFBIZ-6207: Adrian, Can you point me to an example and I'll take a look? > Anyone can view any Request or Quote > > > Key: OFBIZ-6207 > URL: https://issues.apache.org/jira/browse/OFBIZ-6207 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk, 13.07.01 >Reporter: Forrest Rae >Assignee: Deepak Dixit >Priority: Critical > Labels: security > Attachments: OFBIZ-6207-third-attempt.patch > > > This is a security bug in the ecommerce application. Anyone can view any > quote or request in the system regardless of the associated partyId. They > can do this via URL parameter manipulation. > Reproduction: > 1) Login to the ecommerce application as DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 > to view your own request. > 3) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 > to view DemoCustAgent's request. > 4) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 > to view DemoCustomer2's request. > Same goes for Quotes, although there are no quotes in the Demo data. The > attach patch fixes this issue. > Would like this issue back ported to release 13.07 please. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote
[ https://issues.apache.org/jira/browse/OFBIZ-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14379323#comment-14379323 ] Forrest Rae commented on OFBIZ-6207: Deepak, I'll try again tomorrow AM, but I'm fairly sure I tried that. Can you list an example in this context, or maybe post a different patch? It'd help me with learning how to do these types of things properly in OFBIZ. > Anyone can view any Request or Quote > > > Key: OFBIZ-6207 > URL: https://issues.apache.org/jira/browse/OFBIZ-6207 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk, 13.07.01 >Reporter: Forrest Rae >Assignee: Deepak Dixit >Priority: Critical > Labels: security > Attachments: OFBIZ-6207-third-attempt.patch > > > This is a security bug in the ecommerce application. Anyone can view any > quote or request in the system regardless of the associated partyId. They > can do this via URL parameter manipulation. > Reproduction: > 1) Login to the ecommerce application as DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 > to view your own request. > 3) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 > to view DemoCustAgent's request. > 4) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 > to view DemoCustomer2's request. > Same goes for Quotes, although there are no quotes in the Demo data. The > attach patch fixes this issue. > Would like this issue back ported to release 13.07 please. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6207) Anyone can view any Request or Quote
[ https://issues.apache.org/jira/browse/OFBIZ-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6207: --- Attachment: (was: OFBIZ-6207.patch) > Anyone can view any Request or Quote > > > Key: OFBIZ-6207 > URL: https://issues.apache.org/jira/browse/OFBIZ-6207 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk, 13.07.01 >Reporter: Forrest Rae >Priority: Critical > Labels: security > Attachments: OFBIZ-6207-third-attempt.patch > > > This is a security bug in the ecommerce application. Anyone can view any > quote or request in the system regardless of the associated partyId. They > can do this via URL parameter manipulation. > Reproduction: > 1) Login to the ecommerce application as DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 > to view your own request. > 3) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 > to view DemoCustAgent's request. > 4) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 > to view DemoCustomer2's request. > Same goes for Quotes, although there are no quotes in the Demo data. The > attach patch fixes this issue. > Would like this issue back ported to release 13.07 please. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6207) Anyone can view any Request or Quote
[ https://issues.apache.org/jira/browse/OFBIZ-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6207: --- Attachment: (was: OFBIZ-6207-second-attempt.patch) > Anyone can view any Request or Quote > > > Key: OFBIZ-6207 > URL: https://issues.apache.org/jira/browse/OFBIZ-6207 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk, 13.07.01 >Reporter: Forrest Rae >Priority: Critical > Labels: security > Attachments: OFBIZ-6207-third-attempt.patch > > > This is a security bug in the ecommerce application. Anyone can view any > quote or request in the system regardless of the associated partyId. They > can do this via URL parameter manipulation. > Reproduction: > 1) Login to the ecommerce application as DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 > to view your own request. > 3) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 > to view DemoCustAgent's request. > 4) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 > to view DemoCustomer2's request. > Same goes for Quotes, although there are no quotes in the Demo data. The > attach patch fixes this issue. > Would like this issue back ported to release 13.07 please. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6207) Anyone can view any Request or Quote
[ https://issues.apache.org/jira/browse/OFBIZ-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6207: --- Attachment: OFBIZ-6207-third-attempt.patch Third attempt at a patch that works in both Trunk and 13.07. I believe this one is final. > Anyone can view any Request or Quote > > > Key: OFBIZ-6207 > URL: https://issues.apache.org/jira/browse/OFBIZ-6207 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk, 13.07.01 >Reporter: Forrest Rae >Priority: Critical > Labels: security > Attachments: OFBIZ-6207-third-attempt.patch > > > This is a security bug in the ecommerce application. Anyone can view any > quote or request in the system regardless of the associated partyId. They > can do this via URL parameter manipulation. > Reproduction: > 1) Login to the ecommerce application as DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 > to view your own request. > 3) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 > to view DemoCustAgent's request. > 4) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 > to view DemoCustomer2's request. > Same goes for Quotes, although there are no quotes in the Demo data. The > attach patch fixes this issue. > Would like this issue back ported to release 13.07 please. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote
[ https://issues.apache.org/jira/browse/OFBIZ-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14379214#comment-14379214 ] Forrest Rae commented on OFBIZ-6207: Figured it out: > Anyone can view any Request or Quote > > > Key: OFBIZ-6207 > URL: https://issues.apache.org/jira/browse/OFBIZ-6207 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk, 13.07.01 >Reporter: Forrest Rae >Priority: Critical > Labels: security > Attachments: OFBIZ-6207-second-attempt.patch, OFBIZ-6207.patch > > > This is a security bug in the ecommerce application. Anyone can view any > quote or request in the system regardless of the associated partyId. They > can do this via URL parameter manipulation. > Reproduction: > 1) Login to the ecommerce application as DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 > to view your own request. > 3) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 > to view DemoCustAgent's request. > 4) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 > to view DemoCustomer2's request. > Same goes for Quotes, although there are no quotes in the Demo data. The > attach patch fixes this issue. > Would like this issue back ported to release 13.07 please. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote
[ https://issues.apache.org/jira/browse/OFBIZ-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14379199#comment-14379199 ] Forrest Rae commented on OFBIZ-6207: So, in 13.07, in the widget will call GenericDelegator.findOne(). This checks that you're only using primary keys for the search. My patch seems to cause a problem as it was using partyId as part of the search criteria. partyId is not a PK of Quote. What is the recommended way of checking the Quote.partyId field to make sure it matches userLogin.partyId in the actions section of the specialpurpose/ecommerce/widget/QuoteScreens.xml#ViewQuote screen? None of this matters in Trunk as the in the screen never results in a call to GenericDelegator.findOne(). > Anyone can view any Request or Quote > > > Key: OFBIZ-6207 > URL: https://issues.apache.org/jira/browse/OFBIZ-6207 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk, 13.07.01 >Reporter: Forrest Rae >Priority: Critical > Labels: security > Attachments: OFBIZ-6207-second-attempt.patch, OFBIZ-6207.patch > > > This is a security bug in the ecommerce application. Anyone can view any > quote or request in the system regardless of the associated partyId. They > can do this via URL parameter manipulation. > Reproduction: > 1) Login to the ecommerce application as DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 > to view your own request. > 3) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 > to view DemoCustAgent's request. > 4) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 > to view DemoCustomer2's request. > Same goes for Quotes, although there are no quotes in the Demo data. The > attach patch fixes this issue. > Would like this issue back ported to release 13.07 please. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote
[ https://issues.apache.org/jira/browse/OFBIZ-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14379096#comment-14379096 ] Forrest Rae commented on OFBIZ-6207: Honestly, I am a bit lost as to why this isn't working against 13.07. I didn't intend to have a patch for each. > Anyone can view any Request or Quote > > > Key: OFBIZ-6207 > URL: https://issues.apache.org/jira/browse/OFBIZ-6207 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk, 13.07.01 >Reporter: Forrest Rae >Priority: Critical > Labels: security > Attachments: OFBIZ-6207-second-attempt.patch, OFBIZ-6207.patch > > > This is a security bug in the ecommerce application. Anyone can view any > quote or request in the system regardless of the associated partyId. They > can do this via URL parameter manipulation. > Reproduction: > 1) Login to the ecommerce application as DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 > to view your own request. > 3) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 > to view DemoCustAgent's request. > 4) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 > to view DemoCustomer2's request. > Same goes for Quotes, although there are no quotes in the Demo data. The > attach patch fixes this issue. > Would like this issue back ported to release 13.07 please. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote
[ https://issues.apache.org/jira/browse/OFBIZ-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14379076#comment-14379076 ] Forrest Rae commented on OFBIZ-6207: Although, when applied to the 13.07 branch, it seems to cause an error. Strange because it works great applied to Trunk. [java] 2015-03-24 18:06:22,012 |-0.0.0.0-8443-exec-3 |PrimaryKeyFinder |E| Error finding entity value by primary key with entity-one: org.ofbiz.entity.GenericModelException: [GenericDelegator.findOne] Passed primary key is not a valid primary key: [GenericEntity:CustRequest][custRequestId,9000(java.lang.String)][fromPartyId,DemoCustomer(java.lang.String)] [java] org.ofbiz.entity.GenericModelException: [GenericDelegator.findOne] Passed primary key is not a valid primary key: [GenericEntity:CustRequest][custRequestId,9000(java.lang.String)][fromPartyId,DemoCustomer(java.lang.String)] [java] at org.ofbiz.entity.GenericDelegator.findOne(GenericDelegator.java:1483) ~[ofbiz-entity.jar:?] [java] at org.ofbiz.entity.finder.PrimaryKeyFinder.runFind(PrimaryKeyFinder.java:154) [ofbiz-entity.jar:?] [java] at org.ofbiz.entity.finder.PrimaryKeyFinder.runFind(PrimaryKeyFinder.java:86) [ofbiz-entity.jar:?] [java] at org.ofbiz.widget.ModelWidgetAction$EntityOne.runAction(ModelWidgetAction.java:511) [ofbiz-widget.jar:?] [java] at org.ofbiz.widget.ModelWidgetAction.runSubActions(ModelWidgetAction.java:114) [ofbiz-widget.jar:?] [java] at org.ofbiz.widget.screen.ModelScreenWidget$Section.renderWidgetString(ModelScreenWidget.java:186) [ofbiz-widget.jar:?] [java] at org.ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:396) [ofbiz-widget.jar:?] [java] at org.ofbiz.widget.screen.ScreenRenderer.render(ScreenRenderer.java:135) [ofbiz-widget.jar:?] [java] at org.ofbiz.widget.screen.ScreenRenderer.render(ScreenRenderer.java:97) [ofbiz-widget.jar:?] [java] at org.ofbiz.widget.screen.MacroScreenViewHandler.render(MacroScreenViewHandler.java:104) [ofbiz-widget.jar:?] [java] at org.ofbiz.webapp.control.RequestHandler.renderView(RequestHandler.java:916) [ofbiz-webapp.jar:?] [java] at org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:614) [ofbiz-webapp.jar:?] [java] at org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:218) [ofbiz-webapp.jar:?] > Anyone can view any Request or Quote > > > Key: OFBIZ-6207 > URL: https://issues.apache.org/jira/browse/OFBIZ-6207 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk, 13.07.01 >Reporter: Forrest Rae >Priority: Critical > Labels: security > Attachments: OFBIZ-6207-second-attempt.patch, OFBIZ-6207.patch > > > This is a security bug in the ecommerce application. Anyone can view any > quote or request in the system regardless of the associated partyId. They > can do this via URL parameter manipulation. > Reproduction: > 1) Login to the ecommerce application as DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 > to view your own request. > 3) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 > to view DemoCustAgent's request. > 4) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 > to view DemoCustomer2's request. > Same goes for Quotes, although there are no quotes in the Demo data. The > attach patch fixes this issue. > Would like this issue back ported to release 13.07 please. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6207) Anyone can view any Request or Quote
[ https://issues.apache.org/jira/browse/OFBIZ-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6207: --- Attachment: OFBIZ-6207-second-attempt.patch I just attached OFBIZ-6207-second-attempt.patch. This patch should work cleaner. > Anyone can view any Request or Quote > > > Key: OFBIZ-6207 > URL: https://issues.apache.org/jira/browse/OFBIZ-6207 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk, 13.07.01 >Reporter: Forrest Rae >Priority: Critical > Labels: security > Attachments: OFBIZ-6207-second-attempt.patch, OFBIZ-6207.patch > > > This is a security bug in the ecommerce application. Anyone can view any > quote or request in the system regardless of the associated partyId. They > can do this via URL parameter manipulation. > Reproduction: > 1) Login to the ecommerce application as DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 > to view your own request. > 3) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 > to view DemoCustAgent's request. > 4) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 > to view DemoCustomer2's request. > Same goes for Quotes, although there are no quotes in the Demo data. The > attach patch fixes this issue. > Would like this issue back ported to release 13.07 please. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6207) Anyone can view any Request or Quote
[ https://issues.apache.org/jira/browse/OFBIZ-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14379014#comment-14379014 ] Forrest Rae commented on OFBIZ-6207: Turns out my patch isn't correct. The location of the condition in the "ViewRequest" screen is out of place. Please don't apply yet. > Anyone can view any Request or Quote > > > Key: OFBIZ-6207 > URL: https://issues.apache.org/jira/browse/OFBIZ-6207 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk, 13.07.01 >Reporter: Forrest Rae >Priority: Critical > Labels: security > Attachments: OFBIZ-6207.patch > > > This is a security bug in the ecommerce application. Anyone can view any > quote or request in the system regardless of the associated partyId. They > can do this via URL parameter manipulation. > Reproduction: > 1) Login to the ecommerce application as DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 > to view your own request. > 3) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 > to view DemoCustAgent's request. > 4) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 > to view DemoCustomer2's request. > Same goes for Quotes, although there are no quotes in the Demo data. The > attach patch fixes this issue. > Would like this issue back ported to release 13.07 please. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6207) Anyone can view any Request or Quote
[ https://issues.apache.org/jira/browse/OFBIZ-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6207: --- Affects Version/s: 13.07.01 > Anyone can view any Request or Quote > > > Key: OFBIZ-6207 > URL: https://issues.apache.org/jira/browse/OFBIZ-6207 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk, 13.07.01 >Reporter: Forrest Rae >Priority: Critical > Labels: security > Attachments: OFBIZ-6207.patch > > > This is a security bug in the ecommerce application. Anyone can view any > quote or request in the system regardless of the associated partyId. They > can do this via URL parameter manipulation. > Reproduction: > 1) Login to the ecommerce application as DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 > to view your own request. > 3) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 > to view DemoCustAgent's request. > 4) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 > to view DemoCustomer2's request. > Same goes for Quotes, although there are no quotes in the Demo data. The > attach patch fixes this issue. > Would like this issue back ported to release 13.07 please. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6207) Anyone can view any Request or Quote
[ https://issues.apache.org/jira/browse/OFBIZ-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6207: --- Description: This is a security bug in the ecommerce application. Anyone can view any quote or request in the system regardless of the associated partyId. They can do this via URL parameter manipulation. Reproduction: 1) Login to the ecommerce application as DemoCustomer. 2) Navigate to http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 to view your own request. 3) Navigate to http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 to view DemoCustAgent's request. 4) Navigate to http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 to view DemoCustomer2's request. Same goes for Quotes, although there are no quotes in the Demo data. The attach patch fixes this issue. Would like this issue back ported to release 13.07 please. was: This is a security bug in the ecommerce application. Anyone can view any quote or request in the system regardless of the associated partyId. They can do this via URL parameter manipulation. Reproduction: 1) Login to the ecommerce application as DemoCustomer. 2) Navigate to http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 to view your own request. 3) Navigate to http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 to view DemoCustAgent's request. 4) Navigate to http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 to view DemoCustomer2's request. Same goes for Quotes, although there are no quotes in the Demo data. The attach patch fixes this issue. > Anyone can view any Request or Quote > > > Key: OFBIZ-6207 > URL: https://issues.apache.org/jira/browse/OFBIZ-6207 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk >Reporter: Forrest Rae >Priority: Critical > Labels: security > Attachments: OFBIZ-6207.patch > > > This is a security bug in the ecommerce application. Anyone can view any > quote or request in the system regardless of the associated partyId. They > can do this via URL parameter manipulation. > Reproduction: > 1) Login to the ecommerce application as DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 > to view your own request. > 3) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 > to view DemoCustAgent's request. > 4) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 > to view DemoCustomer2's request. > Same goes for Quotes, although there are no quotes in the Demo data. The > attach patch fixes this issue. > Would like this issue back ported to release 13.07 please. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6207) Anyone can view any Request or Quote
Forrest Rae created OFBIZ-6207: -- Summary: Anyone can view any Request or Quote Key: OFBIZ-6207 URL: https://issues.apache.org/jira/browse/OFBIZ-6207 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Affects Versions: Trunk Reporter: Forrest Rae Priority: Critical Attachments: OFBIZ-6207.patch This is a security bug in the ecommerce application. Anyone can view any quote or request in the system regardless of the associated partyId. They can do this via URL parameter manipulation. Reproduction: 1) Login to the ecommerce application as DemoCustomer. 2) Navigate to http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 to view your own request. 3) Navigate to http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 to view DemoCustAgent's request. 4) Navigate to http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 to view DemoCustomer2's request. Same goes for Quotes, although there are no quotes in the Demo data. The attach patch fixes this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6207) Anyone can view any Request or Quote
[ https://issues.apache.org/jira/browse/OFBIZ-6207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6207: --- Attachment: OFBIZ-6207.patch Fixes issue. > Anyone can view any Request or Quote > > > Key: OFBIZ-6207 > URL: https://issues.apache.org/jira/browse/OFBIZ-6207 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk >Reporter: Forrest Rae >Priority: Critical > Labels: security > Attachments: OFBIZ-6207.patch > > > This is a security bug in the ecommerce application. Anyone can view any > quote or request in the system regardless of the associated partyId. They > can do this via URL parameter manipulation. > Reproduction: > 1) Login to the ecommerce application as DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9000 > to view your own request. > 3) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9001 > to view DemoCustAgent's request. > 4) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/ViewRequest?custRequestId=9002 > to view DemoCustomer2's request. > Same goes for Quotes, although there are no quotes in the Demo data. The > attach patch fixes this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6112) Incorrect Error Displayed when "Expiring" a Contact Mechanism
[ https://issues.apache.org/jira/browse/OFBIZ-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14338494#comment-14338494 ] Forrest Rae commented on OFBIZ-6112: Whoops, sorry. I did it again the git repo on github. Thankfully it was just a one liner. > Incorrect Error Displayed when "Expiring" a Contact Mechanism > - > > Key: OFBIZ-6112 > URL: https://issues.apache.org/jira/browse/OFBIZ-6112 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk, 13.07.01 >Reporter: Forrest Rae >Assignee: Jacques Le Roux > Fix For: Upcoming Branch > > Attachments: OFBIZ-6112.patch > > > When expiring a contact mechanism, an incorrect error is displayed. This is > mostly an error due to code reuse. There is no reason to redirect back to > editcontactmech, instead just redirect to viewprofile. See attached patch. > "The contact information specified does not belong to you, you may not view > or edit it." > Repro: > 1) Login to http://demo-stable-ofbiz.apache.org/ecommerce/control/main as > DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/viewprofile > 3) Click Expire next to one of the Postal Addresses. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6112) Incorrect Error Displayed when "Expiring" a Contact Mechanism
[ https://issues.apache.org/jira/browse/OFBIZ-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6112: --- Attachment: OFBIZ-6112.patch > Incorrect Error Displayed when "Expiring" a Contact Mechanism > - > > Key: OFBIZ-6112 > URL: https://issues.apache.org/jira/browse/OFBIZ-6112 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Trunk, 13.07.01 >Reporter: Forrest Rae > Attachments: OFBIZ-6112.patch > > > When expiring a contact mechanism, an incorrect error is displayed. This is > mostly an error due to code reuse. There is no reason to redirect back to > editcontactmech, instead just redirect to viewprofile. See attached patch. > "The contact information specified does not belong to you, you may not view > or edit it." > Repro: > 1) Login to http://demo-stable-ofbiz.apache.org/ecommerce/control/main as > DemoCustomer. > 2) Navigate to > http://demo-stable-ofbiz.apache.org/ecommerce/control/viewprofile > 3) Click Expire next to one of the Postal Addresses. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6112) Incorrect Error Displayed when "Expiring" a Contact Mechanism
Forrest Rae created OFBIZ-6112: -- Summary: Incorrect Error Displayed when "Expiring" a Contact Mechanism Key: OFBIZ-6112 URL: https://issues.apache.org/jira/browse/OFBIZ-6112 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Affects Versions: 13.07.01, Trunk Reporter: Forrest Rae When expiring a contact mechanism, an incorrect error is displayed. This is mostly an error due to code reuse. There is no reason to redirect back to editcontactmech, instead just redirect to viewprofile. See attached patch. "The contact information specified does not belong to you, you may not view or edit it." Repro: 1) Login to http://demo-stable-ofbiz.apache.org/ecommerce/control/main as DemoCustomer. 2) Navigate to http://demo-stable-ofbiz.apache.org/ecommerce/control/viewprofile 3) Click Expire next to one of the Postal Addresses. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
