Unexpected behaivour with columns and issue search APIs

#1

Hello all,

Our customers reported that our app suddenly doesn’t work correctly.
Our Customer says that everything was normal until today, and our app doesn’t have any changes since a month ago.

We expect the return value of columns api (/rest/api/2/filter/id/columns and /rest/api/2/user/columns) as ‘customfield_xxx’, but actual values is custom field name (ex: ‘Gate 5[Time stamp]’).

According to my dev tools, JSD custom fields are correct, but other custom fields are incorrect.

Does anyone know anything about this problem?

filter-columns-return-values

3 Likes
#2

Many customers are affected by this problem and we need quick solution, so our team reported this issue on Ecosystem Developer Service Desk.

#3

Hi @dmorrow,
Sorry for interrupting you.
I have no response on Ecosystem Service Desk (DEVHELP-5167) and our customers are in trouble.
Of course we’re searching some fixes on our side, but do you have any solution or workarounds?

#5

Hi @hirota.takayuki,

I’ve submitted an internal enquiry to the Jira team that looks after custom fields.

Regards,
Dugald

1 Like
#6

This also breaks our app, “Better PDF Exporter”. All users are affected.

We need an urgent resolution to the problem.

1 Like
#7

@hirota.takayuki Can you please add “ferenc.nagy@midori-global.com” and “aron.gombas@midori-global.com” to your ticket (unless that contains confidential information)? We’d love to be up-to-date about the situation.

#8

Hi @aron.gombas, thank you for mention me. Adding you to DEVHELP-5167 done. Feel free to comment and update this ticket.

1 Like
#9

Hi @hirota.takayuki,

Thanks for reaching out to us. The mentioned “unexpected format” is actually our new format that is used for any column item that represents more than one custom field that has the same name and type in the system. Therefore, we cannot use any custom field identifier as the value for such a column item.
We would love to understand a bit more about the use cases of your app on this particular payload to assist you further here. Could you please help us to understand how your app is broken due to the format change?

Best regards,
Nhat

#10

Hi @NhatTran,

Our app has been using these values (the return of columns APIs) as the field’s parameters for search API since 2015.
https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-issue-search/#api-rest-api-2-search-get

We’re confused about this behavior change without any announcement. I’m sorry if we missed some notice. Other marketplace partners might be in the same situation.

#11

Hi @NhatTran,

Let me share our use case as well.

We call this REST API endpoint to get the columns of a filter:
“/rest/api/2/filter/{filterId}/columns”

Result snippet:

{
    "label": "Test_TextMulti",
    "value": "Test_TextMulti[Paragraph]"
}

Then we need to find the corresponding field, returned by this endpoint:
“/rest/api/2/field”

{
	"id": "customfield_10080",
	"key": "customfield_10080",
	"name": "Test_TextMulti",
	"untranslatedName": "Test_TextMulti",
	"custom": true,
	"orderable": true,
	"navigable": true,
	"searchable": true,
	"clauseNames": [
		"cf[10080]",
		"Test_TextMulti",
		"Test_TextMulti[Paragraph]"
	],
	"schema": {
		"type": "string",
		"custom": "com.atlassian.jira.plugin.system.customfieldtypes:textarea",
		"customId": 10080
	}
},

Currently we do the matching based on the column “value” and the field “key”, which is broken now.
I guess we could find a match in the “clauseNames” list, but what if there is another custom field with the same name: “Test_TextMulti” in the above example?

Regards,
Ferenc

#12

Hi @hirota.takayuki,

Thanks for the prompt reply. First of all, we’re sorry that the change is causing your app any inconvenience. It’s likely that there is some gap in our document around the columns APIs that is causing this confusion. The reason why there hasn’t been any announcement is because of that we didn’t consider this as a broken change to the APIs given we’re returning the column item value as mentioned in the document of ColumnItem instead of field id so for a column representing more than one custom field, this is the format we’re using. I think we should have actually handled this change in a better way.
For now, we will pause the rollout of this format change to mitigate the effect and discuss further action in the mentioned DEVHELP ticket. Hope that it sounds good to you.

Best regards,
Nhat

#13

Hi @ferenc.nagy

Thanks for reaching out to us. The mentioned column represents multiple custom fields that have the same name and type. Do you reckon that your app also need to handle multiple custom fields in this case instead of finding one specific custom field?

Best regards,
Nhat

#14

@NhatTran
Before the API change, it was not a problem.
The matching was clear:
“value”: “customfield_10080” -> “key”: “customfield_10080”

That is what we lost with the change.
What is your suggestion for the matching now?

#15

Hi @ferenc.nagy,

My suggestion is to match column item value (e.g: Test_TextMulti[Paragraph]) to the clauseNames returned for each field as a workaround and there could be multiple fields matched by the new way. However, the data is closer to the fact about the column item you’re interested in.
In my opinion, this assumption still relies on the implementation details so it’s possibly fragile. It would be very helpful for us if you can help raise some ticket to discuss your use case further with us so we can see if there is a need of any new API to provide a more solid solution.

By the way, we have just paused the rollout of the format change for now. Could you please do me a favor to add your app use case to the DEVHELP-5167 to help us better understand the impact of this change?

Thanks a lot in advance.

Best regards,
Nhat

#16

Thanks for your reply!
We will open a ticket to further discuss our use case and a possible solution.
I also added that to the related ticket as you asked.
https://ecosystem.atlassian.net/servicedesk/customer/portal/14/DEVHELP-5167

Pausing the rollout however means that now we need to apply a quick fix in our code that handles both the old and the new format :confused:

1 Like
#17

@hirota.takayuki
As I see in my test instance, the “columns” API started to return the “customfield_xxxxx” format again.
Do you see the same?

@NhatTran
Is it possible the change has been rolled back?

#18

@ferenc.nagy
Yes, I see the same. The json payload of “columns” API seems like the old “customfield_xxxxx” format.

#19

@hirota.takayuki
Thanks for the confirmation!

@NhatTran
From your previous reply:

It would be very helpful for us if you can help raise some ticket to discuss your use case further with us so we can see if there is a need of any new API to provide a more solid solution.

As I understand, you’ll want to make the API change eventually, so we need to discuss the details of how that should be done so we can prepare our app for the change.
If so, then could we do that in this existing ticket?
https://ecosystem.atlassian.net/servicedesk/customer/portal/14/DEVHELP-5167

Let me know if I’m wrong.

1 Like
#20

@NhatTran

Is it possible the change has been rolled back?

I want to know too. Rollback completely done?
Our team already applied a temporary hotfix to this incident and needs to roll back on our side.

#21

Hey folks,

I confirm that the change of the API shape has been completely rolled back. Please use https://ecosystem.atlassian.net/servicedesk/customer/portal/14/DEVHELP-5167 to discuss details of the change and potential problems with feature team.

1 Like