Allows leaving `smtp_settings[:domain]` unspecified. Explicitly setting
it to `nil` (as when `OSEM_SMTP_DOMAIN` is unset) overrides the default
value of `'localhost.localdomain'` and caused SMTP connections to fail
with `EOFError`.
When running migration 20170705075039 followed by 20170715131706, the
latter fails due to lingering null values in a newly non-null column—
Mysql2::Error: Invalid use of NULL value: ALTER TABLE `tracks` CHANGE `state` `state` varchar(255) DEFAULT 'new' NOT NULL
db/migrate/20170715131706_make_track_state_not_null_and_add_default_value.rb:17:in `change'
—despite having apparently converted any existing null values prior to
changing the column type. Investigation reveals that actually the
attempted conversion has had no effect, and that this can be resolved by
clearing ActiveRecord internal caches between migrations:
connection.schema_cache.clear_data_source_cache! 'tracks'
The same problem also affects running 20170705075039 followed by
20170720134353, but in that case it leads to silent data corruption as
`change_column_null` automatically converts any lingering null values.
This commit 1) clears ActiveRecord internal caches at the beginning of
each affected migration, and 2) replaces `change_column_null` with
`change_column` to reflect that no automatic conversion is intended.
CarrierWave documentation:
> Note: `recreate_versions!` will throw an exception on records without
> an image. To avoid this, scope the records to those with images or
> check if an image exists within the block.
Resolves#1976:
NoMethodError: undefined method `read' for nil:NilClass
…/carrierwave-1.3.1/lib/carrierwave/uploader/cache.rb:81:in `sanitized_file'
…/carrierwave-1.3.1/lib/carrierwave/uploader/cache.rb:118:in `cache!'
…/carrierwave-1.3.1/lib/carrierwave/uploader/versions.rb:234:in `recreate_versions!'
db/migrate/20171130172334_rebuild_conference_pictures.rb:4:in `block in up'
Many migrations currently fail to run with:
> Directly inheriting from ActiveRecord::Migration is not supported.
> Please specify the Rails release the migration was written for:
>
> class Example < ActiveRecord::Migration[4.2]
I've annotated those that I need to run with the Rails version at the
time each was committed:
rake db:migrate:status \
| grep --perl-regexp --only-matching '(?<=^ down )\d{14}' \
| while read -r id; do
path="$(ls -1 db/migrate/${id}_*.rb)"
version="$(git show "$(git log --diff-filter=A --pretty=format:%H -- "$path")":Gemfile.lock \
| grep --perl-regexp --only-matching '(?<=^ rails \()\d+\.\d+(?=(\.\d+)+\))')"
sed --in-place -e "s/\(< ActiveRecord::Migration\)$/\\1[$version]/" "$path"
done
The help text for the event type field is animated using a technique
unaffected by `Capybara.disable_animation`. Wait for the animation.
Resolves: #2356
Works around: #2661
As of Rails 5.1:
- Rails has built-in support for running tests within database
transactions, so Database Cleaner is no longer needed for this.
- Rails automatically shares the database connection across threads,
so transactional_capybara is no longer needed.
Changes:
- Enable `use_transactional_tests`.
- Remove transactional_capybara.
- Remove the Database Cleaner test wrapper.
This resolves:
- transactional_capybara mismanages the shared database connection,
causing the connection to falsely report as idle after the first
test. At 6 minutes (idle_timeout + reaping_frequency) into testing,
the connection is closed, causing e.g. `PG::ConnectionBad` errors.
Presumably the intent of this was to clear the database and repopulate
it with seed data. `transaction` isn't the right strategy for this; it
just rolls back any existing transactions.
data-provide="markdown-editable" is intended for inline editing of page
content à la contenteditable. When this is applied to a textarea, the
editor is loaded only after the user clicks on the field. This behavior
breaks focus and is incompatible with keyboard navigation.
Resolves#2557:
$ docker-compose run --rm osem bundle exec rspec --tag js
…
WebMock::NetConnectNotAllowedError
See titusfortner/webdrivers#109 for details.
Conferences.incoming is defined on the model as scope:
scope :upcoming, (-> { where('end_date >= ?', Date.current) })
Conference.past
scope :past, (-> { where('end_date < ?', Date.current) })
It used to be a partial inside #index, but having their own page
yields some extra benefits:
- Performance: Move logic from the view to the controller
- Theres' no need to go extra steps inside the :index view
- UI: Remove the extra 'Upcoming Conferences' when the system needs
to start the flow of the creation of the first user
