Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix persist before save in rails 5.2 #36

Merged
merged 3 commits into from
Nov 12, 2018
Merged

Fix persist before save in rails 5.2 #36

merged 3 commits into from
Nov 12, 2018

Commits on Nov 12, 2018

  1. Test against rails 5, 5.1, and 5.2 not just 4.2 

    We add the new rails gemfiles using the `appraisals` gem.  This means that
we can run `bundle exec appraisal rake` locally to run the specs against
rails 4.2, 5, 5.1, and 5.2.  We've also added these gemfiles to the
`.travis.yml` so these rails versions are added to the ruby version test
matrix that we run on CI.  Note that although we use CircleCI to run our
CI tests, we use the `wwtd` gem to read the `.travis.yml` config and do
what it would do.  This is confusing, but it works.
    @h-lame
    h-lame committed Nov 12, 2018
    Configuration menu
    Copy the full SHA
    98a6a95 View commit details
    Browse the repository at this point in the history

  2. Fix bug with vault_persist_before_save! and rails 5.2 

    In rails 5.2 the behaviour of dirty tracking methods changed when they are
run during callbacks.  Methods like `<attribute>_changed?` and `changes`
do the same thing in callbacks run before save, but will behave differently
in callbacks run after save.  We'd already written
`__vault_encrypt_attribute` to understand this and use the
`saved_change_to_attribute?` method instead of `<attribute>_changed?`
method for rails 5.2.  Unfortunately, this is only the correct approach
when we're running `__vault_encrypt_attribute` in an `after_save` callback,
which we're not if we have run `vault_persist_before_save!`.  This means
`__vault_encrypte_attribute` is run in a `before_save` callback where the
`saved_change_to_attribute?` methods don't do what we want (because we
haven't saved any changes yet).  In this case we do want to use the old API
that the raisl < 5.2 branch uses.
    @h-lame
    h-lame committed Nov 12, 2018
    Configuration menu
    Copy the full SHA
    bdb80c8 View commit details
    Browse the repository at this point in the history

  3. Clear up Person vs. EagerPerson when testing vault_persist_before_save! 

    We use `Person` in the "when not used" context because that model class
has not had `vault_persist_before_save!` called on it.  `EagerPerson` has
and that's why we use it in the "when used" context.  It'd be clearer if
we could explicitly call it in the spec, but there's no clean up option to
unset it so we need separate models.
    @h-lame
    h-lame committed Nov 12, 2018
    Configuration menu
    Copy the full SHA
    f99aebd View commit details
    Browse the repository at this point in the history