[pull] main from solidusio:main #411
Open
+27,567
−3,296
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}
Explicit is better than implicit.
Explicit is better than implicit.
Calculators are their own model, and we can just move them one level up, shortening some view references.
When applying or validating an order_promotion, we load all associated promotions and check their usage limit. A discarded promotion can still be associated with an order. If we do not load discarded promotions, then the order_promotion will not have an associated promotion and checking usage limits will result in an error.
When we delete a promotion, we want to be sure that dependent order promotions are also deleted.
This is an additional safeguard that makes sure orders do not get discarded promotions applied to their carts (by removing any manual connections through e.g. promotion codes).
Promotion Actions have been renamed to Benefits, and Promotion Rules to Conditions. This needs to be reflected in the README.
Solidus' promotion configuration interface changes a bit in 4.4, and with SolidusFriendlyPromotions 2.0 we want to adapt those changes.
We don't need to provide our own implementation any longer, Solidus ships with it!
Solidus has a new configuration endpoint for the promotions order adjuster class. Implement it.
This is not needed any longer, as this method is only implemented in solidus_legacy_promotions.
This is present in Solidus core, identically.
This allows the API feature spec to go through.
This is necessary for the API promotion endpoint to work.
We don't need to override Spree::Adjustment.promotion and Spree::Adjustment#promotion?
This will reset the connected order promotions when an order is emptied.
Almost all of our specs don't use the RSpec DSL at the top level. This adds `RSpec.` to the ones that do.
This was relying on Solidus Legacy Promotions' permission set to be present, and it was testing the backend configuration with the redirect.
Use Order#email to show the order's email in new admin
Allow to set Rails deprecations behavior during tests
The default time of 2 seconds is not enough sometimes. Give it 3 more seconds to wait until Capybara raises an error.
tests: Give dialogs a little more time to open
None of this works right now, but let's write a spec that details how things should work.
The promotion class should decide whether it can apply.
This duplicated the logic from SolidusPromotions::Promotion.order_activatable, and this way it reads nicer.
Add can apply to promotions
If the backportable PR contains the backport-vxx label as the first label the condition does not match.
…-page [Admin][Users]Add new admin store_credits show page
…s-create-edit [Admin][Products] Add product properties create/edit flow to admin
These dialog tests fail often. We should give them more time to open.
Fix backporting of PRs with backport label first
…open0in-specs tests: Give even more dialogs more time to open in tests
…om_config Introducing product brand using taxon_brand_selector
`solidus_promotions` is tested with `legacy_promotions`, and needs this dependency to be present in tests. This does not add `legacy_promotions` as a runtime dependency.
Bundler is unhappy about duplicate entries in the Gemfile. This creates a couple of new `group` statements that remove those duplications. This makes the Gemfile harder to read, unfortunately.
…o-promotions-gemfile Add solidus legacy promotions to promotions gemfile
Sometimes, as part of a form, you might want to include a field for something which is not strictly part of the object you are updating. In this instance it was a form for updating a StoreCredit, which needed to include a select for a StoreCreditReason id. Since StoreCreditReason is only linked to StoreCredit via a StoreCreditEvent, this select was blowing up when we tried to use it (due to trying to call store_credit.public_send(store_credit_reason_id) which is not defined). This extra check allows this form field to be used more freely and flexibly without immediately blowing up.
…-refactor [Admin][Users] Add new admin store credits edit_amount flow
This spec was becoming really long, and since store credit actions get their own controller and their own request specs, it makes sense to break these out into their own feature spec too. Now if one case fails we don't have to re-run this entire enormous user spec.
This should get us to 100% coverage for the StoreCreditsController!
…-refactor [Admin][Users] Add new admin store credits edit_memo flow
…-invalidate [Admin][Users] Add new admin store credits invalidate flow
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 : )