* Adjusting ArticlePolicy for admin only posting
The goal of this commit is actually two fold:
1) To add documentation regarding my current emerging understanding of
our caching implementation as it relates to our authorization and
authentication.
2) Flippiing "on" the feature's core authorization check.
Buried within this is the desired normalization of the authorization
between the `ArticlePolicy`'s `#create?`, `#preview?`, `#new?`.
My testing plan for this is to ask for SRE to spin-up a canary, then
test. What does that look like? I'm uncertain because this is nudge
closer towards our edge-caching strategy. Which makes robust testing
more difficult.
Closes forem/forem#16483
Related to #16529, #16571, #16536, #16529
Informs #16490, #16606
* Update spec/requests/editor_spec.rb
Co-authored-by: Jamie Gaskins <jgaskins@hey.com>
Co-authored-by: Jamie Gaskins <jgaskins@hey.com>
* Initial hack
* Begin functionality implementation
* Add proper route
* Finish up
* Fix test and formatting
* Fix test vars
* Update app/views/moderations/actions_panel.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/views/moderations/actions_panel.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/views/moderations/actions_panel.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/controllers/articles_controller.rb
Co-authored-by: Michael Kohl <me@citizen428.net>
* Update file to not use keys that are not needed
* Finalize featured logic
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Co-authored-by: Michael Kohl <me@citizen428.net>
* move script to packs, strip ids
* make sure userdata is available before determining ui
* stop working around old html, fix duplicate ID errors
* skip login modal
* remove DEV hard coding
* replace system spec with cypress spec
* update base_data to include apple auth info, add to cypress tests
* add initial version of DUS to resave HTML
* remove data update script
* Removes code behind new_admin_members feature flag
* Removes components/admin/users/tools/* and the tools components
* Removes unused /admin/users/tools/* controllers, comments, and routes
* Removes New Member View-related E2E and RSpec specs
* Remove admin_users_tools.rb frin spec/support/shared_examples/
* Removes remaining component-related specs
* Removes the view_component gem and test helper
* Resolve merge conflicts in Admin::UsersController
* Removes the view_component gem, as it is no longer used
* Removes view_component from Gemfile.lock
Observed the (beneficial) wayback machine was sending this user agent
string when making archive requests, but has been reporting 403's when
interacting with DEV recently.
This commit builds on the conditional rendering of navigation links by
adding a routing constraint to all :listing routes.
The impact is, if we were to disable the listing feature (e.g.,
`FeatureFlag.disable(:listing_feature_enabled)`) all requests to `GET
/listings` (and those drawn in the [config/routes/listings.rb][1] file)
would return a 404 response.
Related to forem/rfcs#291, #16335, #16338, #16362.
Testing this change:
1. Start your local application (e.g. `$ bin/startup`)
2. Go to http://localhost:3000/listings
3. You should get a Successful response.
4. Now disable the feature (e.g. `$ bin/rails r \
"FeatureFlag.disable(:listing_feature_enabled)"`)
5. Refresh http://localhost:3000/listings
6. You should get an `ActiveRecord::RecordNotFound` error; because the
application is now looking for a user or org named "listings"; in other
words we're not routing `GET "/listings"` to `listings#index` controller
action.
7. Now enable the feature (e.g. `$ bin/rails r \
"FeatureFlag.enable(:listing_feature_enabled)"`)
8. Refresh http://localhost:3000/listings
9. You should get a Successful response.
10. Goto 4
This commit is intended to be the penultimate change before we toggle
the listings section off by default.
[1]:c2ce2c32d5/config/routes/listing.rb (L1)
Prior to this commit, in test, we had two different answers to "what is
the host of this application?" For Rails generates
URLs (e.g. `root_url`) we would get one answer. For our custom
`URL.url("/")` we got another answer.
This resolves and patches that up.
Closes#16347
The fundamental goal in this refactor is to make it easier to disable the
Listings feature set. By extracting a routes file (via the `draw` method [see
implementation details][1]), we can more easily disable those routes _en
masse_. This "crease in the code" could mean that we wouldn't need to update
the controller action logic. An update of that logic might mean going into
each controller action related to listing and adding a conditional for render
404 when listing is disabled.
Now, on to why this should work (not I did not open the application and click
around, but instead went with a "let the framework help me" mindset).
I believe that this should work; though there's a caveat†. Here's why I
believe this will work for extracting the listing routes:
Before making changes I ran the following:
```sh
$ rails routes | sort > original-routes.txt
```
Let's break that down:
- `rails routes` :: renders the routing table for Rails; this is how
Rails converts routes to the magic of stuff like `article_path(:id)`
- `| sort` :: to sort the results
- `> original-routes.txt` :: to write the results into a file.
Then I made the changes and ran the following:
```sh
$ rails routes | sort > updated-listing-routes.txt
```
And finally, I ran:
```sh
$ diff updated-routes.txt original-routes.txt
```
The results were as follows:
```sh
500c500
< api_organization_listings GET (/locale/:locale)/api/organizations/:organization_username/listings(.:format) api/v0/organizations#listings {:locale=>nil, :format=>"json", :to=>"organizations#listings"}
---
> api_organization_listings GET (/locale/:locale)/api/organizations/:organization_username/listings(.:format) api/v0/organizations#listings {:locale=>nil, :format=>"json"}
```
Note the only difference is that the above two lines, one has
`:to=>"organizations#listings"` and the other does not. However, the
`./spec/requests/api/v0/organizations_spec.rb` exercises the route; so I
assume a hiccup/foible in the route reporting.
There was no difference between the before and after files.
† Caveat: if for some reason the order of the routes mattered, this will
have messed that up. I don't think that is the case, but we shall see.
Related to forem/rfcs#291 and #16335
* Added tag search to nav menu
* Added tag search
* Improved tags search results view
* Removed commented lines from the controller
* Fix specs for Search::Tag
* Prepare for tags search pagination
* Fixed Search::Tag specs
* styling
Co-authored-by: Paweł Ludwiczak <ludwiczakpawel@gmail.com>
* Convert symbol hash keys to strings when calling .perform_async
Fixes a warning from Sidekiq 6.4.0+ about perform_async arguments
which are not equal when passed to perform (`JSON.parse(JSON.dump(arg))`
should equal arg).
This is a safety measure to prevent passing objects (like classes, or
model instances) rather than their representations (like a class name,
or a model's attributes hash).
This warning will be an error in sidekiq 7
* Turn warning into an error in non-production environments
* Use string keys for reaction notification and article fetched
Missed these two on the first pass
* Update example argument hashes for #enqueues_on_correct_queue
Since this calls perform_async under the hood we need to pass json
safe hashes in the test cases as well.
https://github.com/forem/forem/blob/main/spec/workers/shared_examples/enqueues_on_correct_queue.rb
* Convert keys from FollowData#to_h to string before perform_async
I'm not sure enough where else (outside of notification) to_h is being
called, so I'm converting here when building args, rather than in
FollowData#to_h, which might be my next step.
* Let FollowData#to_h return a hash with string keys
Update spec to use string keys as well.
* Make to_h return string keys for ReactionData
Like FollowData, the #to_h method is only used to call
notifications (this is used to enqueue sidekiq jobs).
* Remove a key that was in the hash
Since reaction_data calls to_h, it gets string and not symbol,
keys. Call Hash#except with a key that was actually there.
* Initial work
* Implement strategy injection into WeightedQueryStrategy
* Modify field_test config and adding variants
* Change orginal to constant and make some other adjustments
* Fix hardcoded test values
