[pull] main from solidusio:main #411
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
There was a typo in the update
This changes the order spec in core to rely on the stubbed null promotion system. The specs for the legacy promotion system have been moved to the legacy_promotions gem.
The one example here relies on the legacy promo system.
With the upcoming change to using the Null promotion system, these specs will start failing, because they really test another classes implementation (that of the legacy promotions configuration object). Just test for equality instead.
These specs test the entire promotion system, not just the `CreateQuantityAdjustments` class. Moving to the legacy_promotions gem.
These specs test the entire promotion system, not just this unit.
This one spec should not live here.
This change lets this spec pass even if the promotion configuration object changes. It currently prints deprecation warnings, but it will soon be moved over to the legacy_promotions gem.
These specs test not the promotion code model in isolation, but the entire promotion system's functioning. Moving to solidus_legacy_promotions.
This promotion handler only handles promotions with the free shipping action, and that is configured in the legacy promotion configuration. Stub it, so that tests pass even with a Null promotion configuration configured.
While this file looks like a unit test, it's entirely an integration test for the whole promotion system. Moving as-is.
Earlier in the extraction process, I've defined a configuration object for the current promotion system and called it `Spree::Core::PromotionConfiguration`. However, it is much more aptly named `SolidusLegacyPromotions::Configuration`, as it will be moved into that gem shortly. This way it's also clear when we move to the `Spree::Core::NullPromotionConfiguration` what we are changing.
The existing promotion handlers are activated using either `#apply` or `#activate`. The return value `#activate` is usually not read, and is thus not really important, but that of `#apply` must be the handler itself, so that e.g. the adjustments admin has access to any application errors.
Move legacy integration specs
…ration Rename PromotionConfiguration to LegacyPromotionConfiguration
NullPromotionHandler: return self from #apply
With the NullPromotionConfiguration, the default promotion attributes are an empty list. In order to test whether attributes can be deleted from this list, we first have to add an attribute.
We want to use the legacy `Spree::PromotionConfiguration` in the solidus_legacy_promotions test suite.
sprockets-rails 3.5.0 breaks our test suite. See rails/sprockets-rails#524 and rails/sprockets-rails#525
Disallow sprockets-rails 3.5.0
The order search depends on legacy promotion system associations to be
present, but we don't want to introduce Deface as a core dependency.
Therefore, we must make the search fields for orders configurable.
This introduces a new configuration option on the Backend configuration:
`Spree::Backend::Config.search_fields`. This Hash has controller paths
as keys, and arrays that holds hashes with a `:partial` key that indicates
which partial should render this search field.
Optionally, one can specify an `:if` key with a lambda as the value that
gets executed at runtime, so that unnecessary fields ("Store" for
installations with only one store instance) are not displayed.
Complex fields can be done by specifying a custom partial, such as the
`:date_range_picker` partial in this PR.
The third key, `:locals` contains a has of the local variables inside
the partial. Anything that needs to be computed dynamically should be
done with a lambda here.
This search field depends on the `Spree::Order#promotions` relation to be available and searchable. This is not given with a null promotion system or the upcoming new promotion system, where relations will have a different name. So we only add it if solidus_legacy_promotions is also loaded.
With the null promotion configuration in place, we can't use the legacy Spree::OrderContents class, as that makes references to the legacy promotion system. See #5755
This class directly references Spree::PromotionHandler::Cart, and thus needs to live in the legacy_promotions gem. If you inherit from this class, and it happens to not be available after upgrading, please add ``` gem "solidus_legacy_promotions" ``` to your Gemfile.
The new admin allows orders to be filtered by promotion name. However, with the legacy promotion system extracted into an extension, we can't rely on `Spree::Promotion` to exist in `solidus_admin`. In order to get around this issue, we create a new index component for the admin orders page that includes the filter, and register it in an initializer. This also adds a spec for filtering by promotion name.
Use Null Promotion Configuration in core
Create custom orders index component for solidus_legacy_promotions
Except for the flat rate calculator, as that one is so generic it's often just used as a stand-in calculator.
In legacy_promotions, we'll just keep them in `app`, where they're tested, too.
We don't need #recalculate for anything in core, and we don´t need the association to promotion codes.
I'm keeping the spec to test what the model does, but moving the extended spec with the actual promotion to solidus_legacy_promotions.
This should help everyones test suite's to stay green.
This allows running the core dummy app with the Tailwind required for setting sails towards the new frontend.
Support Tailwind CSS in core dummy app
This is used in a number of other places. Also, this adds icons to the adjustment source components, which looks nice (and was probably intended).
It will otherwise get confusing when we add adjustables.
This allows us to remove a bunch of untested (and untestable) code. Especially the `else` block in `figcaption_for_adjustable` is impossible to reach, as only orders, line items and shipments are adjustable. If people have their own adjustable objects, they can now just add a component.
Admin adjustable components
Extract Legacy Promotion System: Move ActiveRecord Models and Factories
This had some copy-pasta, and the requiring the engine requires requiring the gem first.
SolidusFriendlyPromotions does not store promotion code IDs on adjustments, and it does not need to: The promotion code is stored on the `friendly_order_promotions` join table between promotion and order, and adjustments and promotion codes can be joined between that table and the adjustments' source. This fixes the build on solidus_friendly_promotions currently, because what that gem does it simply make `require_promotion_code` return `false` for adjustments created with the new promotion system. This change makes the validation self-contained for adjustments from the `legacy_promotions` gem.
It's always set to nil, so it doesn't matter for the specs in question, and we can just not specify it.
If `solidus_legacy_promotions` is loaded, we can be sure that the column exists.
This moves the column into solidus_legacy_promotions, which is the only place it's used at.
This table is created in legacy_promotions/db/migrate/20160101010001_solidus_one_four_promotions.rb, and that this is still in core is an oversight.
Fix bin/rails in solidus_legacy_promotions
…id-to-legacy-promotions Move adjustment promotion code id to legacy promotions
…-to-legacy-promotions Remove spree_orders_promotions from core migration
This was another oversight, and its breaking builds of other gems.
Remove usage of `if_not_exists` in Promo rollup migration
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )