Updating webhook ID in the database?

[Jason Adam]

Hello! We're running JIRA Server 7.6.2 with PostgreSQL 10.4

We have JIRA deployed in 3 different environments that we use the Configuration Manager plugin to export and import the system configuration (what it manages to grab) between each when changes occur in the workflows, etc.

We also have 4 webhooks that are called at various transitions.

I noticed that in our development environment, my webhooks have IDs that differ from the other environments.

This is causing, on each merge of the Configuration Manager export zip, the other environments to change which webhooks are called in transitions, because it's setting it based on id. And naturally, those environments, despite having the same names of the webhooks, have different ids. So each time we do updates, we have to go back and reset all the transitions with webhooks to the proper ones.

I found in a database schema pdf a table named AO_4AEACD_WEBHOOK_DAO that seems to define what the webhook info is, but that table doesn't exist in my database. I'm assuming this is a created on the fly table so the name is most likely different in my database than the pdf I found online.

I'm curious if it is possible to update the webhook table directly (and how you figure out what table that is), or if there is a better way for us to handle the situation we're in?



Thanks!

[Daniel Eads]

Hey Jason,

That is indeed the database table where webhook configurations are stored. The AO portion of the table name stands for Active Objects. All plugins that store to the database will have tables with this prefix. (Webhooks are a system plugin!) The bits afterward that look like randomly generated characters are actually a hash of the relevant plugin's identifier - so AO_4AEACD is going to be the webhook plugin's data on any system.

I'm curious how you can tell that the IDs are different if you aren't seeing rows in that table. Is Configuration Manager complaining at you that there is a mismatch?

There should be rows in that table. As a sanity check on my own system, I just added some additional webhook and more rows were populated with the details.

Since you're looking to modify your development environment, changing the IDs should be alright. We always recommend stopping Jira before making changes to the database - in this case you're going to want the webhook plugin to pull the new IDs during startup.

Another route I might go since you've got Configuration Manager is just deleting the webhooks on the development system. Configuration Manager should recreate them when you do an import, and it's going to try and set whatever IDs it thinks those webhooks should have from your source Production environment.

Cheers,
Daniel

[Jason Adam]

To get the actual IDs I just queried the webhook REST url which returned all the webhooks, and looked at the "self" URL string to see the actual ID. 

The issue we had is that the webhooks weren't actually being copied with Configuration Manager, despite doing a full system export/import (we do Merge though, not Restore).  The transition post-functions were there referencing webhooks, and the ID associated with the webhooks in the dev environment were set on those transitions, but we had to manually create the webhooks.  The webhook drop down was empty until we created the webhooks. But then they of course had different IDs (we didn't create them in the same order I did in dev, whoops).

I'll try the table again, don't think I fat fingered it but possibly!  My best bet right now is to force our environments to have the same IDs so that when we do future imports we don't muck things up.

Thanks for all the info! 

[Jason Adam]

Ok it turns out I just needed to put quotes around the table and field names.  I ended up writing a script that sets all the webhook ids and we just ran that and all our workflows are synced now.  Woot!