| Table of Contents |
|---|
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 most notable addition is the new and improved custom field default system. The majority of the changes made in this version are related to custom field defaults.
Custom Field Defaults
A new custom field default system is now in place for project mappings. This has brings several benefits over the old system:
- 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)
| Tip |
|---|
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: Installation, Setup and Logging.
Fall-back project attributes (project, component, issue type) are now deprecated
The following settings found under Profile>Project are fall-back attributes will be migrated to the profiles default project mapping if they are validthe 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
If Note that if a default project mapping does not exist, then JEMH will create one and move the previously mentioned settings (if the project is valid).
| Info |
|---|
After upgrading, importing a profile from a previous version will result in any legacy configuration being migrated as per the above criteria. |
Profile level custom field defaults have been removed
Custom field defaults located at the top profile level are being phased outmigrated to the default project mapping. When upgrading to 2.0.11, any valid custom field defaults found here will be moved to 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, its configuration it will no longer be part of the JEMH profile export - please make use of custom field defaults in a default project mapping instead. Importing an older profile that uses this legacy section will result in that configuration being updated as per the new standards.
| Info |
|---|
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 gone. During the upgrade process, JEMH will migrate these to the new system, but only if the following conditions are met:
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)
| Info |
|---|
After upgrading, importing a profile from a previous version will result in any legacy configuration being migrated as per the above criteria. |
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
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] |