Just a thought I want to share with you. It would be great if Jira Cloud fired issue update events whenever read_only issue fields have their values updated; that way, it would be possible to trigger workflow events and other actions from ScriptRunner and the like. Am I right?
issue_property_set webhook event to listen to. Webhooks for this event are fired when an issue property is set or updated. Taking into consideration that a read_only issue field has to be backed by an issue property, webhooks for this event will be fired when a read_only issue field value has changed.
Would subscribing to webhooks of this event enable your use case? If not, could you describe your use case?
It’s more my customer’s use case, really. They see our custom fields listed alongside other custom fields in ScriptRunner and Jira Automation, and they asssume they can use them like other custom fields. Then suddenly, nothing happens.
One customer recently wanted to change the priority of issues whenever the risk level (our app tracks risk) was changed. We store risk assessments as entity properties and expose the risk level as a read_only custom field. The customer tried to automate the priority setting with a Field Value Changed trigger. Didn’t fire. He then tried to automate based on the Issue Updated event. Didn’t fire. The customer called Atlassian Support, who opined that it was probably a bug in our app. The customer contacted us, and we had to explain that our custom fields are… well… a bit dumb.
We’ve had this complaint from multiple customers. We used to have normal, mutable custom fields, which were problematic too because customers assumed that changes to those fields would affect risk assessments, which they didn’t because our app works on entity properties. GAhh!! what to do?!!
Thanks for raising this issue, David.
There’s too much Jira implementation detail leaking through here. It’s a case of Jira appearing so powerful and flexible until it smashes into its own oddly coded complexities. I have Risk Register on an Issue. Though an addon, it looks perfectly at home in the UI. I update Risk Register, it updates. I update other fields, they update. It all looks the same to me—fields on an Issue. ScriptRunner and Jira Automation are effectively the same in their triggers and there’s absolutely no indication that what I want to do is completely impossible. It has wasted my time, David’s time (though he’s a polite fellow who I’m sure will disagree and Atlassian Support’s time. They’ve been on for hours of back and forth.
In Jira Automation, Issue Updated looks like a fitting trigger. But the Issue isn’t Updated, which doesn’t make sense because it so clearly is. (Entity Properties not Fields?? give me a break, classic implementation leak through that should never be customer visible.) Field Value Changed trigger? even more fitting! and the Risk Register addon’s Fields are visible in Automation’s field selector UI. Again, no indication that these are read-only Fields (why would they be? I can change them and they change.) and no indication that these special flowers can’t work.
Atlassian, it stinks of years of poor decisions and half-baked churn-it-so-we-can-sell-it behavior. To be honest. (Sorry, Jakub.)
I have another thought on this. If an issue-updated event really means ‘the user updated the issue’ then it’s OK for a read-only field not to trigger such an event; but I don’t believe that the issue-updated event has those sementics. An issue-updated event indicates that an issue was updated, from whatever source. That being the case, it is surprising to the user that the value of a particular read-only field has changed, and yet no event was fired. Surprise == Bad. What do you think, @jtrzebiatowski?
I agree with you, it makes sense to send issue_updated webhook whenever the read_only field is updated. I came with the issue_property_set suggestion because I thought it could unblock you.
I raised a Feature Request in ACJIRA project (ACJIRA-2230). The issue should be triaged and prioritised accordingly soon.