Redmine

The previously attached patches have conflicts, so I’m attaching a new patch, Adds-reaction-feature.patch, with the conflicts resolved. This patch includes both the implementation and test code. If there are any future conflict resolutions or updates, I will attach a new patch with the same filename.

I strongly support adding a reaction feature to Redmine.

It would make it easy for users to show agreement or feedback with a simple click. Since a feature like this is common nowadays, even beginners can use it intuitively. This could help activate communication by making it easier to respond.

Currently, many users post "+1" comments on www.redmine.org to show their support for the issue. If we have a reaction feature, users can react without posting "+1" comments, helping keep discussions more focused.

The proposed patch allows administrators to disable reactions if they don't need them, so it won't negatively affect users who prefer not to use it.

Many modern tools like GitHub, Jira, Asana, and GitLab already offer reaction features. Without a similar feature, Redmine might be seen as lacking something important.

A feature like this has been requested repeatedly. You can see this from #1011, which was posted 17 years ago, and its related issues.

Let's include this long-awaited feature in 6.1.0. I am setting the target version to 6.1.0.

Holger Just
I appreciate your review of this patch. Please find my responses below.

In the ReactionsController, we should first check require_login, followed by check_enabled to avoid leaking the setting value to anonymous users.

You're absolutely right. I will fix this.

The ReactionsController probably needs to check the request format and handle non-js requests. See #39894 for a similar issue.

I don't think the issue described in #39894 would occur, as the actions in the ReactionsController require authentication. However, explicitly indicating that the controller expects only JS format requests improves code readability. Therefore, I will modify the controller to return a 404 response for non-JS requests.

In the reaction_text_enabling_reactions translation, we probably don't want to spell out the list of objects one can react to so that this list does not become outdated or incomplete if we or plugins later extend the list. This should be more generic.

I agree. The description was intended to help explain the features reactions can be used with, but it's merely supplementary and not essential. Based on your feedback, I will remove the description from the setting.

The reactions should also be included in the API responses for issues, messages, ..., possibly behind an include flag

I suggest we leave it out of the scope of this patch for now and only consider it when there is a concrete proposal or demand for API integration, including discussions around the API specification. The reasons are:

• We need to discuss both the necessity and the design of API support.
• Keeping the scope of this patch minimal will help facilitate focused discussions and reviews.

I will respond to the following points separately, but I will at least address the first one in an upcoming update:

• We may need to check user visibility in the list of users who reacted to an object and only include users visible to User.current. As anyone can react, this may expose non-visible users otherwise. For that, it may be possible to introduce Reaction.visible scope or some other way to filter users.
• I'm not a fan of returning final user names in Redmine::Reaction::Reactable@reaction_user_names. I think we should return actual User objects here rather than names (and thus rename the method). The consumer should then format the user appropriately on the view/helper or e.g. the API. This also applies to Reaction.users_map_for_reactables

I've uploaded a new patch that includes the above changes along with some additional improvements. The file name remains Add-reaction-feature.patch. If you would like to test the patch locally, please use the version with the most recent upload date. You can also view the detailed diff on GitHub here:
https://github.com/hidakatsuya/redmine/compare/master...hidakatsuya:redmine:reaction-feature-updates

The changes included in this patch are as follows:

• Explicitly handle only JS format requests
• Check login status first to prevent configuration leakage
• Remove setting description to avoid inconsistencies if the scope of the feature changes
• Add a readonly style to reaction buttons
• Fix an incorrect expected value in the helper test
• Fix an issue where reaction button positions shifted when zooming in or out

