Solidus v3.4 (2023-04-21)

Minimal requirements:

v2.7

v6.0

This is a slimmer release, but a very important one as it'll be the last on the 3.x series. Following our policy, there won't be other changes except removing deprecated code in release v4. That means if you adapt your store to be free of warnings, you should be ready to go when v4 is out (and it's just around the corner!).

Please, remember to review our generic upgrade guides and run the bin/rails g solidus:update task. You can also check the complete Changelog in our repository.

New taxon and taxonomy validations

New validations were added to the Taxon and Taxonomy models but are behind the new temporary extra_taxon_validations and extra_taxonomy_validations preferences.

• Taxonomy must have a unique name.
• Taxon must have a unique name under the same parent Taxon (or at root level).
• A validation was added in Taxon to ensure Taxonomies can only have one root Taxon.

Before using the new preferences, ensure you don't have any now invalid Taxons or Taxonomies on production:

1. Pull the production Taxons and Taxonomies to a development or staging environment.
2. Set the new preferences to true.
3. Run Spree::Taxon.all.select(&:invalid?) and Spree::Taxonomy.all.select(&:invalid?).
4. If you don't have empty arrays, you'll need to manually fix these records on production (warning you may have products attached to these Taxons/Taxonomies).

If you had any invalid records, take caution in case you have any code that creates Taxons or Taxonomies.

On top of that, some of your tests may break if you have incorrectly built Taxons. We've also added some help to fix those factories:

• Now, if you pass just a parent Taxon, the Taxonomy will be inferred from the parent.
• As before, if you pass no taxonomy, a Taxonomy and its root Taxon will be made.
• Now, the parent will be inferred from the given taxonomy or default created Taxonomy. This means, the created Taxon will always be nested (if you want a root Taxon, create a Taxonomy and get its root).

Configurable order update attributes class

Spree::OrderUpdateAttributes class is no longer hard-coded. That will grant you flexibility if you need to store additional attributes during checkout.

You need to configure your class in the new order_update_attributes_class. Make sure it follows the same signature as the default one:

config/initializers/spree.rb

Spree.config do |config|
  # ...
  config.order_update_attributes_class = 'MyStore::OrderUpdateAttributes'
end

app/models/my_store/order_update_attributes.rb

module MyStore
  class OrderUpdateAttributes
    def initialize(order, update_params, request_env:)
      @order = order
      @update_params = update_params
      @request_env = request_env
    end

    def call
      # true || false
    end
  end
end

Configure allowed ransackable scopes

We already had allowed ransackable attributes and associations to configure authorization on Ransack. We added the missing allowed_ransackable_scopes piece, allowing you to modify the defaults without overriding the .ransack_scopes method:

Spree::Product.allowed_ransackable_scopes.concat([:new_scope])

Improvements for the risk analysis report

The payment risk analysis summary rendered for orders considered dangerous now contains information for all the associated payments instead of only considering the last one.

Easily change from frontend to admin view for an order

That's a small quality of life improvement. If you're checking out an order in the storefront, you can now prepend /admin to the route and land in the admin panel counterpart. Very helpful during development and testing.

All-encompassing update task

Before, running bin/rails solidus:update would only generate the initializer to update default Solidus preferences. Now, it'll also copy the new migration files to your host application. Remember, you'll still need to check and run them by yourself.

Deprecate promotions with an any policy

Actually, promotions with a match_policy of any were deprecated on v3.2. We forgot to add a deprecation warning, so you may only realize it now.

As a reminder, if you have promotions with such a match policy, try running the following rake task:

bin/rake solidus:split_promotions_with_any_match_policy

That will create separate promotions for each of the rules of your promotions with any match policy, which should have the same outcome for customers.

Deprecation of payment offsets

That's just some dangling code removal, as payment offsets (the old refund system) have not been used on Solidus for a long time. You must move entirely to the well-established refund system if you're still using them.

Deprecated #line_item_shipment_price

The Admin::OrdersHelper#line_item_shipment_price method has been deprecated. You can use the equivalent Spree::LineItem#display_amount instead.