nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Incorrect JQL result

Bektas Ozan Topkaya

Hello all,

Our jql filter doesn't always work, but when it does at least it shows the correct data:))

To make it work, I always have to reindex the project or do a complete Jira reindex. But these approaches don't always help. Sometimes I still don't get an issue with the filter.

I have identified that it concerns the "goback-connector" field. Does anyone know why?

This is a completely normal number field.

project = SRVB AND issuetype ="Server Deinstallation" AND goback-connector = 10 AND "Smart Checklist" = itemStatus("Herunterfahren des Servers (init 0)", DONE)

Thanks for your help
Bektas

Accepted answers

All comments

Marc -Devoteam-

Hi @Bektas Ozan Topkaya

I think it might be related to the clause based on the Smart Checklist part.

This is an app related JQL option. I see it uses special characters (10).

From documentation of the app:

Special characters + - & | ! ( ) { } [ ] ^ ~ * ? \ : Special characters aren't stored in the index, which means you can't search for them. The index only keeps text and numbers, so searching for "\\[Jira Software\\]" and "Jira Software" will have the same effect - escaped special characters ([]) will be ignored in the search.

Can you search without the Smart Checklist clause, is the result than accurate?

See also search-syntax-for-text-fields

Tuncay Senturk _Snapbytes_

Hi @Bektas Ozan Topkaya

I am assuming that you've already removed the last part of your query and searched with only "goback-connector = 10" and still you had the same problems.

If you already tried that and it did not work, then it strongly indicates an indexing problem. It's good to inspect the Jira logs for any error messages or warnings associated with the number field or indexing. The logs often contain valuable information that can shed light on potential issues. It's worth noting that problems might arise when updating a field during a transition, especially if a post function fails, leading to indexing failures and the resulting inaccuracies in your search results.

Additionally, I recommend checking the integrity of your Jira instance. Running integrity checks can be beneficial in identifying and resolving underlying issues that might contribute to the problem.

Sorry, I could not be more specific but we think more details to spot the problem.

Bektas Ozan Topkaya

Hi Marc

This is exactly the opposite. Only with Smart checklist part I see always issues.

The cause is "goback-connector". If I leave out the Smart checklist part, jira does not find any tickets with "goback-connector=10"

Of course after some reindexing, if i'm lucky i'll see the results of complete filters.

Radek Dostál

This is a completely normal number field.

Then there is a problem in storing the updated value into index - but because this is a regular number custom field, with a searcher, and the fact that full re-index does populate the index values, means that the way you are updating that custom field value is not done in a "proper" way.

Likely, the values are updated by a script? And the script uses CustomField#updateValue() - which doesn't trigger "issue updated" event, which is iirc the one that triggers index updates.

You could add a simple reindex to it afterward:

ModifiedValue modifiedValue = new ModifiedValue(oldFieldValue, newFieldValue)
customFieldTo.updateValue(null, mutableIssue, modifiedValue, new DefaultIssueChangeHolder())
issueIndexingService.reIndex(mutableIssue)

// com.atlassian.jira.issue.index.IssueIndexingService, obtainable from ComponentAccessor as usual

Or you could use the other way:

mutableIssue.setCustomFieldValue(customField, <float number value>)
issueManager.updateIssue(currentUser, mutableIssue, EventDispatchOption.DO_NOT_DISPATCH, false)

Using MutableIssue#setCustomFieldValue() and IssueManager#updateIssue() to get the issue updated should trigger an index update. If that still doesn't help, ReindexingService#reIndex() after the issue update should ensure it getting stored, but updateIssue() should be enough.

I don't quite see how else you could update a custom field without triggering index updates, without either missing something in the scripts, or using SQL.

Bektas Ozan Topkaya

The cause is may be a storage problem but this is a JMWE transition and an issue update is done in issue history (5) also issue is indexed after the change (6

Bektas Ozan Topkaya

Hi Tuncay

Integrity check is error-free and postfunction runs even without error.

Tuncay Senturk _Snapbytes_

How do you update that number field? Do you use a transition screen to update the value of the field? Or do you update the field directly from the edit screen / inline edit?

Bektas Ozan Topkaya

The field is not updated, I use this field as a pointer for other purposes

Marc -Devoteam-

HI @Bektas Ozan Topkaya

So as I can see on the reply from you on the option from @Radek Dostál

It is an indexing issue, in relation with JMWE and post-function order.

How does the setup look like in JMWE and the related workflow post-function, are you able to share screenshots?

Radek Dostál

Strange.

Have you confirmed that the JQL will work when done otherwise than from the workflow transition?

As in

* workflow transition - no go

* manual issue update - good

This throws me off a bit but in your seat I would suspect the transition to be failing somewhere. UNLESS you have other indexing problems, not just that one specific field.

Bektas Ozan Topkaya

I put "Set field value" on first place and "Email issue" on two then I reindexed project and now I see all issues. I don’t know if this is workaround but I will test it again in the days.

Thank you all

Marc -Devoteam-

Hi @Bektas Ozan Topkaya

You seem to have an old JMWE version running as I use the app as well, this post-function is noted as Obsolete!

You should use the Set issue fields function

OBSOLETE: use the more powerful 'Set issue fields (JMWE app)' post-function instead. Set the value of a field in the current issue or issue(s) related to the current issue.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira

jira-server