Redmine

The attached patch implements web hook support - to call / notify external services when something happens in Redmine.

While this patch just implements the issue create / update / delete events, it was built to be easily extended for lifecycle events of other entities.

Web hooks are defined at the user level, and always run in this users' context, regardless of who triggered the actual event. Events on issues a user cannot see will not trigger this users' configured hooks. The hook payload is JSON and has type (event), timestamp and data (the object involved) top level elements, using the existing issues/show API template for consistency to render the issue data inside data.

Each hook is defined for a list of events and projects. Whenever one of the events occurs in one of the projects, a POST request is sent to the configured URL with a payload depending on the event. Webhook signing with a pre-configured secret is implemented using the same algorithm GitHub uses .

This feature was developed and is in production use at Planio .

We'd very much like this to be integrated into Redmine, since it is really powerful when combined with platforms like Zapier or IFTTT. Zapier for example allows to define transformations (using Javascript) to change the JSON payload before triggering an action on another service and can therefore work as an adapter between Redmine and another service, even if the original payload format is not what the other service expects.

I rebased on current master, added a `use_webhooks` permission and also fixed some random test failures related to the caching of the IP blacklist configuration.

I've committed the change, but we have a Rubocop offense and I'm not sure if we should fix it or not:

Offenses:

app/models/webhook.rb:32:3: C: Rails/HasAndBelongsToMany: Prefer has_many :through to has_and_belongs_to_many.
  has_and_belongs_to_many :projects
  ^^^^^^^^^^^^^^^^^^^^^^^

1030 files inspected, 1 offense detected
Error: Process completed with exit code 1.

I'm attaching patch 0001 to fix another RuboCop error that still causes the lint check to fail.
I'm also attaching patch 0002 to remove unnecessary fixtures declarations from the Webhook test files.

I've confirmed that all tests and lints pass with these changes.

The Webhooks feature is a great addition. However, there may be cases where some users want to completely disable it. I believe providing an option to disable Webhooks can help users adopt Redmine 7.0 more smoothly.

• To operate Webhooks reliably, a stable environment for running asynchronous jobs is required.
  • The :async adapter is generally not recommended for production use, and :inline may noticeably slow down actions such as creating, editing, or deleting issues.
  • Even with other adapters such as :solid_queue, users may need time to verify behavior and scale their asynchronous job infrastructure accordingly.
• There may also be cases where Webhooks need to be disabled entirely for security reasons.
  • While it is possible to restrict Webhooks by disabling the Use webhooks permission for all roles, administrators can still use them.
  • Since Webhooks send Redmine data to external systems, some organizations may not want to allow this for any user, including administrators.

For these reasons, I'm attaching a patch that introduces a configuration option to enable or disable Webhooks.

Details of the patch:

• Adds webhooks: true/false to configuration.yml (default: true).
• When disabled (webhooks: false), Redmine behaves as if the Webhooks feature does not exist:
  • The Webhooks link is hidden from the My account page.
  • Webhook management pages cannot be accessed.
  • The Use webhooks permission is omitted (it does not appear in role settings).
  • Webhooks are never triggered.

Verification:

• All tests and lints pass.
• When Webhooks are enabled, registration, triggering, and permission checks work as expected.
• When Webhooks are disabled, Redmine behaves as described above.

Screenshots:

My page when disabled:

Roles when disabled:

Webhooks (/webhooks) when disabled:

Marius BĂLTEANU wrote in #note-27:

Regarding the setting, adding it to the configuration.yml it will be confusing for users because all the similar features are configurable in the administration and the best example is the API, which is very similar to webhooks because it provides you access to the data from external services.

I'm in favour of:
1. Add this option to administration settings.
2. The API tab it will be a good option, but I think we need to rename it to "Integrations", "API / Webhooks" or any other good wording.

Thank you for your feedback. I agree with your point.

Im attaching a patch to add the Webhooks option to the administration settings. The patch includes the following changes:

• Add the "Enable Webhooks" option to the API tab in the administration settings
• Rename the API tab to "Integrations"
• The option is enabled by default

Ive confirmed that:

• All tests pass
• When Webhooks is disabled, all users including administrators cannot configure Webhooks, and existing Webhooks are not triggered