[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
…tions [Admin] Add new migrations and validations in `core` to support new `admin` `Spree::Role` interface
This calculator uses the `eligible` API from `Spree::Adjustment`, which in a system with the new promotions system will not be necessary. This hasn't been caught before because deprecation warnings did not raise until #5813 was merged.
Decorate Default Return Refund Amount Calculator in LegacyPromotions
This can be re-added whenever we get around to adding a migration to add it to the spree_roles table. For now all we need is the :name & :description.
In a separate PR, descriptions were added to the spree_roles table, and validations were added so that names are now required to be present & unique. The admin specs now reflect that reality and the UI has been updated to display descriptions.
…h-permissions [Admin] Update Spree::Role admin UI with descriptions & required names
Add missing `the` to README
This is building off of the new migrations in #5833 These originate from `solidus_user_roles`. We intend to migrate some of the functionality from that extension into `core`, and this is the (second) step. Co-authored-by: benjamin wil <[email protected]>
Later commits proved the need for an easier method of identifying and categorizing permission sets more cleanly on the front-end, which is why we added the category & privilege columns. Each subclass (eg. `Spree::PermissionSets::ConfigurationDisplay`) has its own privilege and category, which is then used to build the instance (Spree::PermissionSet) with the correct identifying features.
While I am not sure how frequently this will be re-used, the fact that it comes up 14 times across the roles/new and roles/edit pages makes this extraction worthwhile. I also tried out a partial and a helper method previously but both approaches were messy and poorly architected. This should serve us much better in the long run and be easier to maintain.
Building off of the previous commit as well as the migrations that were added to core to pull in some of the key features of solidus_user_roles we can now allow admins to assign permission sets when creating a role.
The role edit modal now also has the functionality to allow admins to assign permission sets.
I would not normally write specs to ensure associations, as that seems like it's not my responsibility to test, but Codecov seems to think otherwise and would like a spec for `Spree::RolePermission`, a model with nothing on it except some `belongs_to`s. I also added specs for the other models that were flagged. The association specs are a bit uglier than they could be if we were using the `shoulda_matchers` and their `is_expected.to belong_to` but it seems like it's not worth it to install it just to beautify 3 specs!
I feel pretty strongly that the default scope should be "all" instead of "customers". That way, when presented with a long list the first thought is to filter it, instead of the first thought being "why is this user missing" and then realizing that it's because it's filtering by users with the "customer" role only.
The new users admin interface now shows the last sign in date instead of the date the user was created. It will range between "Never", "Less than a minute ago", "3 days ago", "2 months ago" etc. It uses the built-in logic provided by `ActionView::Helpers::DateHelper#time_ago_in_words`. The specs are a bit tricky and stubby due to the need to keep them general and agnostic of whatever is being used for the `Spree.user_class`.
…h-permissions-round-2 [Admin] Allow assignment of permission sets when creating/editing admin roles
…ification [Admin] Display `last_sign_in_at` in users admin, change default scope
We introduced a custom Ransacker to allow filtering producs by their variants option values in the new admin interface. This ransacker is broken in latest Ransack v4.2 and overly complicated. By introducing a option_values association to products, that does the same join over variants_including_master and their distinct option_values we can use normal ransack search. Quoting the Ransack documentation: > "Ransackers, like scopes, are not a cure-all. Many use cases can be better solved with a standard Ransack search on a dedicated database search field, which is faster, index-able, and scales better than converting/ransacking data on the fly."
Now that we removed the broken ransacker in previous commit, we can allow Ransack v4.2 - with Rails 7.2 support - again.
We do not use the custom ransacker this was necessary for
Code fails with a 500 on admin because of the order shipping status. The change triggers @order.empty! only when the order is incomplete. Co-authored-by: An Stewart <[email protected]> Co-authored-by: Kendra Chateau <[email protected]>
Add Ransack 4.2 support
…-orders Call empty only on incomplete orders
Three of these examples were failing with the following error:
NameError:
uninitialized constant Spree::Api::OpenStruct
OpenStruct.new(
^^^^^^^^^^
Requiring ostruct and ensuring the correct scope is used when
referencing OpenStruct fixes the errors.
Fix failing API promotions specs
We initially did this because of some Bug in Chrome, but now the download of the very specific version here doesn't work any longer. Let's see what happens if we don't pin.
Stop pinning Chrome
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 : )