What does "Script Enabled" mean in the Incoming Webhook configuration?

As per title really. I have a few webhooks from various services that work well with scripts. I am trying to set up alerts from UptimeRobot, which has a Slack integration. Do I remember rightly that Rocket.Chat is supposed to be Slack compatible for webhooks, and Script Enabled is only for webhooks that can’t be configured to be Slack compatible?

What is happening is that when the webhook is fired, I see the debug in the log, but nothing in the channel.

I20210623-19:49:23.452(0) Integrations ➔ Incoming WebHook.info Post integration: Uptime Robot #some-channel
I20210623-19:49:23.457(0) Integrations ➔ Incoming WebHook.debug @urlParams: {   integrationId: 'MUNGED',   token: 'MUNGED' }
I20210623-19:49:23.458(0) Integrations ➔ Incoming WebHook.debug @bodyParams: {   link_names: 1,   username: 'UptimeRobot',   text: 'Monitor is DOWN: MUNGED ( MUNGED ) - Reason: Connection Timeout',   icon_url: 'https://uptimerobot.com/assets/img/logo-square-128px.png',   unfurl_links: false }
I20210623-19:49:28.433(0) API ➔ debug POST: /hooks/MUNGED/MUNGED
I20210623-19:49:28.435(0) Integrations ➔ Incoming WebHook.info Post integration: Uptime Robot #some-channel
I20210623-19:49:28.436(0) Integrations ➔ Incoming WebHook.debug @urlParams: {   integrationId: 'MUNGED',   token: 'MUNGED' }
I20210623-19:49:28.438(0) Integrations ➔ Incoming WebHook.debug @bodyParams: {   link_names: 1,   username: 'UptimeRobot',   text: 'Monitor is UP: MUNGED ( MUNGED ). It was down for 0 minutes and 0 seconds.',   icon_url: 'https://uptimerobot.com/assets/img/logo-square-128px.png',   unfurl_links: false }

Hmmm.

So webhooks are agnostic. They aren’t designed for any one service:

Did you mean this?

Thanks, but I’ve read the docs and I don’t see what they have to do with my question. I know what webhooks are, but what I don’t know and what I can’t see anywhere in the docs (nor a tooltip in the code) is what the “Script Enabled” toggle does.

Any clues?

Enables the script can you paste in the box below to execute various things?

It gives a sample the Integrations page I linked above.

I’ll assume your answer was in good faith, because it’s blindingly obvious that if it’s enabled, it executes the script below

To clarify my question in the OP, what is the point of a webhook that doesn’t have the Script Enabled toggle set? If you don’t know, feel free to point me to the docs that explain what the purpose of the toggle is.

Yes it was in good faith. I’m not in the business of making fun of people!

It is as simple as deciding whether the script gets run or not. I don’t believe it is any more complex than that.

As far as I remember, some API references don’t require anything else executed.

Were you thinking of this by chance?

P.S. I’ll try and get a more definitive answer in due course. The docs are not very clear on some stuff - we are working to address this.

I couldn’t work out how to quote previous posts, but doesn’t matter.

It is as simple as deciding whether the script gets run or not. I don’t believe it is any more complex than that.

This is the same answer as previously and the follow-up is the same. What is the point of a webhook if the script doesn’t get run.

As far as I remember, some API references don’t require anything else executed.

What does the API have to do with webhooks?

No, I wasn’t thinking of Slack Compatibility - Rocket.Chat Developer, this issues is nothing to do with apps.

P.S. I’ll try and get a more definitive answer in due course. The docs are not very clear on some stuff - we are working to address this.

Thanks, no offence but I won’t hold my breath. After working with RC for ~six years, “In due course” in the RC community often means “going to disappear into the wind”. I would say this is more than the docs not being very clear - this doesn’t appear to be documented at all.

Well, I do find it a little upsetting quite honestly. I don’t think you have been reading here, or Open or bugs much recently.

So yes, I have been around that long too, and am now full time community manager with a small team.

