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

Community Support
1

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 }
2

Hmmm.

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

Did you mean this?

3

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?

4

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

It gives a sample the Integrations page I linked above.

5

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.

6

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?

https://developer.rocket.chat/apps-development/slack-compatibility

7

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.

8

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 https://developer.rocket.chat/apps-development/slack-compatibility, 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.

9

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.

10

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.

11

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.

12

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

13

An incoming webhook can still generate messages even without a script, if the message is sent in the request

Thanks, but that’s opaque. How is the message supposed to be sent? Is there a documented format?

And I didn’t cherry-pick - I went through my issues as a sample that I know well, on the basis that overall I had the same treatment as the general population. Most of my issues fall into neglect from the RC side. I’m sure you’re not suggesting that only my issues are neglected, and everything else is fine.

As for 8989, I have no idea what you mean. Does Rocket.Chat want broken German? Does it want a broken old Markdown parser? Does it want a broken new Markdown parser?

10585, nobody from the Rocket.Chat team said that on the issue, including you, including Diego. Just another orphan.

I can’t even be bothered for the others as I’m about to give up (read on), but I had to comment on 5667. Apparently I do need to @-people on GitHub, because there is no suggestion that they know (or remember, or care). What there is, is an endless sea of changing labels and milestones.

I think I’ll leave it here, because you (“Rocket.Chat”) is, as so often, on the back foot and more concerned with making excuses for mediocrity than making things better.

14

I’m really not sure what you want as an answer here - first I am sure you know how it works anyway.

Next:

https://docs.rocket.chat/guides/rocket.chat-administrator-guides/administration/integrations#incoming-webhook-script

WebHooks are simple event-notifications via HTTP POST. This way any application implementing a WebHook is able to POST a message to a Rocket.Chat instance and much more.

So just use any API call. They are all documented, though some new things may not be there yet - it is difficult as things are being developed so fast.

Some calls require a post call action, hence the script.

Not sure what else to say really.

If you have a specific issue then please document what you have done and where you might be stuck and we can try and resolve it.

Yes - they were your issues and not a random sample, so they were cherry picked.

8989 - What more can I say?

As was mentioned this is not a bug because there is nothing broken, but a discussion point. You can open it here, or on open. It isn’t necessarily being ignored.

No, actually most might not be where Rocket wanted to go, or they didn’t have the development capacity to deal with it and other issues had a higher priority. It is open source - you know that. Their direction of travel for development might not have been the same as yours. That is just the way it goes.

Actually no, you really don’t as it is just annoying and you just get ignored. As you know in Agile dev the developers don’t choose what gets developed. So it is a pointless exercise. You will get much further by working with the Community Team who have access to the people who DO makes the decisions.

Yup we know, and unbeknownst to you we are working on a new simplified labelling system because we know the existing one is a mess and unused. In part that is because github is not where all the development action happens. We are also going be having a big cleanup on bugs soon - we have started some things already, but it isn’t necessarily evident yet. If you contact me directly I can explain in more detail.

Yes that would be really good if you did leave it there. We are working really hard to make things better, including me now on my PTO, and to try and fix some of the things you are complaining about. We can’t do it immediately.

If you want to see change then it will only happen with positive action rather than endless complaining which gets nowhere. We would take a step forward if you helped with some constructive action rather than constant criticism which takes time to answer and really does nothing useful.

You have a choice here. You can help shape the future by helping, or sit on the sidelines and watch. I can assure you that some who have chosen to get involved are having a say right now in what is happening because they have wanted to get involved and are being listened too. Issues being chosen to be looked at and fixed. UI/UX testing, and lots more. You are missing out.

If you want to make a difference come and talk to me.

15

