Skip to content

v3.1.0
Compare
Choose a tag to compare
@kennyadsl kennyadsl released this 10 Sep 09:15
v3.1.0
1e06d43
This commit was signed with the committer鈥檚 verified signature.
kennyadsl Alberto Vena
GPG key ID: 525B72474A73BA6D
Learn about vigilant mode.

Major changes

Spree.load_defaults: preference defaults depending on the Solidus version

Solidus 3.1 brings a new feature where preference defaults can take different
values depending on a specified Solidus version. It makes it possible to stop
deprecating old defaults every time we introduce a change in the recommended
value for a setting. After all, they're just that; recommendations. Instead,
now users can explicitly ask for a given Solidus version defaults and, as
before, override the preferences they want.

When upgrading to 3.1, you have to take action to adopt the new behavior.
You'll need to add Spree.load_defaults('3.1') on the very top of your
spree.rb initializer. As we're not changing any preference default on this
release, nothing will break. A warning will be emitted on boot-up until you do
it!

However, bumping the version given to load_defaults straight away for future
upgrades will not be a safe option. Instead, you'll have to go through the new
update process detailed below.

New update process

As aforementioned, preference defaults can change after a Solidus release. Once
you have your defaults locked to the current Solidus version, a new upgrade
won't break your application because of them. However, it's a good idea to
adapt your application to the updated recommended settings. To help with this
process, Solidus comes with a generator that you can execute like this:

bin/rails g solidus:update

That generator will create a new initializer called new_solidus_defaults.rb,
which will preview all the defaults that have changed between versions, each on
a commented line. From that point, you can activate the new defaults one by one
and adapt your application incrementally. Once you're done with all of them,
you can bump the version given to Spree.load_defaults in the spree.rb
initializer and remove the new_solidus_defaults.rb initializer altogether.

You can read in more detail about this process on our
guides.

Other important changes

Spree::Price#amount field can no longer be nil. Besides adding the
validation at the model layer, we ship with a task that will remove records
where the amount is NULL in the database. You should run the task before
executing the new migrations:

bin/rails solidus:delete_prices_with_nil_amount
bin/rails railties:install:migrations
bin/rails db:migrate

If you're running migrations automatically on deploy, you should run the task
before rolling out the new code. In that case, you first should make sure that
you have affected records:

Spree::Price.where(amount: nil).any?

If the above code returns false, you don't need to do anything else.
Otherwise, copy the
task
into your code, and deploy & execute it. Another option is to execute it
manually in your console in production. However, be extremely careful when
doing that!! 鈿狅笍 鈿狅笍 鈿狅笍

Spree::Price.where(amount: nil).delete_all

Core

API

  • Remove Pending Request Spec: Api Admin update payment state expectations. #4149 (jcowhigjr)
  • Fix gateway_error when no order is defined #4156 (alexblackie)
  • Moving API attribute helpers to API config #4039 (snada)
  • Allow customer returns to reference existing ReturnItems on create through API #4007 (forkata)
  • Let the PriceSelector return a Spree::Price #3925 (swively)

Admin

Frontend

Docs & Guides

Assets 2
0 Join discussion