We’re running into an issue in Jira Cloud where read-only Forge custom fields populated by our app are visible on the Jira UI, but fail Jira workflow transition validators. The custom fields are updated via a Forge issue panel and show up with their correct values when displayed on the screen. However, whenever a workflow transition has a standard “Field Required” validator configured for any of these Forge fields, the transition is blocked with an error claiming the field is empty.
We had one customer report something similar. They were using one of our custom fields (numeric) as field validator. They would pick the field from the list and link it to the field validator (e.g. value > 0). The validator would work for a while, but then they reported the validator would fail after a week with a Jira error “Configured field is no longer available.”
Like your scenario, the customer was able to display the field on the screen with a value. They also recreated the validator again with the same field from the picklist, and it worked for a while, but then spontaneously failed again after a few days.
We couldn’t reproduce this internally and so far only 1 customer reported this, but using build in validator comparisons against our custom fields is not common.
I believe that when the Connect to Forge transition happens that Jira rebuilds the Forge fields with the same name and a new internal custom field ID.
One hypothesis we had is that for this customer somehow Jira is stuck in this upgrade loop and regular rebuilds these custom fields with new internal custom field IDs. If the Jira built in validator stores a reference to the custom field ID and that is discarded/replaced, that could explain why the validator fails after several days of working.
It would be great to have an Atlassian opinion on this…