* Updating valid domain registration
Prior to this commit, our regular expression did not account for the `-`
character as valid within the domain. The `-` character cannot be the
first nor last character of the domain (e.g. `-hello.com` nor
`hello-.com` are invalid but `hell-o.com` is valid).
In addition I tidied up the default value of the
`blocked_registration_email_domains` to match it's sibling `allowed_registration_email_domains`.
This relates to the spammer seo-hunt.com
* Adding validator domain validator spec
* Moving request spec to unit spec
This change does two things:
1) Allows for 2 character domains
2) Moves the spec for 2 character domains from an expensive spec to a
cheaper to run spec (e.g., request-cycle to unit-test validator)
It preserves PR #12268
* Parameterizing featured story requiring main image
This begins to ease the resolution of #15292.
If we merge #15240, I could see setting an `Article` constant for this
value and allowing the administrator to choose the particular behavior.
Once we have insight from the product team, we can move forward with a
more comprehensive solution.
* Adding default parameter
While this is an `@api private` method, I am aligning the defaults with
it's `@api public` caller. Yes, only specs call the method, but I'd
rather not fiddle with the specs at this moment in time.
* Reworking logic to be more scannable
* Guarding against spam from OAuth Sources
Prior to this commit, when an administrator had indicated blocked email
domains, those blocks were not applied to identities created via the
OAuth sources (e.g., Twitter, Facebook, etc). With this change, we're
hooking into the similar logic flow as suspended email accounts.
Related to #15403, #15397, and forem/rfcs#281
* Adding class documentation to exception
* Update app/services/authentication/authenticator.rb
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
* Remove Connect
* Remove more Connect specs
* Remove a lot more Connect code
* 🚮
* It all has to go
* Explicitly add httpclient
* Update application layout
* Remove messages association from User
* Start fixing specs
* reintroduce util function and refactor references
* Remove Connect Cypress test
* Fix more specs
* Remove Connect from listings
* Ignore contact_via_connect column on listings
* Remove contact_via_connect usages
* Ignore mod_chat_channel_id on tags
* Drop Connect tables
* Remove email_connect_messages from user notification settings
* Re-add httpclient 2.8.3
This was mistakenly removed as a merge conflict
* Don't need to exclude removed chat channel file
* Remove unneeded style for chat channels
* Remove unneeded channel list prop type
* Remove chat channels index/connect-link from getPageEntries
* Re-add comment from httpclient in Gemfile
* Remove connect references from mailers
Tag Moderators no longer have a chat channel
No longer will users be notified about new messages (there won't be
any)
No longer will users be notified about channel invites (you can't
invite anyone anymore)
* Don't configure Pusher and remove PUSHER_* from .env_sample
since it's removed from gemfile, the Pusher constant will not resolve, if this is
configured in the environment variables we'll fail to boot.
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Co-authored-by: Dan Uber <dan@forem.com>
* Refactoring and extending article spam behavior
Prior to this refactor, we were checking an Article's title for
spaminess. This change now checks the Article's title and
body_markdown.
In addition, the encapsulates the regular expression implementations in
favor of asking the Settings::RateLimit class to determine if the passed
in text is "spammy".
Furthermore, instead of having lots of inline logic within the article,
this refactor introduces a `Spam::ArticleHandler` class. This helps
tidy up the already busy Article specs by delegating the business logic
of Spam handling to it's own class.
There are further refactors for Comments and Users that would follow
this pattern, but this change is more important to get out the door.
Closes#15396
* Adding comments to clarify behavior of spam handling
* Adding missing expectation to spec
* Removes the 'Setup not complete' banner from the Creator Onboarding flow
* Chains the safe navigation operator to current_user in #creator_setup_mode?
* Replaces current_user with User.with_role(:creator) in creator_setup_mode?
* Checks for URL rather than path helper in #creator_setup_path?
* Consistently remove setup banner on the creator settings form
* Reverts changes to verify_setup_complete.rb
* Adds a setup-banner ID for removal of the gobal setup banner
* Replaces Rspec test with creatorSettings E2E test
* Wraps setup text in regex in creatorSettings.js.spec
* Moving blocked registration domains up
Prior to this commit, the field "worked" but you had to toggle email
authentication to enabled, then fill it out. You could then disable
email notification and it would work.
This builds on #15397
* Update app/views/admin/settings/forms/_authentication.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Prior to this commit, we had filtering options for email registration:
1. Specific allowed domains.
2. Implicitly allow all domains if no allowed domains specified.
With this commit, we add another option: The adminstrator may block one
or more domains from registering.
Closesforem/rfcs#281
This commit removes a handful of magic numbers and instead relies on a
constant.
This has a small impact in that the Basic feed will now return 50
articles instead of 25. However, normalizing the feed pagination window
size helps reduce some oddities in reporting.
In addition, this might be something we consider giving administrators
the ability to set (with default options, because we shouldn't allow
page sizes of 10_000 as that's a massive memory hog).
Related to #14709
Don't allow passing `tag[name]=` in post params to admin tag update.
There's no field for this in the view, it's not expected that someone
change the name (it serves as a natural key) - it's preferrable to
alias an old name to a new tag if a renaming is desired.
Prior to this commit, this instantiation of `Redcarpet::Markdown` was
different from the other instantiations. The other ones all included
the second paramenter (e.g., `Constants::Redcarpet::CONFIG`).
My question is, should we (or can we) be using the same configuration in
all cases?
* Add a failing test for comments index of deleted article
After https://github.com/forem/forem/pull/15052 removed the (also
broken) deleted commentable template and the redirect, requests for
comments from deleted articles raise no method errors (initially
trying to set the page title to "Comments for commentable.title" but
the assumption that @commentable is non-nil is present in several
other places.
This test currently fails (by design). Either we want to update the
controller so that comments from deleted articles are no longer
viewable (returning not found, as we did prior to
https://github.com/forem/forem/pull/5199 or making the view safe for
the case where @commentable is nil and no @root_comment is present.
These requests are happening quite frequently (@maestromac and I
suspect the sitemap may contain these pages and crawlers are visiting
the site from a published link), as evidenced by
https://app.honeybadger.io/projects/66984/faults/81994265
* Add request spec for deleted article scenario
Additionally, relabel the legacy spec (updated during #15052) to
clarify we do not render the deleted_commentable_comment view (this is
testing the comment.path, rather than the article.path/comments index
The scenario with comment.path sets `@root_comment` in the controller,
so does not trigger errors on the `@commentable` method calls.
* Update view
pass 1: get the errors to stop (need to check the rendered page is
also usable, the comment tree is not shown when commentable is nil and
this might be a huge usability/correctness issue).
* extract logic from comments index to methods and update tests
We no longer expect deleted article's comments index to render (should
return 404), only direct links to comments of deleted articles.
Only assign @article in the index for the view if it is in fact an
article (not a podcast episode, it's possible `@root_comment` was for
a podcast episode).
* remove unneeded (and soon to be incorrect spec)
No longer want or need to test for the case where root comment is nil
and so is commentable. This was an exploratory spec (scaffolding) and
can be removed.
* Undo nil safety changes to comments index
and fix typo in comments spec
* Adds a help icon to the creator settings setup page
* Moves the help icon styles from the a tag to the inline_svg_tag
* Removes reused class and aligns help icon to the right
* Refactors help icon out into a partial used across necessary views
* Moves .admin-help-button class from admin.scss to scaffolds.scss
* Adds further utility classes to align help icon as expected
* fix: closing divs and alignments
* fix: closing divs, alignments and add z-elevate
* refactor: remove the confirm email css annd add it to setup_mode
* improve mobile responsiveness
* feat: redirect directly to the new_admin_creator_setting_path from the confirmation email adn the signup
* feat: update the test to no longer show the referral which seems no longer relevant
* fix: update the tests to conform to the new URLS
* update the link
* Dark Theme preference is a user setting and not delegated
Resolves NoMethodError
* Add a view spec
This ensures the /credits/purchase page is rendered
* Test both styles based on user setting
Add an actual expectation to the view test
* views/stories and home related i18n
* PR key names fixes
* remove ja.yml
* Update en.yml
* Update fr.yml
* Update articles_search_spec.rb
* Update _meta.html.erb
* Update index.html.erb
* Update _meta.html.erb
* Update articles_search_spec.rb
text in HTML should not contain raw brackets
* Update articles_search_spec.rb
* Update _signup_modal.html.erb
* Add back missing Search text
Co-authored-by: Fernando Valverde <fernando@visualcosita.com>
* WIP - main formatters with undo syntax
* tests for new text area utils
* WIP: formatters undoing and formatting, tests to follow
* small tweak
* WIP - tweaks to heading
* add heading level tests
* refactor link formatting into separate functions, flesh out tests
* add missing test case, adjust link undo
* fix: closing divs and alignments
* fix: closing divs, alignments and add z-elevate
* refactor: remove the confirm email css annd add it to setup_mode
* improve mobile responsiveness
* Caching sum privileged reaction scores
This relates to work on improving the feed. Namely that in the current
proposal in PR #15240 I'm not accounting for how privileged users have
given feedback on an article.
With this change, I will now have a cached value on the articles table
that can be a proxy for how the privileged users have reacted.
In addition there's a small refactor that moves a constant to the
correct scoping object.
Dependent on #15283.
* Fixing method name to `exists?`
Prior to this commit, I was using `exist?` which doesn't work for
ActiveRecord::Relation objects.
* Add attribute cleaner
* Start using AttributeCleaner
* Add additional check
* Also work with non AR classes
* Remove unnecessray :aggregate_failures
* Rename to StringAttributeCleaner
* Only permit valid class names as sponsorable type
https://github.com/forem/forem/issues/14386 identified an error could
arise if input was provide to the sponsorable_type field in the admin
creation form, but it was not a valid constant (since we include the
related model in the index when loading @sponsorships, this permits
creating a sponsorship that can't easily be managed or deleted).
Add a validation to ensure when the sponsorable type is present, it's
a class (really, we probably want to also ensure it's available as an
associated model type, since we'll be looking it up with find(:sponsorable_id), but this
is an initial attempt at adding some guard rails to this form).
A more realistic solution would be to add a `Sponsorship::SPONSORABLE_TYPES` constant
to the class, and validate the supplied sponsorable type is in
`SPONSORABLE_TYPES.map(&:name)`. That requires more domain knowledge
about what kind of things can be sponsored than I have, it would
certainly include at least ActsAsTaggableOn::Tag but may include other
classes (or why would it be polymorphic).
* Explicitly list the allowed types for sponsorship
I see we can sponsor tags, and suspect that's all we can sponsor
meaningfully (the view only shows details when it is a tag).
* Use inclusion validation with options to replicate custom method
And remove the code, we don't need it any more.
* Update app/models/sponsorship.rb
Co-authored-by: Michael Kohl <citizen428@dev.to>
Co-authored-by: Michael Kohl <citizen428@dev.to>
* Downcase `followable_type` to fix wrong follows creation bug
* Use `follow_button` helper
* Remove puts statement
* Revert use of follow_button helper
* Remove downcase of followable_type from helper
* Refactor switch case for better consistency
* Add e2e test for follow organization from article page functionality
* Split cypress `it` block into two
* Add additional test to following organizations from dashboard
* Remove downcasing of followable_type for decorated objects
* Fix failing follow back spec
* Force capitalize `followable_type` param
Co-authored-by: Mac Siri <krairit.siri@gmail.com>
* Update app/controllers/follows_controller.rb
Co-authored-by: Mac Siri <krairit.siri@gmail.com>
* Add PGHero for more insights into the DB
Andrew Kane's Ruby gems will continue being added until morale improves!
* Add linux x86_64 protobuf
* Fix discrepancy between Gemfile and Gemfile.lock
No idea how this happened, but it happened when merging `main` back into
this branch.
Co-authored-by: Dan Uber <dan@forem.com>
