Skip to content
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

Nil variant shipping category not handled properly in form #5675

Closed
Roman2K opened this issue Feb 28, 2024 · 0 comments · Fixed by #5882
Closed

Nil variant shipping category not handled properly in form #5675

Roman2K opened this issue Feb 28, 2024 · 0 comments · Fixed by #5882

Comments

@Roman2K
Copy link

Roman2K commented Feb 28, 2024

Solidus Version:
v3.4.6 (should still be relevant in v4.3.2)

To Reproduce

  1. Go to the admin backend
  2. Go to Products > Products > [any product] > Variants
  3. Edit any variant that has a nil shipping category

Current behavior
The selected value is the product's shipping category.

Expected behavior
The selected value should be "Use Product Shipping Category".

Screenshots
N/A

Desktop (please complete the following information):

  • OS: Linux
  • Browser: Firefox
  • Version: 121.0b9

Smartphone (please complete the following information):
N/A (not tested)

Additional context
After editing a variant, the inherited shipping category is saved in the variant, taking the product's value at the time of saving. From that point on, it's no longer dynamically inherited after the product's shipping category is changed.

The bug is caused by the collection_select in backend/app/views/spree/admin/variants/_form.html.erb that gets its selected value by calling @variant.shipping_category_id (inherited from the product if nil, instead of the actual nil value in the database).

The fix should be as simple as passing selected: @variant[:shipping_category_id] in the first options hash (ends up in the :selected option passed to options_from_collection_for_select).

Side note: the tax category select field above it should not be impacted by the same bug because Variant#tax_category_id doesn't have the same fallback.


EDIT: Fixed steps to reproduce

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant