Summary

displayConditions are now supported on jiraServiceManagement:portalRequestCreatePropertyPanel, but there is no way to write a condition based on the active request type on the portal request creation screen. The jiraExpression context for JSM conditions exposes user, app, project, issue, serviceDesk, and customerRequest, but there is no requestType variable. As a result, an app cannot restrict this module to specific request types before the module mounts.

This is a Connect>Forge parity gap. In Connect, apps used the entity_property_equal_to_context condition (now deprecated) to conditionally show/hide a panel on the request-create screen based on the request type. There is no Forge equivalent for portalRequestCreatePropertyPanel, so apps migrating from Connect cannot reproduce this behavior.

Current behavior

• The request type ID is only available via the module's extension context (request.typeId, accessed through useProductContext() / getContext()), which resolves after the module mounts.
• Because the only pre-mount gate (displayConditions) cannot see the request type, the panel mounts on every request type and then hides itself in code.
• This produces a visible layout shift: the panel briefly renders (or reserves iframe height) and then collapses, leaving an empty gap on request types where the app should not appear. With multiple apps, these gaps compound.

Requested behaviour

Expose the active request type (for example, requestType.id) to the displayConditions.jiraExpression context for jiraServiceManagement:portalRequestCreatePropertyPanel (and, ideally, consistently across the JSM portal create/detail modules), so apps can gate visibility per request type before the module mounts.