Prior to this commit, we were somewhat naively rendering Hash style data
attributes in our ERB templates. By rendering each hash attribute
separately, we were rendering characters that could break the
javascript (e.g. double hack or backslash `"` or `\`).
By moving to this view_object rendering, we leverage Rails's `to_json`
behavior to ensure properly escaped values. As part of this exercise, I
generalized the method to allow for other places to benefit from this
behavior.
This generalization also helps ensure that we have a more conformant
rendering (e.g. we should always have an :id, :className, and :name
value in our data-info hash).
_Note: I've updated the user's names for Cypress tests as they are more
likely to catch the particular issue than anything else. I assume that
I'm going to break some cypress tests and will need some help fixing
them._
Closes#15916, #14704
Supersedes #15983
How to test locally:
Assuming you have seeded database (e.g. `rails db:seed`), checkout the
"main" branch. Then in `rails console` find a user that's written articles:
```ruby
user = Article.last.user
user.update(name: "\\: #{user.name}")
user.articles.each(&:save)
```
Now, again on the "main" branch, start your application (e.g.,
`bin/startup`).
Then get a logged in and a logged out browser session going. Open your
web inspector and open console. Then go to the local instances homepage
(e.g., http://localhost:3000) and look for JS errors.
On the main branch, you should see an exception around
`JSON.parse(button.data.info)` (assuming that the `user`'s article is
rendered on the homepage).
Then go to the user's page (e.g. https://localhost:3000/:user-slug) and
look for JS parse errors.
On this PR's branch (e.g.,
`jeremyf/take-two-at-resolving-gh-15916`)
you shouldn't see those console errors.
More importantly, the Follow buttons should work.
* updates
* updating doc
* Fixed broken documentation in Storybook stories.
* bring back a element
* md --> mdx
* c-* doc update
Co-authored-by: Nick Taylor <nick@dev.to>
* Add validations and constants for feed_style and strategy
* Convert text fields w/ static options to dropdowns
* Convert Bootstrap selectpicker to native HTML select tag
* Update test to use valid feed strategy
I was working on another branch and as part of my commit, Rubocop
removed a validation (but not the spec that asserted the validation).
Below is the "non-updating" rubocop offense on the other branch.
```shell
❯ rubocop ./app/models/notification_subscription.rb
Inspecting 1 file
C
Offenses:
app/models/notification_subscription.rb:13:29: C: [Correctable]
Rails/RedundantPresenceValidationOnBelongsTo: Remove explicit presence
validation for notifiable_id.
validates :notifiable_id, presence: true
^^^^^^^^^^^^^^
1 file inspected, 1 offense detected, 1 offense auto-correctable
```
To remediate, I ran:
```shell
> rubocop --only "Rails/RedundantPresenceValidationOnBelongsTo" \
--auto-correct
```
This resolved the `app/models`. Then did some regex magic and removed
the assertions from `spec/models`.
For Forem folks, I wrote a [forem.team post][1] discuss if this is how
we want to proceed.
[1]:https://forem.team/jeremy/rubocop-auto-updating-mayhem-33a6
In Travis I found the following message:
> Using `should` from rspec-expectations' old `:should` syntax without
> explicitly enabling the syntax is deprecated. Use the new `:expect`
> syntax or explicitly enable `:should` with
> `config.expect_with(:rspec) > { |c| c.syntax = :should }`
> instead. Called from
> /home/travis/build/forem/forem/spec/models/html_variant_spec.rb:76:in
> `block (2 levels) in <main>'.
* Adding a convenience/optimiization method.
Without this method, the `@object` will handle the `decorate` message;
which will go through the logic of determining the decorator class, and
isntantiating a new decorator.
Related to but orthogonal to #16078.
* Update app/decorators/application_decorator.rb
Co-authored-by: Jamie Gaskins <jamie@forem.com>
Co-authored-by: Jamie Gaskins <jamie@forem.com>
* Refactoring to add helper method
Prior to this commit, we made view level calls to service modules. This
refactor provides convenience methods on the model.
Furthermore, it addresses a few Rubocop violations that "come along for
the ride."
* Ensuring cached entity squaks like User
* Fixing broken spec
* Fixing typo
* 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
* Moving the "Null" user object closer to User
Prior to this commit, we had the presentation concept of a DELETED_USER
in the ApplicationHelper. Further, we did type checks against that
object instead of relying attributes of the object.
With this commit, I moved the "Null" user closer to the User definition
to help highlight the concept that there might be deleted users.
I didn't remove all of the type checks, but did attempt to create a more
"duck-type" object.
Further, I moved away from an OpenStruct which in the past (and perhaps
present) had performance issues.
* Moving DeletedUser into Users module space
ActiveSupport adds DateAndTime::Calculations#after? (and before?) -
which clarifies intent (users newer than the relative time are
skipped) of the early returns.
The download app broadcast (in the Generator) returns early if the
user was created less than 7 days ago. It seems counterproductive to
filter out _only_ users created in the last 7 days.
Add one day to the query range, so users created less than 8 days ago,
but more than 7 days ago, receive the final message.
* Generator output
Add your logic here!
* replicate the logic from the forem connect migration
* Add data update script
This will generate the expected broadcast message to fix#16059
* Add apple connect to seeds file
* 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.
* Name the created after timestamp and remove temporary variables
The logic used to calculate the live at time, the week ago time, then
compare them to find the more recent value.
Move all of this logic to a method (there's a guard to exit if
the setting is nil, so this should be safe).
* Mark method private
This is not part of the public api (for workers, this should be
`#perform` alone). Mark it private
* Initial work
* Implement strategy injection into WeightedQueryStrategy
* Modify field_test config and adding variants
* Change orginal to constant and make some other adjustments
* Fix hardcoded test values
