Summary

Since JIRA 7.1.0, SD 3.1.0, the Customer Request Type field contains a lot more info when retrieved via REST API. Example:

• In 7.0.10, the content of Customer Request Type is simple:

  "customfield_10010":"asd/getithelp"
  

• In 7.3.3, it's much more informative:

  "customfield_10001":{  
     "_links":{  
  	  "jiraRest":"http://10.60.2.10:8733/jira/rest/api/2/issue/11413",
  	  "web":"http://10.60.2.10:8733/jira/servicedesk/customer/portal/3/ASD-14",
  	  "self":"http://10.60.2.10:8733/jira/rest/servicedeskapi/request/11413"
     },
     "requestType":{  
  	  "id":"35",
  	  "_links":{  
  		 "self":"http://10.60.2.10:8733/jira/rest/servicedeskapi/servicedesk/3/requesttype/35"
  	  },
  	  "name":"Request a desk phone",
  	  "description":"If you'd like to request a desk phone, get one here.",
  	  "helpText":"",
  	  "serviceDeskId":"3",
  	  "groupIds":[  
  		 "7"
  	  ],
  	  "icon":{  
  		 "id":"10526",
  		 "_links":{  
  			"iconUrls":{  
  			   "48x48":"http://10.60.2.10:8733/jira/secure/viewavatar?avatarType=SD_REQTYPE&size=large&avatarId=10526",
  			   "24x24":"http://10.60.2.10:8733/jira/secure/viewavatar?avatarType=SD_REQTYPE&size=small&avatarId=10526",
  			   "16x16":"http://10.60.2.10:8733/jira/secure/viewavatar?avatarType=SD_REQTYPE&size=xsmall&avatarId=10526",
  			   "32x32":"http://10.60.2.10:8733/jira/secure/viewavatar?avatarType=SD_REQTYPE&size=medium&avatarId=10526"
  			}
  		 }
  	  }
     },
     "currentStatus":{  
  	  "status":"Waiting for support",
  	  "statusDate":{  
  		 "iso8601":"2017-04-06T22:34:44+0800",
  		 "jira":"2017-04-06T22:34:44.000+0800",
  		 "friendly":"06/Apr/17 10:34 PM",
  		 "epochMillis":1491489284000
  	  }
     }
  }
  

Due to this, it's slower to retrieve the field and its related data in 7.1.0/3.1.0 and above, considering the content of the custom field and size of data. Example:

• In 7.0.10, retrieving 14 issues takes 32.1ms, and the size is 467b
• In 7.3.3, retrieving 14 issues takes 412.4ms, and the size is 1.7kb

The underlying cause is, JIRA needs to query the database to retrieve a lot of information, such as the issue, project, portal, etc. And a lot of this is not cached, so if loading many issues, the number of db calls would multiply.

Suggestion

We should use caching properly, and not retrieve the entire activity list to get the issue's currentStatus (current status of the issue).

Notes

• The main benefit though from caching more data, is that repeated calls to get the same portal, request type for example, do not result in another database call, rather they use the previously returned value.
• Unless we strip out the payload again to go back to returning only the key, rather than the actual customer request data, it won't be back to exactly how it was.