* Renamed display ad variables and constants
* Renamed display_ads associations
* Fixed variable name in display ads
* Renamed display_ads variables in views
* Fixed admin billboard view spec
* Fixed variable name in FilteredAdsQuery
* api v1 endpoint for creating an organization
* address failing specs, regenerate swagger docs
* remove old comment in destroy now that woreker call takes third argument
* refactor our services for profile images into images folder
* 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)
* 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
