Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

Checking Data on the KPI Dashboard

  1. Once Jira processor is successfully run, click on image-20240805-101855.png to go to the KPI dashboards

  2. You can access different Jira KPIs across dashboards

    image-20240805-102046.png

Managing Jira Field Mappings

Jira Field Mappings

Description

Steps

Image Reference

Default settings

default field mappings are associated with the Standard Jira configuration template while setting up Jira.
These metadata identifiers are prepopulated when you click on 'Settings'

  1. Click on image-20240805-103341.png to land on KPI dashboard

  2. Click on 'Settings' on each KPI widget

Custom KPI level settings

override the default mappings by customizing them manually.

  1. Click on 'Settings' on each KPI widget

image-20240805-101201.png

Global Jira mappings

Mappings that are global and apply across dashboards.

  1. Additional Filter Identifier

  2. Custom Fields Mapping

  3. Defects Mapping

  4. Issue Types Mapping

  5. Workflow Status Mapping

  1. Go to ‘Projects’ list and search your project

  2. Click on image-20240805-105640.png to edit configuration

  3. Click on 'Mappings'

    image-20240805-105738.png

  4. Expand each section to edit and save the mappings

image-20240805-105950.png

Things to Remember

When modifications are made to the field mapping, certain fields require the processor to be re-run to implement the changes effectively. Specifically, when we add or remove any mapping, such fields require the processor to be rerun

  1. Global mappings: Any modifications to the global field mappings in a Jira or Azure Board configuration require the processor to be re-run.

  2. KPI-level mappings: A few KPI-level mappings that require processor rerun are marked in the Settings.

  3. For any other changes to the mappings, simply refreshing the dashboard is sufficient to apply the updates.

Note: This applies only to Jira and Azure Board.

1. Custom Fields Mapping:

The changes that we make in the custom field mappings requires the data to be fetched again from the Jira board or azure board, for that we need to re-run the processor.

This will be applicable for all the fields in the custom field mapping.

2.Defect Mapping:

The changes that we make in the defect mappings requires the data to be fetched again from the Jira board or azure board, for that we need to re-run the processor.

In the defect mapping this will be applicable for UAT defect values, production defect values.

3.Additional Filters Mapping:

The changes that we make in the additional filters mappings requires the data to be fetched again from the Jira board or azure board, for that we need to re-run the processor.

This will be applicable for only squads.

For any type in the squad we need to re-run the processor.

4.Issue Types Mapping:

Kanban:

The changes that we make in the Issue type names under Issue types mapping requires the data to be fetched again from the Jira board or azure board, for that we need to re-run the processor.

Scrum:

The changes that we make in the Issue types to be fetched from Jira requires the data to be fetched again from the Jira board or azure board, for that we need to re-run the processor.

Apart from the above mappings, for any other change in the mappings refreshing the dashboard is enough to affect the mappings.

  • No labels

© 2022 Publicis Sapient. All rights reserved.