Redmine

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.

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?

I'll give this a try over Christmas

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?

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.

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.

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.