Bug 1701062 - [RFE] - Ability to set the file extension for generated Satellite 6.5 reports
Summary: [RFE] - Ability to set the file extension for generated Satellite 6.5 reports
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Reporting
Version: 6.5.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: 6.7.0
Assignee: satellite6-bugs
QA Contact: Lukáš Hellebrandt
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-17 22:29 UTC by Brian Smith
Modified: 2020-04-14 13:24 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-14 13:24:11 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 26641 0 Normal Closed Ability to set the file extension for generated reports 2020-08-20 10:46:02 UTC
Red Hat Bugzilla 1658566 0 unspecified CLOSED [RFE] Generated report file has MIME type text/plain 2023-12-15 16:16:18 UTC
Red Hat Product Errata RHSA-2020:1454 0 None None None 2020-04-14 13:24:22 UTC

Description Brian Smith 2019-04-17 22:29:25 UTC
Description of problem:
When generating reports in Satellite 6.5 web interface, the generated reports  have a ".txt" file extension.  It would be nice if the user could specify what file extension the report should be created with (for example, ".csv", or ".html") so that the web browser could open the report in the appropriate application.  


Version-Release number of selected component (if applicable):  Satellite 6.5 Beta


Steps to Reproduce:
1.  Generate report from Satellite 6.5 web interface

Actual results:
Generated file has .txt extension


Expected results:
Ability to specify the file extension on a per-report basis, so that ".csv", ".html", etc. could be specified for the file extension.

Comment 3 Marek Hulan 2019-04-18 07:17:10 UTC
This will most likely be fixed with https://bugzilla.redhat.com/show_bug.cgi?id=1701062, I think we should be able to select what formats are available for a given report template if more than one is assigned, during rendering, user should be able to choose one of them. That should also set the correct mime/type and file suffix.

Comment 4 Marek Hulan 2019-04-18 07:17:58 UTC
Created redmine issue https://projects.theforeman.org/issues/26641 from this bug

Comment 5 Lukáš Hellebrandt 2019-04-18 09:14:05 UTC
Is it OK to close this as duplicate of bug 1658566?

Comment 6 Marek Hulan 2019-04-18 18:03:54 UTC
I was thinking about the same, but I think verify steps for both are different. Most likely the implementation will be the same, but QE should verify both mime type, suffix and format selection as part of it. I don't have a strong preference, so leaving the decision up to you. While it's clear now, it may not be at the moment we'll implement and it will have to be verified.

Comment 7 Bryan Kearney 2019-10-09 02:02:03 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/26641 has been resolved.

Comment 8 Lukáš Hellebrandt 2020-01-16 13:29:15 UTC
This basically works, but there are issues for templates that don't use the report_render macro:

1) Downloaded files have the file extension of ".text" rather than expected ".txt"
2) The format selection field is greyed out (as expected) with the value of "CSV" selected (which is confusing, the resulting file is not a CSV)
3) I think it should be possible to set MIME type to all reports, not just those that contain string "report_render" - even if it doesn't change the actual file contents, the MIME type and extension should be selectable (for instance to tell the browser how to treat the downloaded file)

Also, I think it should be possible to select TXT format. It's not possible now and I'd go as far as calling it regression because previous versions (only) supported generating .txt reports.

One more point, Marek mentioned he wants available formats to be a property of each template. This is not the case.

Comment 9 Marek Hulan 2020-01-17 08:21:15 UTC
Lukáš, I don't think FailedQA is apropriate then. By that you basically indicate this feature is not shippable and block the beta release on it. However you also say it basically works.

Let me respond to you concerns. I believe they all should have been reported as separate BZs so we can prioritize them differently and decide what needs to go into the next version and what not.

> 1) Downloaded files have the file extension of ".text" rather than expected ".txt"

Ok, that is a valid issue and a one-liner to fix. Please open a separate BZ for this. While I think it's a low priority and definitely not a blocker (only customer templates not using macro and suffix is text instead of txt), we can improve it easily.

> 2) The format selection field is greyed out (as expected) with the value of "CSV" selected (which is confusing, the resulting file is not a CSV)

Greyed out fields do not represent a value, that's I think the same in the whole application. The inline help says "... this field is disabled and the output format defaults to plain text.". If you feel strongly, open a separate BZ, we could show empty value in this case, however I suppose we can agree it's not a blocker for this feature.

> 3) I think it should be possible to set MIME type to all reports, not just those that contain string "report_render" - even if it doesn't change the actual file contents, the MIME type and extension should be selectable (for instance to tell the browser how to treat the downloaded file)

If the template does not use report_render macro, there's no way for us to know, what format the output is. I think it would be much more confusing for users, if they select e.g. html in generate form, but they would receive csv instead. Think of the scenario, where person who writes the template is a different person from who generates it. Btw there's a way how to enable format selection for templates that don't use this macro. Just add <%# report_render -%> anywhere in your template. However we don't advertise that because of the confusion I described previously.

> Also, I think it should be possible to select TXT format. It's not possible now and I'd go as far as calling it regression because previous versions (only) supported generating .txt reports.

Why would you want to have plain text format if you always generate one of the recognized format? Plain text is only used when report_render is not used, since in that case we only know, the output is some plain text. I don't think this is a regression, not every change is a regression. If you think it is a regression, please explain what is a downside of specifying correct mime type and suffix and what people get from keeping plain text instead.

> One more point, Marek mentioned he wants available formats to be a property of each template. This is not the case.

That was a suggestion that after investigation wasn't found practical. It would cause a lot of manual effort for user to configure available types, while it's recommended to use report_render macro, which support all types all the time. If user would select 2 or more formats but would not use report_render macro, they would need to take care of the switch in ERB themselves, which I doubt someone would do. They would probably rather create a second report template with different implementation.

Comment 10 Lukáš Hellebrandt 2020-01-17 12:33:29 UTC
After discussion with Marek, I am verifying this and filing a BZ against 1) because while there is no standard specifying text file extension, ".txt" is commonly used.

Marek correctly said that this BZ talks about "6.5 reports" - meaning it's only valid for reports shipped with 6.5, not custom reports. All the shipped reports use macro report_render. Points 1, 2, 3 are all about macros that don't use it. Also, point 3) can be bypassed by writing the macro in a comment.

Furthermore, while the behavior change might be unexpected and I think it would be better to allow TXT format to be selected, it's OK to remove this behavior in favor of the enhancement.

Comment 13 errata-xmlrpc 2020-04-14 13:24:11 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:1454


Note You need to log in before you can comment on or make changes to this bug.