2.0.11 Release Notes

Created by Mike Harrison
Last updated: Jun 27, 2017
4 min read

Summary

This release of JEMH contains several significant changes as part of our restructuring of configuration profiles to a more flexible Project Mapping-based model.  The majority of the changes made in this version are related to custom field defaults.  The most notable addition is the new and improved custom field default system (see here for usage guide).



Custom Field Defaults

A new custom field default system is now in place for project mappings.  This brings several benefits:

  • the hard limit of 3 custom field defaults per project mapping level is removed - you can now add as many as you need

  • administrators can easily see what defaults are inherited from the default or parent mapping and override as necessary

  • easier to add/edit custom field defaults - a list of valid custom fields for the current mapping are shown (no guess work required!)

  • smarter custom field auto-creation on profile import (for profiles exported in 2.0.11 or newer)

For more information on using the new custom default system, please read this wiki article.





Details of changes

In order to future-proof your existing JEMH configuration profiles, some automatic changes will be made to them.  JEMH will output the changes it makes to its log file, so it is a good idea to have JEMH's logging enabled beforehand as per this wiki article: Enabling JEMH logging.

Fall-back project attributes (project, component, issue type) are now deprecated

The fall-back attributes will be migrated to the profiles default project mapping if the project referred exists:

  • Fall-back Project will become the default project mapping's selected Project

  • Fall-back Component will become selected on the default project mapping

  • Fall-back Issue Type will become the default project mapping's selected Issue Type

Note that if a default project mapping does not exist, then JEMH will create one and move the previously mentioned settings.

After upgrading, importing a profile from a previous version will result in any legacy configuration being migrated as per the above criteria.









Example log output
Since JEMH 2.0.11: Migrating project fallbacks (project/issueType/component) and profile level Custom Field Defaults into Default Project Mapping. Also migrating static mapping custom field defaults Applying changes for profile 48 [profile1] ---------- Pre-existing default project mapping found with project key [DEF] Set default mapping project key to fall-back project key [FAL] and removed fall-back project key Set default mapping issue type to fall-back issue type [Bug] and removed fall-back issue type Migrating custom field default for field [Not In SOF project scope] from profile level to default project mapping [FAL] Profile default [name=ValidForService, value=this is not valid for default mapping project] NOT migrated as matching field(s) not valid for project [FAL] Migrating custom field default for field [ValidForAllProjects] from profile level to default project mapping [FAL] Profile default [name=customfield_10014, value=id not name] NOT migrated as matching field(s) not valid for project [FAL] Migrating custom field default for field [TextField2] from mapping [FAL] Mapping default [name=ValidForService, value=not valid for default mapping, mapping=FAL] NOT migrated as matching field(s) not valid for project [FAL] Mapping default [name=ValidForService, value=only for service project, mapping=SOF] NOT migrated as matching field(s) not valid for project [SOF] Migrating custom field default for field [TextField3] from mapping [SOF] Migrating custom field default for field [TextField1] from mapping [SOF] (rule id #47) Mapping default [name=ValidForService, value=only for service mapping rule, mapping=SOF, rule=47] NOT migrated as matching field(s) not valid for project [SOF]





Profile level custom field defaults have been removed

Custom field defaults located at the top profile level are being migrated to the default project mapping.  In order to be successfully migrated, the custom field that a default refers to must:

  • be found to exist in JIRA via a name/system ID match

  • have the default project mapping's project (if it has one) in its context (see here for more information)

The old configuration section will no longer be visible on the profile configuration screen.  In addition, it will no longer be part of the JEMH profile export.

After upgrading, importing a profile from a previous version will result in any legacy configuration being migrated as per the above criteria.

Legacy project mapping custom field defaults have been removed

The three custom field default slots on each project mapping level are now removed.  In order to be successfully migrated, the custom field that a default refers to must:

  • be found to exist in JIRA via a name/system ID match

  • have the corresponding project mapping's project (if it has one) in its context (see here for more information)