Prevent reactions in closed projects (#note-9)

I've addressed this point and attached an updated patch. The changes are as follows:

• In closed projects, reaction buttons are always displayed in a read-only state, just as they are for anonymous users.
• Rather than adding a dedicated permission, I extracted the logic for determining read/write access for reactions into separate methods for clarity.

You can view the detailed diff of the updated patch on GitHub:
https://github.com/hidakatsuya/redmine/compare/master...hidakatsuya:redmine:reaction-feature-updates

User visibility check in reactions #note-8
Return User objects instead of names #note-8

I have updated the patch to hide the names of users who are not visible to the current user (i.e., users not included in User.visible(User.current) ) in the tooltip for reaction users. Instead of showing their names, it now displays a summary like "and 2 others".

Along with this, I refactored the implementation for retrieving reaction data for each object to improve performance (faster response time, reduced memory usage, and better scalability). As part of this change, the reaction data now returns full user objects instead of just user names.

• Exclude invisible users from the reaction user list and improve performance and scalability
• All updates

Apologies for the delay. With this update, I believe all the feedback has now been addressed.

Here is the latest performance comparison. These results are based on opening an issue detail page containing 50 notes (journals), each with 10 reactions. Note that the measurements were taken on a different machine from the one used in the original issue description.

The tools and scripts used for this benchmark can be found here .

Detailed Response Time MeasurementsDetailed Response Time Measurements

Initial run (excluded): time_total: 0.199738, http_code: 200
Run 1: 0.192545
Run 2: 0.200029
Run 3: 0.186287
Run 4: 0.191257
Run 5: 0.194634
Run 6: 0.188203
Run 7: 0.199173
Run 8: 0.192329
Run 9: 0.189462
Run 10: 0.193369
Average: 0.192728
Median: 0.192437

Initial run (excluded): time_total: 0.178120, http_code: 200
Run 1: 0.182629
Run 2: 0.176420
Run 3: 0.176992
Run 4: 0.174192
Run 5: 0.174728
Run 6: 0.169343
Run 7: 0.181807
Run 8: 0.176025
Run 9: 0.183520
Run 10: 0.174477
Average: 0.177013
Median: 0.176222

I found an issue where reaction buttons on issues shift downward when Gravatar icons are enabled. I've attached an updated patch that fixes this problem.

Before fix:

After fix:

You can view the detailed diff of the updated patch on GitHub:
https://github.com/hidakatsuya/redmine/compare/master...hidakatsuya:redmine:reaction-feature-updates

Committed the patch in r23755. Thank you for your great contribution.

Thank you for your commit.

I'm attaching a small patch to handle a corner case where a user associated with a reaction doesn't exist for some reason. Please review and commit this additional change.

I appreciate your feedback.

Holger Just wrote in #note-20:

I can easily think of cases such as a client-facing development environment, where the mere fact that someone has reacted may divulge too much information. In about all other areas of Redmine, we always take only visible information into account (sometimes under great pains) to avoid showing data the current user can't see.

I understand and agree with your point. I've attached a patch that changes the behavior so that reaction details (number and usernames) are shown only for users visible to the currently logged-in user. I would be grateful if you could review it and consider committing it.

With this patch applied, the case described in #note-15 would be displayed as follows:

Thank you for the clarification. I've attached patch 0003, which keeps the method name as visible? for consistency.

When committing, please fixup patch 0003 into patch 0002 before committing.

I’ve confirmed that all tests pass after applying this patch:
https://github.com/hidakatsuya/redmine/actions/runs/15033005022

• Emphasize the presence of reactions by hiding the count when the number of reactions is 0.
• Emphasize the presence of reactions by making the reaction count bold.
• Prevent the underline from appearing below the reaction count on :active and :hover states of the reaction button.

This patch was created with advice and reviews from Katsuya HIDAKA.

I've attached a patch to display reaction buttons for journals without notes (i.e., journals that only show property changes). The reasons are as follows:

• It improves UI consistency by showing reaction buttons on all journals for an issue.
  • When journals with and without reaction buttons appear side by side (e.g., in the History tab), the inconsistency may be confusing to users.
  • Currently, if a journal with a note is edited and the note is cleared, the reaction button disappears — this behavior may be unintuitive.
• Even for journals without notes, users might want to react — for example, to express appreciation or say "well done" when an issue is closed.

History tab:

Property changes tab:

I've verified that all tests pass with this patch:
https://github.com/hidakatsuya/redmine/actions/runs/15063217744