Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 17.12.01, Trunk
    • 17.12.01, 18.12.01
    • content
    • None
    • Patch

    Description

      On demo: content --> "CmsSite" --> CMS:

      Right click on one of the items to add "New Long Text" or "Image".

      After saving the new content:

      Edit WebSite CMS For: []
      "There is no Content PUBLISH_POINT for this WebSite!"

      Having the same problem on a  17.12 local installation.

      Attachments

        1. OFBIZ-10833.patch
          1 kB
          Swapnil Mane
        2. LogCreateContent.txt
          7 kB
          Ingo Wolfmayr
        3. cms_addImage.patch
          1 kB
          Ingo Wolfmayr
        4. OFBIZ-10833.patch
          3 kB
          Sebastian Berg
        5. OFBIZ-10833.patch
          3 kB
          Michael Brohl

        Issue Links

        Activity

          swapnilmmane Swapnil Mane added a comment -

          Hello team,

          It seems there is an issue at the framework level.

          When the form of enctype="multipart/form-data" type is submitted, the parameters are not available to the next response type.

          Here is the example (taking reference of the issue reported here 'CMS add content not working')

          <request-map uri="createTextContentCms"> 
              <security https="true" auth="true"/>
              <event type="service" invoke="createTextContent"/>
              <response name="success" type="view" value="WebSiteCMS"/>
              <response name="error" type="view" value="WebSiteCMS"/>
          </request-map>
          

          The parameters provided to createTextContent service are not available to WebSiteCMS view.

          As per my exploration, here is a possible reason for this.
          UtilHttp.getMultiPartParameterMap method is used to get the parameters in case of "multipart/form-data" type.
          The getMultiPartParameterMap parse the request to get the parameters.

          (trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/UtilHttp.java)

          uploadedItems = UtilGenerics.<FileItem>checkList(upload.parseRequest(request));
          

          As per the Apache commons-fileupload guideline, a request can only be parsed once [1]. So, for the next response (WebSiteCMS view), again the same getMultiPartParameterMap method is executed (with the same request object), and no parameters are found, since, the request is already parsed.

          Also, have a look at the StackOverflow question [2], it also contains related information.

          [1] http://commons.apache.org/proper/commons-fileupload/faq.html#empty-parse

          [2] https://stackoverflow.com/questions/13881272/servletfileuploadparserequestrequest-returns-an-empty-list

          Please feel free to share your thoughts!

          Thanks!

          swapnilmmane Swapnil Mane added a comment - Hello team, It seems there is an issue at the framework level. When the form of enctype="multipart/form-data" type is submitted, the parameters are not available to the next response type. Here is the example (taking reference of the issue reported here 'CMS add content not working') <request-map uri= "createTextContentCms" > <security https= " true " auth= " true " /> <event type= "service" invoke= "createTextContent" /> <response name= "success" type= "view" value= "WebSiteCMS" /> <response name= "error" type= "view" value= "WebSiteCMS" /> </request-map> The parameters provided to createTextContent service are not available to WebSiteCMS view. As per my exploration, here is a possible reason for this. UtilHttp.getMultiPartParameterMap method is used to get the parameters in case of "multipart/form-data" type. The getMultiPartParameterMap parse the request to get the parameters. (trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/UtilHttp.java) uploadedItems = UtilGenerics.<FileItem>checkList(upload.parseRequest(request)); As per the Apache commons-fileupload guideline, a request can only be parsed once [1] . So, for the next response (WebSiteCMS view), again the same getMultiPartParameterMap method is executed (with the same request object), and no parameters are found, since, the request is already parsed. Also, have a look at the StackOverflow question [2] , it also contains related information. [1] http://commons.apache.org/proper/commons-fileupload/faq.html#empty-parse [2] https://stackoverflow.com/questions/13881272/servletfileuploadparserequestrequest-returns-an-empty-list Please feel free to share your thoughts! Thanks!
          jleroux Jacques Le Roux added a comment - - edited

          Thanks Swapnil,

          It seems you nailed it, now we need to fix it

          jleroux Jacques Le Roux added a comment - - edited Thanks Swapnil, It seems you nailed it, now we need to fix it
          swapnilmmane Swapnil Mane added a comment -

          Thank you [~jacques.le.roux]!  

          swapnilmmane Swapnil Mane added a comment - Thank you [~jacques.le.roux] !  
          swapnilmmane Swapnil Mane added a comment -

          Hello team,

          Attaching the patch to fix the issue. Please have a look and let me know if you any inputs.

          As mentioned in my previous comment, a request can only be parsed once and thus the parameters will not be available to the next response.

          To fix this issue, set the consumed parameters [except uploaded file(s) *1] in the request attribute so that it will be available to the next response.

          [*1] The uploaded file(s) are not set in request attribute again to avoid unnecessary memory consumption, also it makes no sense to traverse the uploaded file in the request.

           

          Thanks, Ingo Wolfmayr for reporting the issue, you also try the attached patch.

          swapnilmmane Swapnil Mane added a comment - Hello team, Attaching the patch to fix the issue. Please have a look and let me know if you any inputs. As mentioned in my previous comment, a request can only be parsed once and thus the parameters will not be available to the next response. To fix this issue, set the consumed parameters [except uploaded file(s) *1] in the request attribute so that it will be available to the next response. [*1] The uploaded file(s) are not set in request attribute again to avoid unnecessary memory consumption, also it makes no sense to traverse the uploaded file in the request.   Thanks, Ingo Wolfmayr for reporting the issue, you also try the attached patch.

          The patch does not fix OFBIZ-10834, I removed the "related" link

          jleroux Jacques Le Roux added a comment - The patch does not fix OFBIZ-10834 , I removed the "related" link
          swapnilmmane Swapnil Mane added a comment -

          Sure, thank you [~jacques.le.roux].

          swapnilmmane Swapnil Mane added a comment - Sure, thank you [~jacques.le.roux] .

          The patch works here

          jleroux Jacques Le Roux added a comment - The patch works here
          swapnilmmane Swapnil Mane added a comment -

          Great, thanks so much [~jacques.le.roux] for inputs and review!

          swapnilmmane Swapnil Mane added a comment - Great, thanks so much [~jacques.le.roux] for inputs and review!
          iwolf Ingo Wolfmayr added a comment -

          Hi Swapnil,

          thanks for your work!!! Unfortunately I cannot get it to work. I installed a fresh system with the current trunk and applied the patch. I also added a "print" output to get sure the code is reached - it does.

          Manually creating content via "create new content": The file is uploaded but the dataresource has no reference to it.

          Using CMS (fresh trunk on OfbizSite): right click "new Image". The image apears for about a second and disapears - "content association" is not created but content is created correctly and accessible via content search. Creating other content types via CMS does have the same problem. So I don't now by now if its a CMS problem or connected to issue you described.

          Best regards,

          Ingo

          iwolf Ingo Wolfmayr added a comment - Hi Swapnil, thanks for your work!!! Unfortunately I cannot get it to work. I installed a fresh system with the current trunk and applied the patch. I also added a "print" output to get sure the code is reached - it does. Manually creating content via "create new content": The file is uploaded but the dataresource has no reference to it. Using CMS (fresh trunk on OfbizSite): right click "new Image". The image apears for about a second and disapears - "content association" is not created but content is created correctly and accessible via content search. Creating other content types via CMS does have the same problem. So I don't now by now if its a CMS problem or connected to issue you described. Best regards, Ingo

          I indeed get "There is no Content PUBLISH_POINT for this WebSite!" on trunk demo as locally, when I saw it working locally a week ago.
          I guess a change committed between must be the reason.

          jleroux Jacques Le Roux added a comment - I indeed get "There is no Content PUBLISH_POINT for this WebSite!" on trunk demo as locally, when I saw it working locally a week ago. I guess a change committed between must be the reason.
          swapnilmmane Swapnil Mane added a comment - - edited

          Thanks Ingo Wolfmayr and [~jacques.le.roux] for your comments.
          The changes in the patch are not committed yet, this is why you might be getting the issue on trunk demo.

          Dear Ingo Wolfmayr,
          Thanks for trying the patch, I hope you have applied the patch and restart the server.
          It will be helpful for me if you can share the detailed steps you followed (after applying the patch) and issue faced.
          I will have a look into this over the weekend.

          Thanks!

          swapnilmmane Swapnil Mane added a comment - - edited Thanks Ingo Wolfmayr and [~jacques.le.roux] for your comments. The changes in the patch are not committed yet, this is why you might be getting the issue on trunk demo. Dear Ingo Wolfmayr , Thanks for trying the patch, I hope you have applied the patch and restart the server. It will be helpful for me if you can share the detailed steps you followed (after applying the patch) and issue faced. I will have a look into this over the weekend. Thanks!
          iwolf Ingo Wolfmayr added a comment -

          Dear Swapnil Mane,

          I applied the patch manually and verified the code has been added. I additionally added a print log before the new code line in order to see if it is reached when creating a content item. Here is the result:

          Result manually: "System.out.println("10833: "+ fieldName + " - "+ multiPartMap.get(fieldName));" <-- right before "request.setAttribute(fieldName, multiPartMap.get(fieldName));"

          10833: dataResourceId - master
          10833: dataResourceTypeId - LOCAL_FILE
          10833: objectInfo -

          CMS

          10833: contentAssocTypeId - SUBSITE
          10833: ownerContentId - OFBIZ_HOME
          10833: contentIdFrom - OFBIZ_HOME
          10833: dataResourceTypeId - IMAGE_OBJECT
          10833: webSiteId - OfbizSite
          10833: dataResourceName - CMS Image
          10833: contentName - CMS Image
          10833: description -
          10833: mapKey -
          10833: contentPurposeTypeId - SECTION
          10833: sequenceNum -
          10833: dataTemplateTypeId - NONE
          10833: decoratorContentId -
          10833: templateDataResourceId -
          10833: statusId - CTNT_IN_PROGRESS
          10833: isPublic - Y
          10833: isUploadObject - Y

          I assume some of the information is getting lost (CMS way) when the ECA services for createContent are triggered: Find the log entries starting after the content has been createdLogCreateContent.txt. For example
          " From Field (contentAssocTypeId) is not found in context for createContent, defaulting to null."

          The contentAssocTypeId is there when the content is created. The ECA that creates the contentAssoc reports it is not.

          Maybe you have an idea?

          iwolf Ingo Wolfmayr added a comment - Dear Swapnil Mane , I applied the patch manually and verified the code has been added. I additionally added a print log before the new code line in order to see if it is reached when creating a content item. Here is the result: Result manually : "System.out.println("10833: "+ fieldName + " - "+ multiPartMap.get(fieldName));" <-- right before "request.setAttribute(fieldName, multiPartMap.get(fieldName));" 10833: dataResourceId - master 10833: dataResourceTypeId - LOCAL_FILE 10833: objectInfo - CMS 10833: contentAssocTypeId - SUBSITE 10833: ownerContentId - OFBIZ_HOME 10833: contentIdFrom - OFBIZ_HOME 10833: dataResourceTypeId - IMAGE_OBJECT 10833: webSiteId - OfbizSite 10833: dataResourceName - CMS Image 10833: contentName - CMS Image 10833: description - 10833: mapKey - 10833: contentPurposeTypeId - SECTION 10833: sequenceNum - 10833: dataTemplateTypeId - NONE 10833: decoratorContentId - 10833: templateDataResourceId - 10833: statusId - CTNT_IN_PROGRESS 10833: isPublic - Y 10833: isUploadObject - Y I assume some of the information is getting lost (CMS way) when the ECA services for createContent are triggered: Find the log entries starting after the content has been created LogCreateContent.txt . For example " From Field (contentAssocTypeId) is not found in context for createContent, defaulting to null." The contentAssocTypeId is there when the content is created. The ECA that creates the contentAssoc reports it is not. Maybe you have an idea?

          Thanks Ingo,

          IIRW I did apply the patch locally too

          jleroux Jacques Le Roux added a comment - Thanks Ingo, IIRW I did apply the patch locally too
          iwolf Ingo Wolfmayr added a comment -

          Adding

          <attribute name="contentAssocTypeId" type="String" mode="INOUT" optional="true"/>
          <attribute name="contentIdFrom" type="String" mode="INOUT" optional="true"/>
          <attribute name="contentIdTo" type="String" mode="INOUT" optional="true"/>

          to service "createContent" fixes the CMS part.cms_addImage.patch

          iwolf Ingo Wolfmayr added a comment - Adding <attribute name="contentAssocTypeId" type="String" mode="INOUT" optional="true"/> <attribute name="contentIdFrom" type="String" mode="INOUT" optional="true"/> <attribute name="contentIdTo" type="String" mode="INOUT" optional="true"/> to service "createContent" fixes the CMS part. cms_addImage.patch
          iwolf Ingo Wolfmayr added a comment - - edited

          One more: Updating an existing content type via CMS results in updating the parent content item.

          Reverting https://github.com/apache/ofbiz-framework/commit/b1f62d1075b42cb0c20d0970a96eed918c917ea9#diff-b9f71a6d3f777abe21af18704cf4f5fe makes it work.

          iwolf Ingo Wolfmayr added a comment - - edited One more: Updating an existing content type via CMS results in updating the parent content item. Reverting https://github.com/apache/ofbiz-framework/commit/b1f62d1075b42cb0c20d0970a96eed918c917ea9#diff-b9f71a6d3f777abe21af18704cf4f5fe  makes it work.
          swapnilmmane Swapnil Mane added a comment - - edited

          Fixed the issue in which the parameters are not available to the next response type when form of enctype="multipart/form-data" type is submitted. Changes committed in

          trunk at rev 1858035
          release18.12 at rev 1858036
          release17.12 at rev 1858037

          Issue does not exist in release16.11

          Thanks!

          swapnilmmane Swapnil Mane added a comment - - edited Fixed the issue in which the parameters are not available to the next response type when form of enctype="multipart/form-data" type is submitted. Changes committed in trunk at rev 1858035 release18.12 at rev 1858036 release17.12 at rev 1858037 Issue does not exist in release16.11 Thanks!

          Thanks Swapnil!

          jleroux Jacques Le Roux added a comment - Thanks Swapnil!
          swapnilmmane Swapnil Mane added a comment -

          Dear [~jacques.le.roux] ,
          I have committed the patch which I uploaded for fixing the issue in which the parameters are not available to the next response type when form of enctype="multipart/form-data" type is submitted.
          I commit the change since this was the issue at our framework and needs to fix.

          But as mentioned by Ingo Wolfmayr in above comments, his problem doesn't fixed with this patch.
          I think, we should wait for him to confirm that his issue is resolve and then we can proceed to close this issue.
          WDYT?

          Thanks!

          swapnilmmane Swapnil Mane added a comment - Dear [~jacques.le.roux] , I have committed the patch which I uploaded for fixing the issue in which the parameters are not available to the next response type when form of enctype="multipart/form-data" type is submitted. I commit the change since this was the issue at our framework and needs to fix. But as mentioned by Ingo Wolfmayr in above comments, his problem doesn't fixed with this patch. I think, we should wait for him to confirm that his issue is resolve and then we can proceed to close this issue. WDYT? Thanks!
          jleroux Jacques Le Roux added a comment - - edited

          Reopening, I thought it was complete, thanks Swapnil!

          jleroux Jacques Le Roux added a comment - - edited Reopening, I thought it was complete, thanks Swapnil!
          swapnilmmane Swapnil Mane added a comment -

          Thanks [~jacques.le.roux]!

          swapnilmmane Swapnil Mane added a comment - Thanks [~jacques.le.roux] !
          iwolf Ingo Wolfmayr added a comment -

          This are my test results on https://demo-trunk.ofbiz.apache.org

          I created a new content item via CMS and the result is not as expected. The content assoc to the parent is not created - neither for images, long text a.s.o.. The content is created correct - image available, text available.

          CONTENT --> WebSites --> OfbizSite --> CMS --> (right click ...new imagee)

          iwolf Ingo Wolfmayr added a comment - This are my test results on  https://demo-trunk.ofbiz.apache.org I created a new content item  via CMS  and the result is not as expected. The content assoc to the parent is not created - neither for images, long text a.s.o.. The content is created correct - image available, text available. CONTENT --> WebSites --> OfbizSite --> CMS --> (right click ...new imagee)
          mbrohl Michael Brohl added a comment -

          Hi Swapnil Mane ,

          are you still working on this issue or should we take it and investigate further?

          mbrohl Michael Brohl added a comment - Hi Swapnil Mane , are you still working on this issue or should we take it and investigate further?
          swapnilmmane Swapnil Mane added a comment - - edited

          Hi Michael Brohl,
          Thank you for showing kind interest, please feel free to go ahead.
          Thank you!

          swapnilmmane Swapnil Mane added a comment - - edited Hi Michael Brohl , Thank you for showing kind interest, please feel free to go ahead. Thank you!
          sberg Sebastian Berg added a comment -

          Hi,

          I created a patch containing the missing contentAssoc and the revert so that by updating the child the parent is no longer updated.

          This should fix the issue.

          sberg Sebastian Berg added a comment - Hi, I created a patch containing the missing contentAssoc and the revert so that by updating the child the parent is no longer updated. This should fix the issue.
          pierresmits Pierre Smits added a comment -

          HI Sebastian Berg,

          Is this patch also somewhere implemented in a development/feature branch in a publicly available git repo (e.g. on Github)?

          If so, it may be beneficial to fellow community members to use that for review (and other collaboration) purposes. And if everything checks out, the project can/may decide to use a pull request to establish an officially endorsed 'OFBiz feature branch' to make it available to the entire community, or directly merge it into another branch (trunk and or release branch).

          IMO, providing enhancement contributions (bug fixes, improvements and new features) through development branches in public git repos is more favourable as it leverages key feature(s) of git.

          It avoids you to upload additional enhancements to the solution to this tickets, but also to have reviewing community members to download these enhancements  and apply them to their review branch.

          pierresmits Pierre Smits added a comment - HI Sebastian Berg , Is this patch also somewhere implemented in a development/feature branch in a publicly available git repo (e.g. on Github)? If so, it may be beneficial to fellow community members to use that for review (and other collaboration) purposes. And if everything checks out, the project can/may decide to use a pull request to establish an officially endorsed 'OFBiz feature branch' to make it available to the entire community, or directly merge it into another branch (trunk and or release branch). IMO, providing enhancement contributions (bug fixes, improvements and new features) through development branches in public git repos is more favourable as it leverages key feature(s) of git. It avoids you to upload additional enhancements to the solution to this tickets, but also to have reviewing community members to download these enhancements  and apply them to their review branch.
          mbrohl Michael Brohl added a comment - - edited

          Sebastian Berg, the patch is just fine for me to test and review, thanks.

          Pierre Smits we are aware of the different ways of contributing, no need to reiterate in the Jira issues, we have the mailing list discussions for it. Thanks.

          mbrohl Michael Brohl added a comment - - edited Sebastian Berg , the patch is just fine for me to test and review, thanks. Pierre Smits we are aware of the different ways of contributing, no need to reiterate in the Jira issues, we have the mailing list discussions for it. Thanks.
          pierresmits Pierre Smits added a comment -

          Michael Brohl There is no need to scold and/or dictate a fellow contributor how, where and when he/she choses to contribute. There is also no need to speak for others or use the 'royal we'. 

          Furthermore, I suggest not to use the  flag field to set the 'patch' option. Patches are visible to all right after the moment of upload. And notifications thereabout are sent to the appropriate ml. Plus, in Jira overviews it is shown through the field 'attachments' and the status 'Patch Available'.

          See also: https://cwiki.apache.org/confluence/display/OFBIZ/Guidelines+For+Using+JIRA

          pierresmits Pierre Smits added a comment - Michael Brohl  There is no need to scold and/or dictate a fellow contributor how, where and when he/she choses to contribute. There is also no need to speak for others or use the 'royal we'.  Furthermore, I suggest not to use the  flag field to set the 'patch' option. Patches are visible to all right after the moment of upload. And notifications thereabout are sent to the appropriate ml. Plus, in Jira overviews it is shown through the field 'attachments' and the status 'Patch Available'. See also:  https://cwiki.apache.org/confluence/display/OFBIZ/Guidelines+For+Using+JIRA

          Commit c332322017c93ba1c18ffbb8104d3ee58bdb2624 in ofbiz-framework's branch refs/heads/trunk from Michael Brohl
          [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=c332322 ]

          Fixed: CMS add content not working.
          (OFBIZ-10833)

          This fixes the missing content association and wrong update of the
          parent content reported by Ingo Wolfmayr. Thanks Sebastian Berg for
          providing the patch.

          jira-bot ASF subversion and git services added a comment - Commit c332322017c93ba1c18ffbb8104d3ee58bdb2624 in ofbiz-framework's branch refs/heads/trunk from Michael Brohl [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=c332322 ] Fixed: CMS add content not working. ( OFBIZ-10833 ) This fixes the missing content association and wrong update of the parent content reported by Ingo Wolfmayr. Thanks Sebastian Berg for providing the patch.

          Commit b8f727dc61e12672990152a0a09c95bec9dbfd11 in ofbiz-framework's branch refs/heads/release18.12 from Michael Brohl
          [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=b8f727d ]

          Fixed: CMS add content not working.
          (OFBIZ-10833)

          This fixes the mission content association and wrong update of the
          parent content reported by Ingo Wolfmayr. Thanks Sebastian Berg for
          providing the patch.

          jira-bot ASF subversion and git services added a comment - Commit b8f727dc61e12672990152a0a09c95bec9dbfd11 in ofbiz-framework's branch refs/heads/release18.12 from Michael Brohl [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=b8f727d ] Fixed: CMS add content not working. ( OFBIZ-10833 ) This fixes the mission content association and wrong update of the parent content reported by Ingo Wolfmayr. Thanks Sebastian Berg for providing the patch.

          Commit b318f00d057d5f0a388236c47d2418f9113054ab in ofbiz-framework's branch refs/heads/release17.12 from Michael Brohl
          [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=b318f00 ]

          Fixed: CMS add content not working.
          (OFBIZ-10833)

          This fixes the mission content association and wrong update of the
          parent content reported by Ingo Wolfmayr. Thanks Sebastian Berg for
          providing the patch.

          jira-bot ASF subversion and git services added a comment - Commit b318f00d057d5f0a388236c47d2418f9113054ab in ofbiz-framework's branch refs/heads/release17.12 from Michael Brohl [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=b318f00 ] Fixed: CMS add content not working. ( OFBIZ-10833 ) This fixes the mission content association and wrong update of the parent content reported by Ingo Wolfmayr. Thanks Sebastian Berg for providing the patch.
          mbrohl Michael Brohl added a comment -

          Sebastian Berg your patch did not apply correctly, I uploaded a working patch with the same changes again.

          mbrohl Michael Brohl added a comment - Sebastian Berg your patch did not apply correctly, I uploaded a working patch with the same changes again.
          swapnilmmane Swapnil Mane added a comment -
          swapnilmmane Swapnil Mane added a comment - Thank you Michael Brohl and Sebastian Berg !

          People

            mbrohl Michael Brohl
            iwolf Ingo Wolfmayr
            Votes:
            0 Vote for this issue
            Watchers:
            Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Slack