Issues match with user name in jql doesn't work

Jira Development Jira Cloud
1

Hello, dear community.

We’ve recently noticed an inconsistency in search and match APIs in Jira Cloud.

Example:
user “Vitaliy Ushanov” in Jira is assigned to the issue with id 10618.

  • Request to the search api with body
{
  "expand": [
    "names"
  ],
  "jql": "assignee = \"Vitaliy Ushanov\"",
  "maxResults": 15,
  "fieldsByKeys": false,
  "fields": [
    "assignee"
  ],
  "startAt": 0
}

results in the following json

{
    "expand": "schema,names",
    "startAt": 0,
    "maxResults": 15,
    "total": 27,
    "issues": [
        {
            "expand": "operations,versionedRepresentations,editmeta,changelog,renderedFields",
            "id": "10618",
            ...

Result is correct, issue is found.

  • Request to the match api with body (with the same jql):
{
    "issueIds": [
	10618
    ],
    "jqls": [
	"assignee = \"Vitaliy Ushanov\""
    ]
}

leads to an incorrect empty result

{
    "matches": [
        {
            "matchedIssues": [],
            "errors": []
        }
    ]
}

Single quotes in name (‘Vitaliy Ushanov’) don’t help.

However the problem is solved if one replaces full user name in jql by its id in request body:

{
    "issueIds": [
	10618
    ],
   "jqls": [
	"assignee = 5d2f56472d76f30c36bf88ce"
    ]
}

Now the match result is correct and the issue with id 10618 is found:

{
    "matches": [
        {
            "matchedIssues": [
                10618
            ],
            "errors": []
        }
    ]
}

The problem is highly dramatic for our business. So the question is - can we somehow deal with such an inconsistency? Maybe use workarounds if any?

Thanks in advance.

2 Likes
2

@VitaliyUshanov, I’ve confirmed your defect and opened JRACLOUD-75572. Please watch, vote, and comment. You’ve already identified the only workaround that I can imagine, which would mean dereferencing the assignee search value into a UUID with the user search endpoint.

1 Like
3

Hello @ibuchanan . We transfer user’s queries directly to the match endpoint. So unfortunately additional parsing of these queries isn’t a solution for us.