* DisplayAd audience_segment_id in API
* Rubocop
* Manual not valid if missing id
* manual-type requires an id
* Better audience_segment_type reader
* Use inclusion validation
* Swagger update
* Remove unnecessary
* add composite index to segmented_users table
* bulk queries for segmented users
* create segment endpoint
* adding and removing users
* deleting segments 😪
* fix time precision in specs
* api docs 🎉
* pluck improvements that couldn't be cherry-picked
* better service objects; also introduce batch upserting
* docs???
* Trying some models for audience segmentation
* AudienceSegment basics
* Attach AudienceSegment to DisplayAd
* Possibly use a DUS to populate AudienceSegments
* Add to display ad form UI
* Add to display ad API
* Refresh strategy for audience segments
* Add user_id to async ads query
* Maybe :testing -> :manual, for no-refresh segment
* Test & tweak segment refresh
* Testing audience_segment#refresh logic
* Coverage: testing human_readable
* Scope segment refresh to recently active users
* Tweak logic for when to refresh
* Tweak experience levels to match SettingsHelper
* Test for front-end logic
* Fix test, hope this helps coverage?
* Better test names
* One worker for all, many workers for each, perform_bulk
* Fix audience segment UI, needs to use id, not enum
* cron/schedule should RefreshAll
* Singular id in RefreshWorker
* 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
