Daniel F

It seems you're logging "all" the stuff. Check your constants.php and remove the row with DEBUG_LOG

IC5 will already have this featured

Couldn't you use the HTML widget in combination with the code posted in ?

Yes, Zapier is the easiest way to go.

I have just pushed the fix to our repo. Once it was reviewed and approved, it will be shipped in a future release:)

Thanks a lot! I can confirm that it's missing here. I have filled a bug report for this and a missing language string which I noticed while testing this.

Can you please explain what exactly you mean? It is also fired when one changes his status

It's the "Can edit silently?" group setting.

I can't reproduce this, it's working fine for me. In fact the same webhook is fired for all 3 RSVP states, you have to look for the "action" parameter in the payload, which can be "yes", "no" and "maybe"

The "alert_cant_dismiss" language string is indeed missing in v4 & v5. I have just added it for an upcoming release and I'm looking now at the other issue. Edit: Yes, I can confirm that this is a bug.

No need for a new bug report, I already reported it to our internal bugtracker yesterday.

it's setting the correct date (date is set to today -24h) but yeah, I have noticed that the record_publish_date column contains the current timestamp which is a bug.

This really shouldn't make any difference. An upgraded site won't load anything different to a new installation. The same templates and same JS & CSS files will be returned, it may have some slower DB queries on really really big communities compared to a new, empty installation, but that's all

No, the \ is just a namespace separator, it doesn't matter if it's with or without. I guess yo meant // 😉 Are you still having the issue @Olivier Frascone ? I was able to login into your ACP with the details we have on file and haven't gotten any error.

You had still tasks from uninstalled applications/plugins in your database? Where these from were old 3rd party stuff?

You can have a test/dev instance

There are 2 settings for sendgrid 1. ACP => Integrations => Sendgrid 2. ACP => System => Email Make sure that it's disabled on both.

Is this still an issue on your community?

Was this error logged again since then?

This was answered already in another topic, but leaving the link here too

We have changed this in the recent release

Pleas visit the support area in your ACP and apple the patch which will resolve this issue.

The API doesn’t have any “protection” per se, we’re expecting from the client application to implement their own spam/flood protection if it’s needed.

Is your IP address changing?