Select to view content in your preferred language

Updating .info file to add Webhook

477
6
Jump to solution
07-05-2024 08:45 AM
mattkramer
Frequent Contributor

I am curious if there are any concerns with updating the .info file associated with a published form. We are looking to download form items and add an additional webhook to forms hosted in our portal environment (Enterprise 11.3). From reviewing the downloaded .info file, existing webhook definitions have an "id" included. Would we be able to just create a random id for this or are these values referenced elsewhere?

mattkramer_0-1720194260258.png

Additionally, for us to add an additional webhook this way, would we need to update anything outside of just this info file?

1 Solution

Accepted Solutions
mattkramer
Frequent Contributor

Following up on this. We were able to use the REST api to add a webhook definition to the .info file and reupload. We used the webhook definition from a form that already had the webhook we wanted to apply to all forms and copied that into the .info files for every form that did not have a webhook by the same name. After some testing, we found that forms were successfully updated and the webhooks on the affected forms seem to be working without issue. 

View solution in original post

0 Kudos
6 Replies
abureaux
MVP Frequent Contributor

Have you tried adding the webhook via the S123 Website? If you do that, it should add it to that file for you, thus circumventing any potential issues.

abureaux_0-1720222826067.png

 

0 Kudos
mattkramer
Frequent Contributor

This is the way we typically add webhooks to forms but unfortunately, we have a lot of form builders who are not adding these when they publish. We are trying to check for these during a scheduled task that will run nightly to catch any forms that the publishers forgot to add the webhooks to. Ideally, we would mandate the addition of the webhook as part of the workflow and limit the number of form builders, but this is not feasible for us either for 2 main reasons.

Firstly, I do not think it is possible to disable a Creator account from publishing forms while still allowing them to publish hosted feature services and web maps. Secondly, even if we did limit our form builders, this step is out of the way and easy to be missed which means we would be spending a good amount of time retroactively checking that these are on all of our forms, which we have hundreds.

All this to say, I am looking for a way to do this within a python script instead of manually.

0 Kudos
abureaux
MVP Frequent Contributor

Sorry, not sure how you would do this via Python script.

And you're correct. The permissions for those tasks overlap, so you can't have one without the other. Restricting form publishers would have to be administrative. In my case, we have administrative checks in place to ensure there is only a single publisher. And then all forms go through a review/checking process to ensure connections are in place prior to use (much like what you are after).

abureaux
MVP Frequent Contributor

As an aside, maybe a routine Python script which counts all published forms, and then counts all published forms with an "id" (indicating a webhook exists). Then you could create a list of forms that need webhooks added manually?

That would at least semi-automate the process, and avoid any potential mishaps from programmatically adding the id in.

0 Kudos
mattkramer
Frequent Contributor

I think that might be our best bet as well. I reviewed some of our cloned forms and can see that when cloning, the webhook id does not get updated (so clone id = original id) so we may try reusing the same id values. If that ends up not working, this is the route we will be going. Thank you for the help!

0 Kudos
mattkramer
Frequent Contributor

Following up on this. We were able to use the REST api to add a webhook definition to the .info file and reupload. We used the webhook definition from a form that already had the webhook we wanted to apply to all forms and copied that into the .info files for every form that did not have a webhook by the same name. After some testing, we found that forms were successfully updated and the webhooks on the affected forms seem to be working without issue. 

0 Kudos