Overview

The Import Approval Data functionality allows to import Approval Data saved into the file ApprovalDataExport.zip file. into the current Jira instance.

The sys admin will be able to replace the existing configuration or merge them with the one that already exist.

The capability to import Approval Data includes all data except the following:

• Herzum Approval History
• Herzum Approval Approval Configuration for Single Issue
• Pending approval requests
• Herzum Approval Mail handler
• Herzum Approval Services
• Herzum Approval Validators
• Herzum Approval Post Functions

Import Options

You are able to import the whole Approval Database or a part of it.

The Import form allows to un-check the following option in order to exclude them form the import:

• Global Configuration

• Language Packs

• Approval Configurations

 Notice that on importing the Global Configuration data  will replace the existing data on the target instance.

 Notice that on importing the Language Packs data will replace the existing data on the target instance.

 Notice that on importing the Approval Configurations data will be added to the existing setting on the target instance. 

If you need to replace existing Approval Configurations data, ensure to Delete Approval Data before to perform the import.

Import Procedure 

On clicking the Import Data button, the app, first, check if any referenced Jira entities is missing and if any data duplication may occur by following the import. If any inconsistency is detected, the import aborts.

 We recommend to perform the Import Conflicts Analyzer before to run an import recovery in order to have a detailed view of the referenced  Jira entities and missing consistencies with that. 

If the check is successful, you will be prompt with the request to proceed with the import.

On clicking Proceed with the Import, the app performs the following operations

• delete any dirty data (tuples having  Export status = Draft), if any
• insert Approval Data on the database (exception made for the Config table that is updated:
  • for each xml file, the App search for:
    • the Id or Key of the referenced Jira entity
    • the Id of the referenced Approval entity if any
    • save the tuple into the destination table and set the value Draft on the Export status field
    • add a tuple that that maps the original tuple Id and the new tuple ID into the Entity Id Mapping table

 The xml files are processed so that on inserting the new tuples any existing foreign key is valid.

When all the xml files have been successfully processed, the app performs the following operations

• retrieve the current date and
• update the Export status field with  with a timestamp that consist in the Approval Data Import Date (it is the current date).
• delete all tuples form the table that maps the original tuple Id and the new tuple ID for each entity

If any xml files has Not  been successfully processed, the app performs the following operations:

• for each imported table, any tuple having the Export status set to Draft will be deleted.

 If the process aborts before to complete the deletion successfully, these dirty data can be deleted by performing an Approval Recovery .

 When running an Approvals Check integrity or a Recovery, the Approval Mapping having Export Status Draft are not considered  in order to check or make the issue approval tuples consistent with the configurations.

If the process completes successfully you are prompt with a message that inform and asks to perform the Approval Recovery. 

The 'Approval Recovery' link redirects to the following page:

Database Changes

Export status field

Any table (exception made for Issue Approvals and Approval History ) will have a new field EXPORT_STATUS that can be “” , “Draft” or a timestamp representing the import date.

The Export Status field allows to ensure that it is possible to revert the import if the process doesn't complete successfully. 

If data having status Draft exist, these data will be deleted before to start a new import or by performing an Approval Recovery. 

Entity Id Mapping table

A new table maintains the mapping between the Old tuple Id and the new tuple ID for each entity.

Insert Approval Data on the database by example

Import into Table: AO_D195E9_CONDITIONAL_RULE

INSERT INTO public."AO_D195E9_CONDITIONAL_RULE"

("CONDITIONAL_NAME", "CONDITIONAL_RULE", "USER_EVALUATOR", EXPORT_STATUS)

VALUES taken from the CONDITIONAL_RULE_XML xml file

• For each new record, maintain a map CONDITIONAL_RULE_MAP between the new CONDITIONAL_RULE.ID and the CONDITIONAL_RULE_XML.ID_EXPORT
• Set Export status = Draft

Import into Table: AO_D195E9_LANGUAGE_PACK

INSERT INTO public."AO_D195E9_LANGUAGE_PACK"

("DESCRIPTION", "ENABLED", "LOCALE", "MODIFIED_DATE", "MODIFIED_USER", "NAME",)

VALUES taken from the LANGUAGE_PACK_XML xml file, 

• For each new record, maintain a map LANGUAGE_PACK_MAP between the new LANGUAGE_PACK.ID and the LANGUAGE_PACK_XML.ID_EXPORT
• Set Export status = Draft

Import into Table: AO_D195E9_LANG_PACK_KEY_VAL

INSERT INTO public."AO_D195E9_LANG_PACK_KEY_VAL"

("LANGUAGE_PACK_ID", "PROPERTY_KEY", "VALUE", ID_EXPORT)

VALUES taken from the LANG_PACK_KEY_VAL_XML xml file by replacing LANG_PACK_KEY_VAL_XML .LANGUAGE_PACK_ID_EXPORT with the LANGUAGE_PACK_MAP.IMPORT_ID

• For each new record, maintain a map LANG_PACK_KEY_VAL_MAP between the new LANG_PACK_KEY_VAL.ID and the LANG_PACK_KEY_VAL_XML.ID_EXPORT
• Set Export status = Draft