* Remove dead code associated with old roles
* Remove test references
* Removed from seeds
* Removed unused roles from locales
---------
Co-authored-by: lightalloy <lightallloy@gmail.com>
* Refactor API user suspend, make room for more roles
* Handle adding limited
* Handle remove limited
* And swagger docs
* Update & refactor roles spec
* Remove old route
* Remove old specs
* Basic add remove functionality with few tests
* Updated cypress test and added more unit tests
* Rename display ads vars in the views (#19877)
* Renamed display_ads vars to billboards
* Rename local vars in the feed view
* Renamed display-ad in the comment
Co-authored-by: Rajat Talesra <rajattalesra4914@gmail.com>
* Renamed variables in the views
---------
Co-authored-by: Rajat Talesra <rajattalesra4914@gmail.com>
* Update js-routes to version 2.2.7 (#19883)
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
* add field for billboard target geolocations, with unit and e2e tests (#19855)
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
Co-authored-by: Duke Greene <dukegreene@gmail.com>
Co-authored-by: PJ <pj@forem.com>
Co-authored-by: Anna Buianova <lightallloy@gmail.com>
Co-authored-by: Mac Siri <mac@forem.com>
Co-authored-by: zhangted <tedcbook@gmail.com>
Co-authored-by: Josh Klar <jklar@forem.com>
* Added autocomplete value off (#19882)
* Bust cache of organization page when new member is added (#19861)
* Remove unused freezeScrolling (#19808)
* Remove unused freezeScrolling
* chore: try see if this helps to skip the flakey test that wasn't being skipped
* chore: try see if this helps to skip the flakey test that wasn't being skipped
* oops: revert the gemfile changes
---------
Co-authored-by: Mai Irie <mai@forem.com>
Co-authored-by: Mac Siri <mac@forem.com>
Co-authored-by: Ridhwana <ridhwana.khan16@gmail.com>
* ci: Allow workflow_dispatch runs to log in to GHCR. (#19885)
* ci: Fix base image builder... the right way... (#19889)
* Update postcss to version 8.4.27 (#19888)
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
* Replace uses of toBeDefined with toExist (#19862)
* Replaced toBeDefined with toExist
* Revert db changes
* Rename display ads to billboards: css and js code (#19887)
* Renamed js vars/css names
* Renamed display_ads to billboards in js functions, variables, components
* [ruby] Update sidekiq-unique-jobs 7.1.29 → 7.1.30 (patch) (#19902)
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
* Update oj to version 3.15.1 (#19901)
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
* Updated failing cypress test
* Removed commented code
* Attempt at fixing tests
* Fixed failing tests
* Added more tests
* Basic color and design changes part -1
* Disable/Enable buttons correctly
* Various design updates in Tag adjustement mod UI
* I18N and documentation
* Updated mod panel
* Fixed mod related cypress tests
* Minor design fixes
* Dark mode designs
* Test update
* Mod UI with some bugs
* Updated/simplified code fully-working
* Updated tests
* Added more tests
* Accessibility improvements
* hr line code fix
* Close mod icon bug fix
* Nit fixes
* Design fixes as suggested by Anuj.
* Design fixes
* Dark mode file usage
* Design fixes
* Nit fixes
---------
Co-authored-by: Anna Buianova <lightallloy@gmail.com>
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
Co-authored-by: Duke Greene <dukegreene@gmail.com>
Co-authored-by: PJ <pj@forem.com>
Co-authored-by: Mac Siri <mac@forem.com>
Co-authored-by: zhangted <tedcbook@gmail.com>
Co-authored-by: Josh Klar <jklar@forem.com>
Co-authored-by: Joshua Wehner <joshua@forem.com>
Co-authored-by: Mai Irie <mai@forem.com>
Co-authored-by: Ridhwana <ridhwana.khan16@gmail.com>
* define api routes and create controllers, sketch out index and create actions
* add api v1 organizations CRUD spec and docs spec, need to run swagger
* swagger dry run on admin organizations routes, typo fix in api.rb
* flesh out specs and sketch out admin actions
* move actions out of concerns/include pattern and into v1 inline
* remove private constant call
* add v1 accept header to doc spec, fix syntax in a before block
* update controllers to address failing specs
* simplify controller and clarify route config
* flesh out tests for errors
* fix long line
* add missing commas
* return username show route to v0 concern controller
* create separate show route and action name, remove nesting from create/update params requirement
* clean up syntax in controller params and update show path in specs; move routes
* fix up syntax in params permit
* create organization in index spec
* one more syntax tweak for org params
* refactoring to one show route that handles username or id
* tweak spec syntax to expect the right array
* tweak controller and specs, simplify routing to show
* remove create route, action, and specs from this branch
* add clarifying comment in show controller action
* add explicit not found return to show route
* fix controller formatting causing 404 errors
* remove comment, update specs
* remove commment and fix id show response and specs
* fix show route and request spec for username param
* update unauthorized user specs to use put for now instead of post, regenerate swagger docs
* adjust update 422 spec to break org validity
* fix admin update spec, rerun swagger
* reorganiza controller actions, update specs, ensure authorized update and delete
* improve spec, handle finding one org more gracefully, delete via worker
* copy routes into api namespace instead of moving them from general namespace
* update param in v0 show route to fit more general naming
* regenerate v1 swagger docs
* use profile image url getter in update controller response
* update swagger docs and remove unneeded comment from org' model
* configure organizations destroy action for super admins only (for now)
* Move save over and add button labels
* comment notification design and functionality
* controller error handling
* add ternery operator for background class
* minor cleanup
* add proper styling toggles
* tests and mobile spec
* add for all buttons
* add article as a param
* comment is not required on article preview
* update policy spec
* add test for coverage
* add proper button titles
* use the last user comment as comment id
* add better error handling and remove multiple fetch calls in js
* copy change to threads
* update copy, fix multiple fetch calls, add observer for loading more notifications
* update spec
* add rspecs
* more test specs
* fix test specs
* subscribe button text tests
* add export
* optimistically update ui function tests
* button initialize test
* check for comment ancestry
* add feature flag block
* some cleanup
* update logic and specs
* oops
* rubocop issues
* change config names
* change config names
* fix spec
* add one more conditional
* check for comments
* service-object the toggler
* separate routes
* continual refactoring
* refine spec tests
* clean up policy
* Adjust js and view files to match be params
* some service object refactoring
* separate endpoints on client-side
* broken spec
* service specs
* policy spec fixes
* remove action param
* remove action param from spec
* minor updates
* trigger build
* update to post
* Services don't need permitted params
* Notifications continue to be a mess, decorator specs to follow
* Not toggling now
* This doesn't really belong here
* Fix tests after moving
* Streamline front-end
* There could be errors?
* polymorphic_name is a class thing
* ☠️ json_data in notification views
* Use feature_flag helper to get current_user
* Cannot derive current subscription status from notification, only from subscription
* Default is subscribe to all article comments
* Sync up matching unsubscribe, make subscribe idempotent-ish
* Temporarily comment-out button jest tests to see if I can unstick CI
* Stop trying to detect potential subscribe-to-comment
* Stop trying to detect potential subscribe-to-comment
* Minor spec refactoring
* Add specs for article notification decoration
* NotificationDecorator specs are rather long
* Rubocop likes it?
* Minor spec refactoring
* Doesn't need to stay pending
* Add spec for subscription finder
* Expand Subscribe service specs
* YAGNI, but I don't like hard-coded config
* Refactor Unsubscribe service specs
* nobody expects the infinite scroll
* This *might* work, except for feature flag
* Ancestry can be quite deep actually
* Rubocop
* Update subscribe button for subscribe-to-thread
* Jest tests are just tests
* hasAttribute != getAttribute
* Test knows **nothing** about window size
* Tests have been lying about mobileLabel this whole time
* Make payload/endpoint testable
* Is Jest actually happy???
* Still cleaning up jest/eslint
* Temporarily comment-out cypress tests pending feature flag
* Thanks, Rubocop, what would we do without you
* Preserve round-trip for 'top-level' and 'only-author' subscriptions
* Update specs
* Move save button icon
* Update test with better config param
* Try feature flag specific to cypress env
* Tell cypress to wait for (un)subscribing to work
---------
Co-authored-by: Lawrence S <lawrence@forem.com>
Co-authored-by: Joshua Wehner <joshua@forem.com>
* Skips scheduled posts in featured post count
* Allows removing super_admin role
* adds namespace resolution op
* Adds pundit policy
* Adds rspec for role policy
* Fixes test cases and minor refactoring
* Removes dead code
---------
Co-authored-by: Lawrence <lawrence@forem.com>
* Try a ReactionCategory abstract 'model'
* Use ReactionCategory
* Lookup category, pre-reaction
* Lookup category > constant
* Category can sometimes be nil?
* Try something friendlier for code reloading
* Refactor: extract point calculation out of Reaction
* Reaction Category can have color
* Rename reaction points service to follow convention
* method signature changed as well, calculate -> call
* Fix typo, leading comment, and rename data structures for clarity
* Try renaming moderator -> super_moderator
* Still finding 'moderator' words
* Fixes for failing specs
* Update test with new role name
* Update app/services/moderator/manage_activity_and_roles.rb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Allow trusted user to access response templates
* Add request specs for trusted user templates
* WIP: was just investigating...
* Move permission check to authorizer
* Revert "WIP: was just investigating..."
This reverts commit c38c60f7ab19ce43c174729c2542a9041e9322e2.
* Improved accessibility
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Article query spec for scheduled articles
* Added scheduled article badge on the user dashboard
* Added published_at field to editor options
* Accept and validate published_at from editor
* Refactor published_at validation
* Allow 1-minute difference in published_at
* Notice on an unpublished article page
* Added specs for 'Click to edit' link on scheduled article preview page
* ContextNotification model
* Articles::Publish worker
* Added specs for articles publish worker
* Schedule publish articles worker
* Added tests to check for scheduled posts in feeds
* Don't allow managing scheduled articles
* Don't send notifications for scheduled articles
* Set published_at in Articles::Updater when publishing
* Published_at value in post options
* Pass timezone and set published_at accordingly
* Limit setting published_at to the future
* Readonly published_at for articles that were already published
* Chagning published_at format in editor v1 (start)
* Changed published_at format in frontmatter, specs
* Added specs for updating published_at from frontmatter
* Fixed accepting past published_at for articles published_from_feed
* Enabled published_at validation: don't allow updating published_at for already published articles
* Validate published_at on create
* Added a spec for updating published_at for exported articles
* Fixed specs related to creating articles with past published_at
* Fixed specs related to past published_at for articles
* Added a hack so that admins would be able to update published_at
* Switch button text schedule/publish when changin publishedAt
* Fixed saving published_at with timezone
* Added a feature flag for scheduling articles
* Default text in markdown editor depends on feature flag
* Enable article editor cache again
* Fixed the default value in the markdown editor
* Fix sitemaps spec
* Removed tooltip
* Fixed articles update specs
* Added missing locales
* Fixed article create specs
* Fixed spec
* Removed commented code
* Returned enabling extensions in the schema
* Returned accidentally deleted constraint
* Make articles query spec more stable
Co-authored-by: Jeremy Friesen <jeremy.n.friesen@gmail.com>
* Removed commented code
* Removed unused code
* A clearer policy
Co-authored-by: Jeremy Friesen <jeremy.n.friesen@gmail.com>
* Use StringInquirer for article current state
* Added a note and todo to articles factory past trait
* Remove duplicated PropType
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Refactor query in the Articles::PublishWorker
Co-authored-by: Mac Siri <krairit.siri@gmail.com>
* Refactor articleForm.jsx
Co-authored-by: Mac Siri <krairit.siri@gmail.com>
* Removed specs that are no longer relevant
* Removed useless onKeyUp on a hidden input
* Refactored articleForm
* Hide scheduling from post options when published_at is readonly
* Run sends notifications worker every 5 minutes instead of every minute
Co-authored-by: Jeremy Friesen <jeremy.n.friesen@gmail.com>
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Co-authored-by: Mac Siri <krairit.siri@gmail.com>
The [`ArticlePolicy#moderate?`][1] method answers the questions around article
moderation.
At present this change does not introduce any significant changes (aside
from the JS logic loop). The next "step" is to adjust the
`ArticlePolicy#moderate?` method to test if the user has a moderator
role.
Further, we'd need to see what is available on the action panel.
Related to forem/forem#17606
[1]:5ac3216a5a/app/policies/article_policy.rb (L160-L174)
Prior to this commit, if we didn't have an instance of `Article` we
likely had the class `Article`; we would then run a potentially VERY
expensive query (`SELECT user_id FROM articles;`) to provide an
answer; namely if all of the articles are written by the same user then
yes this user is the author.
With this commit, when you're authorizing the `Article` class, let's
just say "Nope, this user isn't the author".
Closesforem/forem#17604
There are 2 things going on in this pull request:
1. Reducing duplication of knowledge, by favoring constants found in
Reaction.
2. Creating and enforcing the policies regarding the different
categories of reactions.
I chose to conflate these two as I was working on developing the
ReactionPolicy's finder method.
Closesforem/forem-internal-eng#454
Related to forem/forem#17628
* Encapsulating the "why we hide/show" something
Prior to this commit, we were relying on our views/templates to
understand why it might want to append the "hidden" dom class. That is
not ideal, because it required repeating knowledge about the conditions
of the policy outside of the policy's domain.
With this commit, we're removing a duplication of knowledge; or more
appropriately asking the steward responsible for the knowledge to
produce the answer.
* Refining the note to not describe a course of action
* WIP - Conditional rendering of "Create Post" link
This PR builds on the conversation from forem/forem#17056 and moves in a
slightly different direction.
Important in all of this is that the ability to create a post is
enforced on the server. If the "Create Post" button were to be visible
but the user couldn't create a post when they clicked the button, they
would get an authorization error (or some such response).
This PR posits a different and perhaps competing approach to
forem/forem#16606. This PR provides a general approach in which we add
class attributes in our HTML erb files.
Note: I have not included Cypress tests as I don't want to yet commit
that time. I'm also wondering if this is the "right" thing to do. I
definitely think we want to add some JS tests. But could we do JS and
unit tests? (How do we reach consensus regarding our test approach?)
Again, thank you for the conversation and expect an even more "complete"
PR after we have our discussion.
* Extracting AsyncInfo model to ease testing
* Renaming forbidden to visible
* Adding cypress test to assert no 'Create Post'
These are always treacherous. What happens when we rename the button?
The test will continue to work.
* Apply suggestions from code review
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Switching to pack file for policy
Follows on [Suzanne's comment](https://github.com/forem/forem/pull/17076#issuecomment-1088567286)
* Update app/javascript/packs/applyApplicationPolicyToggles.js
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Prior to this commit
This would have been a bug, if someone had:
1. Toggled on the :limit_post_creation_to_admins feature flag
2. Wasn't an admin
3. Already had a published post
4. Went to edit the post and attempted to preview it
Related to the following issues:
- forem/forem#16908
- forem/forem#16944
- forem/forem#16837
- forem/forem#16942
Prior to this commit the following situation existed:
> The path /dashboard/analytics/org/:id requires user
> authentication (e.g. signed in). However, it does not enforce
> authorization. Anyone can see this page. The page, however, uses
> javascript to populate the data. So no information, aside from the org
> name associated with the :id leaks out. The javascript API end point
> enforces organization membership.
>
> I would expect that the authorization in the HTML rendering would be
> the same as the javascript API end point.
This commit ensures that the dashboards#analytics end point uses the
same policy logic as the API analytics end points. Further, it keeps
folks who aren't org members out of the base HTML page for other orgs.
Closes forem/forem/#16985
As part of my AuthN/AuthZ work I'm reviewing policies. I've been
looking at Dashboard pseudo-policies. The dashboard has some implicit
organization policies that I'm looking to expose and describe.
This refactor simply leverages methods already on the user.
Discovered while working on forem/forem#16985
* Adding ArticlePolicy#has_existing_articles_or_can_create_new_ones?
As part of our aspirations to only show users what is relevant to them
and "hiding" what is not, this method will help us with the edge case of
"should we show the user a dashboard listing of posts?"
Related to forem/forem#16837
* Adding further documentation
* Adding clarifying comment
* 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>
This commit does three things:
1) Adds and tests the ArticlePolicy#moderate? feature
2) Refactors the spec helpers to be a bit more flexible
3) Adds a few more edge case tests around ArticlePolicy
My apologies for conflating these changes, as it makes this commit
more challenging to review.
The goal is to adequate demonstrate the logic around users who can or
cannot moderate. At present, the rules for who can moderate is here:
841491c6ee/app/javascript/packs/articleModerationTools.js (L17-L27)
```js
if (user?.trusted) {
if (user?.id !== articleAuthorId && !isModerationPage()) {
initializeActionsPanel(user, path);
initializeFlagUserModal(articleAuthorId);
// "/mod" page
} else if (isModerationPage()) {
initializeActionsPanel(user, path);
initializeFlagUserModal(articleAuthorId);
}
}
```
- Related to forem/forem#16783
- Closesforem/forem#16784
Videos are a conceptual subset of Articles (see
[VideosController#create][1] for supporting "evidence"). As such, we
want to ensure they conform to the expectations of the ArticlePolicy (as
described in forem/forem#16483).
This feature enhancement does a few things:
1. Renames swaps the `VideoPolicy#new?` and `VideoPolicy#create?`
declarations (reversing the alias direction)
2. Moves methods out of the concrete ArticlesPolicy into the
ApplicationPolicy.
3. Exposes these user oriented methods for external
consumers (e.g. making future refactoring work easier). The happy
benefit is that this already removes a bit of duplicated logic.
4. Highlights that while yes the Policy is correct, we also may be
flirting with the concept of some sort of User "properties as it relates
to authorization" logic (good standing users, established users,
etc.)
5. Reworked the timing of a guard clause and setting of instance variables.
[1]:
33e9bac0f7/app/controllers/videos_controller.rb (L18-L22))
Relates to #16483Closesforem/forem#16728
To test this, I'm relying on the existing test suite. I envision that
shifting from returning false for suspended users to raising an
exception might cause some false positive errors. Note, in the
[AppliciationController][2] we handle the responses. Paired with
[config/appliciation.rb][3], we handle the policy exceptions.
[2]:33e9bac0f7/app/controllers/application_controller.rb (L32)
[3]:33e9bac0f7/config/application.rb (L71-L81)
* 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
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
* 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>
* 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>
Our domain of "admin?" method names is already a bit confounding. The
policy methods renamed the existing Policy::Authorizer methods, and
further obfuscated and confused intention.
This refactor aligns the policy methods with the Policy::Authorizer
methods. It is a non-breaking change, but one that may add warnings in
the logs. If you see those, resolve them per instructions.
Related to #16483
