-
-
Notifications
You must be signed in to change notification settings - Fork 409
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean the instance might not be notifiable, but the model is, in general terms.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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::Commentable
everywhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copy/pasted?
|
||
# 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
Result
is commented all participatory process admins should be notified. As @josepjaume suggested I created an abstraction calledNotifiable
with two methods:notifiable?
: Whether a notification should be sent or not.users_to_notify
: A collection of users to notify.I implemented the
Notifiable
concern methods to all theCommentable
resources so theauthor
is not checked to sent notifications.I refactored the
CreateComment
command code so it doesn't check flags anymore. The code was pushed to the model.📌 Related Issues
📋 Subtasks
None
📷 Screenshots (optional)
N/A
👻 GIF