.png%3Falt%3Dmedia%26token%3D303d21c4-bfd2-4778-a50a-1bb043b0732e){kind=icon}
.png%3Falt%3Dmedia%26token%3D303d21c4-bfd2-4778-a50a-1bb043b0732e){kind=icon}
Finalizing the migration in Cloud
As previously stated there are certain configurations that the migration tool cannot move from the On-prem version of the application to the Cloud version.
These need to be finalized manually by the user, and this document aims to share the details on what needs to be done.
If any of the migrated Outgoing Mail Connections uses the OAuth2 method for authentication, they should be authorized before usage.
- Before you authorize replace the redirect URI (The value is always the following: https://jeti.addon.meta-inf.hu/admin/oauth2/callback) at your email provider. For more details visit the documentation depending on your provider Google or Microsoft.
- To authorize, open the connection, then click on Authorization and follow the steps on your email provider site. You can find the connecting documentation here.
Authorizing an Outgoing Mail Connection
If any of the migrated Incoming Mail Connections uses the OAuth2 method for authentication, they should be authorized before usage.
- Before you authorize replace the redirect URI (The value is always the following: https://jeti.addon.meta-inf.hu/admin/oauth2/callback) at your email provider. For more details visit the documentation depending on your provider Google or Microsoft.
- To authorize, open the connection, then click on Authorization and follow the steps on your email provider site. You can find the connecting documentation here.
Authorizing an Incoming Mail Connection
The migrated mail handlers do not contain any actions, due to severe differences in handler functions between the Email This Issue Cloud and On-premise instances. They are, therefore, created as a basic Cloud mail handler and they are using the migrated Incoming Mail Connections.
The Cloud mail handlers have four tabs:
- General handler settings
- Filters
- Find issue
- Rules and actions
The General handler settings are by default filled with values during the migration, all they need is a check from the administrator.
Filter Emails comparison
The below table shows the email filtering options both in On-premise and in Cloud versions:
On-premise option | Cloud option | Migration status |
|---|---|---|
Bulk emails | Filter out bulk emails | FULL MIGRATION |
Delivery status notification emails | Filter out delivery status notifications | FULL MIGRATION |
Auto-submitted | Filter out auto-reply emails | FULL MIGRATION |
Large emails | - | NOT AVAILABLE |
Emails sent from this Jira system | Filter out emails sent from Jira | FULL MIGRATION |
Emails sent from other Jira system | Filter out emails sent from Jira | FULL MIGRATION |
Emails sent from unknown addresses | - | NOT AVAILABLE |
Emails by recipient address | Accept email if any recipient equals... | NEEDS MANUAL SETUP |
Emails by email attribute | - | NOT AVAILABLE |
Emails by sender address | NEEDS MANUAL SETUP |
Find Issues for Email
The below table shows the email filtering options both in On-premise and in Cloud versions
On-premise option | Cloud option | Migration status |
|---|---|---|
Find issues by issues key appearing in the email subject | Default issue lookup (no option for enabling/disabling) | FULL MIGRATION |
Find issues by references in email headers | Enable issue lookup by mail headers | FULL MIGRATION |
Find issue by JQL | Enable issue lookup by JQL | JQL NEEDS TO BE EDITED MANUALLY |
You are required to open each Mail Handler, and build up the complete Rules and actions secion from scratch manually. You can find the documentation on how to do so here.
Depending on the complexity of the migrated templates they may not be working correctly. Please test each template and make the necessary corrections before using them.
- 1.Check out the differences between Cloud and on-premise velocity macros on the below document pages: - On-premise documentation - Cloud documentation
- 2.Check all Jira related identifiers: - Project key / ID - Issue type / ID - Field / custom field ID - User name / ID - Group name / ID - Roles
Editing templates on the Cloud
This step is necessary if the migration contained any Advanced Email Configurations (It is a mix of the General Configuration and the Context on the On-prem platforms).
For more information, please refer to the Advanced Email Configuration documentation.
- Check that the correct Outgoing Mail Connection is selected
- Correct the JQL filter if needed
- Make sure that your Reply/Forward template is correct (other template options may be found in the Manual Email Defaults)
- Check the order field
Places where the Recipients are used:
- Manual Email Configuration recipients
- Notification Event recipients
- Recipient Restrictions
Recipients in the application may take up different input forms. These can be:
- Users
- Email addresses
- Roles
- Groups
- Custom fields
- Other special fields (eg. Reporter, Assignee, Watchers, etc)
If for some reason a value is not migrated by Jira, it cannot be resolved by Email This Issue. You have to check recipients in the settings and fix them manually after the migration process if needed.
Some examples for why the values would not be migrated:
- You are migrating selected projects and project-related users. If you refer to a Role as a recipient, but the project does not have any members in that role, then the role is not migrated and will be missing from the recipients.
- You are migrating selected projects and project-related groups. If you refer to a Group as a recipient, but the project does not have any members in that group, then the group is not migrated and will be missing from the recipients.
- If a custom field is not used on any issues, it is not migrated.
If you have a Manual Email Configuration migrated, correct the JQL filter if needed.
If you have a Notification configured to use any of the following attachment settings:
- Added in the last operation or
- Attachments from attachment selector field
they have been migrated as None since these options are not availbe in the Cloud. If you have a different option selected, please update this part of the configuration.
Also correct the JQL filter if needed.
The list of supported events are different on the On-Prem and on the Cloud versions of our product. Here you can see a comparison of supported events and how they are mapped:
Server | Cloud |
|---|---|
Default Event | Not Supported |
Issue Archived | Not Supported |
Issue Restored | Not Supported |
Request Created | Issue Created |
Request Updated | Issue Updated |
Request Resolved | Issue Resolved |
Request Reopened | Issue Reopened |
Customer Visible Status Changed | Not Supported |
When you are done with finalizing your settings on your Cloud instance, disable data migration in Email This Issue Administration - Migration options.
As the workflow postfunctions are not migrated at all please follow the manual migrations steps detailed at Migrating Post Functions if you have any on the server side.
Last modified 11mo ago