* Add exclude_article_ids int array
* Add specs, normalize inputs better
* Add to form & controller
* Add exclude_article_ids to DisplayAd API
* Use exclude_article_ids in query
* Rubocop
* Comment typo
* Tweak rspec example length config
* Arguments all the way down
* Typo
* Update spec/requests/api/v1/docs/display_ads_spec.rb
Co-authored-by: Ben Halpern <bendhalpern@gmail.com>
* Update spec/requests/api/v1/docs/display_ads_spec.rb
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
* Swagger schema for Display Ad
---------
Co-authored-by: Ben Halpern <bendhalpern@gmail.com>
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
* Pages API pt 1 (read/get/index+show)
* Update spec/requests/api/v1/docs/pages_spec.rb
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
* Update spec/requests/api/v1/docs/pages_spec.rb
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
* API Key not required for index & show
* API Feature flag has long since been removed
* Page schema
* Fix spec broken by merge
* Temporary bugfix: slug uniqueness not working for Page
* Pages API endpoints for create, update, and destroy
* Fix swagger error
---------
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
* Pages API pt 1 (read/get/index+show)
* Update spec/requests/api/v1/docs/pages_spec.rb
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
* Update spec/requests/api/v1/docs/pages_spec.rb
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
* API Key not required for index & show
* API Feature flag has long since been removed
* Page schema
* Fix spec broken by merge
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
* Try a create endpoint
* Try an update endpoint for display_ads
* Try a delete endpoint for display_ads (unpublish)
* Unpublish
* Permit tags as well
* Update docs for DisplayAd tags via API/swagger
* Try an idempotentish reaction create API
* Add tests for create API endpoint
* Try -> ReactionHandler
* Fix existing tests first
* Tests for .toggle; fix broken handle_existing
* Use the Handler
* Tweak http status for reaction create
* Use the category reader
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
* Extract reaction create from controller to service
* Success is having no errors
* Confirm http status successful
* V1 API endpoint for Create Reaction
* Actually reset cache count
* Tweak JSON response
* Reaction create -> toggle
* Try rswagger docs for reaction toggle
This commit does three things:
1. Documents a method
3. Implies the question: "Do we want to use class_attribute in Forem's codebase?"
2. Switches from an inferrence to an explicit (and configurable)
In my experience, I want to favor "explicit" declarations instead of
inferring what they should be. In this case, the inferrence is perhaps
adequate. But as I look to `ApplicationController::PUBLIC_CONTROLLERS`,
I think that is a prime case for a `class_attribute`. (The `api_action`
happened to be the lowest hanging fruit to begin the conversation.)
We still need some clarity into the `verify_private_forem` method as it
looks like it's doing a few different things.
There is precedence for using `class_attribute` found in
[`UniqueCrossModelSlugValidator.model_and_attribute_name_for_uniqueness_test`][1] (also
introduced by me).
[1]:https://github.com/forem/forem/blob/main/app/validators/unique_cross_model_slug_validator.rb
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
We only have one reference to the UnauthorizedError, which is shadows
the ApplicationPolicy::NotAuthorizedError. This commit removes the
exception.
Related to forem/forem#16985 but only barely
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
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.
Prior to this commit, I saw the following in the Rails test log:
```
DEPRECATION WARNING: 'include Pundit' is deprecated. Please use 'include Pundit::Authorization' instead.
(called from include at ./app/controllers/application_controller.rb:12)
```
* 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 hardcoded instances of education field
* WIP Access display_email_on_profile via User Settings
* Remove unused profile column
* WIP Fix reference to bg_color_hex and text_color_hex
* WIP fix issues revealed by systems specs
* WIP fix issues revealed by services specs
* WIP Fix failing tests
* WIP Fix spec failures
* wip
* Move two attributes from controller to decorator
* Update comment
* Match user settings changes
* More consistently use user.tag_line
Even before the profile changes we sometimes used the user.summary
attribute directly but used the user.tag_line method in other places.
* Remove delegation, rename inline concern
* Drop profile columns from users table
* Remove duplicated work display from header
* Update work profile field handling
* Update DUS + spec
* Delegate more carefully
* Update delegation guard
* Adapt for removed delegation
* Undo accidental schema changes
* Fix seeds
* Remove accidentaly change
* Fix User#processed_website_url
* Update guard clause
* Update profile card content
* Add Organization#profile
* Be more conservative with profile fields
* Spec fixes round 1
* Fix typo
* Update spec
* Limit number of header fields and update card content
* Decorate correct model
* Update factory
* Update schema.rb
* Fix validation
* How bad could this possibly be?
* Pretty bad, nevermind
* Remove obsolete code
* Reset profile fields during test runs
* Move profile fields back to before(:suite)
* Spec fixes
* Remove accidentally re-added files
* More spec fixes
* Specs
* Change User#tag_keywords_for_search
* More spec fixes
* Add comment
* Undo accidental schema changes
* Attempt spec fix
* Remove fix attempt
* Fix e2e test
* Update spec
* Remove guard clause
* Remove hardcoded instances of education field
* WIP Access display_email_on_profile via User Settings
* Remove unused profile column
* WIP fix issues revealed by systems specs
* WIP fix issues revealed by services specs
* WIP Fix failing tests
* WIP Fix spec failures
* wip
* Move two attributes from controller to decorator
* Update comment
* More consistently use user.tag_line
Even before the profile changes we sometimes used the user.summary
attribute directly but used the user.tag_line method in other places.
* Remove education
* Add comment
* WIP
* Clean up mostly_work_with
* WIP
* Update work profile field handling
* More work-related changes
* Remove settings_only from display_area enum
* Remove quickfix from _metadata partial
* Remove special attributes
* Remove leftover spec
* Retrieve location from profile, not user
* Profile.special_attributes no longer exists
* Update specs
* More spec fixes
* Update UsersController
* Update UsersController and spec
* Fix e2e seeds
* Minor cleanup
* More e2e seed fixes
* Fix profile field CSV
* Fix e2e seeds
* Move one more attribute in e2e seeds
* Remove duplicate line
* Clear inputs before typing in them
* Fix formatting issues
* Profiles::Update -> Users::Update
* Remove RegistrationsController#resolve_profile_field_issues
* Fix schema.rb
* More cleanup
* Fix specs
* Fix remaining spec
Co-authored-by: Jacob Herrington <jacobherringtondeveloper@gmail.com>
