Administration
Overview
To enable the use of CM4J, the Jira administrator should perform the following steps:
Become acquainted with the Jira concept of custom field contexts and the functionality offered by CM4J. See Understanding Jira Custom Field Contexts.
Install the plugin.
Enable the custom fields that are to be made available for project administrators through CM4J.
Specify the configuration of each of these fields.
CM4J Installation
As a Jira Administrator, navigate to Administration > Manage apps > Find new apps.
Enter “CM4J” as search criteria.
Select either “Buy Now” or “Free Trial” and confirm the app installation.
Enabling custom fields for CM4J
Usually only a limited number of custom fields should be made available for context configuration by project administrators. The Jira administrator must first determine these fields. This is done by going to Jira Administration > Manage apps > Context Manager for Jira/Configuration.
CM4J supports the following standard Jira custom field types: Checkboxes, Radio Buttons, Select List (multiple choice), Select List (single choice), Select List (cascading), Text Field (multi-line), Text Field (single line).
The list of custom fields in the Jira installation available for CM4J is displayed in a table showing details about the configuration of each field. The fields that are already enabled for CM4J are those having project name(s) in the Enabled Projects column. To enable a field, select Configure and select the desired options in the ensuing dialog. See the next section for a guide to setting these options.
Guide to configuring custom fields for CM4J
The following table provides the standard use cases for CM4J and explains how to configure custom fields to support them.
Use Case | Configuration | Remarks |
|---|---|---|
Every project can have its own project-specific context for a given custom field. |
Other options should be disabled. | This is the simplest way of using CM4J. |
Only some designated projects have their own project-specific context for a given custom field. All other projects use the Default Configuration Scheme. |
Other options should be disabled. | This is a good solution when the Default Configuration Scheme is adequate for most projects, but there are a few projects that need to determine their own context. |
Some projects share a project-specific context for a given custom field and they are able to administer the context by themselves. |
Other options should be disabled. | Unlike individual project contexts, shared contexts cannot be created through CM4J. If a shared context is desired, the Jira administrator must first create it and assign it to the desired projects. Once that is done, the projects can administer it by themselves thanks to this option. It is important that changes in the shared context are aligned in advance with the projects sharing the context. |
Some projects share a project-specific context for a given custom field while other projects have their own project-specific context. |
Other options should be disabled.
| This is similar to the previous case, so the same remarks apply, but it also allows projects to create individual project-specific contexts. With this option, a project using a shared context can opt out of it by creating its own context, at which point it loses the ability to edit the shared context. |
Some trusted projects are allowed to administer the Default Configuration Scheme. |
Other options should be disabled. | This case should be used with extreme caution! The permission should only be granted to projects with a limited number of highly trusted administrators, who understand the impact of changes in the Default Configuration Scheme and align such changes in advance with all projects using the Jira instance. We highly recommend that this use case not be enabled: The permission to configure the Default Configuration Scheme should be limited to Jira administrators. Do not forget that any user with the Project Administration role in a project can grant this role to any other user, and (depending on the Jira configuration) might even be able to grant it to a group that is administered by other people in external applications such as Microsoft Active Directory. This lack of transparency is bound to lead to problems! In any case, if you do enable this option, you should limit the potential problems by not enabling the option “Automatically Enable for all projects”.
|
Migration from project contexts to the Default Configuration Scheme
In case a project-specific or shared context is no longer desired by a project, CM4J provides a tool for the Jira administrator that supports the migration of issues with values other than those provided in the Default Configuration Scheme. To invoke the migration tool, go to Context Manager for Jira in a project using the context and select Migrate to global context. This opens a dialog that shows the issues with values other than those in the default scheme and allows them to be migrated to the values of that scheme. Once the migration is completed, the context should be deleted.