- use variables for colors instead of values
- trailinf line at the end of file
- new line after each declaration
- 2 spaces of indentation
- avoid qualifying elements in selectors
- prefer lowercase in hexa color
by default, `input[readonly]` is styled as disable one. Using flatpickr with these disable inputs need to be customized. By clinking on it, it opens the datepicker widget.
Before if you did a bulk product update there was an error:
> TypeError: Cannot set property 'variants' of null
It only seemed to happen if pagination was required i.e. more than 15 products. It seemed to be happening because the default sort order on the products API endpoint which handles the bulk update is 'created desc' but 'name asc' on the /admin/products controller.
Another fix included here is for the sorting direction arrows which were not displaying on the admin products page. The sorting arrows require the sorting expression to be on the :sorting var instead of :q.sorting.
Fixes#6399
This moves a step closer to having a simple and straightforward way to
configure the app's mail delivery which doesn't require to be a nuclear
engineer to troubleshoot mail issues.
It happens way too often that servers have mail config broken when
restarted or redeployed and it takes too much brain power to fix it. No
doubt; it's way too complex.
I chose to leave this page's form fields but "Send mails as" as
read-only. This other field is still used by instance manager to
troubleshoot mail issues.
A deployment to the French server failed because a translation contained
an apostrophe `'` and we were rendering it without escaping in
Javascript. We don't have that problem and avoid other issues by using
the javascript translate function. That way the error message is
translated in the browser with the user's language and we don't have to
do any additional escaping.
On some Iphones the modal wouldn't fit and there were line breaks
between the input fields. The inputs are now stacked vertically on small
screens so that there is still plenty of space for large numbers in the
quantity fields.
Line items were initialised with undefined quantities which makes it
impossible to distinguish between the initial unset quantity and a user
entering an invalid quantity. When a user changed order cycles, all
quantities are reset and the UI displayed the quantity modifier buttons
instead of the Add button.
Initialising with the valid quantity 0 helps us to display the Add
button in that situation.
When the user entered a number beyond the stock level, the browser was
correcting that to the max number which is very helpful. But Angular was
setting the model to undefined which removes the item from the cart.
Deactivating Angular's max behaviour let's us set the value ourselves
which is then used in the cart.
If the user entered an invalid quantity, Angular set the model to
undefined and we removed the input field to show the add button. That
makes it impossible for a user to see what the maximum quantity to enter
would be. For example:
- The variant has a stock level of 5.
- The user enters 7.
- Angular sets it to undefined.
- The input field disappears.
- The user is startled and doesn't know how to proceed.
But now we hide the input only if it's deliberately set to zero.
The user can now type anything into the quantity field and some of it
may not be valid. These safe guards ensure that the buttons still work
even if the quantity is undefined or out of range.
Angular guards against the value being out of range but that has other
side-effects. We want to be able to de-activate some of Angular's
behaviour.
