In looking at forem/forem#16787, it felt like we would benefit from a
similar approach as we adopted for nullifying blank strings.
This refactor helps pave the way for a "normalize_text_for" method (or
some such thing; naming things is hard).
This change also involved introducing a `describe` block into the
associated spec.
* Fix broken documentation link
When sending an invitation, and smtp isn't configured, we show a link
to the old smtp-settings page, which has been renamed
email-server-settings in the admin documentation site.
* Remove explicit link target, assert link text is present
This spec failed when I changed the link target to match the
documentation. Rather than moving the target, I'm just asserting we
show a link to the docs (not where the docs are located).
* Only fetch RSS of users who can create articles
This commit leverages changes from forem/forem#16732 and
forem/forem#16763 to ensure that we're only fetching RSS feeds for
folks who have permission to create articles.
In addition, I chose to rename the variable `user_scope` to
`users_scope` to bring consistency in the variable names.
I also chose to refactor a private method so that it wasn't setting two
instance variables but was instead returning a value that could be used
to set an instance variable.
Closesforem/forem#16487
* Amending method name
This change makes it easier to resolveforem/forem#16487.
What do I mean by that? To address forem/forem#16487, I need to only
select user's who are authorized to create articles. In
forem/forem#16732 I added a method that will allow chaining of a User
scope. So with this current commit and forem/forem#16732, I'm
triangulating on an approach that will make that change easier.
I did not want to conflate those two, as mixing this PR's change and
what is necessary for the closing PR would create a more complicated
review. Not unduly complicated, but one that will require more tests
and a change in logic. And for someone reviewing the diff, those
concerns could easily be lost.
Yes, I have changed the method signature, but that method signature is
limited to one location:
```shell
❯ rg "Feeds::Import.call"
app/workers/feeds/import_articles_worker.rb
21: ::Feeds::Import.call(users_scope: users_scope, earlier_than: earlier_than)
```
So I look to the method signature a bit as an internal API, hence the change.
Related to forem/forem#16487
* Use correct table heading for username
* WIP add role filter and crayonsify forms
* styling
* responsive
* Add form back in that was removed by merge conflict fix
* Suggest only valid search options
* Add basic tests for search and filter by role
* Add aria for search field
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Add email to aria
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
Co-authored-by: Paweł Ludwiczak <ludwiczakpawel@gmail.com>
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
As I'm looking at limiting feed fetching only for users who are able to
create articles, I needed a means of querying "Who are the users who can
create articles?" This bit of work was the smallest chunk that I could
think of.
These kinds of questsions are going to propogate (e.g. give me a list of
all the people who can comment? who can create articles in this space?)
For now, this pattern should suffice.
Yes, there's duplication of knowledge between the policy's instance
method and class method. And there's a bit of knowledge bleed between a
user's method (e.g. `user.any_admin?` and
`*Authorizer::RoleBasedQueries::ANY_ADMIN`) but that's a small "evil".
Related to #16486
This commit compresses the policy check that spanned both :new? and
:enabled?. We hide the ability to upload a video (as per the altered
html.erb files of this commit) but we didn't enforce the same logic in
the controller.
Further, as Videos are a subset of Article, I'm adding the "verify the
user is not suspended" test.
Directly relates to #16483
For sleuthing this relates:
- #16728
- forem/forem#16537
- #16634
And for historical context, this relates to:
- #10955
- #10954
- forem/internalEngineering#149
* Adding indirection for Tag#name to ease future work
In pairing with Arit, we were able to capture a few small wins in
regards to favoring an accessible tag name. In other words, where ever
you see a tag's name, we want to render it as camel-case. This will
greatly help those using a screen reader and frankly visually scanning
the tag (idontknowaboutyoubutthisiskindahardtoread).
However, as we explored the
code base, we found several places that will require further
consideration. These revolve around the API and caching of tags for
articles and listings as well as the JSON documents we use for
populating drop-down lists.
So, instead of unleashing a large pull request, we're opting to provide
a small non-breaking refactor that demonstrates where we're going and
keeps production working as expected while allowing future
development/testing to benefit from these captured gains.
Our next steps are to revisit the related issue and do a proper task
breakdown, becuase there are too many considerations to call this a
"small win".
I also encourage reviewers to read the comments. This is an emerging
mental pattern that I believe helps us conceptually move our codebase
forward while also guarding against the mega-PR with oodles of commits
and file changes that span numerous contexts.
Related to forem/forem-internal-eng#269
* Expanding specs to address feedback
* Don't send notification for invalid reactions
When a moderator flags a user,
and an admin marks this invalid
and the moderator tries to flag the user again
then destroy the existing reaction, and check whether to notify
Since the points for invalid reactions are set to 0, this was not being
skipped. Now it will be.
* cleanup test cases for reaction skip notification
As part of the [Authorization System Use Case
1:1](https://github.com/orgs/forem/projects/46) project, we are driving
towards the feature of: "Only admin's may post articles in this Forem."
This commit ensures that the API's "create an article" end-point
delivers on that feature.
Along the way, I've added reading notes and comments, to help us further
flex in the future (namely move all authorization checks into a policy
object).
Closesforem/forem#16488
* Trigger Build
* Remove cache header before_action and add ability to search by tag name
* Remove cache header before_action and add ability to search by tag name
* Add internal bulk tag endpoint to get tags by array of names or ids
* Restore V0 tags controller
* Update identities where the auth data dump is a plain hash
All but 3 records in DEV have OmniAuth::AuthHash objects serialized as
auth data dump. Normalize the remaining ones so they don't cause no
method errors when we treat the auth_data_dump as an object (sending
`#info` instead of asking for `['info']`).
should address https://app.honeybadger.io/projects/66984/faults/84183659
Add null safety check in a second example (that null values should not
cause an error, and should not be coerced to auth hashes).
* Ignore rubocop suggestion to create list
Because the factory for identities doesn't automatically create the
required user object, this is impractical.
While I'm here, move the identity hash update into the creation block
rather than doing this in two passes.
Co-authored-by: Jamie Gaskins <jgaskins@hey.com>
* Removes logo_svg-related code
* Removes logo_svg-related specs
* Removes the logo_uploader and logo_uploader DUS spec
* Removes the logo_uploader_spec.rb
* Adds a DUS to remove the logo_svg var from the DB
* Reverts the removal of the logo_svg_uploader.rb
* If href is nil, allow node
* Add unit test showing no change
My first pass had the `<a>` within an h1 content, but the scrubber
added a newline after the closing a tag?
* 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>
* don't set nil when size not called
recently, #16570 worked around an issue where aggregated siblings
wasn't present, by only calling size if present.
Unfortunately, this causes a comparison of integer (new json_data
aggregated siblings count) with nil (result of the safe navigation for dig()&.size
assigned nil to previous_siblings_size, when we expected it to be
0). The initial error on the same data moved farther down the controller.
If old_json_data is present, but does not have an array in
reaction.aggregated_siblings, we want to have previous size be zero.
Remove guard clause and previous assignment
The issue was not that old_json_data was nil (it came from an existing
notification) but that there were missing keys (or rather that the
json data for some notifications didn't have a reaction key at all).
Remove the guard clause and either set to the size, or zero if there
is none. I don't understand what the guard clause was for, so replace the
safety by adding a nil safe call to dig. I don't _believe_ this is
possible but in case it was we can shorten the check here.
* Add test to cover missing json_data['reaction'] key
* Remove unneeded temporary variable
* 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>
* feat: create a from_email_address and a reply_to_email_address
* feat: update other mailers with the new SMTP email settings
* test: update all spec files
* fix: use the SMTP::Settings value
* fix tests
* spec: fix the comma
* feat: tighten some logic
* fix: test
* fix tests
* fix tests
* final fix test commit
* fix test
* fix test
* oops
* feat: add a reply_to for Devise Mailer
* chore: update the description
* use a proc for reply_to
* feat: update text
* Update spec/mailers/digest_mailer_spec.rb
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
* Update spec/mailers/verification_mailer_spec.rb
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
* Update spec/mailers/shared_examples/renders_proper_email_headers.rb
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
* refactor: move OPTIONS to a helper as its only being used in the view layer
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
* feat: allow reply_to and email_from to be set for an SMTP config
* feat: use these SMTP values in the mailers
* spec: test the application_mailer
* fix: validate with email, and not url
* feat: mimic macs changes from https://github.com/forem/forem/pull/16216 to use in this PR
* setup packs for admin
* refactor: order the keys and add a const for the auth methods
* feat: rename the header to a more user friendlly name
* chore: move the section with Emails
* feat: add a toggle that will show and hide the SMTP form under certain conditions
* feat: add the javaScript to handle the toggles
* feat: add a better description until we convert to a dropdown
* feat: ensure that we have declared sendgrid_enabled
* chore: add anote to the config controller
* chore: remove references of the email addresses to keep brnach scoped
* feat: tweak js
* test: cypress workflow to update smtp settings
* feat : update the smtp tests
* remove comments
* update test
* chore: rename NOTE
* feat: polisha dn test ForemInstance.only_sendgrid_enabled?
* chore: remove specs
* Update app/lib/constants/settings/smtp.rb
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
* Update spec/system/admin/config/admin_updates_smtp_settings_spec.rb
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
* Update spec/system/admin/config/admin_updates_smtp_settings_spec.rb
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
* Update spec/system/admin/config/admin_updates_smtp_settings_spec.rb
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
* Update app/javascript/packs/admin/config/smtp.js
Co-authored-by: Nick Taylor <nick@iamdeveloper.com>
* refactor js as per comments
* refactor as per comments
* Update cypress/integration/seededFlows/adminFlows/config/emailServerSettingsSection.spec.js
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* refactor: update the Cypress tests
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
Co-authored-by: Nick Taylor <nick@iamdeveloper.com>
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* feat: remove the default email and cobine the periodic digest and the contact email under the Email section
* refactor: rename the email_link to contact link and use the contact_email as a default and fallback to the ForemInstance.email
* chore: alignment
* feat: use the contact_email helper
* feat: move the contact_email to the ForemInstance model
* feat: use ForemInstance.contact_email instead of the application helper method
* removed the application Helper
* feat: set the dafault on the contact_email
* fix: cypress tests
* Update app/lib/constants/settings/general.rb
Co-authored-by: Michael Kohl <me@citizen428.net>
Co-authored-by: Michael Kohl <me@citizen428.net>
* Require profile fields to belong to a group
Remove the empty group dropdown from the group select tag
Remove the optional: true from the belongs_to validation (raise a
validation error on save if the group is not provided)
Update test to remove belongs_to's optional setting
* Update ProfileFields::Add spec to include profile field group
* update factory to ensure a non-empty profile field group
* Add required profile field group to seeded profile fields
Since profile field is required, create was failing (silently).
Add required field so these are available in e2e tests.
* Use factory `association` to create a profile field group
https://github.com/thoughtbot/factory_bot/blob/master/GETTING_STARTED.md#explicit-definition
* provide required profile field group when posting data
* Fix one spec, drop another
Both of these scripts will be removed in the other branch (changing
the attribute name) - dropping the test here seems lower trouble than
modifying an out of data data update script to pass.
* skip test slated for removal
Similar to the last commit - this test exercises a script about to be
archived in the other branch.
* 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
* Removing Articles::Builder making policy decision
This change is a refactoring through triangulation. Given that
`ArticlePolicy#new?` returned true, I'm prepared to assume that calling
`authorize(Article)` in all cases is acceptable.
So to narrow the Builder making a policy decision I renamed the returned
value to reflect what it was actually doing in the logic. And in
renaming, flipped the polarity of the boolean. Why the flip? Because
`needs_authorization == !store_location`.
In consultation with Allison and Jennie, I'm proceeding with a short-cut
to get me unstuck. That unstuck is namely "I need to ensure that the
articles#new action can go through authorization."
Given that I'll be spending time in the authorization layer, I hope
these noted short-cuts and comments will be useful in future spelunking
efforts regarding authorization.
Closes#16529
* Update app/policies/article_policy.rb
Co-authored-by: Michael Kohl <me@citizen428.net>
* Disabling spec
* Update app/policies/article_policy.rb
Co-authored-by: Dwight Scott <dwight@forem.com>
* Update app/policies/article_policy.rb
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Michael Kohl <me@citizen428.net>
Co-authored-by: Dwight Scott <dwight@forem.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* 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
As written in the comments, we're looking at making the smallest change
to deliver on the feature. The other goal is to move from our
`user.admin?` paradigm towards leveraging Pundit policies.
If we need to move beyond Pundit, it will be easier once we've moved
all of our `user.something_something?` to policy questions. And please
note, I don't know if we'll move past pundit.
See [Authorization System: use case 1-1 project][1] for details on the
project.
Closes#16483
[1]:https://github.com/orgs/forem/projects/46/views/1
This is the least effort I can presently think of to allow for us to
reprocess user article's and handle the scenario in which the user may
have once had permission to the liquid tag but no longer.
This DI is not something I imagine using, but may highlight a better
approach for liquid tag permissions.
Related to #12146 and #16460
