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)
