Replace the t-raws used for the end-of-quiz message by t-outs.
This requires marking the two subfields of `quiz/submit` as Markup,
rewrite the method in a more modern style while at it.
Also update the tour to ensure that the message is indeed inserted as
markup, reset the users' karma to a known value to ensure the
motivational message is predictable.
* direct product attributes seem to not be necessary at all,
`list_price` and `price` are just numbers
* mark `description_sale` as markup-safe at load
* mark ribbon.html as markup-safe at load
* mark embed code value as safe on rendering
Mark the fragments as markup-safe after fetching them.
Also make _render private (don't see any reason for it to be publicly
accessible), and avoid unnecessary intermediate enc/dec in it.
Update `_deletePage` to mark `.text` as markup-safe, and modernize the
code base: the outer promise seems useless, and so does the
`cancel_callback` of the dialog.
Using `sale_product_matrix`'s tour as `product_matrix` doesn't
actually have any test for this.
Remove t-raw from the product_matrix(.extra_price) template, by moving
the formatting to the client side (unclear why it was done by the
server in the first place).
Also fixes a bug where a negative price_extra would have *two* `-`
signs: one before the currency, and one after the currency: the price
being formatted should be abs'd to avoid a negation being generated by
the monetary formatting. Also uses non-breaking spaces everywhere
where the server-side formatting mixed breaking and non-breaking
spaces. Keeps from the original the peculiarity that the extra price
should always have a sign positioned before prefix currency signs.
Also changes the calling conventions of `product_matrix.extra_price`:
instead of being called with a formatted `price` it's now called with
the entire cell object.
Replace t-raw by t-out when outputting the chatter message.
Mark message body as safe during preprocessing: messages from the
portal chatter are automatically escaped when
posted (`/mail/chatter_post` assumes the message body is plaintext,
and escapes it before formatting it based on newlines, maybe one day
it'll accept markdown) while messages from the backend chatter are
"HTML-light" and should be sanitized.
And convert the `t-esc` in the template to `t-out` while at it.
So this was a bit of a bummer initially, the PopoverWidgetField gets a
pile of JSON as its value (so from the server), and that pile contains
a template name (optionally) and... the template context,
basically. For leadDaysPopOver the issue was some of that context is
supposed to be rendered HTML to straight inject into the template,
marking that as HTML-safe would be a bit of an issue (having the JSON
specify which parts of the value it returns are HTML-safe being a bit
of a conflict of interest).
However turns out the thing is way over-complicated and
over-engineered: `lead_days_description` necessarily has a very
regular structure owing to being injected as a set of table rows, so
the various overrides to `_get_lead_days` just make their own lives
complicated by formatting the values they want to return into table
rows matching the format of an unrelated template.
Instead we can change the signature of `_get_lead_days` so the
"description" is a list of values to inject in the table (list of
pairs, each pair matching the corresponding columns of the table). The
template can then take care of formatting those values into table rows
the usual way, removing the need for any injection of raw content.
This also makes for better / clearer translation strings.
Remove t-raw of alert messages:
* Add alert testing to one of the existing tests.
* Transform widget data straight in `_fetchWidgetData` so the widget
itself only ever sees the "proper" shape of things (to come), this
includes the existing parsing and reformatting of `wallet`, as well as
the new wrapping of all alerts' `message` in a `Markup`.
Note: conditional updating of `alerts` because while the endpoint
actual always sets it, test data doesn't necessarily do so (?).
Mark the message body as safe pretty much as soon as we receive the
message from the server:
* when receiving message-type notifications
* while loading history
Also reorder history loading a bit while at it:
* convert willStart to async
* immediately reverse & wrap history right there, seems unnecessary to
wait until willStart since `reverse()` works in-place anyway
* when loading messages into the thread, `_.each` seems unnecessary,
Array#forEach will do fine
Need to check and mark legit uses of HTML as Markup. Also fix some
title formattings which are not great (mostly around translations) and
de-escape titles which don't need to be escaped anymore.
Requires markup every markup-using tip content as Markup. Would be a
nice occasion to migrate everything to a markup-safe markdown I think,
especially if we could migrate the translations so we don't lose them.
Add HTML fields support to kanban view (currently bespoke but maybe it
should be done via `format`), and remove t-raw for HTML fields there.
Also just strip some t-raws which were completely unnecessary to start with
Descriptions which need to use markup should be explicitly marked as
such. Update examples test to check that both Markup and String
descriptions work fine.
`escFormat` had to be modified quite a bit and ended up requiring
being its own Markup-adjacent type: if the `sprintf()` result is wrapped
in a `Markup`, then what happens is we first decide to escape because
the object returned by `escFormat` only has a `toString()`, then that
blows up because `toString` returns a non-primitive object and the
regex used to implement `_.escape` is very very unhappy.
`escFormat` could return a `Markup` object but then it wouldn't be
lazy anymore which would rather miss the point.
Therefore implement `[_.escapeMethod]` on the thing, such that it
doesn't get escaped, because it's safe (ish).
Also as a result the icons probably don't need to be markup-ed. Oh
well shouldn't really matter.
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.
Inserted content comes from markup so it's safe by
definition. Apparently missed it when cleaning up the server-side
templates.
Also remove the useless `ref_content` local, that's what `0` is for.
Before this commit, for a subcontracted product with reserved available
tracked components, if at least one component is recorded but not all,
the "Record components" button isn't available anymore.
How to reproduce:
- Create a product and create a subcontracting BOM for this product;
- Add a tracked component for this product;
- Add some qty. for the tracked component in the subcontracting loc.;
- Create a receipt for the subcontracted product (for demand qty. more
than 1) with the subcontractor as partner and confirm it:
=> The "Record components" button should be visible.
- Record a part of the demand qty. then click on "Continue", then on
"Discard":
=> The "Record components" button is now hidden.
It's because the button is hidden if all the MO are done or to close
(they are) and if all the tracked move lines have a SN/LN (they have as
they are reserved).
task-2604728
closesodoo/odoo#73991
X-original-commit: 392bc27c0ef0bc238a7eac98497b293622f0fe1d
Related: odoo/enterprise#19756
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When the cost of a product is set to a value below the currency rounding
the average purchase cost price will be wrongly set to zero.
It can happen for product sold in large quantity, that the cost of one product
must be smaller than the smallest unit of currency.
Instead of doing the zero check with currency precision using the
product price precision, which is the one used for the `standard_price`
fields, makes more sense and fixes the problem.
opw-2601121
closesodoo/odoo#73985
X-original-commit: 251be6b943ea8c3f274bb0863d0af3f7c6b8d10d
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Currently, the payment method lines are only ordered
base on their sequences. This could lead an issue if
the sequences are all the same, where they would be
returned in a random order.
Add a second ordering on the id to avoid such random
issues.
closesodoo/odoo#73984
X-original-commit: ac700908a80f67e5fd15fa242cc111d57abd4aa9
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Nicolas Viseur <vin-odoo@users.noreply.github.com>
There is an issue when computing the suitable payment token ids making it impossible to
open a payment for a user without access to payment acquirers.
Also, the default computation of payment token was wrong and would never set it
correctly.
The compute for the method lines in payment would not filter unavailable acquirers
line and thus select them by default if they were first in line.
Also fix an issue with the ordering of payment method lines
X-original-commit: 73410a0fd76a70e1730883d35b79fc603741b59c
Before this commit, the implementation crashes when the ancestors of a
record contain non-accessible records. This fixes the code to avoid it
to crash.
We also make the semantics of hierarchical searches more consistent in
this case: searching with operators 'child_of' and 'parent_of' returns
the subset of accessible records that satisfy the hierarchy operator.
We actually make it coincide with the results of the search when using
the "_parent_store" optimization.
closesodoo/odoo#73962
X-original-commit: 3e1b960acf3f6a726338476ba9e62e5ef5c84ef9
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When the selectedChildren array was empty it generated an error and a traceback appeared in Odoo.
Task-2580158
closesodoo/odoo#73846
X-original-commit: 65b8ffb56485895cc08be024b18928d1e51949b7
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
On windows when you copy paste text in and into Odoo (for example in the description when creating a ticket) a traceback occurs.
There is an isWhitelist function which verifies that a node is indeed in the authorized items via the following instruction
`item.matches (CLIPBOARD_WHITELISTS.nodes.join (','))`
But on windows there is a comment node containing `<--StartFragment-->`
Here is the clipboard data on linux and on windows for the same copied text (Hello):
- Linux
<meta http-equiv=\"content-type\" content=\"text/html; charset=utf-8\">
<span style=\"color: rgb(102, 102, 102); font-family: "Lucida Grande", Helvetica, Verdana, Arial, sans-serif; font-size: 13px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;\">Hello</span>
- Windows
<html>
<body>
<!--StartFragment--><span style="color: rgb(102, 102, 102); font-family: "Lucida Grande", Helvetica, Verdana, Arial, sans-serif; font-size: 13px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">Hello</span><!--EndFragment-->
</body>
</html>
Except for this additional comment on Windows, the `.matches()` method does not exist.
This PR uses the `Array.includes` function on the item's `nodeName`, which should work in all cases while keeping the same behavior.
opw-2591597
closesodoo/odoo#73952
X-original-commit: 9478cfa0942ad2aee69de197024660cdd6f6c739
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
The compute method `_compute_l10n_latam_document_type` could give
results that were not satisfied by the constraint
`_check_invoice_type_document_type`.
These modules will need to be merged, but in the meantime the tests need
to be green for the CI.
A constraint is raised in `account_edi_proxy_client` is we do not call
that method.
Xavier Morel