* 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
* Don't send auth broadcasts for providers that are in beta
Currently we have :apple as a restricted provider (you can enable it,
but it's treated as beta here, rather than generally available).
While we were correctly checking if you had all GA providers enabled
in authenticated_with_all_providers?, we were incorrectly pulling
all enabled provider names in find_auth_broadcast (the message to send
the user), and picking apple_connect.
Since it doesn't make sense to omit apple id login from consideration
when checking if all available auth methods are used, then recommend
that it be used consistently, capture this "GA" state as a method, and
use it both in the test "does this user have all available identity
providers enabled?" and the selection "which identity provider can I
suggest they setup?" consistently.
Since we're about to enable google as an auth source (in #15986) I'll
check with Josh if he expects this to be GA on release or in limited
beta.
* Clean up authenticated_with_all_providers?
We have a method identities that returns the enabled identities for
the user (a relation), and a method ga_providers that returns a list
of enabled and not beta provider symbols.
Change the set difference to use Array#all? (which will exit early on
the first failure). Efficiency note: while I think this reads
better,it's possible this issues a number of small (cheap) queries for
identity by user id and provider id, but there's a unique index on
(provider, user_id) that should be effective.
* Only check providers that have active broadcast messages
An admin can stop sending "connect using apple" follow ups by
disabling that broadcast.
I randomized the enabled/active broadcasts for connection options so
they're not always pulling the same (facebook? apple?) option every
time.
* Clean up lost thought in comment
ActiveSupport adds DateAndTime::Calculations#after? (and before?) -
which clarifies intent (users newer than the relative time are
skipped) of the early returns.
* Modify welcome notification generator to handle errors per-message
The original flow aborted all processing when any
ActiveRecord::RecordNotFound exception was raised. This causes a
situation where a missing broadcast message (by title) causes that
notification message to fail, and each day the same failure to
occur (since it wasn't successfully sent the day before), blocking all
further messages.
We want these to proceed on the schedule implicit in the checks, and
failing early prevents that.
Modify the error handling to catch RecordNotFound on each message, and
continue throught the checks until a notification is enqueued or all
checks have been attempted.
* Run welcome broadcast check 4 hours after the user was created
This started to fail when I modified the generator (why? because the
user was 7 days old and _other_ notifications would be sent).
Ensure the user is 4 hours old before checking that the disabled
welcome broadcast message is checked, and not sent.
* Add gem omniauth-apple
* Integrate omniauth-apple
* Integrate callback
* Add fields
* Add tests, fix bugs and make it all work
* Show only enabled providers for the current user
* Add default profile image for Apple
* Remove localhost patch
* Bring over the changed Apple username if the user changes it
* More specs fixed
* Incorporate feedback from PR
* Fix specs
* Simplify code and fix spec
* Fix Broadcast generators to take into account the new provider
* Fix spec
* Generate a truly unique apple_username
* Fix user specs
* Add omniauth-apple-0.0.2 to vendor cache
* Fix merge conflict and spec
* Update VCR fastly sloan cassette
* Revert "Generate a truly unique apple_username"
This reverts commit 2462875575b0bbd6b3c1d56b25afcd3189671608.
* Fix user specs
* Fix specs
* Fix specs
* Hide Connect Apple button behind a feature flag
* Revert "Hide Connect Apple button behind a feature flag"
This reverts commit 105bde0373389a4eb9b6e948f60734c7e0e99cba.
* Fix line lengths
* Fix spec
* ES tag
* CSRF bypass for Apple callback
* custom user_nickname in Apple provider with small tweaks + omniauth-apple bump
* Fixes username specs
* Makes Apple users default image Users::ProfileImageGenerator
* Fallback to mascot_image_url in test environment to avoid breaking Travis
* Fixes Apple CSRF error + makes default nickname more readable
* Trigger Travis
* Removes CSRF Apple fix from Omniauth callbacks
* Removes Envfile
Co-authored-by: rhymes <rhymesete@gmail.com>
Co-authored-by: rhymes <rhymes@hey.com>
* Add download_broadcast to generator.rb
* Adds memoized download_broadcast method
* Adds send_download_notification method
* Adds send_download_notification to call method
* Add download_app to broadcasts.rb and seeds.rb
* Adds download_app broadcast info and copy to factory
* Adds download_app copy to seeds
* Add specs around #send_download_app_notification in generator_spec.rb
* Fix quotes around copy
* Remove extra space within copy
* 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 a discuss/ask notification(s) to seeds + factories
* Add a start discussion/ask question welcome notification
* Add a scope for finding articles published by a user + with a certain tag.
* Some clean up/refactoring in the generator
* Reorganize welcome notification sending, add specs for discuss/ask notification
* Rename find_broadcast to find_auth_broadcast
* Fix broken div rendering on /notifications tab
* Allow customize notification to be enqueued
* Add specs for customize welcome notification
Also clean up existing specs to match!
* Rename customization notification method for clarity
* Remove some redundant assertions in generator spec
* Update some test descriptions in notifications_spec
The descriptions of these tests didn't actually match the test's assertions!
* Add welcome_notifications column to users table
Also ensures that welcome_notifications cannot be set to `nil`.
* Show an opt-out message for Welcome broadcast notifications
* Add opt-out link to notifications + welcome notification box to settings
* Allow welcome notification subscription to be updated
* Add tests for unsubscribed to welcome notification users
Also refactor generator specs a bit.
* Fix up paths, copy, tests
Use rails path helpers instead of hardcoding paths. Improve copy in a few locations.
* 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
* Add more Broadcasts to seeds for welcome notification flow
* Remove unnecessary welcoming_user_id from development config
* Add basic service class for generating appropriate broadcast per user
Eventually, this should be called from a rake task that will rely on this service to determine which broadcast, if any, is the appropriate one to send to newly signed-up users, and will enqueue a worker to create/send a welcome notification when appropriate.
* Add a few TODOs, plus some general cleanup
* Add some skipped tests for WelcomeNotification::Generator
