-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Soft-delete ShippingMethod translations #121
Comments
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Looking into implementing this and I've encountered an issue with the setup. I've forked, cloned, and run rake aborted! |
@zcallanan 👋 , please take a look at solidusio/solidus_dev_support#163. It's a long-term fix but in the referenced PRs there's a quick solution that could be applied here as well. Let me know if that works! |
Following the above I replaced:
with:
Running
Running
|
That rake task is recently changed, it's now |
It's found on line 71 of the CONTRIBUTING.md in this project. The test application was created with the new command. One thing of note was I received a number of deprecation warnings (two examples follow): `DEPRECATION WARNING: SolidusSupport::EngineExtensions::Decorators is deprecated! Use SolidusSupport::EngineExtensions instead. (called from class:Engine at /Users/astolot/code/zcallanan/solidus_globalize/lib/solidus_globalize/engine.rb:9) DEPRECATION WARNING: SolidusSupport.solidus_gem_version is deprecated and will be removed in solidus_support 1.0. Please use Spree.solidus_gem_version instead. (called from module:Admin at /Users/astolot/code/zcallanan/solidus_globalize/app/decorators/controllers/solidus_globalize/spree/admin/resource_controller_decorator.rb:16)` As an aside, I noticed what looks like a typo on line 8 of the resource_controller_decorator:
|
I tried running the command `Provide a CODECOV_TOKEN environment variable to enable Codecov uploads An error occurred while loading spec_helper. FactoryBot::DuplicateDefinitionError: Run options: include {:focus=>true}` |
You can safely ignore the deprecation warnings. Thanks for reporting that typo, can you fix it in a separate PR or even just open a new issue to track it. |
This should be fixed now that I've released the last SolidusDevSupport version. Can you please delete the Gemfile.lock and the test app and try again? Sorry for the inconvenience, this should be the last thing. |
I'll open a separate PR for the typo. Running `All examples were filtered out; ignoring {:focus=>true} Randomized with seed 11014 An error occurred in a NoMethodError: #/Users/astolot/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/routing-filter-0.6.3/lib/routing_filter/adapters/rails.rb:30:in `block in generate' #/Users/astolot/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/routing-filter-0.6.3/lib/routing_filter/chain.rb:15:in |
That happens for some reason running specs against the last released version of Solidus (2.11), see here. I think you can ignore that failure to resolve this one, or take a look at fix that as well in another PR, up to you! |
Working through this task, and I have a question below. From the description:
The product translation methods include discard handling for slugs as well as testing of variant callbacks in the method spec. How exact a match should this be to the Product decorator? Should a slug and variant support be added to shipping method translations in order to align with Product translation, or is this task just to add and handle |
Since Shipping Methods have no slug and association with variants, you are right, adding them does not make a lot of sense in this context and is not needed. 👍 |
When starting work on this issue I noted that there was already a test for shipping method translation soft deletes, and it's very similar to the product soft delete test. While investigating how the Discard gem operates, I noticed that only the shipping_method and product are discarded in their tests, and then reloaded. The translations are handled through the after_discard callback and the call of the discard_all method within the decorator. What I'm curious about is if you look at the return of discard_all, it produces a record set where the translation has a deleted_at timestamp, but if you check the same translation following the shipping method or product discard (in the test), it does not have a deleted_at timestamp. I believe this is because discard_all instantiates each record, and this is reflected in the translation in the set having a different memory address from the translation address in the test. Shipping Method Decorator, discard_all return: Shipping Method Test output of translation following shipping_method discard: This prevents you from checking whether a shipping method's translation has been discarded following a |
@zcallanan have you tried reloading the translations after discarding them? translations.discard_all
translations.reload |
That clears up my confusion, thanks! My assumption was that the deleted_at value would be set on discard, before the reload, but that's not the case. Checking the deleted_at value after the reload shows the correctly set deleted_at. Additionally a translation reload isn't necessary, if you look at the translation record after the shipping_method.reload it has the deleted_at set, and the test passes. Decorator:
Test the added deleted_at is correctly set on discard:
|
As we are doing with Product translations, we should also soft-delete shipping method 's translations.
At the moment, we are just keeping them around and they will be restored automatically if the shipping is undiscarded. This works but it's not ideal since they should be marked as discarded as well.
We can improve this extension by just adding the
deleted_at
column to thespree_shipping_methods_transations
table, and adding discard methods to that table as it's currently done withSpree::Product
(in its decorator).Ref: 0293d9f
The text was updated successfully, but these errors were encountered: