Skip to content

Releases: solidusio/solidus

v2.1.0.beta1

06 Dec 21:02
v2.1.0.beta1
0372596
Compare
Choose a tag to compare
v2.1.0.beta1 Pre-release
Pre-release

This is a beta release and may have minor breaking changes before the release of Solidus 2.1.0

v2.0.0

26 Sep 21:51
v2.0.0
320a750
Compare
Choose a tag to compare

Solidus 2.0.0 is identical to Solidus 1.4.0, but uses Rails 5.0 instead of Rails 4.2.

See the Rails documentation on how to upgrade to Rails 5.

All commits since 1.4

Rubygems
Github branch

v1.4.0

26 Sep 21:51
v1.4.0
3380d61
Compare
Choose a tag to compare

Solidus 1.4 will be the final Solidus release on rails 4.2. We are simultaneously releasing Solidus 2.0 for Rails 5.0.

Some caution is warranted surrounding changes to the OrderUpdater, which now uses the (possibly cached) line item, shipment, and adjustment associations.

Rubygems
Github branch

  • Use in-memory objects in OrderUpdater and related areas.

Solidus now uses in-memory data for updating orders in and around
OrderUpdater. E.g. if an order already has order.line_items loaded into
memory when OrderUpdater is run then it will use that information rather
than requerying the database for it. This should help performance and makes
some upcoming refactoring easier.

Warning: If you bypass ActiveRecord while making updates to your orders you
run the risk of generating invalid data. Example:

order.line_items.to_a
order.line_items.update_all(price: ...)
order.update!

Will now result in incorrect calculations in OrderUpdater because the line
items will not be refetched.

In particular, when creating adjustments, you should always create the
adjustment using the adjustable relationship.

Good example:

line_item.adjustments.create!(source: tax_rate, ...)

Bad examples:

tax_rate.adjustments.create!(adjustable: line_item, ...)
Spree::Adjustment.create!(adjustable: line_item, source: tax_rate, ...)

We try to detect the latter examples and repair the in-memory objects (with
a deprecation warning) but you should ensure that your code is keeping the
adjustable's in-memory associations up to date. Custom promotion actions are
an area likely to have this issue.

#1356
#1389
#1400
#1401

  • Make some 'wallet' behavior configurable

NOTE: Order#persist_user_credit_card has been renamed to
Order#add_payment_sources_to_wallet. If you are overriding
persist_user_credit_card you need to update your code.

The following extension points have been added for customizing 'wallet'
behavior.

  • Spree::Config.add_payment_sources_to_wallet_class
  • Spree::Config.default_payment_builder_class

#1086

  • Backend: UI, Remove icons from buttons and tabs
  • Backend: Deprecate args/options that add icons to buttons
  • Update Rules::Taxon/Product handling of invalid match policies

Rules::Taxon and Rules::Product now require valid match_policy values.
Please ensure that all your Taxon and Product Rules have valid match_policy
values.

  • Fix default value for Spree::Promotion::Rules::Taxon preferred_match_policy.

Previously this was defaulting to nil, which was sometimes interpreted as
'none'.

  • Deprecate Spree::Shipment#address (column renamed)

Spree::Shipment#address was not actually being used for anything in
particular, so the association has been deprecated and delegated to
Spree::Order#ship_address instead. The database column has been renamed
spree_shipments.deprecated_address_id.

#1138

  • Coupon code application has been separated from the Continue button on the Payment checkout page
  • JavaScript for it has been moved from address.js into its own spree/frontend/checkout/coupon-code
  • Numerous small nuisances have been fixed #1090
  • Allow filtering orders by store when multiple stores are present. #1149
  • Remove unused user_id column from PromotionRule. #1259
  • Removed "Clear cache" button from the admin #1275
  • Adjustments and totals are no longer updated when saving a Shipment or LineItem.

Previously adjustments and total columns were updated after saving a Shipment or LineItem.
This was unnecessary since it didn't update the order totals, and running
order.update! would recalculate the adjustments and totals again.

v2.0.0.rc1

07 Sep 19:57
Compare
Choose a tag to compare
v2.0.0.rc1 Pre-release
Pre-release

This is a release candidate, if no major issues arise it will become the 2.0.0 release

Solidus 2.0.0.rc1 is identical to 1.4.0.rc1, but requires rails 5.0 instead of rails 4.2

All commits since 1.4

Rubygems
Github branch

v1.4.0.rc1

07 Sep 19:53
Compare
Choose a tag to compare
v1.4.0.rc1 Pre-release
Pre-release

This is a release candidate, if no major issues arise it will become the 1.4.0 release

This is the final release (excepting patches) using rails 4.2. Use Solidus 2.0.0.beta1 for rails 5 support.

Rubygems
Github branch

  • Use in-memory objects in OrderUpdater and related areas.

Solidus now uses in-memory data for updating orders in and around
OrderUpdater. E.g. if an order already has order.line_items loaded into
memory when OrderUpdater is run then it will use that information rather
than requerying the database for it. This should help performance and makes
some upcoming refactoring easier.

Warning: If you bypass ActiveRecord while making updates to your orders you
run the risk of generating invalid data. Example:

order.line_items.to_a
order.line_items.update_all(price: ...)
order.update!

Will now result in incorrect calculations in OrderUpdater because the line
items will not be refetched.

In particular, when creating adjustments, you should always create the
adjustment using the adjustable relationship.

Good example:

line_item.adjustments.create!(source: tax_rate, ...)

Bad examples:

tax_rate.adjustments.create!(adjustable: line_item, ...)
Spree::Adjustment.create!(adjustable: line_item, source: tax_rate, ...)

We try to detect the latter examples and repair the in-memory objects (with
a deprecation warning) but you should ensure that your code is keeping the
adjustable's in-memory associations up to date. Custom promotion actions are
an area likely to have this issue.

#1356
#1389
#1400
#1401

  • Make some 'wallet' behavior configurable

NOTE: Order#persist_user_credit_card has been renamed to
Order#add_payment_sources_to_wallet. If you are overriding
persist_user_credit_card you need to update your code.

The following extension points have been added for customizing 'wallet'
behavior.

  • Spree::Config.add_payment_sources_to_wallet_class
  • Spree::Config.default_payment_builder_class

#1086

  • Backend: UI, Remove icons from buttons and tabs
  • Backend: Deprecate args/options that add icons to buttons
  • Update Rules::Taxon/Product handling of invalid match policies

Rules::Taxon and Rules::Product now require valid match_policy values.
Please ensure that all your Taxon and Product Rules have valid match_policy
values.

  • Fix default value for Spree::Promotion::Rules::Taxon preferred_match_policy.

Previously this was defaulting to nil, which was sometimes interpreted as
'none'.

  • Deprecate Spree::Shipment#address (column renamed)

Spree::Shipment#address was not actually being used for anything in
particular, so the association has been deprecated and delegated to
Spree::Order#ship_address instead. The database column has been renamed
spree_shipments.deprecated_address_id.

#1138

  • Coupon code application has been separated from the Continue button on the Payment checkout page
  • JavaScript for it has been moved from address.js into its own spree/frontend/checkout/coupon-code
  • Numerous small nuisances have been fixed #1090
  • Allow filtering orders by store when multiple stores are present. #1149
  • Remove unused user_id column from PromotionRule. #1259
  • Removed "Clear cache" button from the admin #1275
  • Adjustments and totals are no longer updated when saving a Shipment or LineItem.

Previously adjustments and total columns were updated after saving a Shipment or LineItem.
This was unnecessary since it didn't update the order totals, and running
order.update! would recalculate the adjustments and totals again.

v2.0.0.beta1

22 Aug 18:59
Compare
Choose a tag to compare
v2.0.0.beta1 Pre-release
Pre-release
Version 2.0.0.beta1

v1.4.0.beta1

22 Aug 18:57
Compare
Choose a tag to compare
v1.4.0.beta1 Pre-release
Pre-release
Version 1.4.0.beta1

