* 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>
* 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>
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
* 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>
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
* Don't update social information for suspended/banished accounts
* Prevent suspended users/accounts from updating their profile information
* Add tests and fix some logic
* Refactoring questions asked of user
In this pull request, I'm extracting and normalizing role-based
questions asked of the user.
Prior to this commit, our codebase has asked two very similar questions
of our user model:
- `user.has_role?(:admin)`
- `user.admin?`
In asking `has_role?(:admin)` we are relying on implementation details
of the rolify gem. In addition, the `has_role?` question asked
throughout controllers or views means that it's harder to create
hieararchies of permissions.
In favoring `user.admin?` as our question, we can use that indirection
as an opportunity to discuss and decide "Should someone with the
`:super_admin` role be `user.admin? == true`?"
The details of this commit is to do three primary things:
1. Ask the `has_role?` questions in "one place" in the code (e.g. the
`Authorizer` module)
2. Extract the role based questions that are on the `User` model and
provde backwards compatable delegation.
3. Structure the code so that it's harder to accidentally call
`user.has_role?` (e.g., make `User#has_role?` and `User#has_any_role?`
private).
This is related to #15624 and the updates are informed by discussion in
PR #15691. This commit supplants #15691.
* Refactoring the liquid tag policy tests
* Fixing typo
* Bump for travis
* 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>
I noticed a warning from rspec when this policy spec ran:
Using expect { }.not_to permit_actions could produce
confusing results. Please use `.to forbid_actions` instead. To
clarify, `.not_to permit_actions` will look at all of the actions and
checks if ANY actions fail, not if all actions fail. Therefore, you
could result in something like this:
it { is_expected.to permit_actions([:new, :create, :edit]) }
it { is_expected.not_to permit_actions([:edit, :destroy]) }
In this case, edit would be true and destroy would be false, but both
tests would pass.
I just follow the helpful advice.
* Create DiscussionLocks
* Fix specs
* Update nullify_blank_notes_and_reason
* Update before_validation call
* Updated DiscussionLockPolicy for clarity
* Move permitted_attributes to a constant
* Update route
* Apply suggestions from code review for frontend
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Add title tags
* Wrap unlock confirm in main element
* Wrap flash messages up in div
* Actually fix title tags
* Hide comment reply button when discussion is locked
* Add E2E tests
* Try to fix E2E tests
* Cypress...you work locally but not in CI...why!?
* PR feedback
* Update E2E tests
* More E2E updates 😭
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Add SiteConfig.feed_pinned_article and validation
* Display pinned article at the top of feed
* Add (basic) functionality to pin/unpin post
* Admins can pin other users posts as well
* Hide the button if looking at the non pinned post
* Add pinned/unpinned snackbar message
* Rename SiteConfig usage to Settings::General
* Add pinned article to the Admin articles index
* Show the pin post button when there's no pinned article
* Move pinning to a separate controller
* Fix SiteConfig reference
* Hide PinController actions to unauthorized users
* PinnedArticlesController#show action and refactor some of the code
* Add Modal interaction
* Fix modal-pinned checkbox interaction
* Fixed pin/unpin post
* Add ArticleDecorator#pinned? specs
* Add PinnedArticlePolicy and PinnedArticlesController specs
* Add ability to actually pin an article from the admin after submit
* Add partial Cypress pin/unpin spec
* Fix pinned article and add basic Cypress interaction tests
* Add Crayons styling to modal
* Only render the pinned article on the default Feed page
* Use persisted?
* Add some comments
* Update app/javascript/articles/Article.jsx
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/javascript/packs/homePageFeed.jsx
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Fix Cypress tests
* Update app/javascript/admin/controllers/article_controller.js
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
* Fix pinning in article show page
* Used PinnedArticle domain model
* Fix spec
* Update cypress/integration/adminFlows/articles/pinArticle.spec.js
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update cypress/integration/adminFlows/articles/pinArticle.spec.js
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update cypress/integration/adminFlows/articles/pinArticle.spec.js
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update cypress/integration/adminFlows/articles/pinArticle.spec.js
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update cypress/integration/adminFlows/articles/pinArticle.spec.js
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update cypress/integration/articleFlows/pinArticle.spec.js
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update cypress/integration/articleFlows/pinArticle.spec.js
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/views/admin/articles/index.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Fix merge woes
* Add missing article pin post flows
* Add missing admin article flows
* Add Unpin to Admin as well
* Add Audit::Log entries for pin/unpin actions
* Update app/controllers/stories/feeds_controller.rb
Co-authored-by: Michael Kohl <citizen428@dev.to>
* Do not rate limit in E2E tests
* Use .find instead of .filter
* Rename ArticleIdValidator to ExistingArticleIdValidator
* Treat draft and deleted articles the same
* Make sure posts can be pinned after the pinned article is unpublished or deleted
* Use .get directly
* Fix spec and fix PinnedArticlesController#show
* Strengthen pinArticle Cypress tests
* Add Cypress test heading guard
* Add another Cypress test heading guard
* Remove duplicate validator
* Try using the Tools: header instead of the article title
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
Co-authored-by: Michael Kohl <citizen428@dev.to>
* Rename banned and comment_banned roles
* Add data update script to rename roles containing 'ban'
* Add named error for Suspended users
* Update unidiomatic method names
* Rename misc banned to suspended
* Apply suggestions from code review
Co-authored-by: Michael Kohl <me@citizen428.net>
* Add unit tests for suspended methods
This commit also adds TODO comments for removing banned and
comment_banned from the codebase after data update scripts have
successfully run on all of our Forems.
Co-authored-by: Michael Kohl <me@citizen428.net>
* Prevent banned users from accessing API
* Prevent banned users from creating API keys
* Delete API keys when deleting user
* Add tests
* Prevent banned signed in users from accessing API oops
* Refactor authenticate! for readability
* chore: use consistent code styles for the parenthesis around arguments
* Revert "chore: use consistent code styles for the parenthesis around arguments"
This reverts commit 281c899a5cff0480b182fef45b10ef69979166cb.
* chore: add consistent parenthesis
* Add missing foreign keys to models related to users
* Fix specs
* Change FK for page_views and rating_votes to nullify
* Improve rating vote validation and fix Users::Delete specs
* Revert "Spec Fix:Nullify Rating Votes when Deleting Users (#10071)"
This reverts commit 12dfe4ab3b.
