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
* when there is no div for it, don't render CommentSubscription
* Retrigger CI
* Retrigger CI
* don't write an error to the comment div if its gone
This fixes an issue seen in tests, where the page transitioned while
we were running the articlePage async handler, so the article-body
element was gone (can't access dataset of null), and the error handler
catch block tried to access the innerHTML of another getElementById.
* Use existing found element `root` when setting the error message
No need to find a new comment-subscription div to write the error to,
we already named the one we're interested in at the beginning of the function
* Remove dots from chart when time range is Infinity
* refactor: 🐛 Remove dots using the chart options
* refactor: ♻️ Improve params of drawChart func
* refactor: ♻️ Use a variable showPoints
* only init mod tools if we're still on article page
* Update app/javascript/packs/articleModerationTools.js
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
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
* Updates the copy for all modals within Admin Member Detail view
* Resolve most failing tests within managaUserOptions.spec.js
* Update app/views/admin/users/show/profile/actions/_export.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update cypress/integration/seededFlows/adminFlows/users/manageUserOptions.spec.js
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* 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
* Updates the overview copy and over modal copy
* Updates E2E tests for Admin Member View overview fields
* Fixes copy on credit button in manageCredits.spec.js
* 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
In conversations with citizen428, this method looked to be a holdover
from a past approach. Reviewing the code, we can get the same behavior
with other methods.
Further, I added some comments for future considerations, and refactored
for more readily scannable guard clauses.
Related to forem/forem#16488, forem/forem#16681, and forem/forem#6255
As I was investigating an approach for #16488, I stumbled upon two
methods partially doing the same thing. This helps consolidate the
logic and provides some guiding documentation.
* 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>