v1.3.1

06 Jul 20:25
v1.3.1
349e9b0
Compare
Choose a tag to compare

Solidus 1.3.1 contains only one change intended to simplify the upgrade process for users upgrading to 1.3.x:

  • Removed solidus:migrations:ensure_store_on_orders:up rake task, which now exists as a migration. #1267

Rubygems

v1.3.0

22 Jun 20:26
v1.3.0
0a7ca86
Compare
Choose a tag to compare

Introducing Solidus 1.3.0, the "international" release

This release introduces major changes intended to better support VAT taxation and per-country pricing. Martin's SolidusConf 2016 talk gives an introduction to these changes and their motivation. A blog post focusing on upgrading is to come.

This release includes 1075 commits from 39 different authors. Thanks to everyone who contributed, tested, or provided feedback for this release.

Rubygems
Github branch

Changelog

  • Order now requires a store_id in validations

All orders created since Spree v2.4 should have a store assigned. A
migration exists to assign all orders without a store to the default store.

If you are seeing spec failures related to this, you may have to add
let!(:store) { create(:store) } to some test cases.

  • Deprecate Spree::TaxRate.adjust, remove Spree::TaxRate.match

The functionality of Spree::TaxRate.adjust is now contained in the new
Spree::Tax::OrderAdjuster class.

Wherever you called Spree::TaxRate.adjust(items, order_tax_zone), instead call
Spree::Tax::OrderAdjuster.new(order).adjust!.

Spree::TaxRate.match was an implementation detail of Spree::TaxRate.adjust. It has been
removed, and its functionality is now contained in the private method
Spree::Tax::TaxHelpers#applicable_rates(order).

  • Allow more options than current_currency to select prices

Previously, availability of products/variants, caching and pricing was dependent
only on a current_currency string. This has been changed to a current_pricing_options
object. For now, this object (Spree::Variant::PricingOptions) only holds the
currency. It is used for caching instead of the deprecated current_currency helper.

Additionally, your pricing can be customized using a VariantPriceSelector object, a default
implementation of which can be found in Spree::Variant::PriceSelector. It is responsible for
finding the right price for variant, be it for front-end display or for adding it to the
cart. You can set it through the new Spree::Config.variant_price_selector_class setting. This
class also knows which PricingOptions class it cooperates with.

Deprecated methods:

  • current_currency helper
  • Spree::Variant#categorise_variants_from_option
  • Spree::Variant#variants_and_option_values (Use Spree::Variant#variants_and_option_values#for instead)
  • Spree::Core::Search::Base#current_currency
  • Spree::Core::Search::Base#current_currency=

Extracted Functionality:

There was a strange way of setting prices for line items depending on additional attributes
being present on the line item (gift_wrap: true, for example). It also needed
Spree::Variant to be patched with methods like Spree::Variant#gift_wrap_price_modifier_in
and is generally deemed a non-preferred way of modifying pricing.
This functionality has now been moved into a Gem of its own
to ease the transition to the new Variant::PriceSelector system.

  • Respect Spree::Store#default_currency

Previously, the current_currency helper in both the core and api gems
would always return the globally configured default currency rather than the
current store's one. With Solidus 1.3, we respect that setting without having
to install the spree_multi_domain extension.

  • Persist tax estimations on shipping rates

Previously, shipping rate taxes were calculated on the fly every time
a shipping rate would be displayed. Now, shipping rate taxes are stored
on a dedicated table to look up.

There is a new model Spree::ShippingRateTax where the taxes are stored,
and a new Spree::Tax::ShippingRateTaxer that builds those taxes from within
Spree::Stock::Estimator.

The shipping rate taxer class can be exchanged for a custom estimator class
using the new Spree::Appconfiguration.shipping_rate_taxer_class preference.

#904

In order to convert your historical shipping rate taxation data, please run
rake solidus:upgrade:one_point_three - this will create persisted taxation notes
for historical shipping rates. Be aware though that these taxation notes are
estimations and should not be used for accounting purposes.

