Uploaded image for project: 'Pentaho Reporting and Pentaho Report Designer'
  1. Pentaho Reporting and Pentaho Report Designer
  2. PRD-3516

Saving a report in PUC via IE gives the filename as "reporting" instead of giving the prpt's name as filename.

    Details

    • Notice:
      When an issue is open, the "Fix Version/s" field conveys a target, not necessarily a commitment. When an issue is closed, the "Fix Version/s" field conveys the version that the issue was fixed in.

      Description

      When we are trying to save the prpt file in PDF format we are getting the file name as "reporting". Could you please let us know whether this is the default behavier of Pentaho or is it possible to change the file name as the report name? PFA.

        Issue Links

          Activity

          Hide
          kcruzada Kurtis Cruzada added a comment - - edited

          It should use the report file name like Excel.

          Show
          kcruzada Kurtis Cruzada added a comment - - edited It should use the report file name like Excel.
          Hide
          tmorgner Thomas Morgner added a comment -

          http://stackoverflow.com/questions/151079/name-web-pdf-for-better-default-save-filename-in-acrobat

          According to that post, the Acrobat Reader is to blame for
          that. It ignores all relevant headers. I do not see a way
          to fix that for now, other than "faking" a file on the server
          via some HTTP-redirect magic and loads of filters.

          If it is important enough to potentially break existing
          clients then:

          (1) On a "renderType=REPORT" request we return immediately
          with a HTTP-302 response forwarding the browser to

          .../reporting/render/fancy-filename-here.pdf?all-other-params=here

          (2) The reporting plugin then checks for a "extra-path" that
          starts with "/render/" and proceeds with the normal report
          generation and sends the content.

          Impact:

          (1) Creating a report requires at least one extra call to the server
          for the 302-response and the next GET

          (2) It may break OEMs who are not prepared to handle 302 responses
          or who use these responses as "Authentication failure". We use that
          sort of trick for the publish code, so I assume it is used elsewhere as well.

          (3) Generating a PDF from XAction or Analzyer probably
          suffers from the same problem, so expect to do more fixing there as
          well.

          (4) I do not know how the dashboards or other integration points will react
          to a 302 response. They may or may not work properly.

          Show
          tmorgner Thomas Morgner added a comment - http://stackoverflow.com/questions/151079/name-web-pdf-for-better-default-save-filename-in-acrobat According to that post, the Acrobat Reader is to blame for that. It ignores all relevant headers. I do not see a way to fix that for now, other than "faking" a file on the server via some HTTP-redirect magic and loads of filters. If it is important enough to potentially break existing clients then: (1) On a "renderType=REPORT" request we return immediately with a HTTP-302 response forwarding the browser to .../reporting/render/fancy-filename-here.pdf?all-other-params=here (2) The reporting plugin then checks for a "extra-path" that starts with "/render/" and proceeds with the normal report generation and sends the content. Impact: (1) Creating a report requires at least one extra call to the server for the 302-response and the next GET (2) It may break OEMs who are not prepared to handle 302 responses or who use these responses as "Authentication failure". We use that sort of trick for the publish code, so I assume it is used elsewhere as well. (3) Generating a PDF from XAction or Analzyer probably suffers from the same problem, so expect to do more fixing there as well. (4) I do not know how the dashboards or other integration points will react to a 302 response. They may or may not work properly.
          Hide
          tmorgner Thomas Morgner added a comment -

          Acrobat Reader does not evaluate the Content-Disposition header and wants to use the file path of the URL for filenames. I now use a 302 redirect to move the report to distinct path. The extra path is not used at all, it solely exists for the broken PDF plugin. The filename is sanitized of some dangerous characters (?, &, *, =, '../').

          Applications that read generated content from the URL may react badly to a redirect, interpreting it as a login-failed attempt (which also redirects with a 302) and thus may show strange and erratic behaviour. Therefore this new "feature" can be disabled with the pentaho.xml setting "report-execute-redirect-to-virtual-file" set to false.

          Show
          tmorgner Thomas Morgner added a comment - Acrobat Reader does not evaluate the Content-Disposition header and wants to use the file path of the URL for filenames. I now use a 302 redirect to move the report to distinct path. The extra path is not used at all, it solely exists for the broken PDF plugin. The filename is sanitized of some dangerous characters (?, &, *, =, '../'). Applications that read generated content from the URL may react badly to a redirect, interpreting it as a login-failed attempt (which also redirects with a 302) and thus may show strange and erratic behaviour. Therefore this new "feature" can be disabled with the pentaho.xml setting "report-execute-redirect-to-virtual-file" set to false.
          Hide
          kcruzada Kurtis Cruzada added a comment -

          This is not an IE only issue. This happens on other operating systems. I just validated this on the Mac OS X. Can you try this on windows? Open the Income Statement report. View as PDF. Then, hit save. It should have the report name in the save dialog.

          Show
          kcruzada Kurtis Cruzada added a comment - This is not an IE only issue. This happens on other operating systems. I just validated this on the Mac OS X. Can you try this on windows? Open the Income Statement report. View as PDF. Then, hit save. It should have the report name in the save dialog.
          Hide
          gdavid Golda Thomas added a comment -

          I have tried this on windows using the PRD nightly build from 8/1/2011 and have attached screen shot for it.

          Show
          gdavid Golda Thomas added a comment - I have tried this on windows using the PRD nightly build from 8/1/2011 and have attached screen shot for it.
          Hide
          gdavid Golda Thomas added a comment -

          I have tested the income statement reporting IE 8 and when viewed as PDF in IE 8 and then saved the report saves with the correct name and not seeing reporting any where while saving.
          Marking this issue as resolved.
          Tested using the nightly build from 8/1/2011

          Show
          gdavid Golda Thomas added a comment - I have tested the income statement reporting IE 8 and when viewed as PDF in IE 8 and then saved the report saves with the correct name and not seeing reporting any where while saving. Marking this issue as resolved. Tested using the nightly build from 8/1/2011
          Hide
          gdavid Golda Thomas added a comment -

          Validated using the BISERVER nightly build on 8/1/2011

          Show
          gdavid Golda Thomas added a comment - Validated using the BISERVER nightly build on 8/1/2011

            People

            • Assignee:
              gdavid Golda Thomas
              Reporter:
              tmorgner Thomas Morgner
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: