Defect #39854
closed"For any event on my bookmarked projects" option not sending notifications for non-member bookmarked projects
0%
Description
When selecting the "For any event on my bookmarked projects" option under email notifications, it is expected that users will receive notifications for events in their bookmarked projects, regardless of their membership status in those projects.
However, it has been observed that notifications are only received if the user is both a member of the project and has it bookmarked.
The issue appears to be related to the logic defined in the following section of the code: https://github.com/redmine/redmine/blob/4cc0b8d2ca80f4de3a0217184e9ef982f2407c05/app/models/user.rb#L494-L505
This code updates the list of projects for which notifications should be sent. However, it seems to rely on the 'mail_notification' column of the member model to determine whether to send notifications, which does not account for non-member users who have bookmarked the project.
Therefore, if you are not a member, you will not receive notifications for projects you have bookmarked.
Related issue: Feature #35189: New email notification option "For any event on my bookmarked projects"
Files
Related issues
Updated by Mizuki ISHIKAWA 8 months ago
- File defect-39854.patch defect-39854.patch added
I couldn't come up with a good idea to send notifications to non-members, so I attached a patch to keep the functionality as is and adjust the terminology to match the actual functionality. In the patch, I changed the label key to avoid confusion with labels that have already been translated.
Updated by Marius BĂLTEANU 8 months ago
- Related to Feature #35189: New email notification option "For any event on my bookmarked projects" added
Updated by Jens Krämer 8 months ago
I would prefer if we could extend the current implementation so we can send notifications about bookmarked projects even if the user is not a project member.
Updated by Marius BĂLTEANU 8 months ago
Jens Krämer wrote in #note-3:
I would prefer if we could extend the current implementation so we can send notifications about bookmarked projects even if the user is not a project member.
I'm in favour of this as well. Will you work on this implementation or do you need help?
Updated by Jens Krämer 7 months ago
Ideally we could query for get me all users who have set their preference to 'bookmarked' and who have bookmarked project X in Project.notified_users
. This would make life much easier and we would not need to store this information anywhere else (that is, we would not have to abuse members.mail_notification
for storing the notification setting of bookmarked projects).
As it is now, due to the serialized user preferences that hold the notification preference as well as the actual bookmarks, this would mean loading all preferences and doing a full scan in Ruby code. Since this runs in all kinds of hooks whenever something changes this likely isn't going to work well.
We could introduce a separate model to store project bookmarks - the structure would look like members
, and the bookmarks.mail_notification
flag would be managed and used in the same way members.mail_notification
is right now. I don't feel great about this since it feels really redundant.
Alternatively we could pull out the mail_notification
flag from members
and introduce a new table dedicated to such user-project-settings, regardless of actual project membership. Then the current logic that rewrites the mail_notification flags when a user updates their pref could stay as is, it would just have to work on the new table.
I could also imagine allowing Member
records without any associated roles, just to hold the notification settings. But this is certainly going to break lots of stuff initially.
If this happened in a 'fresh' project, the bookmarked project ids would probably be stored in a JSON column that could be indexed and queried directly, but I am not sure if this is feasible to build and have it perform well in all the databases we support.
What do you think?
Updated by Marius BĂLTEANU 7 months ago
Thanks Jens for your analysis on this!
I was thinking as well to pull out the mail_notification to a separate model in order to have maximum flexibility, but now that I read your analysis and having fresh info after my work at #36162 which is related to how Redmine is sending the notifications, I've a new ideea that I would like to evaluate together.
First of all, I think committing #35189 as it is was wrong from the beginning, even if it looks like a very nice feature. I'm saying this because internally we just introduced another "entity" that manages the notification and this brings complexity and more edge cases (like this issue).
What about introducing the option to (1) watch a project using the acts_as_watchable
in order to get notification from that project and to (2) improve the UI of "Add bookmark" to have options like:
- add bookmark and watch (two actions with one click)
- only add bookmark
- only watch
with clearly text for users to indicate what means each option.
Of course, we still need to clarify some aspects, but I think we can obtain the same functionality for the users while keeping the code more clear internally.
Updated by Jens Krämer 7 months ago
I agree - watching a project in order to get notifications feels more natural than having this as a side effect of bookmarking. Also it's reasonable to be able to have one without the other. I am not sure if the "add bookmark and watch (two actions with one click)" option is really necessary - this is something users will usually only ever click once for any given project, so probably it's better to keep this simple.
If we rolled back #35189 and introduced watchable projects instead, we would not even need another option in the notification preferences since this would be covered by the existing "notify me about things I watch or am involved in" option.
I wonder if, as a next step, we might even be able to remove the option to explicitly select projects to be notified about since the same can be achieved by simply watching them.
Updated by Marius BĂLTEANU 7 months ago
Jens Krämer wrote in #note-8:
I agree - watching a project in order to get notifications feels more natural than having this as a side effect of bookmarking. Also it's reasonable to be able to have one without the other. I am not sure if the "add bookmark and watch (two actions with one click)" option is really necessary - this is something users will usually only ever click once for any given project, so probably it's better to keep this simple.
Agree with having distinct actions.
If we rolled back #35189 and introduced watchable projects instead, we would not even need another option in the notification preferences since this would be covered by the existing "notify me about things I watch or am involved in" option.
Yes, I'm going to revert that ticket and close it as "Won't fix" together with this one.
I wonder if, as a next step, we might even be able to remove the option to explicitly select projects to be notified about since the same can be achieved by simply watching them.
Indeed, there are some improvements that we can do on top of watchable projects, but we need to write them down before start working on this.
I think here we have a conclusion regarding notifications based on bookmarked project, I propose to move the discussion about watchable projects to a new issue.
Updated by Marius BĂLTEANU 7 months ago
- Status changed from New to Closed
- Resolution set to Wont fix
I've reverted the changes from #35189 after we agreed that handling the notification based on the bookmarked flag is not the best solution.