“entityPropertyContainsAnyUserGroup” has analog in Atlassian Connect.
And due to Forge Docs seems to be working for Confluence.
So will it work again for Jira (now in context of Atlassian Forge)?
Best regards,
Oleh
So will it work again for Jira (now in context of Atlassian Forge)?
Not from what’s documented today. entityPropertyContainsAnyUserGroup is marked Confluence only in the entity property conditions reference, and the Jira/JSM page lists only entityPropertyExists, entityPropertyEqualTo, entityPropertyContainsAny and entityPropertyContainsAll.
Jira does have jiraExpression, and the global context gives you user and app, so the Connect semantics are expressible:
displayConditions:
jiraExpression: "app.properties['allowedGroups'].some(g => user.groups.includes(g))"
I ran the expression half against a live site rather than trusting the reference:
POST /rest/api/3/expression/evaluate
{"expression": "[\"site-admins\",\"nope\"].some(g => user.groups.includes(g))"}
-> {"value": true}
The same call with a group I’m not in returns {"value": false}, so the lambda and user.groups both behave. user.groupIds is there if you store IDs.
Two caveats. app isn’t in the context of a plain REST eval, it fails with "app" - identifier not available in context, so the app.properties half is docs-only for me and not something I’ve run. And user.groups is flagged as an expensive field, which matters if the condition sits on something that renders often.
If you go test it, /rest/api/3/expression/eval is gone and fails with a misleading Please migrate to the /rest/api/3/search/jql API. /rest/api/3/expression/evaluate is the live one.
This thread tried close to the same and reported it not firing, with no resolution. If you get the app.properties form working, worth posting back there.
Thanks for the answer @Mihai_leanzero !
All the ways mentioned look like workarounds. And it works differently than original Connect displayConditions - that is wrapping values to strings automatically.
Looking forward for support entityPropertyContainsAnyUserGroup in Jira if there (if there is some Atlassian support ticket for that i’d like to vote)!
Best regards,
Oleh
if there is some Atlassian support ticket for that i’d like to vote
FRGE-2221, filed 31 July by an Oleh Kosar, so I assume that one is yours. The one to spend a vote on is FRGE-2153, same shape from a different reporter, addon_property_contains_context against user.accountId, open since May at 0.
Both sit in Reviewing, and that status carries a description you do not see from the issue view:
This suggestion needs more unique domain votes and comments before being reviewed by our team
Unique domain, so the gate is votes from other companies rather than more from yours.
The other lever is not voting. @rmassaioli’s Connect EoS thread asks partners to fill in a “Request review” form from the Issue Context panel, which stamps connect-eos-requested. 107 issues carry it and 97 have a decision, 9 accepted and 88 rejected, with the wording that rejected “does not necessarily mean it will never be picked up”. He announced three cycles from March and then a freeze, and the cycle labels do stop at connect-eos-may, but it is not dead: FRGE-1895 was rejected on 23 July and FRGE-2218 was stamped on 25 July. FRGE-2221 carries no connect-eos label at all, so that form has not been filled in on it. I would.
The string-coercion difference is worth putting in the ticket body rather than leaving it here, since that is the part Connect did for you and the expression form does not.