🎩 What? Why?

WIP

We want users to be able to follow some resources in Decidim, we'll start by Meetings as per #1692 but the implementation should take a polymorphic account so following other resources should be easy to implement.

I'm using ActiveSupport::Notifications to notify events to the whole application and ActiveJob to act on those events.

📌 Related Issues

• Fixes Follow a meeting #1692

📋 Subtasks

• Add the Follow entity, which relates a user and a Followable resource (unique per user/resource combo)
• Add the Notification entity, which is related to a user and a Followable resource. Not unique. Needs to have an notification_type so that notification templates can be customized in a per-event basis.
• Create a Followable concern/module encapsulating all the logic for followable resources (only Meetings in this PR) and make it include Notifiable
• Add events
• Add event_class param to Decidim::Events. The event class must be a class that wraps the event name and the resource and builds the needed information to publish the event to the different subscribers in the system.
• When an event is triggered for a Followable resource, for each follower trigger a job to create a notification. This job should check whether the resource is notifiable for the given user or not (by default, true, but this might change for proposals - eg. the proposal author does not want to be notified when they update that proposal). This should be checked in the notifiable?(context) method in the Notifiable concern. Also, Followable should set the users_to_notify method to followers.
• Make event emitters know which users should receive the notifications. Send an array of user IDs along with the event, and make the jobs check for that array when generating the notification. This allows us to decouple the notifications generation system from the Followable concern and generate system-wide notifications about things that are not followed by a given user.
• Create an event_class for each event.
• Create an EmailNotificationGenerator, with its needed jobs, so that events can generate emails.
• Move email texts to I18n
• Add a Notifications Dashboard where a user can check all their notifications. Use the event_class to generate the logic needed to render the notification
• Rename fields in Notifications (followable => resource, notification_type => event_name), add "read_at" field
• Modify the resource_icon in IconHelper to handle processes and assemblies
• Notifications i18n
• Set notification as read by clicking on a button and delete them
• Add a button to mark all notifications as read
• Filter notifications by type (?) and paginate them
• Add missing docs
• Make event classes know about the path of the notification icon. Try to get it from the resource.feature.manifest.icon, or from resource.manifest.icon, so it can be overwritten for specific event classes.Needs to know whether to use icon or external_icon methods, depending on the value, so it isn't that easy.
• Add a way to follow meetings from the UI. Should be separated, so that it can be reused by other resources.
• Update Changelog