we have a custom field type defined in the manifest, and now want to programmatically create a new custom field based on that type.
To do so, we need to pass the “custom field type” ID as the new “custom field” type property value. This ID contains both the installation Id and the app Id, which we are not sure how to get.
Is there a way to obtain these ids programmatically (other than lifecycle events as we cannot get those to work, see
How can we test Lifecycle events?)
If you have access to the product context, it contains the
localId property, which has the form of:
You can use that to construct the ID of your custom field type, which is:
Let me know if you have any further questions
Hi @kkercz - thanks for your answer.
We are using a CustomUI (adminPage), and it seems that the productContext is empty (I guess that context is only of UiKit Components?).
Is there a way to get those IDs from a CustomUI?
Our ideal scenario is running the creation of the custom field from the post-install/post-upgrade lifecycle events (which give access to those IDs). However we’re struggling to test those events out (see my original post), so we are creating the custom field type from a custom field type manifest module, and then we’re attempting to create a custom field of that new type when the admin user visits a customUI adminpage, but we cant get the custom field type id from the custom field type created in the manifest. Our adminPage has to be a customUI because that will be a complex UI with a fair bit of client-side user interactions and we want a good user experience.
Thanks for your help!
@EulogioGutierrez You can get the product context with
For those who find this thread looking for a way to get the app ID and environment ID in a Confluence app: Unfortunately, the
localId doesn’t have the same format for all products. In Jira apps, it has the format
ari:cloud:ecosystem::extension/<appID>/<environmentId> but in Confluence, the colons and slashes are replaced by dashes:
ari-cloud-ecosystem--extension-<appID>-<environmentID>, which makes the ID a bit more difficult to parse.
These are the regular expressions I’m using to get the IDs:
Thanks @klaussner - view.getContext works from the custom UI frontend.
For other people looking into this, any frontend request that uses the bridge to call a backend resolver function will be passing this context without needing to do any work. You can just inspect the params passed to the backend function and the context will be there with a localId prop.