27th of March, 2018
Download the latest version of Structure and its Extensions
Try It: Structure Sandbox Server (no installation required)
Changes in Detail
The Structure Automation feature is very powerful, and very flexible. It gives the user the building blocks – generators – for constructing dynamic structures. As with any powerful and flexible feature, it's possible to unintentionally create an unanticipated load on the Jira server. The Automation Timeout is a safeguard that protects Jira from unintended server loads.
Some generators already have a considerable level of protection. For example, JQL Inserter offers an option to limit the maximum number of issues it adds to a structure. Extenders have a maximum number of levels to expand a hierarchy. Automation Timeout adds universal protection on top of that by limiting the amount of time Structure app can spend generating a particular structure.
Here's how it works.
When Structure app detects that a structure is being generated for an unreasonably long time (by default, 30 seconds), it pauses Automation for that structure. The Structure panel will show the "Automation was paused" message and the structure itself will miss the generated content. If the structure contains only dynamic elements, it will appear empty.
If the user clicks "More" link, they can inspect which generators took most of the time.
Any user who can view the structure can resume Automation by clicking Resume button. This will cause Structure to try and generate this structure again.
Documentation: Paused Automation
Inline Status Editing
It is now possible to edit an issue's Status inline by double-clicking on its current status in the Status column.
You can then select a new status from a list. The list will show only the statuses that could be the issue's next status, according to the workflow. If a particular transition includes a screen with additional fields, this transition cannot be executed through inline editing and will require the use of Jira Actions.
Documentation: Editing Issues
Notable Fixes and Improvements
Structure 4.6 and all extensions support Jira versions from 7.2 to 7.8. All editions of Jira (Jira Core, Jira Software, Jira Service Desk) are supported. Jira Data Center is supported.
With respect to other add-ons and custom integrations, this release is backwards-compatible with Structure 3.4–4.5. Structure.Testy extension, Colors, Structure.Gantt and integrations with third-party apps should continue working normally.
Installation and Upgrade
If your Jira server does not have Structure yet, the installation is simple:
Upgrade procedure from versions 3.x–4.5 is simple:
Enterprise Deployment Notes
Structure 4.6 has a number of changes that are particularly important for large installations and Jira Data Center instances.
One of the problems we've seen in the past is that one or more improperly configured structures would take a lot of time to generate, consuming system resources. In extreme and rare occasions, system load could make entire Jira instance unresponsive. To prevent that from happening, we're introducing a time limit for structure generation. If a structure takes longer time to get generated, it will be marked as "paused", and all generators in it will be temporarily disabled.
The default timeout is 30 seconds. If some of your structures currently take a long time to generate, they might get paused after the upgrade.
Therefore, we advise you to carfeully check your all of your bigger and mission-critical structures in a staging environment before upgrading and adjust the timeouts as necessary. The structures with paused automation will be marked as such on the Manage Structures page.
The timeouts can be adjusted for each structure using "Configure" link on the Manage Structure page. The global default can be adjusted in the Administration | Structure | Defaults menu section.
Synchronizers on Jira Data Center
Structure uses only one cluster node to run synchronizers. We've seen some problems with the mechanism used to select a cluster node for running synchronization and hand off its work to a different node in case the original node is stopped or loses connectivity. These problems could cause all synchronizers in the system to stop working.
In this version we're introducing a simpler and more reliable mechanism which uses conditional database updates and Jira's built-in node aliveness checks. A new database table, AO_8BAD1B_ATOMIC_FLAG, is introduced to support the new solution. In this version, it is expected to contain only a single row that shows which node is currently responsible for running synchronizers.
You can use the following steps to test syncronization node selection and hand-off:
Lucene Index Monitoring
Structure relies on the Lucene index to check users' access to issues, or quickly read a single value for a large number of issues. The index may be temporarily inconsistent during full or project reindexing, index replication or recovery. Structure 4.2 introduced re-index monitoring as a part of a dark feature used to work around a race condition in Jira Data Center. We've updated this mechanism in Structure 4.6 to also handle index replication and automatic recovery, and now we're enabling it for all instances, so that Structure is able to recover when it detects massive index changes.
After the upgrade, a new, undeletable system custom field called "Structure Index Monitor" should appear. This field is used only to track the "reindex" events. It does not contain any data and will not have any effect on issues. If Structure is uninstalled, this custom field disappears.
Old Row Manager Implementation Removed
Structure 3.4 introduced a new implementation of one of its core components used to store temporary rows in the generated structures. The old implementation remained in the code with the ability to switch to it by setting a system property. In over a year since that release the new implementation has proven to be reliable, and we never advised our customers to switch to the old one. In Structure 4.6 we remove the old implementation and its dependencies completely.
If you see folders named rows0, rows1, etc., under JIRA_HOME/structure folder, they can be safely deleted – they were a part of the older implementation.
Testing on Staging Environment
There are no particular special areas of interest for load testing and stress testing Structure 4.6. We advise running the same testing procedures as you've done for previous upgrades.