* 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>
* 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: update url
* remove name from invite user flow
* remove name from invitation instructions
* update invitations spec
* update specs and invitation actions overflow menu name
* allow users to set name when accepting invite
* First greedy algorithm approach to awarding community wellness badge
* Update app/services/badges/award_community_wellness.rb
I'm sorry I ignored you rubocop. It's still on draft for a reason 😅
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* Update app/services/badges/award_community_wellness.rb
Okay, whatever you say rubocop. This line will go away before merging anyways
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* Use app/queries/comments/community_wellness_query.rb to replace greedy algorithm
* Query indenting + rename positive_reactions to negative_reactions in EXCEPT
* First step towards query spec
* Fix spec and make it more robust
* Slight cleanup/tweaks
* Badge reward & message
* copy edits + spec improvements + 3 days ago min for query
* Cron update to run daily + small tweak for FeatureFlag use
* inline comment tweaks
* Slight reorder of guard checks in service (FeatureFlag related)
* PR review feedback
* Fix specs from static method refactor
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* Remove sustaining member newsletter, and its settings
This removes the concept of sustaining memberships from the system,
and logic related to or dependent on it.
This does not remove the monthly_dues column from the users table (todo).
* Remove unused newsletter setting
Since nothing accesses the mailchimp_sustaining_members_id setting,
it's safe to remove.
* Use destroy rather than delete to ensure settings cache is cleared
We have a callback in Settings::Base to clear the cache after commit,
I assume it's useful to trigger that. This requires destroy, not
delete, to be called.
When we merge this, Forem admins will see the "Admin > Content Manager >
Spaces" section in their Admin area. This will then allow them to
toggle on and off spaces.
Closesforem/forem#17161
* Don't create podcast episodes without a media_url
There is an early return from add_media_url to prevent using an empty
enclosure_url, which avoids errors in
`GetMediaUrl.call(a_blank_value)`, however there's also a not null
constraint on podcast_episodes.media_url in the database, which causes
upsert to raise an error.
Returning early here avoids the error (which had halted the worker).
See also
https://app.honeybadger.io/projects/66984/faults/80833402
This error happens regularly, 96 times per day in DEV, it looks like at least
one podcast feed_url is for an rss feed filtered by /tag/podcast/,
(and at least one post was tagged "podcast" but didn't include any
media to get).
My understanding is at worst we'll ignore the error silently.
* Add test cases
given a blog post (not a podcast episode, no media url), don't raise
any error, don't create any episode.
Included codepunk.io feed that was showing this issue initially.
* Prefer compact_blank! to delete_if blank
Rubocop suggested this. Why would I argue.
* When sort_direction is anything other than asc or desc, remove it
There is initializer code in the search/query classes that handles nil
sort_direction by adding a default value, so deleting the sort
direction is reasonable here.
* Set a default sort direction for articles of :desc
* Only sort if sort_direction and sort_by are present
* Add test case for article search with invalid parameter
You had a good ride, but your successor, the
`Articles::Feeds::VariantQuery`, is doing well in production. And has
been for quite awhile.
You helped us get to a better spot in regards to the feed algorithm, but
your time has come to rest as a memory in our git history.
* Rename unsubscribe to remove_from_mailchimp_newsletters
* Permanently delete from mailchimp instead of unsubscribing
* Rename method and remove comment
* Don't use i18n because of error message
We don't want to use i18n here because e.title comes from the error response. If a Forem
was using a different locale and Mailchimp for newsletters, they would still receive the
error response in English (because of Mailchimp).
* Refactor and rename a bit
* Rename methods in tests accordingly
* Remove now moot test
* Rename method in other places it was previously called
* Remove unused translation, see 62fee247ee2565e4d3d14919a8636a76ce5ecc9f
* Fix typo and report error if not 404
As I was looking into the implementation details of the `/t/:tag_name`
relevancy feed I noticed an instance variable that we do not need.
Below are the results of looking for the instance_variable
`@article_index` or a potential `article_index` local variable or method name.
```shell
❯ rg "@?article_index"
app/controllers/stories_controller.rb
28: @article_index = true
131: @article_index = true
162: @organization_article_index = true
app/controllers/stories/tagged_articles_controller.rb
18: @article_index = true
app/controllers/stories/articles_search_controller.rb
7: @article_index = true
app/views/articles/_single_story.html.erb
26: <% if story.cached_organization && !@organization_article_index %>
32: <a href="/<%= story.cached_user.username %>" class="crayons-avatar <% if story.cached_organization && !@organization_article_index %> crayons-avatar--s absolute -right-2 -bottom-2 border-solid border-2 border-base-inverted <% else %> crayons-avatar--l <% end %> ">
79: <% if story.cached_organization && !@organization_article_index %>
```
* feat: remove feature flag on the member index view and re-arrange some partials
* feat: remove Feature Flag for the invitations view
* feat: remove Feature Flag for the gdpr view
* feat: remove Feature Flag for the controls
* feat: remove the feature flag in the tests
* remove extra queries that we no longer use
* Update app/views/admin/invitations/index.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/views/admin/invitations/index.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/views/admin/users/index/_controls.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/views/admin/users/gdpr_delete_requests/index.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update cypress/integration/seededFlows/adminFlows/users/userIndexView.spec.js
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update cypress/integration/seededFlows/adminFlows/users/userIndexView.spec.js
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/views/admin/users/gdpr_delete_requests/index.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* feat: attempt to fix Cypress test
* fix: soem other cypress tests
* fix: search bar
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
This commit does three things:
1. Breaks the inheritance of the VariantQuery.
2. Revisits the in-line documentation to better reflect current state.
3. Removes branching logic that we don't need.
My goal is to have a VariantQuery that is what we need, conforms to the
method interface of WeightedQueryStrategy but does not rely on it.
After we merge this, we can observe if things break on DEV and fallback
to WeightedQueryStrategy if this doesn't work. Once the
`Articles::Feeds::VariantQuery` has fledged on it's own, we can remove
the feature flag and then finally remove the weighted query strategy.
But that's the future steps.
Related to forem/forem#17393
