* Base author reaction functionality
* Get logic more in place
* Finalize tests
* Add admin clause for new user points
* Add proper registered_at for seeded user
* Fix regsitered_at in e2e
* Add registered_at across the board in e2e tests
* Update comments
* Update spec/models/reaction_spec.rb
Co-authored-by: Jamie Gaskins <jamie@forem.com>
* Update spec/models/reaction_spec.rb
Co-authored-by: Jamie Gaskins <jamie@forem.com>
* Update spec/models/reaction_spec.rb
Co-authored-by: Jamie Gaskins <jamie@forem.com>
* Put points in constant and refactor points resave logic
Co-authored-by: Jamie Gaskins <jamie@forem.com>
* Initial statement of intent regarding Listings
I want to use this pull request as a means of conveying intended
direction; namely that we want Forem administrators to be able to toggle
off (or on) the Listing feature set.
This refactor is a first, yet incomplete pass, that doesn't make the
code worse. Expect more of a similar vein as we work to put the Listing
feature set behind a feature flag.
Related https://github.com/forem/rfcs/issues/291
* Adding feature flag based on reviewer comment
Prior to this commit, we were treating all NavigationLink attributes as
unique. So, were we to change a position of one of the NavigationLinks
during the add_navigation_links rake task, we would have created a new
NavigationLink (and the only one would have remained).
With this commit, we're introducing the concept of the NavigationLink's
surrogate identity, that is to say if we have two NavigationLink objects
with the same `url` and `name` we should consider them the same
NavigationLink. This allows us to update properties of those
NavigationLinks (via the rake task) without the risk of creating new
entries.
This unblocks PR #16268 which addresses #16076.
The hotness score is an "opaque to our users" score, it reflects
"activity" on the tag. However, by also showing the number of tags on
the associated view, there's a bit of a head scratcher when a "hotter"
tag with less tags is rendered ahead of a popular tag.
Closes#16321
* Ensuring we fetch latest podcasts by pubDate
Prior to this commit, we fetched the podcasts that were the first(:limit)
XML `item` nodes in the RSS feed. Some folks might choose to list those
in descending pubDate order, while others list in ascending pubDate
order.
Closes#3580
* Bump for travis
* Added tag search to nav menu
* Added tag search
* Improved tags search results view
* Removed commented lines from the controller
* Fix specs for Search::Tag
* Prepare for tags search pagination
* Fixed Search::Tag specs
* styling
Co-authored-by: Paweł Ludwiczak <ludwiczakpawel@gmail.com>
* 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.
* Refactoring cached_followed_tags
This refactor consolidates two queries and a loop into a single query.
One thing that is unclear is if we're ever really clearing the cache of
the user by id?
What follows is un-related to the refactor but appears to be related to #14937.
> First, I see we set a cache here:
>
> ebdaaaf15b/app/decorators/user_decorator.rb (L23-L34)
>
> But when I look at what busts the user cache, it doesn’t look like we’re busting it for the above cached location:
>
> ebdaaaf15b/app/services/edge_cache/bust_user.rb (L3-L22)
>
> What if anything am I missing in regards to cache busting?
* Adding some deprecated methods
* Updating documentation
* Bump for travis
* Bump for travis
* Updating comments to fix confusion
NOTE: I might be introducing more confusion, but at least
I'm addressing the prior confusion.
* Bump for travis
* Updating so we don't cache ActiveRecord objects
* Selecting only applicable attributes for caching
* Apply suggestions from code review
Co-authored-by: Michael Kohl <citizen428@forem.com>
* Adjusting code based on feedback
* Bump for travis
* Bump for travis
* Update app/decorators/user_decorator.rb
Co-authored-by: Michael Kohl <citizen428@forem.com>
Co-authored-by: Michael Kohl <citizen428@forem.com>
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
* Don't set saw_onboarding automatically
This should be set by the onboarding checkbox update (user accepted
terms of service and code of conduct).
The issue is a PATCH request to track the last seen page is sent on
the first page, _before_ the user consents to the terms via the
checkboxes.
This issue is masked by a 422 unprocessable entity response when we
don't get a username in the patch request (next commit).
* Only validate username on the username page
Every other "last page seen" dialog was returning a 422 because the
username is only submitted in the 3rd dialog "build your profile".
Only validate the username field when it's submitted, process other
onboarding updates normally.
* Remove failing test
Since the onboarding_update action no longer sets saw
onboarding (since we send the patch before they've accepted the code
of conduct), don't test that we do.
There's a parallel test for the onboarding checkbox update later in
this file that covers the checkboxes have been accepted.
* overwrite instead of merging user_params
We now initialize it empty, no need to merge params here.
On the DEV.to database, I ran the following SQL:
```sql
SELECT name, short_summary FROM tags WHERE short_summary LIKE '%<%';
```
There were three tags with a `<` in them:
- changelog
- cnc2018
- javascript
This PR will tidy up our short summary as part of saving a tag. It will
also tidy up the existing tags.
* add default placeholder, remove focus on first load
* fix some bugs re autofocus and mouse click to select
* allow custom selected styles to be passed in
* operate on objects with name property rather than plain strings
* WIP main functionality in place
* set default selections, allow a max to be placed on selections
* switch help context
* bug fixes to edit mode, static suggestions
* make sure suggestion resumes when edit begins
* cleanup and docs
* update existing form test
* add component tests
* add more component test cases
* refactor max selections flow, ensure default tag data only loads once
* stop removing combobox properties now the input stays visible
* add max selections test
* refactor
* make sure input refocus happens after blur event
* update cypress tests
* some small renames and doc changes
* only fetch exact matches from added tags
* fix test, update dark theme background
* set a max height on the popover, and ensure options can be scrolled into view
* woops - max height
* Update app/javascript/article-form/components/TagsField.jsx
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
* refactors
* stop dropdown from flickering
* use ButtonNew
* remove redundant variant
* nudge PR checks
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
The fix might be a bit of a work-around for a more general approach, but
we're fighting against the magic of the points vs. explicit_points
tension as defined in the [Follows::UpdatePointsWorker][1].
That is to say, it's possible (and happens) where I have assigned an
`explicit_points` of 1 for a tag, but the calculated `points` are less
than 1. The calculated `points` are what we send forward in the
[AsyncInfoController][1] (by way of the
[UserDecorator#cached_followed_tags][3] method).
In DEV, I ran the following queries:
**User assigned points `>= 1` but calculated `< 1`**
985,352 records
```sql
SELECT count(id)
FROM follows
WHERE followable_type = 'ActsAsTaggableOn::Tag'
AND points < 1
AND explicit_points >= 1;
```
**User assigned points `>= 1` but calculated `>= 1`**
5,366,478 records
```sql
SELECT count(id)
FROM follows
WHERE followable_type = 'ActsAsTaggableOn::Tag'
AND points >= 1
AND explicit_points >= 1;
```
**User assigned points `>= 1` but calculated `>= 0`**
0 records.
```sql
SELECT count(id)
FROM follows
WHERE followable_type = 'ActsAsTaggableOn::Tag'
AND points <= 0
AND explicit_points >= 1;
```
**User assigned points `<= 0` but calculated `> 0`**
1,146 records
```sql
SELECT count(id)
FROM follows
WHERE followable_type = 'ActsAsTaggableOn::Tag'
AND points > 0
AND explicit_points <= 0;
```
Synthesizing that, almost 1 million tag follows of the total 6.3 million
are not showing up in the user's left navigation. And 5.3 million are
roughly correct.
In adjusting the logic, we're now going to have more tags showing up in
the left. And just over 1,000 might now show up that would be unexpected.
Closes#14937.
[1]:c63e0b629e/app/workers/follows/update_points_worker.rb
[2]:c63e0b629e/app/controllers/async_info_controller.rb (L40-L65)
[3]:c63e0b629e/app/decorators/user_decorator.rb (L23-L34)
