[IMP] webhook_outgoing: send outgoing webhooks

[hoangtrann]

No description provided.

[rvalyi]

Great! Using queue job also seems interesting. I didn't dig deeply into the review yet though, but I might use it and help.

For reference here is the webhook code In Odoo 17.0+ CE (so not available on Odoo 16.0)
https://github.com/odoo/odoo/blob/master/addons/base_automation/models/base_automation.py#L98

(usage can be seen here https://medium.com/@karan.bk/simplify-integration-with-odoo-17-using-webhooks-4ec56c46fcb3)
This is not a lot of code; eventually there are some ideas to get, eventually some sort of compatibility can be achieved.

EDIT: to achieve some kind of compatibility, from a quick overview:

• it looks like the webhook.consumer object of this PR could be merged into the Odoo base.automation object from base_automation. Fields can be made the same.
• base_automation don't use queue job, so eventually, this would be a great addition from this extra OCA module.
• the ir.actions.server override here is minimal just like it is minimal in base_automation, so we could easily ensure it works closely enough: https://github.com/odoo/odoo/blob/master/addons/base_automation/models/ir_actions_server.py#L54
• In this PR calls are logged in a new object called webhook.logging while in base_automation, the log object is ir.logging that is available at least since Odoo v14: https://github.com/odoo/odoo/blob/16.0/odoo/addons/base/models/ir_logging.py

cc @pedrobaeza @sebastienbeau @hparfr @sbidoul @lmignon @simahawk @etobella

[rvalyi]

there is also possibly some overlap with https://github.com/OCA/web-api/blob/14.0/webservice/models/webservice_backend.py from the https://github.com/OCA/web-api/tree/14.0 OCA project. In any case, quick and dirty web hooks with no code is certainly something important to have for simple and quick automation.

[rvalyi]

it can also be installed as an option, but eventually this server_action_logging module might help.

[rvalyi]

BTW, @gurneyalex pointed that the security of the native Odoo v17 web hooks is probably not so good: https://x.com/gurneyalex/status/1817900552329560150 ...

So good if this extra module could bring some real security... Is it safe now https://github.com/OCA/webhook/pull/13/files#diff-ca6b9e897fddbb1f998aefd239a9630cef55fbdcd6de7a2b20043e2faff24b29R28 ?

Eventually, we might use base_rest_auth_api_key https://github.com/OCA/rest-framework/tree/16.0/base_rest_auth_api_key may be ?

[ivs-cetmix]

@hoangtrann @rvalyi looks like `codecov/project' action is still running. It will consume tons of minutes

[ivs-cetmix]

also @sbidoul please have a look at the codecove job here

[hoangtrann]

@ivs-cetmix force push to trigger actions seem to solve the issue

[ivs-cetmix]

Thank you once again for your contribution. Some thoughts here:

• Probably the first module should be named something like webhook_outgoing for better matching the module designation. Same for the module name and description
• Maybe it would be better to have 2 different PR's per module. You can add dependencies in the second PR using test-requirements.txt. This will make reviews and merging modules faster
• Test coverage is something that is a must so tests should be added in order to proceed further
• Same with documentation. However this is something we can also assist with

[ivs-cetmix]

We don't need this dependency because "base_automation" already depends on "base".

[ivs-cetmix]

Not an issue, just curios: how does this work in selection fields?

[ivs-cetmix]

"webhook_base" already depends on "base_automation" so no need to add "base" and "base_automation" here

[hoangtrann]

thanks @ivs-cetmix @rvalyi for your feedback, I've updated the PR to only include the webhook_outgoing for sending out webhook requests.

I've made changes accordingly as well:

• Merge with ir.actions.server, all fields are brought to this model
• I'd like to keep webhook.logging for now to log information that we can relate directly to the webhook

I'm going to update the tests as well as creating another PR for incoming webhook

[agent-z28]

@hoangtrann lets get it merged ! it's really great.

[lmignon]

Thank you for this addons. Can you add tests plz? Unittest are required to ensure code quality and maintainability.

[hoangtrann]

@lmignon I've added tests, sorry that it takes a while though

[hoangtrann]

ping @ivs-cetmix @rvalyi as well for review

[hoangtrann]

@OCA/tools-maintainers appreciate some reviews here

[rvalyi]

EDIT: hum, this PR is now only for the outgoing webhooks, so there is no such overlap issue here as I initially mentioned below here...

@simahawk @etobella @LoisRForgeFlow @lmignon @pedrobaeza @ivs-cetmix how do you guys see these modules here fit together with https://github.com/OCA/web-api (specially the endpoint and webservice API), seems there is some overlap for a webhook server. This proposal here is however closer to the Odoo native webhook thing that comes at v17+.

Ideally we don't duplicate efforts. But I didn't investigate too much if the webhook server here would still make sense or if convergence/compatibility is somewhat possible...

[ivs-cetmix]

@simahawk @etobella @LoisRForgeFlow @lmignon @pedrobaeza @ivs-cetmix how do you guys see these modules here fit together with https://github.com/OCA/web-api (specially the endpoint and webservice API), seems there is some overlap for a webhook server. This proposal here is however closer to the Odoo native webhook thing that comes at v17+.

Ideally we don't duplicate efforts. But I didn't investigate too much if the webhook server here would still make sense or if convergence/compatibility is somewhat possible...

I would partially agree with you, as the endpoint module does the job for us as an incoming web hook.
I think it would be more reasonable to put efforts towards improving the existing modules rather than creating a semi-copies of them in different repos.
One of the options could be to build a webhook repo modules as a wraparound over the web-api ones.
@hoangtrann

[rvalyi]

@ivs-cetmix I'm sorry I just found out that the scope of this PR changed and as for now only the webhook_outgoing module is proposed for review. So my previous comment was not pertinent anymore (I added an EDIT line).

[hoangtrann]

Yup I've separated this PR and made another one for incoming webhooks for ease of review. The major features this bring are render payload using Jinja template and execute using queue job. This allows user to quickly build an integration to send custom Slack notification for example.