On this page:
|
Test the migration
Of course it is necessary to test that configuration objects are actually moved to a target instance of Jira. At the end of the day, that is what 99% of the users will want the extension to do for them.
...
Verify that the changes displayed match what you expected. They should be the same as those previewed in the simulation. Finally, check the dashboard in Jira and verify that the new gadget has been created with the correct configuration. Make sure the gadget is configured for a new filter, also created by the import, called "Due this week (RR)" and owned by user "admin".
Use the
...
object dependencies report
The Object Dependencies report is a feature of Project Configurator that analyses dependencies between configuration objects in any instance of Jira.
...
| Note |
|---|
The Object Dependencies report includes only those objects that are directly or indirectly used by any of the projects in the instance. This means that the following will not appear: objects that are exclusively used by dashboards, filters, or Agile boards and the relations where any object is used by any dashboard, filter, or Agile board. In general, any object which is not used by any project (like an inactive workflow). |
Pro Tip: Create the extension in two stages
Creating the extension in two stages simplifies both the implementation and the testing.
...
This lets you partially implement the support for some custom entity, test that partial implementation, and later, with the confidence that a substantial part of the extension is already correct, proceed to complete the "create / delete / update" methods.
Use the Jira log if necessary
It is possible to extract a lot of useful information from the Jira log file. If this is required, then set the log level to DEBUG for the package com.awnaba.projectconfigurator. See Change Logging Levels in Jira Server to learn how to temporarily change the log level for specific packages in Jira.
...