[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}
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.
Spree::PromotionCodeBatchBuilder is from another gem.
We have no ApplicationJob.
With the initializer, we need a full Rails app to test the presence of the default classes. By leveraging `add_class_set` and `add_nested_class_set` from Solidus core with their `default` option, we don't need to do as much in the initializer.
Without this, we get version conflicts (but our code works with both 1.4 and 2.x)
We don't need ActionCable, and it's not loaded in our test suite. This stops Turbo from autoloading channels that need it. We don't need it.
This updates the `MIGRATING.md` file to reflect the current state of the gem.
This is the first step in making this gem independent of solidus_backend.
We don't depend on solidus_backend, and stores should be able to load the extension even if they don't use the backend.
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
solidus_support 0.11.0 introduced flickwerk for patch loading. Somehow this messes with the zeitwerk autoloader and things acting weird (inflections broken, wrong constant module nesting, etc.) 0.12.0 reverted flickwerk.
Sometimes the modal that contains the field is not present yet. Let's use capybara's waiting capabilities before filling the field.
Use at least solidus_support 0.12.0
This was just some leftover WIP code that would have impacted the error
state of the controller. Now the flash messages will display the correct
success and failure states. This wasn't caught by the specs as the old
busted code (now removed) would have just displayed both `flash[:notice]
= t('.success')` (and also) `flash[:error] = t('.failure')`
and this would match on the assertion:
```
expect(response.body).to
include("Something went wrong. Store credit could not be invalidated.")
```
Since they are set using different keys, they didn't overwrite each
other in the flash hash.
Regardless, the old WIP code has been removed and the flow now displays
the expected flash.
Previously these were only used on edit actions which was fine because the `render_edit_with_errors` method is able to accommodate both the `update_amount` and `invalidate` actions. However, I want to re-use the `ensure_amount` method inside of the new/create flow. Since new/create flow would need to render a different template (eg. `render_new_with_errors`) I have altered the ensure method to accept a block instead of being hard-coded to `render_edit_with_errors`.
…-create [Admin][Users] Add new admin store credits create 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 : )