| Age | Commit message (Collapse) | Author |
|---|
|
* website_form, debian
Our old library for datetimepicker for bootstrap 3 is deprecated and
an updated version is developed by the same team under the new name
"tempusdominus", for bootstrap 4.
The lib is imported by taking the *unminified build* JS and the *src*
scss. Odoo is also bundling the lib better by putting the scss file
in both backend and frontend assets instead of only in common (so that
the scss is compiled differently for the frontend and the backend).
Note: the lib also needed to be patched inline to solve a bug at one
line.
|
|
Before this fix, there was an issue when you changed the value of
a datetime field by editing direclty the input (without using the
datepicker popup).
If this value was equal to the offset of your timezone,
the new value wasn't saved. The problem was that no event was
triggered by the 'bootstrap-datetimepicker' lib because it
considered that the old datetime and the new datatime were the
same...
In odoo JS, we always manipulate UTC moment objects and we
manually add the timezone offset at rendering (we mainly do that
for testing purposes). When the offset is added, calling format()
on the moment object doesn't convert the datetime to the browser
timezone because it's flagged as being UTC.
The datepicker lib creates moment objects in the browser timezone.
So comparing the ones it creates with the one given by Odoo is
like comparing apples and oranges, and it gives wrong results
when the datetimes differ by the exact timezone offset. So in this
case, no 'datetime change' is triggered by the lib.
We could fix this by wrapping moment objects into some kind of
OdooDate class and stop manually adding the timezone offset, but
this would involve a refactoring that can only be done in master.
Instead, we prefered to patch the lib to ignore the comparison
between UTC and non-UTC objects, as this is the safest way we
find to fix this issue in stable version.
|
|
There were two main problems with the datepicker since the lib was
updated:
- it appeared broken in the search view "Filters" menu
- it did not overflow the parent which scrolls
Indeed, before the update, the datepicker was placed in the <body/>.
Now this is a lib option. Unfortunately, the option is broken (I don't
know why they broke it since it worked before the lib update...). As the
lib does not expose its internal functions, the only found workaround was
to patch the lib code itself.
opw-745311
opw-745625
|
|
from 3.0.3 to 4.17.42
|
|
lazily load locale
|
|
|
