-
-
Notifications
You must be signed in to change notification settings - Fork 724
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
Fix product with ml unit display dl #11741
Fix product with ml unit display dl #11741
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good!
Do we want to list all the available Units on the product creation form?
I would display only the configured available units unless someone complains...
units = WeightsAndMeasures::UNITS.values.flat_map(&:values).pluck("name").sort.uniq | ||
expect(units).to eq(all_units.sort.uniq) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is the same, shall we call WeightsAndMeasures::UNITS.values.flat_map(&:values).pluck("name")
from all_units
? Then we don't need to maintain two lists. We just need to make sure that the units are in the right order.
|
||
describe "compatibleUnitScales", -> | ||
it "returns a sorted set of compatible scales based on the scale and unit type provided", -> | ||
expect(VariantUnitManager.compatibleUnitScales(1, "weight")).toEqual [1.0, 1000.0, 1000000.0] | ||
expect(VariantUnitManager.compatibleUnitScales(453.6, "weight")).toEqual [28.35, 453.6] | ||
|
||
pending "should load only available unit", -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this new test is failing.
I don't know how to update availableUnits
before running the tests.
I tried directly assigning a new value to VariantUnitManager.availableUnits
, but it didn't work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not familiar with this testing framework to suggest how to fix it directly sorry. But I thought that we could re-arrange it to resolve the problem, so tried this in another commit. Let me know what you think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work! You identified an inconsistency in the app and changed it to respect the configured preferences, which is a great end result.
I noticed we can use a better way of accessing the preference, so have added a commit for this to demonstrate.
I also thought of a way to make the JS test pass and added another commit.
I think we could tidy up the JS a bit, but don't know how, so I approve of this ;)
|
||
describe "compatibleUnitScales", -> | ||
it "returns a sorted set of compatible scales based on the scale and unit type provided", -> | ||
expect(VariantUnitManager.compatibleUnitScales(1, "weight")).toEqual [1.0, 1000.0, 1000000.0] | ||
expect(VariantUnitManager.compatibleUnitScales(453.6, "weight")).toEqual [28.35, 453.6] | ||
|
||
pending "should load only available unit", -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not familiar with this testing framework to suggest how to fix it directly sorry. But I thought that we could re-arrange it to resolve the problem, so tried this in another commit. Let me know what you think.
if availableUnits | ||
available = availableUnits.split(",") | ||
(parseFloat(scale) for scale, scaleInfo of @units[unitType] when scaleInfo['system'] == scaleSystem and available.includes(scaleInfo['name'])).sort (a, b) -> | ||
a - b | ||
else | ||
(parseFloat(scale) for scale, scaleInfo of @units[unitType] when scaleInfo['system'] == scaleSystem).sort (a, b) -> | ||
a - b |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the condition could have been included into the existing code, rather than copy to a separate branch.
In fact, it looks like all functions in this class need to filter by available units.
I think there should be a filtered units
list, which would probably be shared with the other functions.
But I have to admit I'm struggling with this kind of Javascript and am not sure how to refactor it!
So if you'd like to try, I'd be very thankful, but don't expect you to!
before do | ||
Spree::Config.set_preference(:available_units, available_units) | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should actually mock the preference, so that it doesn't leak into other specs. In fact, there's and example below in this file!
It wasn't working because you used a different method for accessing the preference. I've added a commit to change this to use the more standard format (Spree::Config.available_units
), and now product_import_spec.rb
works without any further changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great improvements.
Hi @abdellani, Before staging
After staging
I think we should look at the error 500 and think about a migration before merging. Will move this back to In Dev but we're close. Thanks again! |
…hat are selected on 'Available Units' list
added a test to make sure that all units on WeightsAndMeasures::UNITS are list on all_units
And mock the preference value, rather than setting it. Before, the set preference could have leaked to other tests. (I noticed that it was already like this in product_import_spec.rb)
Best viewed with white-space ignored
4d51a43
to
d1017c6
Compare
… untis when needed
d1017c6
to
847c3af
Compare
Nice catch @drummer83 👍 Thank you |
@openfoodfoundation/train-drivers-product-owners Can you please comment on the question about converting existing dl and cl to ml? |
So only the new/edited products were updated to dl since the change? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A migration seems like a good idea, because we're confident that dL
was not intended on any products. It is possible that someone might intentionally use dL
, in which case a future migration could cause an undesired outcome. So I'd suggest it's better to choose now or never.
But it's easy to manually fix and hopefully doesn't affect too many people, so "never" is probably a reasonable option :)
def scales_for_variant_unit(ignore_available_units: false) | ||
return @units[@variant.product.variant_unit] if ignore_available_units | ||
|
||
@units[@variant.product.variant_unit]&.reject { |_scale, unit_info| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This no longer caches the result, but I assume caching wasn't needed anyway. Even if it gets called twice, it seems like an inexpensive process.
Hi @abdellani, I have tested my scenarios from above again. Everything is still looking good and I couldn't reproduce the error 500 anymore. 💪 One thing I need to mention: Staging failed on FR server. I assume this is because I had staged the first version of this PR on that server earlier already. It worked well on AU server. So - I'm not merging this one because I'm not sure about the failed staging. But apart from that this PR is ready to go! Thanks! 🙏 Ping @filipefurtad0, since you will be drafting the release tomorrow. |
Thanks for testing and the heads-up @drummer83. I'd propose to still stage on UK-staging (doing so now), and all is well, then merge? |
I just checked the logs for the fr-staging deployments and it appears to have failed due to this error during asset compilation:
I think I've seen this before. This is certainly not related to this PR, so we're good to go 👍 But we should pay attention to the warning. I'll give that a try.. |
Thanks @dacook ! 🙏 |
What? Why?
What should we test?
In addition to the scenario described in the original issue. I highlighted some fields that require a special focus
Release notes
Changelog Category (reviewers may add a label for the release notes):
The title of the pull request will be included in the release notes.
Dependencies
Documentation updates