Redmine

The only related feature I found: https://www.redmine.org/issues/23368 but is closed

This would be really nice. I'm trying to join in Camunda BPM into a ticket so a ticket can be assigned a proecess. Webhooks would be wonderful.

Anyone got ideas?

This functional is not realized?

I would also benefit form this feature greatly. We use Shortcut (shortcut.com) as a Scrum tool and it would be great if we could consume Redmine webhooks in order to update user stories in Shortcut.
Is there any plan for this feature?

Thank you for sharing this great patch developed at Planio! I believe it would be a very valuable improvement to Redmine.

I have just one concern: currently, it seems that any user can create webhooks.

Since webhooks automatically send data to external services, some administrators might want to restrict or even disable their use for security or data protection reasons.

To support such requirements, I think it would be helpful to have permission settings to control who can create or use webhooks.

Yes, I agree that some organizations might want to limit who can use this feature even if users only could share data they can actually see. I'll update this issue with a second patch that implements this soon.

+1

Marius BĂLTEANU wrote in #note-18:

but we have a Rubocop offense and I'm not sure if we should fix it or not:

I'm also not sure if we should fix it or not, but currently all commits since r24034 fail CI due to lint errors. It's a bit of noise when developing Redmine. If it may take some time to resolve, how about temporarily adding rubocop:disable to suppress the error?

diff --git a/app/models/webhook.rb b/app/models/webhook.rb
index 39e866343..d45a01e39 100644
--- a/app/models/webhook.rb
+++ b/app/models/webhook.rb
@@ -29,7 +29,7 @@ class Webhook < ApplicationRecord
   end

   belongs_to :user
-  has_and_belongs_to_many :projects
+  has_and_belongs_to_many :projects # rubocop:disable Rails/HasAndBelongsToMany

   validates :url, presence: true, webhook_endpoint: true, length: { maximum: 2000 }
   validates :secret, length: { maximum: 255 }, allow_blank: true

Katsuya HIDAKA wrote in #note-22:

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.

Committed the both patch in r24038 and r24039. Thank you.

Katsuya HIDAKA wrote in #note-22:

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.

Sorry for not double checking, I wanted to quickly help you and commit the fix and I failed.

Marius BĂLTEANU
No problem at all. Please don't worry about it.

I agree that having an option to enable / disable this feature could be useful for some instance administrators, but having a stable environment for running asynchronous jobs is required not only for this feature, but also for sending emails, destroying projects and other cases in the (near) future.

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.

Jens Krämer, do you have any preference regarding the recommendation made by Rubocop to use has_many :through instead of has_and_belongs_to_many?

Thanks, I've committed the change but I've added the label_integrations as a new key instead of replacing the existing label_api key.

The initial work is done, I've updated the locales and removed the to do.

I'm curious about the copyright section that I saw is missing on all these new files, is this expected or can I add the missing license block on all the files?

Jan Catrysse: Thank you for your contribution.

As Redmine 5.1 is now in its final security maintenance phase, it will not receive any new feature updates or non-security-related bug fixes anymore. Your patch will thus not be included in any 5.1 release.

In order for us to be able to use your work in a future Redmine version (such as 7.0), please rebase your patch on top of the latest trunk (which contains the current status of the webhooks feature). Your current monolithic patch duplicates a lot of exisging functionality and appears to subtly change some parts. This makes the patch very hard to review.

To be able to more easily evaluate your proposed changes, it is often helpful to extract the different changes in separate patches and to describe why you are proposing your specific changes, i.e. which specific problem they solve and (if applicable) why you chose your specific approach. With more manageable and up-to-date patches, your changes may become part of a future Redmine release.

Holger Just wrote in #note-37:

Thank you for your contribution.

As Redmine 5.1 is now in its final security maintenance phase, it will not receive any new feature updates or non-security-related bug fixes anymore. Your patch will thus not be included in any 5.1 release.

Hi Holger Just,

This feature was urgently needed for my production environment, and I hope it proves beneficial to others on 5.1.

When I have a few moments, I will update the patch to align with the main trunk and divide it into smaller components as you suggested.

Marius BĂLTEANU wrote in #note-33:

Thanks Go MAEDA for committing the last patch.

I've extended the webhooks to wiki pages. Please review the attached patch.

Webooks added for WikiPage.

Is it planned to add this feature to v6.1 as v5 is in its final security maintenance phase?

Lucas Schatz wrote in #note-40:

Is it planned to add this feature to v6.1 as v5 is in its final security maintenance phase?

No, it is not planned to add this feature to Redmine 6.1 series.

New features for Redmine are generally added in the next major release. At this point, the next major release will be Redmine 7.0. No new features will be added to the Redmine 6.1 series or any earlier stable releases. Only bug fixes will be applied to these stable releases.

Marius BĂLTEANU wrote in #note-39:

Webooks added for WikiPage.

I will fix the failing test tonight.

In r24198, webhook for WikiPage is added, but the newly introduced webhook_payload_test.rb was failing. In r24199, the failing assertion below was removed:

assert_equal @project.id, h.dig(:data, :wiki_page, :project, :id)

However, instead of removing the assertion, I propose including project information in the webhook payload. Reasons:

• Uniqueness: WikiPages can share the same title across projects. The receiver needs project.id to identify the page.
• Consistency: Issue webhook payloads already include project.id and project.name. WikiPage payloads should do the same for consistency.

The following change in show.api.rsb will fix the test:

With the following change, the WikiPage payload will include project.id and project.name, and the failing test will be fixed.

diff --git a/app/views/wiki/show.api.rsb b/app/views/wiki/show.api.rsb
index 6165a94cc..30c974714 100644
--- a/app/views/wiki/show.api.rsb
+++ b/app/views/wiki/show.api.rsb
@@ -7,6 +7,7 @@ api.wiki_page do
   api.version @content.version
   api.author(:id => @content.author_id, :name => @content.author.name) unless @content.author_id.nil?
   api.comments @content.comments
+  api.project(:id => @page.project_id, :name => @page.project.name) unless @page.project.nil?
   api.created_on @page.created_on
   api.updated_on @content.updated_on

Go MAEDA wrote in #note-46:

In r24198, webhook for WikiPage is added, but the newly introduced webhook_payload_test.rb was failing. In r24199, the failing assertion below was removed:

[...]

However, instead of removing the assertion, I propose including project information in the webhook payload. Reasons:

• Uniqueness: WikiPages can share the same title across projects. The receiver needs project.id to identify the page.
• Consistency: Issue webhook payloads already include project.id and project.name. WikiPage payloads should do the same for consistency.

The following change in show.api.rsb will fix the test:

With the following change, the WikiPage payload will include project.id and project.name, and the failing test will be fixed.

[...]

Committed this change as part of #43569, thanks for pointing this out.