* Adding more context to `/admin/abtests`
Prior to this commit, the `/admin/abtests` was fully rendered by the
field_test gem (see
https://github.com/ankane/field_test/blob/master/app/views/field_test/experiments/index.html.erb
and
https://github.com/ankane/field_test/blob/master/app/views/field_test/experiments/show.html.erb).
With this commit, we're pre-pending our own
partial (e.g. `app/views/field_test/experiments/_experiments.html.erb`)
in the view paths; which means instead of rendering
https://github.com/ankane/field_test/blob/master/app/views/field_test/experiments/_experiments.html.erb
we render our newly created
`app/views/field_test/experiments/_experiments.html.erb`)
Why the ugly antics in the view? As I'm not fully certain if this will
"meet" the full needs of those monitoring the experiments. I'm also
constructing this to most closely match the spreadsheet that has been
assembled for tracking this information.
Why introduce another caching layer for the variant assembly? The
original caching
layer (e.g. `Articles::Feeds::VariantAssembler.pre_assembled_variants`)
is in place to provide the quickest access to the assembled variants.
But due to the nature of the implemented view, we are needing a
programmatic representation of all variants. And the added Rails cache
is there to minimize disk reads.
Closesforem/forem#17820
* Update app/models/articles/feeds/variant_assembler.rb
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
* Update app/models/articles/feeds/variant_assembler.rb
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
Prior to this commit, as a matter of undocumented practice, we would
overwrite past experiments with upcoming experiments.
With this commit, we're leveraging a feature of the field_test gem:
declaring a winner. Instead of overwriting an experiment with the next
experiment, we're going to declare the expiring experiment's winner then
prepend to the ./config/field_test.yml the new experiment.
The [field_test/app/views/field_test/experiments/index.html.erb][1] then
uses logic to first render "active" experiments and "completed"
experiments. A "completed" experiment is one in which we've declared a
winner.
Closesforem/forem#17816
[1]:https://github.com/ankane/field_test/blob/master/app/views/field_test/experiments/index.html.erb
* Add tooltip for cover image button
* Add cover img tooltip to v1 editor
* Use a slightly different message
* Fix tests
* Use proper comment syntax for front matter
* Fix Cypress test
* Use regex to find matching label
* target modal content by a classname to avoid duplicate IDs
* woops - fix missed selector
* use showWindowModal in editUser
* move add org to a partial
* move add role into a partial
* move adjust credits to a partial
* move profile modals to be re-used
* generalise approach to add organisation modal
* generalise add role modal form
* generalise adjust credits modal
* rework unpublish modal
* refactor banish user modal
* refactors
* prevent issues with duplicate ids
* fix banish form action
* make sure role management specs covered in cypress
* let hidden modal content use IDs
* rename file for clarity
* add some JSDoc notes
* cleanup some redundant changes
* one more
* woops - fixed id that contained a classname
* added ability to assign moderator role via admin/super admin
* create Mod User in seeds
* add Cypress specs
* fix failing Cypress tests
* fix failing specs by moving test Mod user to the end
* nudge Travis
* nudge Travis
Co-authored-by: Arit Amana <msarit@gmail.com>
* WIP initial component/story
* examples of customisation
* populate the month year pickers
* change the calendar view when the month or year is chosen
* fix which dates should be disabled
* style left right nav buttons
* add calendar icon, fix some date range styles
* extract some color variables
* some minor changes to styles and comments
* add phrases, allow all dates to be toggled in story
* consolidate styles
* conditional navigation given max and min dates
* labels on selects, tweaks to story
* undo unrelated changes from merge
* undo unrelated changes from merge
* undo unrelated changes from merge
* undo unrelated changes from merge
* retry adding dependencies, not feeling hopeful XD
* is this a preact issue?
* Revert "is this a preact issue?"
This reverts commit 5f3f720f8e739cc3dcca7fd54f8d97e08d8bb88c.
* without css import
* import styles via sass file, not component
* Apply suggestions from code review
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
* 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
