Undocumented property/value limit when using the entityProperty module

Hi there,
as I was experimenting with the module and got an error stating

error All jira:entityProperty modules combined cannot declare more than 30 values. valid-module-required

Will this limitation be removed once the feature hits GA or is there another way to get an elevated limit for a specific app? 30 properties will not be sufficient for the use-case I’m currently building.

Regardless, could you add a notice to the documentation informing developers about that limit?

Greetings
Gideon

Hi @GideonNolteJodocus,

Unfortunately, there is no plan to lift the restriction and the 30 properties limit will apply after the feature hits GA. Could you provide more details about your use case? How many properties would be enough for you?

Regarding documentation - this is definitely an oversight on our part, sorry for that. We will update our docs soon. Thank you for raising this issue!

Best regards,
Łukasz

Hi Łukasz,
the use case we are currently developing is a general extension for JQL without much more functionality besides that. I can see how an app which would expose a few properties derived from their core functionality would have plenty of possibilities to do so with 30 properties.
On the other hand I’d argue, that a search extension for JQL would need at least 50, if not more, keywords to offer value / expected functionality similar to connect apps which extend the search. I definitely see, that adding more than 30 properties per app might cause performance degradation over time with the growing index size per app, but I would like to be able to have elevated limits for specific apps/use cases.

On that note, I was wondering whether composite properties would be a way to increase the limit with a smaller impact. Similar to being able to provide a list of objects of a given type, e.g. a list of users, I could imagine providing an object with values of a given type, which would count as one property.

For example: the property linkCount could be an object of number values with keys for the given link type. This would mean rather than using:

{
blockedIssueCount: 0,
blockedByIssueCount: 1,
relatedIssueCount: 0,
}

with manifest

- path: blockedByIssueCount
  type: number
  searchAlias: blockedByIssueCount
- path: blocksIssueCount
  type: number
  searchAlias: blocksIssueCount
- path: relatedIssueCount
  type: number
  searchAlias: relatedIssueCount

one would use

{
  "linkCount" : {
   "blockedBy" : 0,
   "blocks": 1,
   "related": 0,
    ...
  }
}

with manifest

- path: linkCount
  type: number
  searchAlias: [blockedBy, blocks, related]

or

- path: linkCount
  type: number
  searchAlias: dynamic

resulting in linkCount.blockedBy = 0 vs. blockedByIssueCount = 0

This way, one could use far less properties and also possibly enable more dynamic paths to account for custom link types (with searchAlias: dynamic for example). What is your take on that?

Is there a plan to enable forge developers to write custom JQL functions or evaluate partial JQL queries dynamically while searching?

Sorry for the lengthy response. I hope our use-case and my ideas are clear.
Greetings
Gideon

Hi @GideonNolteJodocus,

Thank you for the interesting take on jira:entityProperty improvements! Could you create ticket with feature request here: Forge - Issues - Ecosystem Jira? It will be easier to gather an interest and discuss further details there.

Regarding JQL functions module - we are currently working on that. You can track the status here: [FRGE-231] - Ecosystem Jira

Best regards,
Łukasz