I'm not sure why, but the pre-compiling of assets triggered Rails to
render `style="..."` instead of `style='...'` in this case. But when
assets are compiled on-demand, we get the single quotes. So I changed
the spec to be agnostic of this detail. We actually just want to know
about the link and its href.
We use Webpacker *and* Sprockets to compile assets. I hadn't realised
before that we were still compiling lots of JS with Sprockets. So even
after we pre-compiled assets with Webpacker, we still needed to compile
more assets on the first page visit in test environment. That made some
time-critical specs, like caching specs, fail.
This approach pre-compiles all assets but only in CI. Running the
compilation task adds 6.5 seconds even if there's nothing to compile
while the previous Webpacker call returned instantly. So I decided to
run the compilation only on CI and activated on-demand compilation to
the test environment.
Time-critical specs will still be flaky without pre-compilation locally
but I figured that a fair trade-off for faster specs in general. During
most development, we don't need all assets to be compiled and it's
faster to just compile what's needed. And running a time-critical spec
twice solves the flakiness.
Add new text key admin.order.edit.additional_tax_included_in_price
Add spec file for additional tax display. Add new trait for enterprise fee and calculator factory
Price is actually an association with lots of custom methods to make it look like a field, and so changes were ignored.
Now this issue is fixed, perhaps it should be moved to a concern..
Note, there are other delegated fields: product name and description may be assigned from the variant. But there's no hooks to save the prroduct, so I didn't include it when checking for changes.
They were already counted as changed by the javascript, but didn't have a 'changed' class to indicate it.
The reason they are 'changed', is because the dropdown has no blank option, and is forced to select the first item in the list.
This is purely to cover the case of invalid data, but should help a lot when debugging data issues. I don't think it's any less efficient, because the extra 'classList.toggle' calls don't do anything on unchanged fields.
- Changing producers, category and tax category, done in 15ee4f6
- Updating Unit value, done in 49226ff
Removes comment about errors for empty variant_unit_name
I think this was done in commit f05d27b
Would you agree @dacook?
- presence: true is redundant since Rails 5.0 BUT applies
with new default config of
belongs_to_required_by_default to true.
Lots of files with belongs_to_required_by_default = false
(backward compatibility).
So: deleting this setting implies to adding optional: true
Most production servers don't use the source locale `en`. Even if the
default language is English, they use a local variant like `en_AU` or
`en_GB` to customise some of the translations.
However the environment is configured, the app should always fallback to
`en` if no other translation is available.
This was another large file, potentially causing a bottleneck.
All the order setup is duplicated from the other file which is a bit of shame, but I think it makes sense.
The orders file is too big and causes a bottleneck for parallelising specs.
Maybe they should be merged with the above specs, but I'm not familiar enough to know for sure.
This was actually shown in one place and represents a user-facing
change. But you weren't able to edit the field which means that only
very old enterprises would have had this field set and were not able to
change it anymore.
I searched au-prod and found the following values in the database:
- "Friday 31st January"
- "From 4pm, Monday 30 September"
- "From 5pm-7pm Monday"
- "Saturday 27 April 12noon"
- "January 31st/February 1st"
- "Saturday 1st February"
They seem specific to a certain order cycle and have no value as
fallback any more. Seems safe to remove.