We are working hard to try and fix some of things that annoyed people as I am more than well aware of what has happened, but we can’t do it all over night. It would be nice if community members reciprocated and lent a hand too - that’s what the community is all about. Give and take.

So, as to your question, I will try and get an ‘official’ answer on the subject, but it might take me a little while.

As I have said, it is likely that either it is because not every webhook needs a script executing, or the other possibility is you can turn it off as required without losing all your settings.

Funnily enough, I used to have permissions to triage / moderate RC GitHub issues, and I did, until one day they were revoked without a word.

I can’t believe you’re blaming the community for lack of engagement in this area. It’s the RC team that leaves open loops most of the time. Have a read of Support for Markdown escaping · Issue #8989 · RocketChat/Rocket.Chat · GitHub, especially at the end.

Need to allow incoming webhook to notify @all in channel e.g. for urgent alerts · Issue #12247 · RocketChat/Rocket.Chat · GitHub opened 2018, assigned to the 4.0.0 milestone in 2020, nothing since.
git rebase > git merge when updating feature branches · Issue #10585 · RocketChat/Rocket.Chat · GitHub radio silence on a workflow improvement which would make contributors lives easier.
HTML rendering as text in incoming webhook · Issue #8332 · RocketChat/Rocket.Chat · GitHub added to a million milestones in 2018, nothing since.
Better-explain default settings in Notifications dialog · Issue #6846 · RocketChat/Rocket.Chat · GitHub what a surprise, assigned, unassigned, radio silence. What’s the point of assigning users and milestones if they aren’t going to get done, and they aren’t cleaned up?
Stick with initial username for OAuth registration · Issue #5667 · RocketChat/Rocket.Chat · GitHub milestone city.

I didn’t cherry-pick these from GitHub, they are most of the issues I opened that are currently open.

Unfortunately, the RC team is simply not good at project management. So before blaming the community, understand the community.

I think you are missing what is going on at the minute.

Yup - I understand your frustrations. I was frustrate too and hence I walked away some while back.

So, we are scaling rapidly. If you read here and issues you would see that I am trying to get things more organised to keep the community better informed and more involved. I can’t do all that by myself, or do it overnight.

You should shortly see a move to better labelling on issues. The reason you don’t see much appear to happen is all the work on product and issues is done on an internal tracking system. The problem with that is no one externally can see what is happening so we are trying to improve it.

We also have a product team now. That means the product managers decide what gets fixed or not, and what new features are implemented. This has been a huge transition and is still in progress.

The mountain of bugs is an issue but as you can see we are trying to work on that. Some issues in there are old and fixed, but the issue is not updated.

Some still exist, but they don’t fit with the direction of travel for the product - ie they are feature requests rather than bugs.

You can see 8989 is being looked at, but just because you want it doesn’t meant that that Rocket.Chat wants it.
12247 again is a NFR.
10585 is a discussion point and should be on open.rocket, not github.
8332 - using html in the message is a long debated topic as it has lots of scope to be abused. Hence we don’t currently do rich text. Whether that will change I don’t know, and again will depend on the product managers.
6846 - is an irritation - I know we updated the documentation on this. I have asked the Product manager to take a look but there is also a UI revamp going on and this may be there anyway.
5667 - I have again asked the Product manager to take a look (you do not need to @ people on github - those who need to know already know)

Actually, you did :wink: You picked your own issues, not just random ones… But the point still remains that there are a lot open, but you will see in the forthcoming months that this will change as we try to get down a to a more sensible level.

Also note that generally we don’t take many PRs for the core code these days. We would like people to focus on the apps side of things to add functionality. We are investing heavily in this area.

They might not have been, but that was then and this is now. Believe me, from behind the scenes the changes are enormous. Change is coming.

I didn’t blame the community. I just said it would be nice if they started to lend a hand. I’m doing my best. My new team members are helping. There is a limit to what we can do in a day.

NB I have no idea why your perms were revoked. I know there has been a clear up of a lot of permissions that had been granted to inactive people. Find me on open.rocket. if you want to discuss further.

As per a developer:

Script enabled means it should run the script
An incoming webhook can still generate messages even without a script, if the message is sent in the request