* Penciling in a Default Spaces section
This delivers two primary things:
1. Extracting shared policy examples
2. Providing a functioning skeleton for toggling on the
"limit_post_creation_to_admins" feature.
Important is that once merged, it would be possible for this code to
"leak" out. But how that leaks out is also how you can test that the
feature works.
First, to orient, there is a constraint for a new route. That
constraint checks if the feature flag exists (e.g. has been explicitly
enabled or explicitly disabled). In other words, at this point, you
can't accidentally enable the feature via the UI. But once you have
enabled the feature, you can then toggle the feature on and off.
So, to test this in the browser:
1. Pull down this branch
2. Run `rails runner "FeatureFlag.disable(:limit_post_creation_to_admins)"`
3. Startup your the web server.
4. Login as an administrator
5. Goto /admin/content_manager/spaces
a. Bask in the glory of a plain HTML form
6. With another browser, login as another non-admin user
7. Go to /settings/extensions, you should see a section Publishing from RSS.
8. Now with the admin's session, update the form to turn on
"limit_post_creation_to_admins"
9. Back to the non-admin browser, refresh /settings/extensions, you
should no longer see the section Publishing from RSS.
Note: I have not included an admin menu item as that is related to and
dependent on some refactors I'm working on (see forem/forem#16888 and
forem/forem#16847). So a bit of "security through obsurity"
Note: In the future, once we resolveforem/forem#16490, we'll start
toggling the "Create a Post" button.
Note: I am not including Cypress tests nor request tests for this
feature because the implementation details related to the testing via
that approach are a little too volitale.
Related to forem/forem#16842
* Updating copy based on forem/forem#16893
* styles
* styles
* dark styles
Co-authored-by: Paweł Ludwiczak <ludwiczakpawel@gmail.com>
* complete IG implementation of profile embed, refactors, update specs
* Follow redirects and check them for validity via recursion
* working out redirects
* add IG test links with params
Co-authored-by: Dwight Scott <dwight@forem.com>
* Adding docs and specs to AdminMenu.nested_menu_items
This relates to PR forem/forem#16847 which addresses issue
forem/forem#16842.
The goal of this PR is to help me develop an understanding of the
AdminMenu so I can further extend it and better understand it.
There's also a bit of knowledge sharing that I'm looking for, and the
comments and tests are there to help "confirm" that knowledge. There
might be more that I'd consider regarding a refactor, but I want to make
sure I'm on the right path before I go further.
tl;dr - this is the smallest commit I can make to begin to tease out an
understanding of the method I put under test.
* Update app/models/admin_menu.rb
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
* Adding more documentation
* Update app/models/admin_menu.rb
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
* feat: add the feature flag route and controller
* feat: add a ff page
* feat: update to a post with a success banner
* feat: test the feature
* feat: update the styling
* feat: change feature flag to extension witha few more improvements like adding a model not backed by a table
* feat: update the text
* refactor: if you enable a FF, it gets added under the hood as well
* feat: accessibility name for label
* use keyword args
* use locales
* Update app/views/admin/extensions/index.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/views/admin/extensions/index.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/views/admin/extensions/index.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update config/locales/controllers/admin/fr.yml
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/controllers/admin/extensions_controller.rb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* fix: rubucop
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Refactors _banish.html.erb by removing duplicate code
* Refactors _banish.html.erb to account for new and old users
* Moves conditional into Admin::UsersController#set_user_to_be_banished
* Reverts last commit, as it didnt work as expected
* Fixes last commit, which reverted to the incorrect code
* Pulls banishable user into instance var and fixes button txt
* Re-enable imageUpload native integration
* remove temporary inline comments
* move addEventListener to useEffect hook
* console.log on native messages from image upload integration
* Debug suggestions
* store text area in ref rather than state
* call error callback from native message handler
* Remove debug logs
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Removes admin_member_view feature flags and refactors conditionals
* Removes unused admin/users/_email_tools partial and user_email_tools_spec
* Actually remove the admin/user_email_tools_spec this time
* Removes the edit route from admin.rb users
* Adds a DUS (and spec) to disable and remove admin_member_view flag
* Fixes admin/users_spec.rb failures by updating spec with Member Detail changes
* Fixes spec failures within admin_bans_or_warns_user_spec.rb
* Refactors Admin::UsersController#credit_params due to failing specs
* Removes last traces of edit_admin_user_path and fixes buttons, specs, etc.
* solution
* fixing specs
* complete specs
* nudge Travis
* resolve database issues
* nudge Travis
* Check that the settings table exists before loading the class
This maybe fixes an issue in test-console-check accessing a missing
table `users` (because we're requiring
settings during the initializer, and we're initializing the app during
a schema load on a newly created db).
* refactor check
* privatize and rename
* add self
* reposition private class method
* Prevent accidentally deploying to DEV
* Skip tests to try deploying to benhalpern
* Allow PR to deploy to benhalpern
* Allow other branches to deploy
* Oops
* Revert changes to travis.yml
Co-authored-by: Dan Uber <dan@forem.com>
Co-authored-by: Andy Z <17884966+Zhao-Andy@users.noreply.github.com>
* Normalize article titles
* Change method name to match what it does
* Expand on allowed emoji ranges
This required a few changes to be in compliance with Rubocop because
that regex is a beast.
* Limit feeds import fanout to users with feeds
This filtering for feed settings occurs in
Feeds::Import#filter_users_from already, so the enqueued ForUser
jobs were mostly no-op, but the queue latency spiked as hundreds of
thousands of jobs were added to default.
Prescreen users to avoid enqueuing a noop job every hour for every single
user without a feed.
* Update tests to check only jobs for users with feeds are enqueued
* spec cleanup
Only include alice when we check no job is enqueued for her.
Assert no job is enqueued for alice.
Rename bob to user when alice isnt there to contrast.
* Update spec
Use update_columns to bypass setting validation (checking feed is
valid/reachable)
Remove unneeded timecop block when passing a set time
Remove sidekiq: fake and allow Import.call to be received
* Empty commit to trigger CI rebuild
We had been (since the beginning) disabling webmock in this
test (which means vcr was _not_ intercepting requests and we were
making them live). This appears to have been a work-around for an
issue where the captured URL in the cassette pointed to cloudinary,
while the code was fetching from the source directly, and an unhandled
request error was raised when running the spec.
However, the upstream source (https://via.placeholder.com/350x150)
activated cloudflare bot detection, and rather than a png image
response, we were getting an unprocessable html gateway page "Checking
your browser..." from cloudflare, and the test was failing.
Point the vcr cassette at the same url the test checks, and remove the
local webmock disable.
* Fan out Feeds::ImportArticlesWorker
Doing all that work within a single Sidekiq job has begun taking over an
hour on DEV. Regardless of the reasons we did it that way originally, we
should be able to handle this concurrently. If we cannot, we need to
investigate why and handle it properly rather than consigning it to
sequential work.
* Fix specs
The specs make assumptions about how the code under test is implemented.
This commit does not change that, as much as I would like to. Instead,
it just aligns the assumptions with the new implementation.
The previous tests didn't actually represent reality though, since we
can't get a Time or ActiveSupport::TimeWithZone instance inside of the
`perform` method while running it through Sidekiq. Instead, the specs
seem to be relying on the fact that the time instance gets serialized to
ISO-8601/RFC3339 format and that that format is understood by Postgres.
Otherwise, I'm not sure how it would work in production as written.
The new specs reflect reality more closely. The `earlier_than` value
will be converted into an ISO8601/RFC3339 string when passed through
Sidekiq.
* Add parens to perform_bulk call
Turns out, we actually do this pretty consistently. I could've sworn I
saw a bunch of these calls without parens. ¯\_(ツ)_/¯
* Improve variable naming
This is not a list of ids, it's a list of lists of arguments for Sidekiq
jobs, the inner of which contains an id, but that's not the only thing
it contains.
```shell
❯ rg "@notifications_index"
```
The above shell command exits status code 1, which means there are no
results found.
This relates to exploratory work for forem/forem#16821
