Add notifications when a Result is commented#1543
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1543 +/- ##
===========================================
- Coverage 96.99% 64.73% -32.27%
===========================================
Files 494 56 -438
Lines 8430 984 -7446
===========================================
- Hits 8177 637 -7540
- Misses 253 347 +94 |
Codecov Report
@@ Coverage Diff @@
## master #1543 +/- ##
==========================================
- Coverage 97.01% 96.99% -0.02%
==========================================
Files 495 496 +1
Lines 8434 8461 +27
==========================================
+ Hits 8182 8207 +25
- Misses 252 254 +2 |
|
|
||
| # Public: Overrides the `notifiable?` Notifiable concern method. | ||
| def notifiable?(_context) | ||
| false |
There was a problem hiding this comment.
So is this notifiable or not? I mean, I feel it's weird having the Notifiable module included, but it not actually being notifiable. Maybe a better naming would solve this, but the current state feels very confusing to me :/
There was a problem hiding this comment.
Well.. I followed the same pattern as the Commentable module. I think it's just an issue about naming because the method is pretty handy to add some logic.
There was a problem hiding this comment.
I believe the method refers to the instance: A particular resource might not be notifiable in some circumstances, but the resource itself is.
There was a problem hiding this comment.
I mean the instance might not be notifiable, but the model is, in general terms.
There was a problem hiding this comment.
I find this confusing too. I interpret that Notifiable as a module means that the including object needs to define the interface (#notifiable? and #users_to_notify), whereas notifiable? itself means whether the class is actually notifiable or not. Is that it?
Also, should this inclusion be moved to the Commentable's module?
There was a problem hiding this comment.
Yeah I thought the same @deivid-rodriguez . I think the Commentable module can include the Notifiable but then I should rename it to something like NotifiableOnComment or something like that (I'm very bad at naming things).
There was a problem hiding this comment.
Well, I don't think the module is really coupled to comments in any way. It's just that the only usage right now is on every commentable, so I guess it's more DRY to let Comentable do the inclusion instead of having
include Decidim::Notifiable
include Decidim::Comments::Commentableeverywhere.
There was a problem hiding this comment.
The module itself is not coupled but their implementation on every model is right now. Let's keep it DRY for now and we can do renames on a later PR when we have other use cases.
| extend ActiveSupport::Concern | ||
|
|
||
| included do | ||
| # Public: Whether the object's comments are visible or not. |
|
|
||
| # Public: Overrides the `notifiable?` Notifiable concern method. | ||
| # When a proposal is commented the proposal's author is notified if it is not the same | ||
| # who has commented the proposal and if the proposal's author has comment notifiations enabled. |
There was a problem hiding this comment.
s/notifiations/notifications/
93072ba to
23e89e1
Compare
* Add Notifiable concern * Send notifications to users to notify * Add some tests * Fix rubocop issues * Add missing params to CommentNotificationMailer specs * Fix specs * Fix specs * Add some feedback * Specs: add process admin to test results notifications
🎩 What? Why?
When a
Resultis commented all participatory process admins should be notified. As @josepjaume suggested I created an abstraction calledNotifiablewith two methods:notifiable?: Whether a notification should be sent or not.users_to_notify: A collection of users to notify.I implemented the
Notifiableconcern methods to all theCommentableresources so theauthoris not checked to sent notifications.I refactored the
CreateCommentcommand code so it doesn't check flags anymore. The code was pushed to the model.📌 Related Issues
📋 Subtasks
None
📷 Screenshots (optional)
N/A
👻 GIF