* chore: rubocop
* feat: rename the worker in accordance to our guidelines and to be more verbose
* refactor: move the NotificationsModeration service to be a users query, and move the constants out to new files
* refactor: removed subscribed_to_mod_roundrobin_notifications? which was only being used once in a test
* refactor: remove the aliass from the user method and add them to notification_setting + update references
* Convert symbol hash keys to strings when calling .perform_async
Fixes a warning from Sidekiq 6.4.0+ about perform_async arguments
which are not equal when passed to perform (`JSON.parse(JSON.dump(arg))`
should equal arg).
This is a safety measure to prevent passing objects (like classes, or
model instances) rather than their representations (like a class name,
or a model's attributes hash).
This warning will be an error in sidekiq 7
* Turn warning into an error in non-production environments
* Use string keys for reaction notification and article fetched
Missed these two on the first pass
* Update example argument hashes for #enqueues_on_correct_queue
Since this calls perform_async under the hood we need to pass json
safe hashes in the test cases as well.
https://github.com/forem/forem/blob/main/spec/workers/shared_examples/enqueues_on_correct_queue.rb
* Convert keys from FollowData#to_h to string before perform_async
I'm not sure enough where else (outside of notification) to_h is being
called, so I'm converting here when building args, rather than in
FollowData#to_h, which might be my next step.
* Let FollowData#to_h return a hash with string keys
Update spec to use string keys as well.
* Make to_h return string keys for ReactionData
Like FollowData, the #to_h method is only used to call
notifications (this is used to enqueue sidekiq jobs).
* Remove a key that was in the hash
Since reaction_data calls to_h, it gets string and not symbol,
keys. Call Hash#except with a key that was actually there.
I saw the following error in Honeybadger:
```
[PROJECT_ROOT]/app/services/notifications/reactions/send.rb:61 :in `call`
old_json_data = notification.json_data
previous_siblings_size = notification.json_data["reaction"]["aggregated_siblings"].size if old_json_data
notification.json_data = json_data
[PROJECT_ROOT]/app/services/notifications/reactions/send.rb:20 :in `call`
[PROJECT_ROOT]/app/workers/notifications/new_reaction_worker.rb:16 :in `perform`
[PROJECT_ROOT]/app/models/notification.rb:84 :in `send_reaction_notification_without_delay`
[PROJECT_ROOT]/app/controllers/reactions_controller.rb:136 :in `destroy_reaction`
[PROJECT_ROOT]/app/controllers/reactions_controller.rb:168 :in `handle_existing_reaction`
[PROJECT_ROOT]/app/controllers/reactions_controller.rb:77 :in `create`
```
As I was exploring the error, I saw that we were making assumptions
about the data coercion. These are valid and somewhat stable
assumptions, but I wanted to look a little deeper into the situation.
This refactor helps consistently negotiate two situations where we're
transforming request-cycle models into lightweight data structures. It
also begins to show a path towards a generalizable "macro" for this behavior.
Related to #2122, #9534
* Favoring delete_all on user relationships
Prior to this commit, several of the user's "has_many" were marked as
`depenedent: :destroy`.
In the case of :destroy, ActiveRecord instantiates each object and then
runs destroy. Whereas in the case of :delete, ActiveRecord issues a SQL
command to delete the related files.
It is often "safer" to use :destroy, as it guarantees that you'll
instantiate the record and run it's callbacks. But sometimes you have
to go with the speed of SQL.
And while not directly related to #15424 it is representative of our
callback ecosystem creating some unexpected computational loads.
Related to #15442 and #15424
* Noting models that user no longer cascade destroys
* Initial work for @-mention notifications from posts
* Revert article.published changes to article updater, add clarifying comments
* Extract article preview into reusable partial for notification views
* Clean up Article Updater
* Address + remove some FIXMEs
* Add a whole buncha specs for @-mention functionality in posts YAY
* Refactor create all spec to use shared examples, add clarifying comments
* Add guard clause to create all service
* Update new mention and notifiable action specs
* Some additional cleanup
* Add specs + shared examples to SendEmailNotificationWorker spec
* Use aggregate_failures where applicable
Co-authored-by: Michael Kohl <citizen428@dev.to>
* Cleanup and address code review comments
* Add MentionDecorator + relevant specs
* Address comments/issues flagged by @rhymes
* Optimize plucking user_ids when checking for article followers
Co-authored-by: Michael Kohl <citizen428@dev.to>
* Add "Welcome" type to Broadcasts, allow dynamic "authoring" of Broadcasts
This adds a new `type_of` to the Broadcast model: "Welcome". As we begin to create a new "welcome notification" workflow, we'll categorize them by making them all of the same type.
This also adds a concept of a "welcoming user", which can be set via an ENV var. The WELCOMING_USER_ID will allow us to explicitly set (and change) which user in the database is the one that "sends" welcoming notification. In production, we plan for this to be dev.to/sloan.
* Allow WelcomeNotificationWorker to accept + send any kind of broadcast
This abstracts out the logic of deciding which broadcast to send from the woker into the calling method. This will help us send many different kinds of welcome notifications using one, resuable worker class.
* Raise if a Notification can't be created
* Add STAFF_USER_ID as an ENV var
This is in preparation for moving away from SiteConfig.staff_user_id, and replacing it with an ENV var. We will need to set this in production first, and then make a separate PR to replace all instances of staff_user_id with the newly-set ENV var.
* Prevent need for eager loading
* Add initial implementation of user block
* Remove debugger oops
* Add index and foreign keys for user_block table
* Use private method instead of exists
* Move channel handling logic to service object
* Update styling a bit
* Use profileDropdown file for future proofing
* Remove commented out code
* Render json: { result } for all endpoints
* Add statuses for sad paths
* Add better sad path handling in the JS
* Remove accidentally committed spec file
* Don't wait for DOM to load block button
* Use equality for accuracy in slug query
* Add status code for unauthorized requests
* Add missing comma sigh
* Increase efficiency and fix pagination offset issue
Right now we filter recently aggregated notifications at runtime, which worked before when there was no pagination, but now filtering is not a good idea combined with offset pagination because it throws off the calculations.
The filtering should be done in the SQL query before paginating, which is what we've switched to. I added a bunch of scopes to make the code clearer as well.
To avoid nesting tags I've also updated the HTML and the JS logic to insert it in the right place.
* Add explanation for hiding the load more button for new users
* Clarify uncommunicative variables in labor classes
Single letter variable names are largely a question of preference, in
some cases I think that convention mitigates the opaque nature of single
letter variable names (e.g., e for error, i for index, etc).
However, in some cases they can be unclear and there isn't much reason
to use single letter variables unless for some reason character length is
really important.
In this case, I would prefer clarity in variable names over brevity of
code so I've used Reek to identify short variable names and I'm changing
them.
It's pretty boring, but hopefully incremental code love changes like
this one add up and improve readability and accessibility for those
interested in reading this codebase.
* Remove commented code from 2 years ago
* Clarify uncommunicative naming in services classes
There is some context for this change in 6b81880f
* Clarify uncommunicative naming in models
There is some context for this change in 6b81880f
* Clarify uncommunicative naming in liquid_tags
There is some context for this change in 6b81880f
* Moved notifying followers to a service + specs
* Created an ActiveJob for notifiable action notifications
* Call the job from the Notification#send_to_followers
* Refactor creating notifiable action notification
* Handle possible nil followers while sending notifiable action notification
* Use activerecord import to bulk-create notifications
* Set notified_at for the bulk-created notifications
* Move compact to the appropriate place
