* Replace current onboarding notification with set_up_profile welcome notification
Also ensure that only "active" set_up_profile welcome notification is sent, and that "inactive" ones are ignored.
* Notify only if broadcast active, log error if broadcast not found
* Reports to Honeybadger if an active broadcast cannot be found
* Reorganize order of generator specs
* Ensure welcome_broadcast can be written to in spec
* Remove redundant spec
* Add Welcome Thread Broadcast to generator.rb
* Add welcome trait to broadcasts.rb
* Add additional tests around welcome_broadcasts:
- ensure that the correct Broadcast is sent
- ensure that a User only receives a single Notification
- ensure that only certain Users receieve the Notification
* Refactor and remove unncessary code from generator.rb and generator_spec.rb
* Refactor generator_spec and eagerly load welcome_thread_comment to get spec passing
* Initialize user in place of receiver_id in generator.rb
* Add before action to make generator_spec more readable
* Add latest_published_thread method to generator.rb
* Update generator.rb to be reusable with latest_published_thread
* Update generator_spec to use welcome tags for Article obj
* Create mascot_account using let to reduce User creation in spec
* Adjust expectation for a User who should not receive a notification
* Use active in place of sent on internal broadcast routes
* Add and use active scope on broadcasts
* Update seeds + specs to use active broadcasts
* Add note about active broadcasts to /internal/broadcasts page
* Skip moderation notification if the user is the moderator
* Update spec/workers/notifications/moderation_notification_worker_spec.rb
Co-Authored-By: Vaidehi Joshi <vaidehi.sj@gmail.com>
Co-authored-by: Vaidehi Joshi <vaidehi.sj@gmail.com>
* 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.
