Join 34,000+ subscribers and receive articles from our blog about software quality, testing, QA and security.
 

Feature Request: Send Report as PDF Attachment


#81

This is a major issue for us now and is a real shame as the remainder of the tool works well. Not only can many of our suppliers not open the zip file (corporate policy to block it in many cases) but we implement Cyber Essentials Plus policy and this mandates the blocking of java script that is contained in the report so we can’t even send it.


#82

Hi Kevin,

Thanks for your feedback. It is planned to review this as additional format but this is not a small or easy to implement feature unfortunately with the complexity of the reports and the complexity that comes with generating 100% compatible PDFs from HTML. We would like to look into this for a future version but don’t have a time frame or estimate at this point.

Cheers,
Tobias


#83

Hi Tobias,

There are absolutely applications that do this, though, so it can’t be a monumental task. We have AppDynamics, and in fact I get regular PDF reports in my email (without having an AppDynamics account). And, of course, AppDynamics is a Web/HTML app.

If it’s a business decision not to do it, I can appreciate that, but it’s hard for me to believe that it’s totally unfeasible from a technical standpoint.

Jim


#84

Hi Jim,

Thanks for your feedback. Yes, it’s certainly possible from a technical perspective, it’s just that it’s a very complex and difficult feature (especially since we need to support it on both TestRail Server and Cloud). For now, we have the ZIP/HTML version and this also supports non-TestRail users. This works well for a large majority of customers but I understand that having an additional PDF option would be better and we would like to review this again at some point.

Cheers,
Tobias


#85

Hi Tobias,

We’ve been using TestRail at Seagate for a couple of years now and like it very much. Unfortunately, this issue with the email report attachments is becoming a very severe issue for us. Echoing the feedback of so many users in this thread, we desperately need to have the automated email attachments be in PDF format or, at the very least, the basic HTML progress information embedded in the body of the automated email.

Like most other commenters here, our senior execs loath to open up attachments, extract files, then launch an index.htm file in a browser. They’d rather not even go to a website - If it’s more than one click to access data, they’ll skip it, and in turn blame ME for not providing the data in the format that they want or are accustomed to.

But now it’s more than just preference/inconvenience - it’s a security issue. Our IT group will no longer allow the ZIP file to remain attached to TestRail’s automated email, and they won’t Whitelist @testrail.com / @testrail.net to keep it from being stripped. Not strictly because of the ZIP attachment, but because in addition to the HTML files in the attached ZIP there are also two .js Java files and these files are considered executable. Because of the number of java scripts out in the wild that are malicious, there is a mandate from our IT and eSecurity group that absolutely none be delivered via Seagate’s email system. As a result, they will not bypass this security measure for me or TestRail despite my pleas.

I am at an impasse. I need to send Daily Progress Reports for an average of 6 test projects to dozens of people every day, most of whom are senior execs without access to TestRail (nor do they desire it). The automated reporting capability of TestRail is currently useless to me, and doing this manually will take at least an hour of my time every morning, something I can ill afford. If I can’t figure something out I may have to look into alternatives to TestRail.

Regards,
Kris


#86

Hello Kris,

Thanks a lot for the additional feedback! I understand that it’s more difficult to use the attached report ZIP files if your IT team is blocking the JavaScript files. The main issue is that it would be difficult for TestRail to generate PDF files for the reports, as the reports include rich charts and other information that would be difficult to render in a PDF file. Web browsers can generate a PDF file from the view, as they know how to run JavaScript and render the reports. Based on your description I think the following options would be the best alternatives for your scenario at the moment:

  • Instead of sending the reports as attachment files, you could send a link to the report instead; this would require a login to TestRail and would also make links in the reports more useful; I understand that you prefer not to invite some of the users to TestRail, but it would make it much easier for you to share reports

  • You could alternatively also ask your IT team if they could at least allow one email address to receive the reports and e.g. have a script automatically put the HTML reports on a web server; you could then provide a link to the report to non-TestRail users; the JavaScript files are the pretty much the same in the ZIP file as in TestRail, e.g. to render the charts, so there would be no security difference. Please note that the files are JavaScript files, not Java files, so there might be a misunderstanding your IT team has

I hope this helps!


#87

Please add my Vote! to this PDF request as a format option for scheduled reports


#88

Thanks for your feedback, Alex!

Cheers,
Tobias


#89

