You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
New-JiraIssue and Set-JiraIssue perform very poorly when a Jira instance has a large quantity of custom fields. Our development instance has 630 CFs defined and calling Set-JiraIssue (with 3-5 Fields in the -Fields parameter) takes roughly 8 seconds to complete. The underlying HTTP PUT to Jira's REST API for creating the issue is only about 150ms of this.
Steps To Reproduce
Configure Jira with a lot (~500) custom fields.
Do one of the following. In either case, use the -Fields parameter to set a few custom fields for the given issue type.
Create an issue with New-JiraIssue
Update an existing issue with Set-JiraIssue
Observe performance.
Expected behavior
Response time is relatively performant/semi-aligned with Jira web UI
Screenshots
Your Environment
JiraPS 2.14.7
Possible Solution
New-JiraIssue and Set-JiraIssue appear to be calling Get-JiraField in a loop for each KVP in -Fields. While the call to Get-JiraField contains a -Name parameter, the underlying API is unfiltered. This means that, when creating an issue and specifying 3 fields in the -Fields parameter against an instance with 500 custom fields, we end up retrieving (and parsing!) 1,500 custom field entries.
Two options seem to be available here:
Hoist the call to Get-JiraField out of the foreach loops here and here
Use field info from CreateMeta/EditMeta which, AFAICT, has:
All of the fields available for a given issue type (or issue in its current state)
Their field IDs
Those fields' structural/schematic requirements (required or not, type, etc.)
We're already fetching CreateMeta in New-JiraIssuehere, so this is likely a straightforward fix.
The text was updated successfully, but these errors were encountered:
Upon further inspection, Invoke-JiraIssueTransition (though I haven't tried it) appears to have a similar problem - we're calling Get-JiraField in a loop against the -Fields param contents here:
if ($field=Get-JiraField-Field $name-Credential $Credential) {
There's not a meta endpoint for transitions, though the transitions API endpoint (when contextualized to a specific issue) should provide a map of properties available. This might be a better solve for parameters there (optionally falling back to EditMeta or the fields API)
Description
New-JiraIssue
andSet-JiraIssue
perform very poorly when a Jira instance has a large quantity of custom fields. Our development instance has 630 CFs defined and callingSet-JiraIssue
(with 3-5 Fields in the-Fields
parameter) takes roughly 8 seconds to complete. The underlying HTTP PUT to Jira's REST API for creating the issue is only about 150ms of this.Steps To Reproduce
-Fields
parameter to set a few custom fields for the given issue type.New-JiraIssue
Set-JiraIssue
Expected behavior
Response time is relatively performant/semi-aligned with Jira web UI
Screenshots
Your Environment
JiraPS 2.14.7
Possible Solution
New-JiraIssue and Set-JiraIssue appear to be calling
Get-JiraField
in a loop for each KVP in-Fields
. While the call toGet-JiraField
contains a-Name
parameter, the underlying API is unfiltered. This means that, when creating an issue and specifying 3 fields in the-Fields
parameter against an instance with 500 custom fields, we end up retrieving (and parsing!) 1,500 custom field entries.Two options seem to be available here:
Get-JiraField
out of theforeach
loops here and hereWe're already fetching CreateMeta in
New-JiraIssue
here, so this is likely a straightforward fix.The text was updated successfully, but these errors were encountered: