* 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>
* Add audit logging for negative reactions
This change saves requests that create negative reactions to the audit
log. We need to be monitoring admin and moderator actions throughout the
app to increase visiblity on how our tools are being used and identify
abuse.
Additionally, this will help east concerns about giving elevated users
more powerful tools.
* Add a basic UI for moderator audit logs
* Log experience level ratings
* Log tag adjustments
* UI tweaks for moderator actions log
* Add logging to internal reactions controller
* Add logging for admin actions on users and articles
* Add searching to the moderator actions table
* Move audit instrumentation out of concern
We are able to use a PORO here instead of using a Rails concern. Moving
this also makes syntax to audit something quite a bit more explicit and
obvious to future developers
* Change moderator logs pagination page length
* Move auditing to after action filters
* Add moderator actions to the internal navbar
* Add request spec for internal moderator actions
* Use request params to populate AuditLog slug
