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
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
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