Feature #42630
openAdd reaction feature
0%
Description
This patch adds a reaction feature.
- Adds reaction buttons to issues and notes, news and comments, and forum messages
- Shows a tooltip with the names of users who reacted—up to 10 names, with the remaining number shown if there are more than 10
- The feature is enabled by default and can be turned off in the administration settings
Please also refer to the following screenshots and GIF:
Background / Purpose¶
- In my experience, there are many times on Redmine when I want to react to something without leaving a full comment. Reactions are now a common way to express appreciation, agreement, or support. I believe this feature will help encourage more interaction within Redmine.
- Many modern project management tools like GitHub and Jira already support reactions. By adding this feature to Redmine, I believe it will help modernize the platform and promote its adoption.
Details¶
- The icon used for reactions is thumb-up. This icon is commonly used to express appreciation, agreement, or support, and is widely adopted in tools similar to Redmine, such as GitHub, Jira, Asana, and Slack. Based on my experience, thumb-up is the most frequently used reaction icon in these tools.
- Since reactions should be widely available by nature, this patch does not add a specific permission for them. Instead, access is controlled based on the following rules:
- Add/Remove a reaction: Any logged-in user who can view the object (e.g.,
object.visible?(user)
returns true) - View reaction button: Any user who can view the object
- Add/Remove a reaction: Any logged-in user who can view the object (e.g.,
Implementation¶
- To reduce memory usage and performance impact when displaying objects with many journals (such as issues), I implemented the feature to load only the minimum necessary data.
- I confirmed that all tests, including system tests, pass.
You can also check the source code on GitHub:
https://github.com/hidakatsuya/redmine/tree/reaction-feature-dev
Performance¶
The following results were measured using rack-mini-profiler and memory_profiler when opening an issue detail page. The tested issue has 50 journals, each with reactions from 10 users. The Redmine instance is running the latest trunk on PostgreSQL in production mode.
Response Time (average of 5 runs) | Memory Performance | |
---|---|---|
Reactions Enabled | 257ms | Total allocated: 14490218 bytes (128483 objects) Total retained: 2576895 bytes (7804 objects) |
Reactions Disabled | 214ms | Total allocated: 11122428 bytes (96509 objects) Total retained: 2064420 bytes (6036 objects) |
Files
Related issues
Updated by Katsuya HIDAKA 4 days ago
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.
Updated by Go MAEDA 3 days ago
- Category set to UI
- Target version set to Candidate for next major release
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.
Updated by Mizuki ISHIKAWA 3 days ago
+1
After applying the patch, it looks really good!
The thumbs-up icon is very useful because it allows users to widely express positive reactions, such as agreement, appreciation, or confirmation, without having to leave a comment.
I would really love to have this feature available.
Updated by Go MAEDA 3 days ago
- Related to Feature #1011: Add voting to tickets added
Updated by Go MAEDA about 18 hours ago
- Target version changed from Candidate for next major release to 6.1.0
Updated by Holger Just about 6 hours ago
Thank you for this proposal!
I do have some random remarks. Sorry for the brevity.
- 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 introduceReaction.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 actualUser
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 toReaction.users_map_for_reactables
- In the
ReactionsController
, we should first checkrequire_login
, followed bycheck_enabled
to avoid leaking the setting value to anonymous users. - The
ReactionsController
probably needs to check the request format and handle non-js requests. See #39894 for a similar issue. - In the
reaction_text_enabling_reactions
translation, we probably don't want to spell out the list ob 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. - The reactions should also be included in the API responses for issues, messages, ..., possibly behind an
include
flag
Some suggested feature work:
- Add a column and a filter for the
IssueQuery
to filter issues which the current user (or some other user?) has reacted to. This can be similar to the watcher column / filter. * A sortable column containing the number of reactions may be helpful. * For larger projects, a column/filter with some definition of of "recent" reactions might also help. - Maybe add a set of permissions to control who can react and who can see reactions. These permissions probably need to be per object type (i.e. separate permissions for issues and forum posts). At least a "can react" permission would be helpful.
- A useful (later) extension may be to add negative reactions (or something like a set of possible emoji reactions, some of which may be positive or negative). While this may still need additional refinements, the design should probably allow this as a future extension.
- A user may (optionally?) want to be notified when someone reacts to one of their posts.
Updated by Holger Just about 6 hours ago
One additional issue:
It must not be possible to react to objects in closed projects. This may require specific checks as the view permissions are still granted here, while changes must not be possible anymore.
Edit: This and similar issues may be solved by introducing new "View reactions" (read-only) and "React" (write) permissions, similar to the various watcher permissions. If desired, we could add a migration which sensibly grants these permissions to existing roles, e.g. mirroring the watcher permissions of the respective role.