* make feed image consistent with cover image
* small tweaks for the logged out view of the feed cover image`
* update feed cover image for logged in users
* update to reflect new cover image
* reverting to see if the build, builds?
* snapshot tests
* update spec to look for the right class
* too long by ONE character 121/120 🙄
* Update app/javascript/articles/components/ArticleCoverImage.jsx
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/views/articles/_single_story.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/views/articles/_single_story.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* no need for the anchor tag to have a bg color
* update snapshot test expectations
* remove unnecessary span with hidden class
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Prior to this commit, our fallback HREF was using only the URL's
domain (e.g. `guides.rubyonrails.org/routing.html`) instead of the
provided URL (e.g. `https://guides.rubyonrails.org/routing.html`). This
resulted in the link resolving to
`<url-of-article>/guides.rubyonrails.org/routing.html`)
With this commit, we're using the given URL for the HREF.
An interesting side note, the Ruby on Rails guides includes an
`og:title` but not an `og:url` so we hit the fallback condition. Could
we use the given URL if `og:url` does not exist?
Fixesforem/forem#17679
With comments, publishing articles, and reactions we had symmetry on two
goals:
- Create a _subject_ (e.g. Comment, Published Article, Reaction)
- Create four _subjects_ within a week.
For page views we only had "Create four _subjects_ within a week." This
PR addes the "Create a _subject_".
To do this required adjusting some tests as they were too specific in
nature (looking at an expected count).
In addition, in consultation with Jennie, I've updated the experiment
order to better reflect some hierarchical importance.
**Rollback considerations:**
This also includes a feature flag that we can explicitly disable if we
overload the application with workers handling reaction goals. Using
`FeatureFlag.accessible?(:field_test_event_single_create_pageview)`
returns `true` unless we explicitly disable this flag.
Related to forem/forem#17673
Related to forem/forem#17669Closesforem/forem#17691
This commit adds three new feed experiment goals:
* user publishes four posts within a week
* user reacts with a "heart", "unicorn", or "reading list" to an article
* user reacts with a "heart", "unicorn", or "reading list" to an article
four times in a week
In addition it adds it to the existing experiment. Adding it to the
existing experiment is acceptable because:
1. We can ignore the results
2. The experiments are structured such that these new goals could be met
with prior data.
3. Both variants are playing by the same rules, so the results relative
to each other are valid.
**There is a nuanced assumption in how we handle reactions:**
This implementation does not count by unique article reactions. However,
most folks will ❤️ , 🦄 , and 🔖 in one swoop; thus
those 3 reactions are all grouped into happening on one day.
Further, it's a reflection of the person taking an action after reading
a post, not how much action on that particular post.
**Rollback considerations:**
This also includes a feature flag that we can explicitly disable if we
overload the application with workers handling reaction goals. Using
`FeatureFlag.accessible?(:field_test_event_for_reactions)` returns
`true` unless we explicitly disable this flag.
Closesforem/forem#17669
Prior to this commit, if the Forem limitted article creation only to
admins, when a new user would sign-up their call to action was to
"Create a Post". If that new user clicked on the button, they would get
an action unauthorized error.
With this commit, the call to action for Creating a Post is hidden to
that user.
The `users/onboardings/_task_card.html.erb` is rendered as part of the
home page. The home page, due to our [EdgeCacheSafetyCheck][1], does not
allow us to access attributes of the current user (e.g. are they an
admin); which means we can't add a `if policy(Article).create` to the
HTML erb. We must instead use the [`application_policy_content_tag`][2]
as well as the [AsyncInfo][3] to help inform the
[applyApplicationPolicyToggles.js pack][4] of the conditional rendering.
Closesforem/forem#17638
Related to forem/forem-internal-eng#347
[1]:8160089f3d/app/controllers/concerns/edge_cache_safety_check.rb
[2]:8160089f3d/app/helpers/application_helper.rb (L390)
[3]:8160089f3d/app/models/async_info.rb (L52-L61)
[4]:8160089f3d/app/javascript/packs/applyApplicationPolicyToggles.js
The [`ArticlePolicy#moderate?`][1] method answers the questions around article
moderation.
At present this change does not introduce any significant changes (aside
from the JS logic loop). The next "step" is to adjust the
`ArticlePolicy#moderate?` method to test if the user has a moderator
role.
Further, we'd need to see what is available on the action panel.
Related to forem/forem#17606
[1]:5ac3216a5a/app/policies/article_policy.rb (L160-L174)
Prior to this commit, if we didn't have an instance of `Article` we
likely had the class `Article`; we would then run a potentially VERY
expensive query (`SELECT user_id FROM articles;`) to provide an
answer; namely if all of the articles are written by the same user then
yes this user is the author.
With this commit, when you're authorizing the `Article` class, let's
just say "Nope, this user isn't the author".
Closesforem/forem#17604
Related to forem/forem#17612
Related to forem/forem#17634
Looking at the following error, I *think* this might address the
observed issue.
```shell
✖ jest --findRelatedTests:
No tests found, exiting with code 1
Run with `--passWithNoTests` to exit with code 0
Make sure Jest's configuration does not exclude this directory.
To set up Jest, make sure a package.json file exists.
Jest Documentation: https://jestjs.io/docs/configuration
```
There are 2 things going on in this pull request:
1. Reducing duplication of knowledge, by favoring constants found in
Reaction.
2. Creating and enforcing the policies regarding the different
categories of reactions.
I chose to conflate these two as I was working on developing the
ReactionPolicy's finder method.
Closesforem/forem-internal-eng#454
Related to forem/forem#17628
