Hi there,
When creating a webhook from add-on descriptor (atlassian-connect.json) it works (as I get callbacks notifications) but it is not listed under Webhooks section, nor available in post-function workflow section. Descriptor example is:
"webhooks": [
{
"event": "jira:issue_updated",
"url": "/cascade-epic-details.php?issuekey=${issue.key}&projectkey=${project.key}",
"excludeBody": false,
"filter": "project = GR and issuetype=Epic"
}
]
},
"scopes": [
"read", "write"
]
Instead, if I create the webhook directly on Jira or via REST it is available and working perfectly.
Is this the expected behaviour?
Thanks in advance,
HĂ©ctor
1 Like
Yes. The idea is that admin-created webhooks should be managed manually, where they can be modified and removed manually. But add-ons need UI modules, webhooks, and other resources to be available “atomically” – that is, all at once, or not at all. It would create a lot of problems (or at least much more error handling code for add-ons) if an admin could modify or remove the webhook that an add-on needs.
2 Likes
Thanks @ibuchanan, it is clear now. Thinking loud, I would say that if an add-on defines the existance of a webhook, that makes that webhook and the add-on coupled and none of them can exists w/o the other, so it is a single package, and the webhook could behave in the same way as it does when it is created from the tool, but in read mode from the “webhook’s admin section” point of view, and it has to be managed by the add-on directly. In other words, if admin wants to remove that specific webhook, then the way is to remove the add-on, becuase the add-on comes with a webhook
. Does it makes sense from the model perspective?
2 Likes
That makes complete sense. You nailed it!
1 Like