JIRA PDF View Plugin 3.3.0 released: support for JEditor and JIRA Agile, better performance, smarter templates

Midori is proud to announce that JIRA PDF View Plugin 3.3.0 is available at Atlassian Marketplace!

New in this release

There are lots of exciting improvements in this release, so prepare for our longest-ever release announcement!

Support for JEditor

This was the single most requested item in our public feature request forum.

From this plugin version, PDF exports will preserve the formatting of all JEditor-rendered fields, including Environment, Description, comments, single- and multi-line text custom fields.

Support for JIRA Agile fields

This version also introduces proper export for the JIRA Agile-specific custom field types, "Sprint" and "Epic”.

It was added to the issue-fo.vm and the issue-navigator-fo.vm templates, so you will need to upgrade the template’s code, as well. Please see the “Upgrading” section below for more details.

Performance improvements for large exports

We also worked hard on making the bulk exports faster. Many users reported that their PDF export requests timed out when trying to bulk-export 800, 1000 or more issues (typically resulting in several hunded page long PDF documents).

With this version, you can export large number of issues 30-40 times faster! What took for long minutes previously, will be completed in 5-20 seconds now.

(This improvement is hardly noticeable for single issue exports, as those were already performing efficiently.)

Revised default template

We added several small, but important features to issue-fo.vm:

  • Subtasks, labels, view restrictions for comments are now exported

  • Support for the Security Level field

  • 2 modes to export custom fields:

    1. The new default mode will export only those custom fields that are visible in the current Issue Details screen configuration. It allows showing, hiding, re-ordering custom fields and grouping them to tabs (which appear as separate sub-sections) in the PDF documents.
      At the same time, we do not export the issue’s field change history when using this mode (you can, as always, easily change it in the template).

    2. The All mode, as its name suggests, exports all custom fields that has non-blank value. Plus, it also exports the field change history.
      Please note that it has been the default behaviour until this version, but the user feedback convinced us to change it. If you want to continue with the old-style behaviour, you can easily do that by setting the $exportAllCustomFields variable to “true”, as written in the “Upgrading” section below.

  • Fixes in international texts: some field names and values were exported in English, even if the user had a different language setting activated. Now fixed!

We also introduced a couple of new configuration variables, in context of the previously listed improvements:

  • $exportAllCustomFields: set to "true" to export all custom fields, or to "false" to export only the visible ones.

  • $excludedCustomFieldIds: comma separated list the ID's of the custom fields to be excluded from the export, e.g.: [10001, 10015].

  • $exportChangeHistory: set to "true" to export the issue field change history.

New tools in the Velocity context

To give more power to template developers, the following new tools are available through the context:

  • $fieldScreenRendererFactory: allows you to obtain field screen renderers, to check which custom fields are added to what screens and tabs.

  • $fieldViewManager: checks whether a custom field is visible for an issue.

  • $workRatio: calculates JIRA's special "work ratio" metric.

  • $dateTimeFormatter: is JIRA's built-in date formatter.

  • $date: supports standard Java date formatting patterns for flexible date formatting.

Please their detailed description in the template development documentation.

New “Getting Started” page

We added a “getting started” page to save some reading for first time evaluators.

As it may be useful even for more experienced users, it can also be visited via the link at Administration Add-Ons  Getting Started (under PDF Views).

Upgrading to this version

Due to all these changes, upgrading is a little more work than upgrading the plugin itself only.


  1. Upgrade the plugin JAR as usual, through the Universal Plugin Manager.

  2. Upgrading the templates: you also need to upgrade your templates to leverage the improvements. For that:

    1. Download the ZIP that contains the latest template files: jira-pdfview-plugin-3.3.0-templates.zip

    2. Extract the ZIP and open the issue-fo.vm template file.

    3. Login to JIRA as administrator, go to Administration Add-Ons  PDF Templates (under PDF Views) and open your current issue-fo.vm file.

    4. If you haven’t made any changes in the original issue-fo.vm file, then just copy-paste the content of the new template (the one you just downloaded) to the editor, save it and you are done.

    5. If you made changes to the original issue-fo.vm, you will need to migrate those to the new template. This should be done by comparing the content your current issue-fo.vm file with the new one, and merging all changes you made in the former to the latter. Use a visual merge tool (like WinMerge or Eclipse’s compare and merge editor), and it should be trivial.

    6. Repeat these upgrade steps also for the issue-navigator-fo.vm template file.

  3. Upgrading the views: the new plugin version has two modes for the default exports, one of them exports only the visible custom fields, while the other exports all those. If you want to have these two separate modes after the upgrade, then:

    1. If you already have a view called “PDF”, then leave it there.

    2. Add a new view, called “PDF (All fields)” which renders the issue-fo.vm template. Explanation: the latest template checks if the view’s name contains the “All” string, and switches to the second mode if it does.

As mentioned previously, the behaviour of the default template has slightly changed. According to the new default, only the visible custom fields will be exported (not everything, as previously). Also, the issue field change history will not be exported. If you want to return to the old behavior, simply set the $exportAllCustomFields and $exportChangeHistory configuration variables in issue-fo.vm to “true”.



Have more questions? Submit a request


Please sign in to leave a comment.