This is a "quick and dirty" hack. Do I like it? No. Do I want to delve
into further debugging/refactoring of [a 72 line method][1]? Not at the
moment. There are a few pathways forward, but for now, this is the
pathway to hopefully give us insight into the
**Why will this likely address the issue?**
Prior to this commit, for an experiment we would render each of the
goals (anywhere from 8 to 11); each of which would require 2 expensive
queries; which means about 16 expensive queries.
After this commit, the experiment page has none of those expensive
queries; instead each goal now runs the 2 expensive queries.
The hope is that this will help us show the results (albeit on multiple
pages) while coming in under the response time out handlers we have in
place.
**Why no tests?**
Ugh; I know right?!? I'm beginning to ask that myself. But for now,
because this is only visible to tech_admins, the consequences of
breaking are limited. In otherwords, this is not a customer facing
feature, so it can be a bit less robust in it's testing. At least
that's the rationalization I'm establishing.
Further, local tests would not reveal the production environment
complications of large data sets. The aforementioned expensive queries
are blisteringly fast on my local machine...in part because I don't much
field_test experiment data.
Closesforem/forem#17981
Related to:
- forem/forem#17895
- forem/forem#17869
[1]:ab2d7d29d0/lib/field_test/experiment.rb (L98-L160)
* Adds the Adjust credit balance modal to index view
* Adds e2e tests for adjusting credit balances via modal
* Adds the ability to update credits to #user_status
* Adjusts the e2e to address failures
* Move .skip_confirmation! call to .find_or_create_user! method
* Add regression tests to avoid email confirmation delivery
* Keep the original place where we had user.skip_confirmation! too
* Update logic to require email confirmation from omniauth
* test confirmation is required with SMTP
* Keep :notice instead of :global_notice
* Forem Account bypass email confirmation reorg
* inline comment reorder + clarification
* Apply suggestions from code review
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
Co-authored-by: Fernando Valverde <fernando@visualcosita.com>
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
* refactor: use the DefaultSelectionTemplate to list out the items
* refactor: rename function so that we map it to the deselect item event
* feat: first pass of adding edit functionality
* feat: update the name of the function from clearSelection to clearInput
* feat: setup the edit state by ensuring that we set the editValue and the inputPosition and then use useEffect to monitor changes
* chore: remove the old method in favour of a shared component
* feat: set the order of the items
* refactor: rename handleBlur function name to handleInputBlur
* feat: ensure that the edit field gets resized according to its current input
* feat: oops add inputSizerRef
* feat: when an item is being edited we need to ensure that it gets set back into the correct position and that we clear the previous state
* feat: handle the actual resizing fo the field on an input edit
* feat: use a shared DefaultSelectionTemplate for both the multiautocomplete and the multiinput component
* feat: make the defaultSelectionTemplate customizable based on the variant adn the classname
* feat: pressing backspace will start editing a previous selection if there is one
* feat: read out the selected items as its removed or edited
* feat: pass the regex through as a prop
* feat: move the functions around
* feat: add screen-reader only class
* Update app/javascript/crayons/MultiInput/__stories__/MultiInput.stories.jsx
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
* Update app/javascript/crayons/MultiInput/MultiInput.jsx
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* feat: add the props to JSDoc
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* show the pills
* clicking pills removes filter
* add some more spacing
* another alignment tweak
* add cypress spec
* put it behind the feature flag
* make the clear all link a button for consistency
* tweak to comment for clarity
* show the organizations checkboxes
* apply clear filter button and indicator
* filter by org in users query
* add some rspec tests
* add cypress specs
* correct cypress spec
* Fixing UsersQuery to ensure singular user by organization
Co-authored-by: Jeremy Friesen <jeremy.n.friesen@gmail.com>
* tweak for smallest viewport
* layout essentially there
* conditionally toggle what the filter button triggers
* contain width of filter section on large screens
* reinstate old view depending on feature flag status
* add type: button (woops)
Prior to this change, we setup our feed variant query to have a cached
randomization seed. For a given user this seed is cached for 15
minutes. The goal of this is to provide mostly consistent sort orders
on the feed articles during that 15 minute window.
With this change, we allow for a feed variant to say ignore the cached
seed and generate a new one for this call.
I have also added explicit settings to each of the feed variants to
reflect our desired intentions for those features.
Relates to
- forem/forem#17833
- forem/forem#17826Closesforem/forem#17940
* prevent ID conflicts in filters modal by caching content
* show roles with expandable section
* minor tweak
* don't use the hidden field
* send array of role
* role -> roles. small refactor
* set initial checked status
* show an indicator when a filter is applied
* add JS to toggle filter clear buttons and indicators
* update some comments, make sure users only appear once in list
* add some cypress specs, fix some bugs
I had looked at using `User.with_any_roles` but that creates one User
query per role passed. Which is not ideal, given that we want to have
an ActiveRecord::Relation object on which we'd paginate.
This adjustment does it's best to mimic Forem's role structure and
adhear to how Rolify builds the underlying query.
An astute reader will notice that in these specs we use `role: "admin"`
and `roles: ["Admin"]`; the primary reason relates the user interface
being worked on in forem/forem#17884. It is my understanding that the
`role` approach and `roles` approach will be separated by a feature
flag (we're rolling out the `roles` approach).
Related to
- forem/forem#17491
- forem/forem#17884
* Adds an Add Organization modal and e2e tests for the modal
* Conditionally redirects to the correct view upon adding org
* Combines modal tests within userIndexView.spec.js
* Removes redundant code and switches assign role and add org button positions
* Updates RSpec tests to account for conditional redirection
* Lowercases the o in organization within _user_actions_dropdown.html.erb
* Fixes failing e2e tests
This change introduces several things things:
1. Fixes the performance of the `/admin/abtests` page; instead of
rendering all of the experiment results, just render the overview.
2. Adjust the show page for an experiment to show the summary of
results.
3. Favor the existing "started_at" and "ended_at" attributes of
FieldTest (see https://github.com/ankane/field_test#config)
4. Update the field test experiments to include the `started_at` and
`ended_at` attributes.
5. Skip processing all non-active experiments in our conversion handler.
Why are there no tests? This is a page that is Admin only and is only
visible for reporting purposes. So, it's not quite worth writing tests
as you'd need lots of data. So we'll assume the logic from the upstream
[field_test gem][1] is adequate.
Closesforem/forem#17869
[1]:https://github.com/ankane/field_test
In the general sense we have an existing `order by` that follows the
following format: `order(x) = f(x) * rand() ^ ( 1 / g(x))`
For the present [20220603-variant-b][1], `g(x)` is the article’s score.
And `f(x)` is 1.
This pull request introduces a few named variations for the above
`order(x)` formula.
The three named formats each use a different `g(x)` function; namely
`greatest(0.1, ln(1 + greatest(0, public_reactions_count)))`. The more
public_reactions the article has the closer to zero the resulting
positive number will be. And raising a random number, with range
`(0..1)`, to the inverse of that number will tend to mean that artciles
with many reactions will tend to group towards the higher end of the
random range, whereas articles with few reactions will have a more even
distribution across the range.
Further the `ln` function helps dampen the weight we give to reactions.
The variation within these three order levers is on the `f(x)` portion:
1. Using `published_at`
2. Using `last_commented_at`
3. Using a mix of `published_at` and `last_commented_at`
In all cases, those dates are converted to an integer. A date 2 weeks
ago will result in a number less than a date 1 week ago which will be
less than a today.
The idea for the mix of `published_at` and `last_commented_at` is to see
a mix of things where some “older” articles (from the underlying result
set) will get a chance to show up earlier in the feed.
My rational for this order structure is because the `RANDOM() ^ (1 /
score)` is showing possible success in a current experiment. And in
past trials long past, it rose to the top as a likely and viable
contender.
These new `order_by` lever patterns introduce three things:
1. A variable based on a date in time
2. A dampening of what can be a large number; (we have scores in the
publication range that are between -200 and 750 so I think it is
important to apply a dampening. For example `(0.1 ^ (1/100)) =
0.977` and `(0.01 ^ (1/100)) = 0.955`; in other words these large
scores aggressively pushed their corresponding posts to the top of
the relevance; even as we weren't explicitly querying for those
scores.
3. With the score being quasi-magical, it doesn’t make sense to sort on
that value but to instead sort on a property that represents what
we’re setting as our experiment goals (e.g. publishing something or
commenting on something and/or reacting to something)
Note: it would be feasible to extract these into a singular order lever
that we would configure. But that's a future concern.
Also note, none of these are yet part of any experiment, but are instead
being "queued up" to add to our available corpus.
Closesforem/forem#17834
Related to:
- forem/forem#17827
- forem/forem#17826
- forem/forem#17833
- forem/forem#16128 :: for past order queries to seek as inspiration
[1]:https://github.com/forem/forem/blob/main/config/feed-variants/20220603-variant-b.json
* Adds the Assign Role modal to the Member Index View
* Adds e2e tests for the Assign role modal
* WIP: Conditionally redirects to the correct view upon assigning a role
* Conditionally renders the redirect in the correct method :|
* Adjusts the conditional redirect to account for ID
* Adds an even more explicit check for the correct refferer
This is uncalled code. We instead use
`Spam::Handler.handle_article!` (see
[Article#create_conditional_autovomits][1]) for usage.
```shell
❯ rg ArticleHandler; echo $?
1
```
The above command shows for the "after this commit" state that there are
no mentions of the `ArticleHandler`. The `1` is the exit status of the
`rg` (e.g. `ripgrep`). A 1 exit status means no matches found.
[1]:bea711310e/app/models/article.rb (L915-L917)
Relates to forem/forem#15412
* Add utils for preset date ranges
* show the preset options in the calendar
* allow ranges to be selected in storybook
* add some more docs
* add missing prop type
* add tests
* move story out of beta
* fix last time periods
* small refactors
Prior to this commit, we were always using a new random number for a
query. With this commit we cache the randomized seed; which allows us
to have "a repeatable random" experience within a windo of time.
Closesforem/forem#17826
* refactor(listings-dashboard): migrates comp to pure comp
* refactor(listing-dashboard): organizes data setup for tests
* refactor(listing-dashboard): uses func to setup tests and starts using screen
* test(listing-dashboard): refactors tests using role query and expects
* test(listing-dashboard): separate first listing tests into another description block
* test(listing-dashboard): separate second listing tests into another description block
* test(listing-dashboard): separate third listing tests into another description block
* feat: create a crayons component called MultiInput that appears under App Components/MultiInput
* feat: add the doc describing the components to storybook
* feat: create the component ina different file and reference its usage from the stories
* feat: add a random class to hook up a stylesheet to the component
* lets just copy soem HTML
* chore: remove arias that will not be used for the multiinput
* feat: update the classnames and remove unneeded html
* feat: multi input css updates
* feat: add the ability to set the list of emails using state
* feat: add the ability to clear the input selection
* feat: remove item
* feat: handle key events like space, comma and enter in the input
* refactor: clean up code a bit
* refactor: rename email to item
* fix: remove space keydown as its causing weird behaviour
* refactor: remove unused css now that we using pills
* feat: ensure that we do not add blank pills
* feat: add the component to BETA
* feat: rename addToList to addItemToList to be more verbose
* feat: add the first component prop i.e. placeholder
* feat: add a more descriptive text
* feat: add a padding to the field
* remove unused arial labels, and erword soem descriptions
* feat: add imports to scss
* Update app/javascript/crayons/MultiInput/MultiInput.jsx
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/javascript/crayons/MultiInput/MultiInput.jsx
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/javascript/crayons/MultiInput/__stories__/MultiInput.mdx
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
The commit includes three changes that work to allow us to "seed" the
randomization. When using the same seed, and randomizer should/must
return the same sequence of numbers.
First, I added the "seed" parameter to the variant query. If you want
the same sequence of random numbers from query to query, pass the same
seed. Otherwise, we'll use a Ruby generated random seed.
Second, I added a virtual column to the virtual `article_relevancies`
table. If you provide a seed, and call the query twice, the first row
in each of `article_relevancies` will have the same `randomized_value`,
likewise the second row, etc.
Third, I amended the existing `order_by_lever` that had a `RANDOM()`
postgresql function call. I replaced that with the `randomized_value`
which is computed based on the provided seed.
Fundamentally the idea is to allow for randomness but introduce possible
repeatability; a hard thing considering that some of the inner selection
criteria is not fixed (e.g. number of reactions can change from moment
to moment).
I wrote a [complimentary blog post][1] to further explain what's
happening.
Related to forem/forem#17826
[1]:https://takeonrules.com/2022/06/03/adding-reproducible-randomization-to-sql-queries/
* 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