#1068

  • Deprecate setting a line item's currency by hand

Previously, a line item's currency could be set directly, and differently from the line item's
order's currency. This would result in an error. It still does, but is also now explicitly
deprecated. In the future, we might delete the line item's currency column and just delegate
to the line item's order.

  • Taxes for carts now configurable via the Spree::Store object

In VAT countries, carts (orders without addresses) have to be shown with
adjustments for the country whose taxes the cart's prices supposedly include.
This might differ from Spree::Store to Spree::Store. We're introducting
the cart_tax_country_iso setting on Spree::Store for this purpose.

Previously the setting for what country any prices include
Spree::Zone.default_tax. That, however, would also implicitly tag all
prices in Spree as including the taxes from that zone. Introducing the cart
tax setting on Spree::Store relieves that boolean of some of its
responsibilities.

#933

  • Make Spree::Product#prices association return all prices

Previously, only non-master variant prices would have been returned here.
Now, we get all the prices, including those from the master variant.

#969

  • Changes to Spree::Stock::Estimator
  • The package passed to Spree::Stock::Estimator#shipping_rates must have its
    shipment assigned and that shipment must have its order assigned. This
    is needed for some upcoming tax work in to calculate taxes correctly.
  • Spree::Stock::Estimator.new no longer accepts an order argument. The order
    will be fetched from the shipment.

#965

  • Removed Spree::Stock::Coordinator#packages from the public interface.

This will allow us to refactor more easily.
#950

  • Removed pre_tax_amount column from line item and shipment tables

This column was previously used as a caching column in the process of
calculating VATs. Its value should have been (but wasn't) always the same as
discounted_amount - included_tax_total. It's been replaced with a method
that does just that. #941

  • Renamed return item pre_tax_amount column to amount

The naming and functioning of this column was inconsistent with how
shipments and line items work: In those models, the base from which we
calculate everything is the amount. The ReturnItem now works just like
a line item.

Usability-wise, this change entails that for VAT countries, when creating
a refund for an order including VAT, you now have to enter the amount
you want to refund including VAT. This is what a backend user working
with prices including tax would expect.

For a non-VAT store, nothing changes except for the form field name, which
now says Amount instead of Pre-tax-amount. You might want to adjust the
i18n translation here, depending on your circumstances.
#706

  • Removed Spree::BaseHelper#gem_available? and Spree::BaseHelper#current_spree_page?

Both these methods were untested and not appropriate code to be in core. If you need these
methods please pull them into your app. #710.

  • Fixed a bug where toggling 'show only complete order' on/off was not showing
    all orders. #749
  • ffaker has been updated to version 2.x

This version changes the namespace from Faker:: to FFaker::

  • versioncake has been updated to version 3.x

This version uses a rack middleware to determine the version, uses a
different header name, and has some configuration changes.

You probably need to add this
to your controller specs.

More information is available in the VersionCake README

  • Bootstrap 4.0.0-alpha.2 is included into the admin.
  • Pagination now uses an admin-specific kaminari theme, which uses the
    bootstrap4 styles. If you have a custom admin page with pagination you can
    use this style with the following.
<%= paginate @collection, theme: "solidus_admin" %>
  • Settings configuration menu has been replaced with groups of tabs at the top
  • Settings pages were grouped into related partials as outlined in #634
  • Partials are rendered on pages owned by the partials as tabs as a top bar
  • Admin-nav has a sub-menu for the settings now
  • Lists of classes in configuration (config.spree.calculators, spree.spree.calculators, etc.) are
    now stored internally as strings and constantized when accessed. This allows these classes to be
    reloaded in development mode and loaded later in the boot process.
    #1203

v1.3.0.rc2

17 Jun 22:41
v1.3.0.rc2
3644b31
Compare
Choose a tag to compare
v1.3.0.rc2 Pre-release
Pre-release

This is a release candidate, there may some incompatible changes before the final release. Ongoing development is in the v1.3 branch.