Please +1 vote for this feature. We have lots of administrative staff that don`t have the time nor the willingness to login into testrail or even worse to save, unzip and open the html file.


#90

Thanks for your feedback, Pierre!

Cheers,
Tobias


#91

Hi Tobias,

The issue of .js attachments and security has just gotten more serious and complicated for me and my company. Last month, I was able to convince our corporate IT security to allow TestRail emails with .js attachments through our system to the non-TestRail user report recipients. While people did continue to grumble about the clumsiness of having to save a ZIP attachment and then launch an index.html file to see the report, we at least had the mechanism working as a (hopefully) stop-gap until you can provide the much-asked for improvement of supplying the report either in PDF format or HTML embedded in the email itself.

We’re now faced with a new challenge. Starting this month, Google (GMail) is blocking all emails with .js attachments. This means the TestRail emails aren’t even reaching our corporate servers…they’re being blocked at Google. We noticed this Monday…no reports (with attachments) are reaching my executive staff. Google has refused to allow an exception for us.

What options (other than “program custom APIs for yourself”) can you provide me and other customers who are now seriously impacted by being unable to utilize your test report attachment feature?

Thank you,
Kris


#92

Hello Kris,

Thanks for the feedback! We are happy to look into options to make the JavaScript files optional, but the reports wouldn’t be very useful without JavaScript files, as all the charts etc. require this. TestRail wouldn’t really be able to generate full PDF files for the reports easily. The problem is that we don’t have any influence on how email servers behave and even if we changed the JavaScript to something else, Google might still block HTML or even ZIP files at some point, so only the Google support team would be able to resolve this for your account.

Our recommendation would still be the same to send emails with links to the report instead of sending the attachments. The links would also make it much easier to open the reports, as it’s just a single click and using the links instead of attachments has various advantages, including better email delivery with stricter email servers.

Regards,
Dennis


#93

Hi Dennis,

I wasn’t asking about making the .js optional - I was asking about getting reports without the need to rely on .js or possibly even attachments. Why can’t the reports be embedded in the email itself without attachments? Many other web based tools can do this. Most of the people that would utilize this function, I think, would be perfectly happy with static reports indicating progress/metrics and don’t need the report to be “live” with functional links that dig deep into details.

Your recommendation to still send emails with links instead of attachments is, in a word, frustrating. You’re basically saying “pay us more money to utilize a reporting feature that you can no longer use”. Using links to online reports requires a consumption of a license, of course. I’ve got 30 execs and management people who do not want or need access to TestRail but do need automated daily progress reports. As clumsy as the ZIP attachment is (and it’s not just “a single click”…you save it locally, extract it locally, navigate to the saved folder, and then “single click”), it at least was working before Google/Gmail did the same thing my local IT did at first…shutdown and block .js due to security concerns. Now you’re suggesting I spend upwards of $200-$300/month addition in order to consume licenses for a reporting feature that I was previously using in-box.

Even if I decided to spend the money and consume the licenses, I wouldn’t want to as reading the reports online exposes the entire project (read-only) to the recipients in even it’s most basic user / access role.

We chose TestRail for it’s out-of-box features and hands-off cloud hosting. If I’ve got to spend more money either on licenses or hiring someone to author APIs for us to utilize something that worked for us previously, TestRail’s value becomes less and less to me and my company.

Kris


#94

Hi Kris,

We are happy to look into other options as well, but we also already considered inline email reports, which technically just wouldn’t work with today’s email clients. E.g. a few years ago Outlook removed even basic HTML support when they switched to the Word rendering engine, so reports that would work across a large number of email clients just wouldn’t be that useful. But we will review this and see if we can eventually add ‘lite’ reports for this, but they could likely not include more than basic tables. The best way to access the reports would still include directly accessing them in TestRail, but we will make sure to review other options. You can also generate full PDF files with your web browser from the print views and email PDF files if you don’t want to provide access to TestRail.

Regards,
Dennis


#95

Hi Dennis,

Thank you for your considerations. “Lite” reports would be just fine (basic metrics/pie chart and burn down chart), at least for our situations. While I do know I could produce my own PDFs via print functions in my web browser (which I often do when I need to produce copies of our test plans for our OEM partners), that negates the benefit of TestRail providing automated daily emailing of test progress reports to stakeholders. Otherwise, I have to spend time manually produce the PDF and sending it out to an email list each day. Who’s got time for that? :slight_smile:

I’m looking forward to seeing what options you guys come up with.

Thanx,
Kris


#96

Another vote for reports being sent as PDFs. We won’t buy until it does. Sorry guys.


#97

Thanks for your feedback, I’ve added your vote!

Regards,
Marco


#98

It’s been a couple of months since the above quote from Dennis was posted. Any progress on alternative options for automated email BASIC reports (non-linked charts/graphs and raw pass/fail/progress metrics)? With Google blocking TestRail report emails due to the inclusion of Java code, we continue to not have what was once a basic function/feature of the product. TestRail is taking a beating internally at my company and I’m afraid I’ll soon lose capital expense support for it come renewal time.

Kris


#99

Hi Kris,

Thank you for the follow up post. We are still working on implementing new functionality to help with this. I would recommend keeping an eye out on our blog for new release information:

https://blog.gurock.com/tag/testrail-release/


#100

Another vote for this feature! We had a lot of struggles to get the budget for Test Rail and now everyone from the management is complaining about having to do more that one click to open the report! On the other hand, the HTML file is hardly readable (screenshot provided) - do other encounter the same issue?