Can I combine properties in JQL?

I require to combine several properties in issues and projects in a single JQL.
It seems, that I cannot combine 2 properties like this and the result ist always empty:

customPropA != "foo" AND project.customPropB = "bar"

JQL searches for either JQL part works fine but not together as expected.

Hi @lkimmel, thank you for reaching out.
I will try to reproduce the problem and see if there is a bug. If you could share with me your app manifest, it would be super helpful in my investigation.

Best regards,
Łukasz

Hi @ljarzabek,

Just now while testing this out I get some results. :smiley:
But this was not the case when I started testing it yesterday. :smiley:
But still something is off but maybe I need to add something to the query.

The relevant part of the manifest looks something like this to catch the basic idea:

  jira:entityProperty:
    - key: issue-index
      entityType: issue
      propertyKey: myProp
      values:
        - path: value
          type: string
          searchAlias: customPropA
    - key: project-index
      entityType: project
      propertyKey: myProp
      values:
        - path: valueB
          type: string
          searchAlias: customPropB
        - path: valueC
          type: string
          searchAlias: customPropC

The prop myProp within the issue is stored as {value: "foo"} another issue has {value: "foobar"}.
The prop myProp within the project is stored as {valueB: "bar", valueC: "other"} and it’s the project of that issue above.

The query customPropA != "foo" AND project.customPropB = "bar" returns results as expecting today, while yesterday the result was empty. So this seems fine today.

The query customPropA != "foo" seems to be off a little bit.
The results might miss out issues without the property myProp.
I would expect customPropA != "foo" to include issues without the prop myProp or the value myProp.value.
Or does this require a different query?

Hi @lkimmel, thank you for detailed example. It really helped me to understand your case.

The query customPropA != "foo" AND project.customPropB = "bar" returns results as expecting today, while yesterday the result was empty. So this seems fine today.

I don’t know what could be a reason it didn’t work earlier. Sometimes, after installation of the app, it requires some time to actually apply all changes. Please let me know if the problem will appear again.

The query customPropA != "foo" seems to be off a little bit.
The results might miss out issues without the property myProp .
I would expect customPropA != "foo" to include issues without the prop myProp or the value myProp.value .
Or does this require a different query?

Yes, it requires different query. Try to use one of below:

  • customPropA is null - returns all issues that don’t have entity property value defined
  • customPropA is not null - returns all issues that have entity property value defined
  • customPropA != "foo" - returns all issues that have entity property value defined and value is different than foo

@ljarzabek thank you. IS NULL did not seem to work last week either, but seems to work today as expected.

I can understand, that it takes a while for the index to be in sync.
Is there any indicator or guaranteed time frame when changes apply to an entity? It did not seem to work within a few hours, and that’s why I started the topic.
Is there any time frame you could say, that complete configuration changes in the manifest apply to the index?
Also, which environment (development, staging, production) are relevant for the index? What happens if they are different?

@lkimmel There shouldn’t be such a long delay. In general, after installation of the app, it should be available in a few minutes (and what I meant before, is a delay with app installation process, indexing shouldn’t take that long). Unfortunately, I don’t have any guaranteed timeframe I could share with you.

Is it possible that you had multiple apps installed with same aliases configured? Maybe this is the reason why your query didn’t work as expected?

Also, which environment (development, staging, production) are relevant for the index? What happens if they are different?

That’s a good question and I realised that we should improve in this field. Currently the behaviour is non deterministic - if you change your app between staging and production version, it’s not determined which alias will be applied in the query.

However, as a workaround you can access entity property directly, e.g.:
issue.property['stats'].comments = 5
https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-entity-property/#example