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>
Add a new parser in the ace for the qweb highlight. This makes it possible
to visualize the qweb tags and the part of code.
Used in the website and in xml fields.
closesodoo/odoo#69609
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
The range date lib would open the selector on focus.
This is a behavior we don't want in lists, but want to keep in quickedit
forms.
Task id: 2492914
closesodoo/odoo#68390
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
A previous commit (934e0896160272542dd00) modified QUnit to make sure we
can display better tracebacks in debug=assets mode. However, this
commit did not apply to errors coming from failing promises.
To fix this, we can simply keep a reference to the error in that
specific case.
closesodoo/odoo#67048
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Warning: this commit savagely patches qunitjs sourcecode. I know... I
feel bad.
Since we updated the way debug=assets work, we have a new problem in the
qunit test suite: the tracebacks displayed by QUnit are relative to the
bundle file, not the original file, which is annoying in practice.
There is really no good way that I could find to integrate with QUnit to
perform that task, so I had to do it the ugly way: modify QUnit from the
inside to use the StackTrace library to annotate the traceback with the
proper information.
closesodoo/odoo#66771
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The recent change in the way debug=assets works (which now bundles all
files in a bundle instead of serving them statically) had a negative
impact on the stacktrace displayed in the error dialog in debug=assets:
it now display the bundle/linenumber instead of the actual file/line
number.
This is not a huge deal, most of the time, because the errors displayed
in the console display the correct information, and the debugging
process should work as before. But it can certainly be annoying in some
cases.
With this commit, we use the Stacktrace.js library to dynamically fetch
the sourcemaps and to decorate the displayed information with the
correct file and line numbers.
closesodoo/odoo#66318
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In a4d170ad9 there were some improvment to not show event totally empty
on the day calendar view because of different style (font + padding).
The lower part of the text was still a little cut, this commit try to
improve this for week and day view mode by removing 5 additional pixels.
opw-2422700
note:
Also fix the fc-short for fullcalendar Odoo, we had this 2019 change:
fullcalendar/fullcalendar@e879c43
that made it not working without title (odoo use case), in 2020 it was
reverted when refactoring for 5.0:
fullcalendar/fullcalendar@7c7ce1eclosesodoo/odoo#66109
X-original-commit: b856d312be19b0fdf636600a76c4d9b427eedb7c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This commit update owl from 1.2.3 to 1.2.4, and
introduces a few fixes for code that was broken (because it accesses
private owl values)
Note the fix for the test menu code is interesting. Before this commit,
the handler for the click on the home menu component was not called, so
the click had a side effect: it modified the url to its href, which
caused the action manager to load the next application, even though the
home menu was not mounted.
With the update to Owl, this is no longer true: the handler is called,
and call preventDefault on the event. Because of that, the url is not
changed. However, since the home menu is itself not mounted, it cannot
communicate to the web client that we should load the next app. This is
why it was broken. The fix is simple: we actually make sure that the
home menu is displayed before clicking on the app menuitem.
closesodoo/odoo#65906
X-original-commit: 2385e58d76aa5e4bca0fc6d76ecedc7de5fd4267
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Issue
- Install "Project" modules
- Set user language as "Hebrew"
- Go to Project and open any project
- Go to 'gantt' view
- Try to resize a task
Everything is reversed.
Cause
Jquery-ui 'resizable' widget do not manage RTL feature.
Solution
Update the the `position.left` props according to the language
direction (LTR or RTL).
opw-2367692
closesodoo/odoo#61082
X-original-commit: 1f318d7c7aa66287c8756a89b49293b4e8c2217e
Related: odoo/enterprise#14507
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
On safari with apple device in belgium timezone, this code:
```
x = new Date(2020, 2, 28, 2)
x.setDate(29)
```
returns:
> Sat Mar 28 2020 02:00:00 GMT+0100 (CET)
> Sun Mar 29 2020 01:00:00 GMT+0100 (CET)
This is not consistent with any other combination of OS and browser
tested, where this code would return eg. for chrome on macOS:
> Sat Mar 28 2020 02:00:00 GMT+0100 (Central European Standard Time)
> Sun Mar 29 2020 03:00:00 GMT+0200 (Central European Summer Time)
In most instance, this is not an issue, but for country with midnight as
Daylight Saving Time (DST) change, this is an issue, because the Tempus
Dominus calendar widget will have a duplicated day which might eg. make
a month totally not usable.
This issue can eg. be reproduced in Lebanon timezone at this address:
https://tempusdominus.github.io/bootstrap-4/Usage/
Going to the month of April 2020, an error happen because to get the
first day of the week of 1st April, we do:
```
this._viewDate.clone().startOf('M').startOf('w').startOf('d');
// .startOf('M') => Apr 01 00:00:00
// .startOf('w') => Mar 28 23:00:00 (safari bug)
// .startOf('d') => Mar 28 00:00:00
```
which gives us the wrong day (28 instead of 29) which causes an error.
Other report of the issue:
- https://www.donedone.com/timezone-specific-browser-specific-datetime-bug-2014/
- https://github.com/date-fns/date-fns : issue 571
- https://forum.mobiscroll.com/t/issue-with-invalid-dates-range-script/108
opw-2271482
closes#59786closesodoo/odoo#59908
X-original-commit: 112267d62544c56acfdcef96727c32c314c15f16
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
After each test, a check is done that there is no leftover in the
DOM. If there are, the suite fails, but there is no indication on
the test that left elements in the DOM.
This commit logs that missing information. We also stop dumping
the DOM when this happens, as it was rather creating noise than
providing useful information (the remaining elements are still
logged though).
closesodoo/odoo#58806
X-original-commit: 598d036b59012af0a95894d759fe3b6276fc8ccb
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Mainly transifex issues but also some errors found through 'grep' checks.
Fix typos and obscure english strings in xml contents, fields strings/helps, some docstrings, ...
ensuring correct translations base (and fallback when translations isn't available).
closesodoo/odoo#57276
X-original-commit: 4214f05d454bca2b60fda3a288d529c098e84f77
Related: odoo/enterprise#13053
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Show digital signatures items in PDF.JS preview even if the signature
verification is not implemented.
From discussion in mozilla/pdf.js this is like this because they don't
want to give the user a false sense of "the digital signature has been
verified" when it has not, but for a preview of the PDF this seems
misleading, in any case the user can have a full fledged PDF reader and
know if the document is well signed then.
https://github.com/mozilla/pdf.js/ issues/4743
opw-2287840
closes#54922closesodoo/odoo#54988
X-original-commit: 820128385c523f562b9ee82698c81daa63149bb7
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit, defining a extension of a template by using the
combination of directives 't-name' and 't-extend' ignored potential
extensions that could have been defined beforehand.
For instance, let's assume the following templates.
```xml
<t t-name="a">
<div><span>1</span></div>
</t>
<t t-extend="a">
<t t-jquery="span" t-operation="replace">
<span>2</span>
</t>
</t>
<t t-name="b" t-extend="a">
<t t-jquery="div" t-operation="append">
<span>b</span>
</t>
</t>
```
Rendering template "b" displayed "1b" whereas we would expect "2b".
Moreover, when the extended template is itself an extension of
another template:
```xml
<t t-name="a">
<div><span>a</span></div>
</t>
<t t-name="b" t-extend="a">
<t t-jquery="div" t-operation="append">
<span>b</span>
</t>
</t>
<t t-name="c" t-extend="b">
<t t-jquery="div" t-operation="append">
<span>c</span>
</t>
</t>
```
Rendering template "a" displayed "a", template "b" displayed "ab",
but template "c" displayed "ac", whereas we would expect "abc".
With this commit, other extensions done to a template are kept when
a new extension is defined. It relies on the templates order, and
takes into account all extensions that have *already* been defined.
This is exactly how the new qweb inheritance mechanism (using
't-inherit' and 't-inherit-mode') behaves.
closesodoo/odoo#54315
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
During TempusDominus autobinding to fields matching its default classes
(like `.datetimepicker-input` used by our DatePicker widget) and no
config was previously provided to the library (like when we disable it
on mobile), an unsafe access to the config's `_options` property results
into an error as the config is `undefined`.
This commit fixes it by first checking for config existence before
attempting to access its property.
Note: as this is a fix inside a library, a comment is added to make
clear. Also similar fixes where already done in the same file.
opw-2242880
X-original-commit: fe1f7c3e361bbd249b4025a464c546f478b6e989
This lib is also used by the Gantt view, so we move it to the
common basis between web_editor and web_gantt, which is web.
Part of task 2205607
closesodoo/odoo#51606
Related: odoo/enterprise#9740
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Samuel Degueldre