* Add reading_time to articles api responses
Fixes#13436
* Update api docs to match changes to the articles response
* Follow up docs updates
- increment api docs version
- add reading_time to articles/me responses
- add reading time to the show response example format
* Change reading_time attribute to reading_time_minutes
Update the article builder to use `article.reading_time` and present
it as `"reading_time_minutes"`.
Update the api spec to expect the new property name instead of the attribute.
* Update api documentation to reflect the new name
- Change reading_time -> reading_time_minutes.
- I decided to keep the (possibly redundant) description text here.
* 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>
* Optimize Article.published scope
The index on `articles.published` is not being invoked due to lack of
diversity in the values in that column (it only has 2 possible values
because it's a boolean).
The index on `articles.published_at` is extremely diverse and will be
invoked any time it can reduce the scope of a query by an order of
magnitude or more.
On DEV, this does not change the row count for the scope:
irb(main):001:0> Article.where(published: true).count == Article.where(published: true).where(Arel.sql("published_at < now()")).count
=> true
The query plan for the `Articles::Feeds::LargeForemExperimental` service
invoked in the `Stories::FeedController#show` endpoint goes from this:
Planning Time: 0.271 ms
Execution Time: 329.258 ms
to this:
Planning Time: 0.330 ms
Execution Time: 0.468 ms
This is a reduction in query time of 99.7%
* Set published_at in articles factory
An article that is published should always have a `published_at`
timestamp
* Use Time.current for Zonebie
* Add clarifying comment to Article.published scope
* Generate timestamp in Ruby instead of SQL
I think using transactions for specs was interfering with comparing
timestamps generated in SQL, so this commit generates the timestamp in
Ruby.
* Move published_at outside of the transient block
This was causing articles to be marked as `published_at` right now even
if `published_at` was specified in the `FactoryBot.create` call.
* published_at: nil is no longer the factory default
* published_at is no longer nil by default
* published_at is no longer nil by default
* We didn't actually want to clear this published_at
This was intentionally left out to show that published_at does not get
cleared when we flip published true->false.
* Start refactoring articles update
* Articles update refactoring
* Added a couple of tests for Articles::Updater
* Reorganized code in Articles::Updater and ::Attributes a bit
* A couple of more tests for Articles::Attributes
* Reverted changed in the articles_controller
* Edited_at in Articles::Attributes
* Use Articles::Updater in ArticlesController
* Tests for notifications when published/unpublished an article
* Removed old code
* Return result object from Articles::Updater
* Don't reset articles collection when no series was passed
* Fixed sending notifications when published an article the first time
* Fix articles collection when updating
* Fix setting attributes for articles update
* Spec for articles update via api failure
* More tests for Articles::Updater
* More specs for articles updating
* Pass article instead of article_id to articles updater to avoid loading an article twice
* Remove the redundant check in the articles_controller
* Articles::Attributes refactoring
* 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
* Disable ActionController auto params wrapping
Rails by default accepts wrapped and unwrapped parameters in JSON requests (with or without a root object), regardless of the fact that the contract with the client requests wrapped parameters or not. This results in unforeseeable bugs when the client sends unwrapped parameters in lieu of wrapped ones.
As undeterministic bugs are a PITA and this is the classic grey area in Rails apps and as the customer facing API is fully documented and the internal can be manually adjusted, we disable this and be done with this odd feature.
https://github.com/forem/forem/issues/11645https://github.com/forem/forem/pull/11638
* Remove accidentally committed file
* Add check to id param to use slug if passed
* modify to use slug in a different action
* wrote test for this api endpoint
* update test to check array equality
the test also checks if the first tag in the parsed list is the same as the first tag in the article
* Add dual booting logic to Gemfile
This might be helpful for the Rails 6.0 upgrade project.
* Add more than one gemfile to Travis' configuration
We want to see how the application behaves with more than one Rails versions:
- Gemfile -> Rails 5.2
- Gemfile.next -> Rails 6.0
This will help us figure out what needs to be addressed before migrating to Rails 6.0.
If you want to read more about this technique (dual booting) you can check out this page: https://www.fastruby.io/blog/upgrade-rails/dual-boot/dual-boot-with-rails-6-0-beta.html
* Fix joins
* Upgrade Gemfile.next.lock
* Make sure we're installing the correct versions of gems
* Add Rails 6 notes
* Update rubocop in Gemfile.next.lock
* Fix organization spec
* Fix page_views_spec
* Add Rails 6 and run rails app:update
* Remove some tricks
* Remove Gemfile.next for now
* Fix .content_type deprecation
* Fix deprecation of .where.not NAND/NOR behavior
* Fix deprecation of parameterized emails
* Fix specs
* Remove next flag for now
* Fix spec (hopefully)
* Add wait_for_javascript
* Fix spec, thanks @maestromac!
* Try without wait for javascript hack
* Remove unnecessary bin/update
* Remove file that snuck in the rebase
* Update the vendored gems
* Replace migrate+db:setup with db:prepare
* Update vendored gems
* Fix Gemfile.lock and update vendored stuff
* Fix Gemfile.lock to be the same as master's minus the changes
Co-authored-by: rhymes <rhymesete@gmail.com>
* Rename positive_reactions_count to public_reactions_count
* Add positive reactions count back in so we can remove it
* Use public_category method for reactions
* Add positive_reactions_count in case any old caches rely on it
* Add positive_rxn_count to account for API endpoints
* Remove unused method
* One more spot...
* Add method back in because of caches
* Update specs to match new functionality
* Fix typo
* Remove unused methods
* Add correct rate limit exception to Articles::Updater
* Send Retry-After with HTTP 429 back to the client
* Update API specs for error 429
* Test build
* Fix spec
* Add retry after to ImageUploadsController and fix specs
* Generalize a bit
Currently, we don't allow users to remove the `main_image` of an article once it has been set. It can be changed, but never removed.
This change allows the `main_image` to be removed by checking for the `cover_image` key in the frontmatter that is sent along in the article's markdown. This means that a user should be able to remove the image associated with an article by removing the value of `cover_image:` from their frontmatter.
* Add check for article param being a Hash & spec
* Remove unnecessary blank line
* Move logic to private method and before_action call
* Change check_if to validate
* Use is_a? to type check
* Fix type check for specs
* Fix article description issues
* Move tag info to decorator
* Fix description edge cases
* Fix description creation logic
* Fix test and adjust naming
* Modify line in processed_description
Surrogate keys are about setting expectations on cache purging.
Presently we use a combination of all parameters to set changing surrogate keys depending on the result of the `ArticleApiIndexService`. This approach has two limitations:
- if two set of params lead to the same exact set of articles, we still create two different caches
- deleted articles will remain for 24 hours in the cache because the cache key doesn't take the record keys into account
By simply using record keys we make sure that different params leading to the same result set will share the same cache and that deleted keys won't appear anymore in the cache.
* Remove mock from specs to test the actual Suggester
* Fix articles API top articles n+1
* Fix n+1 in articles API with state parameter
* Remove eager loading for organization dashboard
* Eager load notifiables in notifications only when needed
* Algolia does not like this
* Regenerate rubocop todo
* Fix outstanding problems
* Fix Style/FormatStringToken
* Final update to rubocop todo file
* Set RSpec/ExampleLength to max 10 and regenerate todo file
* Add collection ids to Api (reading + filtering)
- refactored controller
- modifyied views
- added tests
* Add collection ids to Api (reading + filtering): requested changes
- changed order in service
- proper test in filtering
