- I am app developer, We are having the server and cloud app for HTML but in cloud due to conflict with the native App we are requested to change the macro name to html-bobswift.
- In order to support for our server customers on the migration front we need to change our macro name in server where it is html to html-bobswift and we need to keep the existing pages to work.
- Please guide us better solution for our requirement and let me know if you need any additional details to support this.
We would like to rename macro before the migration and migrate all the references of the macro to cloud
We faced a similar issue with one of our plugins.
You would need to run some SQL queries to update the macro name in the database.
If you want a reference, Our SQL file is available on this FAQ page.
Feel free to let me know if you need any help.
Thanks John for the suggestion and inputs.
I think with this approach existing pages on the server will not work as we are changing the storage format through DB.
We are looking at the Customisation of the Listener which needs to trigger while the Migration Assistant kick start and existing pages should work as is in the server front after the migration as well as the migration is might happen at multiple times.
Few references we are looking are :
Using: atlassian-app-cloud-migration dependancy
- Reference from Atlassian as sample: https://bitbucket.org/atlassian/confluence-roadmap-plugin/pull-requests/110/
We were made some progress with second option but not through plugin upgrade listener. But through manual intervention in the configuration screen.
So, now we are looking at the option:1 how we can trigger only at the migration time and the previous pages should work as is.
The existing pages will work if you update the server instance with a custom build of the plugin with the cloud macro name and then migrate the instance to cloud.
I am not clear what is mean by custom build of the plugin ?
An unreleased & modified version of the plugin where the macro name is changed to the cloud macro name.
It can be installed by uploading the jar file.
The plugin listener isn’t really designed to post-process pages because it’s designed to provide you with a mechanism to upload any specific data to your service, e.g. global configuration.
One option is an upgrade task on the plugin to change the storage format, however this will generate a page edit and entry in history for each page.
If you modify the
bodycontent table directly the end user won’t have any auditing of the change.
Otherwise, I think you’re looking at providing a button to allow the admin to start the upgrade themselves, which would have the same effect as the upgrade task, I’d expect.
Please understand that the App Migration code at this time is at Proof of Concept, and not production level. The APIs may change, so if you need a solution now, please continue to look at the upgrade or manual task.