* 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
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
* Adding new relevancy lever for privileged reactions
This PR includes four changes:
1. Renaming the variant to remove Jennie's name
2. Starting a new experiment
3. Adding a new relevancy lever
4. Adding a new variant that uses the relevancy lever
1 and 2 is somewhat straight-forward.
For 3, we're looking at having a total of 5 "slots" for privileged user
reactions. Hence the four boundary values.
For 4, we're configuring the granular levers with the following:
- `[-∞..-5)` should have a 0.05
- `[-5..0)` should have a 0.5
- `[0..5)` should have a 0.9
- `[5..10)` should have a 0.98
- `[10..∞)` should have a 1.0
The 20220509-variant.json is a copy of 20220422-variant.json but
replaces the `privileged_user_reaction` lever with the
`privileged_user_reaction_granular` lever.
Below is the diff to highlight the similarities and differences between
the two variants.
```shell
❯ diff config/feed-variants/20220509-variant.json config/feed-variants/20220422-variant.json
90c90
< "privileged_user_reaction_granular": {
---
> "privileged_user_reaction": {
92,96c92,93
< [-2, 0.05],
< [-1, 0.5],
< [0, 0.9],
< [1, 0.98],
< [2, 1]
---
> [-1, 0.2],
> [1, 1]
98,102c95,97
< "fallback": 0.9,
< "very_negative_reaction_threshold": -5,
< "negative_reaction_threshold": 0,
< "positive_reaction_threshold": 5,
< "very_positive_reaction_threshold": 10
---
> "fallback": 0.95,
> "negative_reaction_threshold": -10,
> "positive_reaction_threshold": 10
```
Closesforem/forem#17584
* Update app/models/articles/feeds.rb
Co-authored-by: Josh Puetz <josh@dev.to>
* Adjusting testing logic to reflect latest experiment
* Adjusting negative threshold
Co-authored-by: Josh Puetz <josh@dev.to>
* test(cover-image): uses correct queries for ui unit tests
* test(form): replaces queries to getByRole and adds expect where necessary
* feat(help): adds expect assert and uses within to test inside specific block
* feat(image-uploader): uses correct queries to validate behaviour
* test: corrects queries and adds expect assertions to some unit tests
* Adds an empty state to the GDPR delete requests table
* Refactors and fixes gdprDeleteRequests.spec.js
* Updates aria-describedby for the GDPR delete requests table
* Adding a field test option for post publishing goals
We have page view and comment view "goals" but have not looked at
publication "goals". We're using these "goals" to help us refine the
feed towards sustainable engagement and community health.
The conjecture on publication goals is that the content on the feed
itself can nudge folks in their decision to publish posts.
Closesforem/forem#17585
* Fixing broken test
Prior to this commit, the SQL fragments included variables that were set
configured at a global level.
With this commit, we're now saying that each lever "knows" what variable
it needs; and providing the means at lever declaration time to "say"
what those variable names are. (e.g. `Articles::Feeds::LEVER_CATALOG`).
Then as part of the variant configuration (in the
`./config/feed-variants/*.json` files) we now include the expected value
of those parameters; which by convention (and coercion) are integers.
This relates to forem/forem#17584 because we want to move from a
privileged user reaction that has two values (`negative` and `positive`)
into four values (`very_negative`, `negative`, `positive`, and
`very_positive`). To do that, we'll create a new lever; but that's for
another pull request.
* WIP: Adds an empty state to the invitations table
* Pulls invited member empty state into partial
* WIP: Center empty state within invited members table body
* Removes partial and adjusts empty space styling
* Adds an e2e for the empty state to invitedUsers.spec.js
* Moves empty state outside of table and adds aria-describedby to table
* Update app/views/admin/invitations/index.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Adjusts ara-describedby erb tag
* Updates the route used within invitedUsers.spec.js to fix e2e failure
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* update Modal to add sheet variant
* dont use prompt title for modal sheet stories, to better reflect intended purpose
* Apply suggestions from code review
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
* feat: update all the paths as a first order of business
* feat: update all the folders to no longer appear under users
* feat: update specs
* feat: update specs
* feat: remove User namespace
* feat: remove route namespace
* feat: path change
* feat: move the menu items to the sidebar
* feat: add a badge
* feat: remove tabs partial
* xs font
* feat: update describe blocks
* feat: update cypress tests
* chore: oops member_manager instead of member_management
* feat: c-indicator
* feat: update the tests
* feat: update the gdpr test
* feat: add the invitations
* chore: align
* feat: update the GDPR constant
* feat: rename to GDPR actions
* feat: add member manager route
* Moving Experiments into AbExperiment namespace
This commit entails two major concepts:
1. Extracting logic out of a worker.
2. Cleaning the conditions in which we convert experiments.
In addition, I revisited some spec names to tidy them up for
clarification and structure.
**Extracting Logic...**
For workers, my preference is that they be a simple router to another
object. A non-worker object, with it's initialize method, can both
better manage instance variables. Further, workers are somewhat "flat"
in hierarchy,
In this case, having the AbExperiment be knowledgeable both in setting
the experiment and handling conversions makes (to me) organizational
sense. For example, the AbExperiment is constructed as a wrapper to the
FieldTest gem. But the RecordFieldTestEventWorker had knowledge of
FieldTest.
With this refactor, it does not have that knowledge. This also provided
an opportunity to replace magic strings with constants.
**Cleaning the conditions...**
This relates directly to and closesforem/forem#17530. I was looking at
the experiments after 2 days, and realized that there shouldn't be
results for
`user_views_pages_on_at_least_nine_different_days_within_two_weeks`;
after all the experiment started 2 days ago, how can we have results
that look at 2 weeks.
By adding the "max" function calls, we ensure a clear boundary of
"before the experiment began" versus "while the experiment is running".
Closesforem/forem#17530
* Update spec/models/ab_experiment_spec.rb
Co-authored-by: Mac Siri <krairit.siri@gmail.com>
* Apply suggestions from code review
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
Co-authored-by: Mac Siri <krairit.siri@gmail.com>
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
