Adding more jiraIssueFields items after an app is installed

Hi there

I am testing something in terms of some custom fields we require in our Jira instance. I started by installing an app with no modules at all, only used for JWT Rest API calls initially. After installed, I added the jiraIssueFields module (https://developer.atlassian.com/cloud/jira/platform/modules/issue-field/) to the app descriptor and it looks like it records a minor update under my vendor app listing … but the field does not create and is not appearing under Issues > Custom Fields.

Is there an issue with my process or am I understanding incorrectly on adding new jiraIssueFields to the app descriptor … ie. if I add more going forward, how long should I wait for it to display in the Custom fields list?

Thank you in advance

Hi @YatishMadhav,

Most types of changes you make to your app and Connect descriptor will be reflected immediately after the new version of the app is installed. If your app is listed in the Marketplace, then all instances of Jira will be upgraded to the latest version of your app, but this can take quite a while to go through all tenants (several hours).

Some descriptor changes such as changes to your payment model and changes of scopes required by your app need to be reviewed before the upgrade of your app is allowed. There are a couple of stages of review - Atlassian review and Jira tenant administrator review.

Regarding your custom fields, I believe your changes should be reflected immediately after the app is installation so if you’re not seeing your fields, your implementation may be incomplete.

Regards,
Dugald

Thanks for teh quick response @dmorrow

So I am testing this on a test dev instance. And also it will remain a private app only ever installed on our one instance of Jira.

For those changes that required moderation - how long would that take out of curiousity?

So I believe my app was installed correclty and I have received the install payload to make JWT REST calls.

But now I would like to add fields and work with those. But I am not seeing those fields created on Jiras Issue Custom fields UI list when I search/filter by the name or key or description.

Thank you

Hi @YatishMadhav,

The moderator review by Atlassian only occurs for public apps. This won’t affect you since your app is only private.

Do you see your field if you visit https://your-tenant.atlassian.net/rest/api/3/field?

Regards,
Dugald

OK I see.

No, I don’t see it listed in that callback.

So the only update I did see is under the versions on the Marketplace vendor app listing as a ‘Minor version update’ with version ‘1.0.1’ … but under managed apps on th instance it only shows ‘Version: 1.0’

Thank you

Hi @YatishMadhav,

Can you share:

  1. Your jiraIssueFields module part of your Connect descriptor.
  2. The details about how you are querying the field.

Regards,
Dugald

Hi
This is the module added in the json:

		"jiraIssueFields": [
			{
				"description":
				{
					"value": "testing a staff field dropdown from the connect app"
				},
				"type": "single_select",
				"extractions": [
					{
						"path": "category",
						"type": "text",
						"name": "categoryName"
					}
				],
				"name":
				{
					"value": "Staff"
				},
				"key": "staff-dropdown-field"
			}
		]

And the way I am checking initially is by going to https://xxxxxx.atlassian.net/secure/admin/ViewCustomFields.jspa?page=1&searchFilter=staff

I installed the app descriptor with a jiraIssueFields item this morning and that loaded the custom fields as locked successfully. I added another custom field a few minutes back to see the update reflected on https://marketplace.atlassian.com/manage/apps/xxxxxxxxxx/versions and then expectedly on the first link I shared above.

I have yet to write the code to update the custom fields via the REST API but can only do that once the app descriptor change is detected and the field is created and available.

Hope this helps in you helping me?

Thank you again

So this showed up under the app listing :
image

But this is still what shows under the Custom Fields on the admin side:
image

FYI I retried this compared to when I initially posted this … so both times the app version updates … but it does not reflect on the admin side showing the newly added custom field.

Please advise?

Hi @YatishMadhav,

You should be able to test your changes without creating new versions in Marketplace by running your code on your development machine and using ngrok to create a publicly visible URL which tunnels to your development server. Also, it takes quite a while (several hours) for Marketplace to install new versions of apps in all the customer tenants.

My understanding of your problem is that you’ve declared a second jiraIssueFields module, but you can’t see it in the Jira admin.

Regards,
Dugald

Hi there.

Yeah, I am aware of the ngrok route. But I am testing on a test server that can be accessed publicly. No worries with that. When you say “a while (several hours) for Marketplace to install new versions”, how long is this as the last 10-odd hours has been the wait? And how can I see the version on the instance compared to the Vendor listing versions as I showed above?

So I got up this morning, got ready and checked the custom fields list to see if it picked up the 2 new “jiraIssueFields” items that I have added … and still, the only one listed on the interface under Custom Fields is the one that was in the app descriptor when I initially installed the private app. Again, the current modules in the descriptor as is since last night is:

	"modules":
	{
		"jiraIssueFields": [
			{
				"description":
				{
					"value": "testing a staff field dropdown from the connect app"
				},
				"type": "single_select",
				"extractions": [
					{
						"path": "category",
						"type": "text",
						"name": "categoryName"
					}
				],
				"name":
				{
					"value": "Staff"
				},
				"key": "staff-dropdown-field"
			},
			{
				"description":
				{
					"value": "testing a staff field dropdown 2 from the connect app"
				},
				"type": "single_select",
				"extractions": [
					{
						"path": "category",
						"type": "text",
						"name": "categoryName"
					}
				],
				"name":
				{
					"value": "Staff 2"
				},
				"key": "staff-dropdown-field-2"
			},
			{
				"description":
				{
					"value": "testing a staff field dropdown 3 from the connect app"
				},
				"type": "single_select",
				"name":
				{
					"value": "Staff 3"
				},
				"key": "staff-dropdown-field-3"
			}
		]
	}

Please advise what is wrong or why it is “blocking” from adding the new fields AFTER the app has already been install? Is this a bug or something that I am missing in the documentation?

Thank you
Yatish

Hey @dmorrow … any feedback on this please? Or could you perhaps involve someone else on this too to get further insight? Thank you

Hi @YatishMadhav,

Are you using Marketplace to distribute new versions of your app for testing? The typical development loop is to create a testing tenant of Jira by visiting http://go.atlassian.com/cloud-dev and updating your app by submitting the app’s descriptor at https://your-test-tenant.atlassian.net/plugins/servlet/upm (make sure you click Enable development mode in the settings on that page). Make sure you don’t install any test instances of your app on your production Jira tenant because this will prevent future installations of your production version of the app on your production Jira tenant.

Have you validated the latest version of your descriptor? You can use the validation service at https://atlassian-connect-validator.herokuapp.com/validate.

I tried reproducing your problem as follows:

  1. Added the same fields as you’ve defined to my test app’s jiraIssueFields module.
  2. Restarted the server on my laptop where the app is hosted.
  3. Reinstalled the app by entering the ngrok URL that tunnels to my local app server into the Jira manage apps admin page (https://xxxxxxxxx.atlassian.net/plugins/servlet/upm). Note that I’m testing against a tenant that I created by visiting http://go.atlassian.com/cloud-dev. Once again, don’t do this step on a production tenant because this will prevent the ability to install the Marketplace version of the app.
  4. Reloaded the custom fields admin page, https://xxxxxxxxx.atlassian.net/secure/admin/ViewCustomFields, and searched for the added fields.

At step 4 I could see the added fields straight away.

Are you able to follow these steps?

Regards,
Dugald

Hi,
Yeah, I am using the marketplace for the test app too - 1. it is differant app from the one I will use on Production instance. 2. I cannot channel my local dev instance using ngrok for security reasons so I am using a dev Jira instance and a dev app environment too that is publicly available.

I have checked the latest and the inital app descriptor on the validator and it passes:
image

In your step 2, you restarted your app server? Does that mean I need to reboot the app server everytime the descriptor is updated? Or should I just restart apache/IIS/nginx?

In your step 3, you reinstall the app descriptor on your Jira instance. Is this also a required step? If so, the install payload then sends a differant secret to use to for JWT calls - that means we need to then update our config each time as well?

So … What are ALL the required steps needed for the Jira Cloud instance to “pick up” the changes in the app descriptor? (FYI for dev/testing, we’re using a test/UAT environment and the dev/testing Connect app is also on the marketplace as a private app under our vendor)

Please advise urgently?

Thank you
Yatish

Hi @YatishMadhav,

In my step 2, I restarted my app server to ensure it was serving the latest version of the descriptor and code. This step is dependent on your server setup.

In step 3, yes - the app needs to be re-installed. You don’t need to uninstall it - just install it over the top of the existing installation. Your app will receive an installed payload, but it will be signed by the JWT using the same shared secret previously provided. The payload may theoretically contain a new shared secret, but this does not happen often.

Regards,
Dugald

Hi @dmorrow
Thank you for that quick reply …

I didnt need to restart the server on my end … see below.

OK so I tried your step 3 as you mentioned installing it over the existing one and it works … It seems a bit of a “forceful” / manual step. Can this rather be done automatically, ie as soon as the new app version is detected on the marketplace private listing, it installs/updates on the instance? That is the expectation …

OK so some progress here. But as menetioned, can I omit having the need to re install the app and instead only update the descriptor (because seeing a new version of the app under the vender app version is a little misleading)? This is something that may need to be documented on https://developer.atlassian.com/platform/marketplace/upgrading-and-versioning-cloud-apps/ as well or am I missing something?

Thank you
Yatish

Hi @YatishMadhav,

It’s good to hear we are making progress.

The “installing over the existing one” is exactly what Marketplace does. This process tells Jira about only the changes relating to the descriptor. Of course, you can make many improvements to your app without needing to modify the app’s descriptor. Since Connect apps are separately hosted to Jira, you can deploy these completely independently of installing the Connect descriptor.

In order for you to be clear on which version of the Connect descriptor is installed, you could add a version or timestamp into the app’s name in the descriptor. This will be visible at https://your-tenant.atlassian.net/plugins/servlet/upm so you can check what version is installed in Jira.

Regards,
Dugald

Thanks for the tip on adding an indication in the name of the app. Handy. Could it rather be done to the description instead of the name?

Yeah, i know of the changes to the app that is non-app-descriptor related, eg. panels, glances, etc.

But I mean if the app descriptor is changed/updated, for example, adding new custom fields to be used. Is it always a 2 step process to have it reflect on the Jira instance UI - i.e update app desc json file > re-install app descriptor?

I would expect it to be 1 step (ie. update app desc json file) and the marketplace would auto re-install if for me on the instance(s) since it already does pick up the change.

Thank you

Hi @YatishMadhav,

There are two steps, but Marketplace should be automatically performing the second step for minor updates (e.g. no changes to scopes and pricing model).

Also, the version of the app you see in Marketplace has no relationship to the version you see in the Jira manage apps view. The version you see in the Jira manage apps view is the same as the version you define in your app’s Connect descriptor. If you omit the version attribute in your app’s Connect descriptor, it defaults to 1.0.

Regards,
Dugald

Hi again.

Yeah, so my updates currently are only minor ones. i.e adding to the jiraIssueFields. Why does it not execute the 2nd step automatically after I add new fields or correct field names? I have to manually re-install the app even if it is a minor update.

That is why i thought there may be a bug OR I am missing something in this?

OK, great. Now I understand that versioning differences better too. Thanks for that explanation.

Thanks
Yatish

Hi @YatishMadhav,

I’m not sure why Marketplace didn’t install the app after detecting changes to the descriptor. Would it be possible for you try the following:

  1. Change the version in your app descriptor.
  2. Check if Marketplace detects the new version and creates a new minor/micro Marketplace version of your app.
  3. Check if Marketplace installs the new version by visiting https://your-tenant.atlassian.net/plugins/servlet/upm and checking the version of your app matches the version in your descriptor. Note that this still will take a lot longer than the previous step - maybe ~8 hours.

Note that previously I suggested you include a version in your app’s name, but this is not necessary as I now realise you can specify a version in your descriptor which surfaces in https://your-tenant.atlassian.net/plugins/servlet/upm.

Regards,
Dugald