FAQ

In this page

General

Why is feature X missing in the Cloud version of the app?

It is important to understand that, although we do everything we practically can to reach that, there is no 100% feature parity between the various hosting types of the app. For example, the Cloud version may not have a feature which the Server version has and vice versa.

Why? This is primarily the consequence of the radically different technical environments in which the different deployment types are operated.

The Server and Data Center versions of the app are both being executed in the same Java Virtual Machine as their host application (Jira). Therefore, the app has access to the public and even to the internal Jira APIs, and can approach problems in creative ways. Due to their similarity, it is possible to offer the same exact end-user feature set for Server and Data Center. (The "only" difference is that the Data Center version comes with clustering capabilities for High Availability.)

Cloud as a hosting type is very different.

Jira Cloud apps integrate with Jira using the technology called Atlassian Connect. Atlassian Connect is a powerful and continuously evolving technology, but it also has certain limitations. Most typically, if the Jira REST API (which is the backbone of Atlassian Connect) does not expose some information that is otherwise available for Server/Data Center apps, then the Cloud version of the app will not able to implement the features that rely on that information.

Unfortunately, these kind of limitations cannot be worked around by the app. The missing feature can be added only after Atlassian has removed the limitation in the Atlassian Connect side.

What to do with missing features?

First off, limitations are not "static". We look at these as temporary short-comings that we can add as soon as Atlassian removes the "road-block" which is the originating cause for it.

For that, we already reported the originating cause of each limitation to Atlassian, and those are available as public Jira issues.

If you miss a feature, you can indicate your interest for Atlassian by:

1. Opening the corresponding issue we reported to Atlassian. (See the table below.)
2. Login to the Atlassian Jira (otherwise cannot do the next two steps).
3. Vote for the issue.
4. Add a comment to the issue with your use case.

This way the issue will gather more interest, and Atlassian will (hopefully) prioritize it for a faster resolution.

Known limitations in Better PDF Exporter for Jira Cloud

The table below summarizes the known limitations, their originating cause and where to go to indicate your interest in resolving it.

Why do the version numbers differ in the Version History page and in UPM?

Rather confusingly, there are two types of version numbers used with the app:

1. Atlassian-assigned version numbers
   In cloud, Atlassian operates an automatic polling service which assigns a new version number to an app when it detects a change in the app. The app vendor doesn't have control over the new version number generated by this service. This is the version number you can see in the Atlassian Marketplace listing of the app and also in UPM (the app manager built in to Jira).
2. Midori-assigned version numbers
   At the same time, Midori maintains its own version numbers for the app. These are semantic version numbers we manually assign and which convey meaning about the "size" of the change and the risk associated with the change. (We also need these because we want to keep track of the upgradable resources, templates and scripts, shipped with the various app versions.) This is the version number you can see in our own version history.

We know that this "dual" versioning is confusing, but it is inevitable at the moment, unfortunately.

The rule of thumb is that when you see an upgrade guide, blog post, documentation page, other type of Midori-written material, it uses the Midori-assigned version numbers. In that sense, these are the "primary" and "relevant" version numbers. Atlassian-assigned version numbers are used only in Atlassian managed interfaces (typically, in the UPM interface).

How can I know if I'm using the latest app version?

Basically, you are always using the latest app code. When we deploy a new app version to production, it will be available for everyone without any further effort.

The question is rather if you approved the new version in the UPM and if you updated the changed resources (templates and scripts)? Please read on for details.

How can I update the app version?

New app versions may introduce certain changes that require manual approval from the Jira administrator. These include changes in the way how the app integrates to the Jira user interface (e.g. the new version wants to add itself to a new screen or menu) or changes in the permissions required by the app (e.g. the new version needs to read or write some information previous versions didn't need). Note that these changes are rather infrequent.

The more frequent change is when the new version introduces changes to the resources (templates and scripts). On the contrary to the automatic app code updates, templates are never updated automatically. It is because if the old version contained customizations, that'd be lost during an automatic update. Therefore, some semi-manual work needed for a proper and reliable resource update.

To help with it, the app detects if there are updated resources in the new app version. If so, it will show a small message for every user to encourage him to contact the Jira admin. As only the Jira admin can manage the resources, only he can execute the steps of the upgrade guide which typically include uploading the changed resource versions. After he confirms that he completed the update, the popup will disappear.

There are two basic scenarios:

• If there are no customizations made to the views and the templates, in other words if everything is in its factory-default state, you can simply reset the views and reset the resources. It will guarantee that they will be reset to their latest versions and you have an uptodate system.
• If there are customizations made, follow the upgrade guide written for the corresponding version precisely. (We always write and test these very carefully.)

Questions?

Ask us any time.