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
