* 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
* Send new comment notification service + specs
* Call new comment notification service from the model
* Return to non-bang notifications create
* An ActiveJob for the new comment notifications
* Call comments notification ActiveJob from Notification
