parent b680697af6
author Nihal Mohammed <mnihal64@outlook.com> 1621004464 +0530
committer Nihal Mohammed <mnihal64@outlook.com> 1621022463 +0530
# This is a combination of 4 commits.
# This is the 1st commit message:
Add advanced settings button to incoming and outgoing pages in OC cycle edit
# This is the commit message #2:
Remove extra header text
# This is the commit message #3:
Moved repeating code blocks to partial
# This is the commit message #4:
Refactored code
# This is the commit message #5:
Delete _advanced_settings_hidden.html.haml
At `CapQuantity`'s instantiation time the proxy's order is not yet
initialized, and so `CapQuantity` was checking against nil all the time.
This went unnoticed because the job's specs were not integration-level
tests and were stubbing way too many things.
While doing that we pass stock changes to the service but we
lazy-evaluate them. This way we don't fetch all this data from DB when
it might not be used due to an early return.
Also, this makes it possible to save the stock-related logic for later.
Finally, when changing things to rely on `#initialize_order`'s boolean
return value I noticed though, that we were evaluating
`proxy_order.order` too early. When instantiating the service object it
won't exist yet.
In the current version of Webpacker all assets are kept under a new path called `app/javascript`. This is a really stupid name, as it can contain all kinds of assets that are *not* javascript at all, like SCSS. It's common practise to rename this to something sensible like `app/webpacker` or `app/frontend`...
This was activated with a feature toggle. But when we re-implemented the
feature toggles, we accidentally broke this one and it hasn't been
active for two months. Nobody complained and it doesn't seem to be
needed while developers are keen to remove instance-specific
customisations anyway.
If the current tax rates are badly *misconfigured*, and an included-tax rate is being applied but a *default* rate does not exist (there are validations to stop this case from occurring, see DefaultTaxZoneValidator), this line can throw an error. This situation will not actually arise in production, but can happen fairly easily in dev or with staging data when switching datasets, and when it does it's kind of annoying.
Note: the logic in the check here is still good; if there's no default tax rate we check if the order's tax zone matches the zone for the current tax rate, which is correct.
There's a race condition here that means the order's address is not always present when the email is first sent, but it *is* present shortly after. The fix in this commit is a temporary solution.
