-
-
Notifications
You must be signed in to change notification settings - Fork 725
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
shipping fees on admin: avoid backend error when updating calculator type #8979
shipping fees on admin: avoid backend error when updating calculator type #8979
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.
Nice.
A test would have been nice. 😜 I think that every bug deserves a spec. It helps while developing and makes sure that the same bug doesn't happen again. I find this often more important than trying to cover new features with all possible specs. You can't predict bugs but you can make sure that you don't do the same mistake twice. |
I thought about it. My concern was about creating a test for a very specific bug, pretty old actually, that will increase the time consumed by each continuous integration. For sure creating test will avoid to us to do the same mistake. But in this particular case, I thought it was unnecessary. Will do anyway. |
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.
Thank you!
This one is 1 month old, has been reviewed by @mkllnk --> moving to |
Ideally, we would not have manual testing stage at all - right? But I guess slowing down the build is a side effect, yeah. But still desired trade-off, right? What do you think? Maybe something for delivery circle :-) |
Hey @jibees , Somehow this one is not quite working just yet, I still get the error 500 when switching from a weight-based calculator to any other calculator:
Also, I've looked at the server logs, the error might be triggered by:
Here is the full log:
Hope this is helpful. Moving back to in dev. |
I'm not sure, actually. Ideally, we would have manual release testing. But the author of a PR is always biased and it's very difficult to think outside the box. That's why we have reviews for the code and we need testing as a review of functionality. The best PR testing is actually not just following testing steps because that's something the author can do and we can automate. We need a hacker mind thinking: "How can I break this?" How could this go wrong? Which other parts of the application may be affected?
Right. There's a limit, of course, but a spec that runs a few seconds is always better than manual testing. |
As they're not handled by the backend
+ Missing some spree i18n keys
e8212b5
to
4b629ea
Compare
@filipefurtad0
EDIT Right, I finally reproduced it (need more ☕️ ?) |
As they're not handled by the backend
Not that issue should be now tested in both |
Back in |
Hey @jibees , Awesome, all good now: Merging 🎉 PS: not related to this PR, we have this console output - when editing shipping methods:
|
What? Why?
Ensure that form element are well disabled to not submit them, as they're not handled by the backend
This solution is not perfect (I did not change the UX behavior which can be improve a lot, I didn't remove any angular code, ...) but this seems to be straightforward and should probably improve the UX experience.
Closes #6300
What should we test?
Well described in the original issue:
On both
/admin/shipping_methods/9/edit
and/admin/enterprise_fees
Release notes
Changelog Category: User facing changes
The title of the pull request will be included in the release notes.