Hi @antgel (sorry for @'ing, want to make sure you don’t miss this!)

Small rant (is it really a rant though? :no_mouth:)

I don’t want ro repeat what John said there, just that 100% correct.

But at the same time, you’re right in some regards as well. I can’t say for what used to happen since I wasn’t here back then, nowhere near even.

Right now, we ARE working to fix the wrongs.

Actual post

You’re right. The documentation regarding incoming/outgoing webhook scripts are NOT clear enough. And I’ll tell you something, after joining, I myself was confused for a while that what the hell was its purpose?

Here’s the answer -

I’ll take incoming webhooks as my reference frame here.

Consider some app, POSTing some data to the rocketchat incoming webhook endpoint - it isn’t necessarily in the structure that RC understands.

How do you fix that? Webhook scripts.

The process_incoming_webhook method takes a parameter request - this object holds the data that was sent from the other application (namely in request.content). Now through the script you can modify the data to something that RC understands, and voila, it’s going to work as you’d want it to.

You can basically do whatever you want to with the incoming data through the script. One example is this issue right here, please go through it whenever you have time - Bug in the attachment text parsing · Issue #22867 · RocketChat/Rocket.Chat · GitHub

Basically you don’t always have control over the data that’s being sent, so the script is there to enable you to modify it to your needs.

Documentation

I’m not going to ignore the fact that you’re absolutely right on saying that these should be clearly documented.

I will talk to our documentation team to update it asap. They’re already working on many parts of our docs. We know that its $h|* :stuck_out_tongue:

That being said, I’ll admit, I might just forget. I hage a pile of things that I neee to take care of and I’m already behind schedule.

What I’d really, REALLY appreciate, is if you could ping me on the open server, just once about this documentation part. I might just update it myself if need be. You can find me on open under debdut.chakraborty

Finally, we do care and we’re trying so damn much to make things better. We’ll continue to do so.

Thank you for being part of it :slight_smile:

16

Thanks, you explained what happens what happens when Script Enabled is activated. I understand that. What I don’t understand is what is the point of deactivating a script? Clue: What is this magic “something that RC understands” when the setting is off?

17

You could disable for testing, or if it is not required for a time, or there is no code to process, or any other reason you feel is suitable.

It just doesn’t process the JS code in the box. Simple as that. There is nothing compicated about it. Check the source code if you want - it is all in github.

I’m not sure what is so hard to understand about it, nor why you are making such a meal of something that is so trivial. If you don’t need it disabled, ignore it the setting and leave it enabled.

1 Like
18

Spoilt only by the fact that I’m not talking about the webhook enabled toggle, rather the script enabled toggle. Please, if you’re going to be condescending, at least understand the issue. Why would one want an enabled webhook with no script enabled given that the script does the parsing?

I know I can read the source, let’s just close the forum because everyone can do so. Get real. I came here for support, nobody knows the answer, let’s leave it at that.

19

Incoming webhooks expect a very specific json structure for a message. Please see the example code in our integration documentation, notice the return statement. The structure is as follows -

      content:{
        text: request.content.text
        // "attachments": [{
        //   "color": "#FF0000",
        //   "author_name": "Rocket.Cat",
        //   "author_link": "https://open.rocket.chat/direct/rocket.cat",
        //   "author_icon": "https://open.rocket.chat/avatar/rocket.cat.jpg",
        //   "title": "Rocket.Chat",
        //   "title_link": "https://rocket.chat",
        //   "text": "Rocket.Chat, the best open source chat",
        //   "fields": [{
        //     "title": "Priority",
        //     "value": "High",
        //     "short": false
        //   }],
        //   "image_url": "https://rocket.chat/images/mockup.png",
        //   "thumb_url": "https://rocket.chat/images/mockup.png"
        // }]
       }
    };

IF your other server POSTs a JSON that conforms to this structure, you don’t need a script because rc will be able to parse and process the payload as is.

If say the other server is POSTing something like this -

{
  message: "hello world!"
}

Rc won’t be able to process it because it isn’t expecting this structure. So now you can use a webhook script, that will return a new json, with the data from the payload like this

return {
    content: {
        text: request.content.message
    }
}

Hope this makes it clear now. Thanks.

20

Thank you, finally! Do you have a link to that doc for anyone else who might come by here? If I can see the whole doc, maybe I can work out how to patch it for future browsers.