| Table of Contents | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
1. Update permissions
After migrating, you will need to review all your permissions schemes.
In default Cloud permission schemes apps are granted all required permissions to project role atlassian-addons-project-access, The Scheduler requires to add this role atlassian-addons-project-access to all permissions otherwise app may not work properly.
(Remember to verify our app permissions Permissions )
...
.png?version=3&modificationDate=1714975922494&cacheVersion=1&api=v2&width=362)
.png?version=1&modificationDate=1714975911698&cacheVersion=1&api=v2&width=388)
It is equally important that the administrator adds users to the appropriate groups (Settings → Atlassian Admin → User Management) . These groups are created automatically when the migration is complete, and without assigning users to them, the Scheduled Issues will not execute correctly.
| Info |
|---|
If the Administrator does not assign users to the appropriate groups before executing Scheduled Issues, all SIs with a status of Failed will need to be edited after rights have been granted. It is important to reassign the migrated users, only then will the SIs be active. |
.png?version=1&modificationDate=1714978704672&cacheVersion=1&api=v2&width=362)
2. What can look different
2.1 Mentioned users formatting
When eg. in description of The Scheduled issue you mentioned user:
after migration at cloud side it will have different format:
2.2 Text formatting
Text decorators like italic, bold, underline or applying color on server side like:
after migration to cloud will look:
2.3 Scheduled issues states
Due to fact that not everything is migrated, states of the Scheduled Issues will be mapped after migration according to following rules:
Invalid → Disabled
Active → Active
Inactive → Disabled
Skipping → Skipping
Calendar day off → Active
Pending → Active
Expired → Expired
2.4 Scheduled Issues with multiple triggers
Due to the fact that the Cloud version of the app doesn't support multiple triggers, when Scheduled Issue with multiple trigger is migrated from Server / DC, it needs to split. It ensure that all planned executions are covered.
Exemplary Scheduled Issue with multiple triggers in Server:
after migration to Cloud it is split:
Please note that when trigger is not supported in Cloud (eg. workflow trigger) it will not be migrated as in the example above.