Steps to follow:
- Switch the current lang to mongolian
- Go to a list view
- Add a custom filter on a date type field
-> locale() locale mn-MN is not loaded from moment locales!
Cause of the issue
- moment.js tries to use the mongalian locale but it is not present
Solution
Add the mongolian locale (from moment 2.29.2)
opw-2829233
closesodoo/odoo#90704
X-original-commit: 179a4b2f31d8e2e0e2be308917725a05c5b78058
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
This owl update is significant: it introduces a change in the way
components are rendered: now, child components check if there is a
current rendering somewhere in their ancestors. If this is the case, the
rendering will be delayed. This prevents lots of issues where a
child components may be in some kind of corrupted state after some state
changes.
closesodoo/odoo#88572
X-original-commit: 93710d082bf860d0ea576fe99db9506af9bb42b0
Related: odoo/enterprise#26135
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Géry Debongnie <ged@odoo.com>
Currently when we click on external links from a PDF opened in our
PDF viewer, you are redirected to the link, means you are leaving
the record which is not ideal.
With this commit, external links in PDF document will be opened in
new tab so that the opened record is not lost. For that we need to
change the default option of the pdfjs lib, because we cannot pass
this parameter in iframe (link of the documentation is available in
task pad). For that, we changed the value of 'externalLinkTarget'
from 0 (which sets target to NONE) to 2 (which sets target to BLANK)
in 'getDefaultPreferences' function.
taskID-2752002
closesodoo/odoo#84594
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since Odoo now accepts ES2019 code anyway, I think that this polyfill
can safely be removed, to reduce assets size.
closesodoo/odoo#85800
Signed-off-by: Samuel Degueldre <sad@odoo.com>
This commit introduces the "useWowlService" hook. This hook allows
Owl components that use the legacy env (not the one of the
webclient for instance, typically called the "wowl" env) to access
services from the wowl env. Its API is the same as the classical
"useService" hook.
closesodoo/odoo#85769
Signed-off-by: Géry Debongnie <ged@odoo.com>
Following new policies in terms of product design-language, this commit
will partially revert 546477d reducing the number of `oi` icons.
It will also improve rendering when icons are rendered at our default
font-size (13px), avoiding blur effects when icons use thin lines.
Since fontAwesome will coexists with `oi` longer than expected, the
commit will also review size utility-classes in order to get consistent
result when used in conjunction with fa's ones (notably `fa-lg`).
Part-of: odoo/odoo#85651
ENCOUNTERED ISSUE:
Unable to close a dropdown with ESC when the focus has been given
to a select element inside the dropdown.
TO REPRODUCE:
i.e. in the searchpanel, go to "FilterMenu > Add Custom Filter" and
open the field select element.
Press ESC once: the field select element closes just fine.
Press ESC a 2nd time: we expect the dropdown to close but nothing occur.
REASON EXPLANATION:
Since 84715436d our Dropdown component uses the 'dropdown-menu'
bootstrap class.
But under some conditions bootstrap stops the keydown events propagation
when the event.target matches the query selector '.dropdown-menu'.
IMPLEMENTED FIX:
This commit refines this selector directly inside the bootstrap library.
This is admittedly a bad practice but:
- this modification is trivial and sensible
- the modified selector is only used locally
in the bootstrap's 'dropdown.js' file
- the added test should prevent the lost of
this customization in the future
task-2764821
Part-of: odoo/odoo#84969
Chart.js did badly compute the graph canvas container height (width) by
using clientHeight (resp. clientWidth) that may be rounded up by the
browser. This leads to the appearence of a useless scrollbar in the
graph view and makes it flicker on some update.
closesodoo/odoo#84476
X-original-commit: 6bceae94619da9f4943cbc1e58844fdbe0215802
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit introduces our own icons meant to be extended over time and
to coexist with FontAwesome 4.7.
The goal is to provide a wider range of icons specifically made for our
UI and cover FontAwesome's lack of iconography for specific businesses
and functionalities.
Classes' names are available in our documentation website and the SVG
source files can be found in our `design-assets` repo.
This new bundle mirrors fontAwesome architecture; icons are rendered
applying classes to standard HTML flow-tags (normally an `<i>`), eg:
`<i class="oi oi-odoo"/>`
This implementation applies size and alignment rules directly to the
`:before` pseudo-element rather than to the class itself. The aim is to
prevent misalignment when icon classes are applied to buttons and other
UI elements, eg:
`<button class="btn btn-success oi oi-arrow--right"/>`
Note: Despite being technically feasible, this approach is highly
discouraged and should be avoided.
This commit also introduces utility-classes specifically made for
our UI. In detail:
- Fours sizes: '.oi-small', '.oi-normal', '.oi-large', '.oi-larger'
Relative to the parent font-size, these classes cover a range from
`0.8em` to `1.77em`. Each size has been designed to match our default
text-fonts in the attempt to compensate font-icons common alignment
issues (https://css-tricks.com/icon-fonts-vs-svg/#aa-positioning ).
- Responsive classes: `.oi-[screen]-[icon_size]`
Responsive classes mirror Bootstrap ones and can be combined to
achieve different size results at specific resolutions, eg:
`<i class="oi oi-studio oi-larger oi-md-normal oi-lg-small"/>`
- Fixed width: '.oi-fw'
Mirrors FontAwesome 'fa-fw' by setting icons at a fixed width.
Our implementation adapts according to size and responsive classes.
- Animations: '.oi-spin', '.oi-pulse'
Mirrors FontAwesome default animations.
This commit is part of v16 overall restyle (task-2704984).
enterprise: https://github.com/odoo/enterprise/pull/23848
task-2745275
Part-of: odoo/odoo#83501
This commit "forks" fontAwesome into `src/libs` in order to allow
further customization.
Part of v16 overall restyle (task-2704984).
task-2745275
Part-of: odoo/odoo#83501
This commit moves the ZXing library (used for QR/Barcode decoding) from
`web_enterprise` to `web` so it can be reused in other modules.
Change motivated by odoo/odoo#78204closesodoo/odoo#80014
X-original-commit: 8c81e2f7c614c55247138278ffdf914e2866ec41
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Currently, if a test fails there's very high chances the DOM will not
be clean, because qunit doesn't have good cleanup APIs. This means a
test failure will always be prefixed by a dump of the page DOM which
is just confusing and makes it hard to find the actual error.
This change updates the OdooAfterTestHook handler to:
* Receive the `Test` itself, instead of adding more information to the
synthetic object it currently receives.
* Only show the leftover DOM if the test otherwise succeeded.
* Do the entire reporting via `pushFailure`, rather than having
duplication between an explicit `console.error` and a test failure.
* Update the QUnit.log handler to
- not show `undefined`
- try to improve readability by removing the bracketing and quoting
closes odoo/odoo#75951
Forward-port-of: #75939
X-original-commit: 8bceac8032f48ae77e8a2c0c038f3bc26489e0ac
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
In new version of chrome (92) or firefox when some fonts (eg. courier)
were used:
- either the page would never finish loading (odoo 13 and below)
- or the text would in this font would not be shown (odoo 14 and over)
This was solved in pdf.js whith this commit:
https://github.com/mozilla/pdf.js/commit/8805614a03
And this PR is backporting that commit in 12.0 version up to master.
opw-2621405 opw-2613412 opw-2620186 opw-2618225 opw-2616690 opw-2615502
opw-2616249 opw-2615144 opw-2613969 opw-2613793 opw-2618129 opw-2617736
opw-2622506 opw-2614508 opw-2620883 opw-2622105 opw-2620863 opw-2615326
opw-2622842 opw-2620220 opw-2622842 opw-2620220 opw-2615346 opw-2615026
opw-2618389 opw-2619382 opw-2613286 opw-2621730 opw-2613412 opw-2622029
opw-2620625 opw-2622311
closes#75020closesodoo/odoo#75057
X-original-commit: d3feb26c8923cfde60894058f06dc2c2a8be05f5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
* Remove AST in favor of pure Pyhon. This should make it easier for
developers to understand and create new directives because they do not
need to know AST.
* Remove `t-call-options` as it has been merged into `t-options` for more
consistency. Support for t-call-options is retained.
* Use generators for lists. This increases performances as the rendering
can be sent directly without having to wait for the creation of the
entire list.
* Optimize expressions runtime computation by pre-computing the static
parts.
Example:
'<' + 'div' + '>' + '<' + dynamic_value + '>'
Now compiles as:
'<div><' + dynamic_value + '>'
A note concerning the attributes which I will probably need to take a
look at in the vdom version: the Python version has to process attf in
order to stringify individual elements, and separately stringify the
attribute value so it gets forcefully escaped even if it's
markup-safe (because markup-safety and attributes-safety are
different).
The first should not need to be performed on the JS side, because
Markup can not overload addition, therefore in JS String + Markup is
String whereas in Python it's Markup (and the String gets forcefully
escaped). In general, js!markup is currently much simpler than
py!markup, both by necessity (can't overload operators) and
simplicity (we might want to overload some of the operations
e.g. String#replace, but that's complicated and it's not been strictly
necessary for now).
Also wrt Markup / _Markup: `class` ctors can only be invoked with
`new` meaning they can't be used as template strings or regular
functions. Here `class` is useful to avoid the mess of calling the
super's constructor explicitly (which may not even be possible for
`String`), however it means we need a facade function to support our
use-cases.
Also update `utils.sprintf` to be Markup-aware: if the format string
is a Markup object, interpolated values get automatically escaped (if
necessary) and the result remains a Markup object.
If we need to perform explicit instance check we can always set
`Markup.prototype = _Markup.prototype` (I think), however in theory
that's not necessary: there are protocols in place for the relevant
pseudo-escaping operations and they ought suffice.
qweb/js divergence from qweb/py
===============================
Unlike qweb/py, qweb/js will *not* return a Markup object. That is
because in js a primitive `string` and a boxed `String` object don't
match when typechecking, and while `markup instanceof String` passes,
`typeof markup === 'string'` does not.
The overwhelming majority of string typechecks are the latter: there
are all of 6 `instanceof String` in the entire codebase, all in
dependencies, while there are hundreds of `typeof $X === 'string'`,
several of which get fed the output of template rendering
e.g. `jQuery.parseXML` or `AbstractView#init` (some widgets will
render a template then use it as the `arch` of a subview, so
`viewInfo.arch` can be the output of a qweb template rendering). This
makes for very annoying and somewhat gnarly debugging.
Plus jQuery in particular really doesn't like being fed a boxed
String, as it will interpret said boxed string as an array, and assume
it's an array of DOM elements to wrap, leading to a rather strange
jQuery object as output. Since feeding the result of a template
rendering to jQuery is a major use-case in non-vdom widgets... that's
a bit of an issue.
For the same reason while `_.escape` is `Markup`-aware, unlike
`markupsafe-escape` it does not *produce*, though it is
`Markup`-transparent.
Two internal warnings are features which literally are not (entirely)
implemented, the tests can't be fixed to avoid them. Also augmented
the log messages with which test triggered the log, as it's very hard
to debug the issue otherwise.
As for the qweb debug mode warning, there's no way to disable it
easily because multiple tours explicitly opt into debug mode (with
good reasons), so it's not enough to just bypass the `mode` setter in
the test setup helpers (test_main in POS and main_tests in web), there
would also need to be special workarounds in the 4 modules which set
`owl.config.mode` based on the session's debug mode.
I don't know that this warning is even useful, it defaults to `false`
so the only situation in which this would be relevant would be for a
third-party to use Owl *and* explicitly enable the debug mode *and*
forget to remove it when deploying to production *and* look at their
console.
- Error handlers have been simplified, handlers don't returns functions
anymore and take 3 params: env, uncaughtError and originalError.
- Source maps have been reintroduced.
- The original error message and name are now concatenated to
the "wrapper" error ones.
closesodoo-dev/odoo#895
Related: odoo-dev/enterprise#154
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit is the first phase of the conversion of the web/ JS
codebase to the owl framework. The impact of this commit is two-fold.
First, it rewrites the framework part of web with a new system of
services and registries. Services allow to execute code (e.g. do rpcs,
setup things) before launching the application. They can also expose
an API to be used by other parts of the application (e.g. a notification
service would expose a function to display notifications). Services are
often a good extension point for external modules that want to execute
code at webclient startup. Registries offer another way to extend the
application. They provide well designed extension points to add
elements/behaviors from the outside (for instance, to add a systray item,
an error handler...).
Second, this commit initiates the conversion of the webclient to owl
with a top-down approach, around those notions of services and registries.
The root of the web application is now an owl application. Among others,
the WebClient, ActionManager, Navbar, UserMenu, DebugManager, Dialogs,
services (e.g. notification, ajax...) have been converted to the new
framework/architecture.
Legacy views and client actions are still supported (and used). They
will be converted in the next months, and at some point, the support
will be dropped.
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
This commit updates owl to the latest release. It only contains a
fix to better handle t-calls in nested t-slots
Release on github: https://github.com/odoo/owl/releases/tag/v1.3.1closesodoo/odoo#71989
X-original-commit: 5c66f47e849144f79ecf9dd63d51529be3510aff
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit updates owl to the latest release. It contains an
improvement: the support for the t-tag directive, which allow us
to have dynamic tagname in templates
Release on github: https://github.com/odoo/owl/releases/tag/v1.3.0closesodoo/odoo#71775
X-original-commit: a1c173ef6d3808a7c70b7e758e7e65fc6a40b2c7
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit update owl to the latest release. It only contains a small
fix on the order of lookup for the t-component directive.
Release on github: https://github.com/odoo/owl/releases/tag/v1.2.5closesodoo/odoo#70972
X-original-commit: 67e706b76fefa7eaff12722a4bda6fa4ce497eaf
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Some features of the PDF.js library doesn't work in the
webview of the mobile apps.
Initially 'window.print' is defined as an empty function in
webviews unlike browsers where it is already ready.
After that, PDF.js needs to monkey patch 'window.print' and
saves a reference to the original definition, which is not
yet fulfilled in by the mobile app (Java part).
So the print of PDF.js doesn't work in webviews and end
users will need to download the file before printing it.
Regarding the Download button, the 'download' attribute is
not supported by the webview as you can see in:
https://bugs.chromium.org/p/chromium/issues/detail?id=432414
As there's many ways to download a file in Odoo it's not
a big deal to simply hide it in PDF.js.
Because it's quite complicated to fix this, we decided
to hide the features that don't work (Download / Print)
or don't make sense (Open file).
Note that a refactoring is already in progress in order to
avoid to patch this library in master.
closesodoo/odoo#70110
Task-id: 2200168
X-original-commit: 39225827035efe11cdc90b2a7f1ae1f24a54b136
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: rfr-odoo <rfr-odoo@users.noreply.github.com>
Nicolas Bayet