* QWeb bodies should be markup-safe so `0` should always be
markup-safe.
* `head` is qweb-rendered so the same.
* The `json` pseudo-module in qweb templates is `json.scriptsafe`,
which should be markup-safe.
* fix generation of preferences markup so everything's properly
safe (and flag as markup)
* tips should be the result of templates rendering and thus safe
* same for body
* The result of `plaintext2html` is fully controlled and
markup-safe (the first thing we do is escape the input).
* For `append_content_to_html`, we assume the inputs are HTML and the
output is thus always properly HTML.
Alternatively, we may want to `Markup("%s%s") % ...` and require the
inputs to be properly marked? That seems like a good idea.
* In `_replace_local_links`, applying re.sub will strip out the markup
mark, so store it and reapply it on output if necessary.
That one is a big gnarly, because if the input to ustr is
markup-safe bytes (e.g. qweb rendering output) then the output is a
Markup object, but if the input is str then the output is str, so we
need to check before and after unless... we update ustr to check for
subclasses instead of exact type?
* In `_prepend_preview` the issue is similar to that of
`append_content_to_html`, though in this case we should *not* trust
the input, so we can flag the "parent document" as Markup and format
the preview bit in.
* And since we're marking mail's jinja output as safe, do the same for
web and iot.
Sadly there doesn't seem to be any hook for doing that at the
environment level of jinja, so every `Template.render` site has to
be marked.
`markupsafe.escape` always escapes single and double quotes, and
escapes them to their numeric values rather than symbolic
According to pallets/jinja@f35e28154f,
this is for compatibility with HTML 3.2: the only named entities in
the HTML 3.2 DTD are `amp`, `gt`, and `lt`.
Update tests to match.
Add a big fat warning when the qweb compiler finds a `t-raw`.
`t-esc` should now be used everywhere, the use-case for `t-raw` should
be handled by converting the corresponding values to `Markup`
objects. Even though it's convenient, this constructor *should never
be made available in the qweb rendering context* (maybe that should be
checked for explicitely?).
Replace `werkzeug.escape` by `markupsafe.escape` in
`odoo.tools.html_escape`, this means the output of `html_escape` is
markup-safe.
Updated qweb to work correctly with escaping and `Markup`, amongst
other things QWeb bodies should be markup-safe internally (so that a
`t-set` value can be fed into a `t-esc`). See at the bottom for the
attributes handling as it's a bit complicated.
`to_text` needed updating: `markupsafe.Markup` is a subclass of `str`,
but `str` is not a passthrough for strings. So `Markup` instances
going through would be converted to normal `str`, losing their safety
flag. Since qweb internally uses `to_text` on pretty much
everything (in order to handle None / False), this would then cause
almost every `Markup` to get mistakenly double-escaped.
Also mark a bunch of APIs as markup-safe by default
* html_sanitize output.
* HTML fields content, sanitization is applied on intake (so stripped
by the trip through the database) and if the field is unsanitised
the injection is very much intentional, probably. Note: this
includes automatically decoding bytes as a number of default values
& computes yield bytes, which Markup will happily accept... by
repr-ing them which is useless. This is hard to notice without `-b`.
* Script-safe json, it's rather the point (though it uses a
non-standard escaping scheme).
* Note that `nl2br`, kinda: it should work correctly whether or not
the input is markup-safe, this means we should not need to escape
values fed to `nl2br`, but it doesn't hurt either.
Update some qweb field serialisations to mark their output as
markup-safe when necessary (e.g. monetary, barcode,
contact). Otherwise either using proper escaping internally or doing
nothing should do the trick.
Also update qweb to return markup-safe bytes: we want qweb to return
markup-safe contents as a common use-case is to render something with
one template, and inject its content in an other one (with Python code
inbetween, as `t-call` works a bit differently and does not go through
the external rendering interface).
However qweb returns `bytes` while `Markup` extends `str`. After a
quick experiment with changing qweb rendering to return `str` (rather
unmitigated failure I fear), it looks like the safest tack is to add a
somewhat similar bytes-based type, which decodes to a `Markup` but
keeps to bytes semantics.
For debugging and convenience reasons, MarkupSafeBytes does *not*
stringify and raises an error instead (`__repr__` works fine). This is
to avoid implicit stringifications which do the wrong thing (namely
create a string `"b'foo'"`).
Also add some configuration around BytesWarning (which still has to be
enabled at the interpreter level via `-b`, there's no way to enable it
programmatically smh), and monkeypatch `showwarning` to show warning
tracebacks, as it's common for warnings to be triggered in the bowels
of the application, and hard to relate to business logic without the
complete traceback.
`t-out`
=======
`t-esc` is a bit confusing for the new behaviour of "maybe escape
maybe not", so add a `t-out` alias with the same behaviour.
Unlike `t-raw`, `t-esc` is only soft-deprecated for now: there are
thousands of instances, so editing all the templates is not
great. Eventually we'll add a `ci/style` to prevent addition of new
ones, and eventually we might do a bulk-replace and hard-deprecate.
Attributes handling
===================
There are a few issues with respect to attributes. The first issue is
that markup-safe content is not necessarily attributes-safe
e.g. markup-safe content can contain unescaped `<` or double-quotes
while attributes can not. So we must forcefully escape the input, even
if it's supposedly markup-safe already.
This causes a problem for script-safe JSON: it's markup-safe but
really does its own thing. So instead of escaping it up-front and
wrapping it in Markup, make script-safe JSON its own type which
applies JSON-escaping *during the `__html__` call.
This way if a script-safe JSON object goes through `markupsafe.escape`
we'll apply script-safe escaping, otherwise it'll be treated as a
regular strings and eventually escaped the normal way.
A second issue was the processing of format-valued
attributes (`t-attf`): literal segments should always be markup-safe,
while non-literal may or may not be. This turns out to be an issue if
the non-literal segment *is* markup-safe: in that case when the
literal and non-literal segments get concatenated the literal segments
will get escaped, then attributes serialization will escape
them *again* leading to doubly-escaped content in attributes.
The most visible instance of this was the `snippet_options` template,
specifically:
<t t-set="so_content_addition_selector" t-translation="off">blockquote, ...</t>
<div id="so_content_addition"
t-att-data-selector="so_content_addition_selector"
t-attf-data-drop-near="p, h1, h2, h3, .row > div > img, #{so_content_addition_selector}"
data-drop-in=".content, nav"/>
Here `so_content_addition_selector` is a qweb body therefore
markup-safe, When concatenated with the literal part of
`t-atff-data-drop-near` it would cause the HTML-escaping of that
yielding a new Markup object. Normal attributes processing would then
strip the markup flag (using `str()`) and escape it again, leading to
doubly-escaped literals.
The original hack around was to unescape() `Markup` content before
stringifying it and escaping it again, in the attribute serialization
method (`_append_attributes`).
That's pretty disgusting, after some more consideration & testing it
looks like a much better and safer fix is to ensure the
expression (non-literal) segments of format strings always result in
`str`, never `Markup`, which is easy enough: just all `str()` on the
output of strexpr. We could also have concatenated all the bits using
`''.join` instead of repeated concatenation (`+`).
Also add a check on the type of the format string for safety, I think
it should always be a proper str and the bytes thing is only when
running in py2 (where lxml uses bytestrings as a space optimization
for ascii-only values) but it should not hurt too much to perform a
single typecheck assertion on the value... instead of performing one
per literal segment.
Note: we may need to implement unescape anyway, because it's still
possible to get double-escaping with the current scheme: given an
explicitly escape-ed `foo` and `t-att-foo="foo"`, `foo` will be
re-escaped.
fixup! [CHG] core, web: deprecate t-raw
Scenario:
- add a file in mass mailing editor => an icon is added linking the file
- save
- edit => the icon is replaced by a generic icon
- save
- send mail => no icon is shown in email received
The system is using eg. `data-mimetype="pdf"` to show the icon, before
12.0 this worked but in saas-12.3 the system uses mailing.mailing
body_arch's field that is sanitizing attributes and remove it on save,
so the icon is only working in received email if you save one and only
one time after adding file inside the mass mailing.
opw-2474053 (ticket for similar issue in 14.0)
closesodoo/odoo#70057
X-original-commit: 7e14515b84d8081557517df7e9dc7d8c0d17f2be
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#70058
Forward-port-of: odoo/odoo#69993
Forward-port-of: odoo/odoo#69927
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce the bug :
- Create a French company
- Go to accounting settings > in “Fiscal Localization” install French accounting
- Install “l10n_ch_qriban”
- Go to contacts > Configuration > Bank accounts
- Create a new bank account > add a French company newly created in the “Account Holder” field
Problem:
The specific fields to a Swiss company appear.
Solution :
Check if the country of the company encoded in the “Account Holder” field is Switzerland.
opw-2504699
closesodoo/odoo#70011
X-original-commit: 326dc3f7001f605d7ebb929740ed8478fce20e7e
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
Steps to reproduce the bug:
- Let's consider a user U not in group group_system
- Log with U
- Create a vendor payment with payment method Checks
- Print it
Bug:
An access error was raised because U didn't have the rights to write on model ir.sequence
opw:2513014
closesodoo/odoo#70062
X-original-commit: 11376c88e0068a0bece0b0b56ffd4a9f296ffb87
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When the user submits a form, a lead will be created but the language
won't be the one selected by the user.
To reproduce the error:
(Enable debug mode)
1. Settings > Translations > Languages
2. Activate another language L_other
3. On website, add a form:
- Action: Create an Opportunity
4. Add an existing field: "Language"
5. Submit the form
- Language must be L_other
6. Consult the new lead
Error: The language is not the selected one.
OPW-2486276
closesodoo/odoo#70050
X-original-commit: 8d6a971a8dba860fe7c2a453c3a15f62916f656a
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Steps:
- Go to Inventory / Products / Products
- Create a product (2)
- Storable Product
- Cost: 10
- Click Update Quantity
- Create a new quantity line with 3 in On Hand Quantity
- Update the line with 1 in On Hand Quantity
- Go back to the product
- Click the "Forecasted" smart button
Bug:
The on hand value is 30 instead of 10.
Explanation:
When `location_dest_id` is the current location, it is used to specify
that a given quantity has been added to this location's stock. However,
when removing a quantity, the move goes from the current location to a
virtual one. The current location is, in this case, stored in
`location_id` and the destination is the virtual location.
This makes stock removals not appear in the on hand value since we only
filter the layers on their move's `location_dest_id`.
This commit assumes that a move always goes from or to a virtual
location and checks if the current location is in `location_dest_id` or
in `location_id`.
opw:2510911
closesodoo/odoo#70038
X-original-commit: 978853a6355e36e81752bf0714102f519a6a7931
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
Use the last version of raspberry pi os to build the IoT Box
We don't hold anymore the firmware-brcm80211
closesodoo/odoo#70037
X-original-commit: a8c952fe477d22f5a88696df44e63faca13cba06
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Before this update if you would update the module the default livechat details would be reset.
By wrapping it in a no-update they're not updated with a module update.
closesodoo/odoo#70029
X-original-commit: 45c330c1e44d6a9526596b5ec1dfbff317579b68
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Scenario:
- add a file in mass mailing editor => an generic icon (instead of lower
version where icon depended on mimetype) is added linking the file
- save and send mail => no icon is shown in email received
The system is targeting `a[href*="/web/content/"][data-mimetype]:empty`
to add real image inside instead of using background-image attribute
which is stripped in sanitized.
With this commit, data-mimetype is not removed when image processing
attributes are removed when a file is inserted.
opw-2474053
closesodoo/odoo#70022
X-original-commit: eb3772508ce518ff3f84724eebbe43fd1e040d77
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Purpose of the commit is to do the generic improvement for the
refactoring of some module's view.
So in this commit, done the following changes:
- Reporting > Tasks Analysis , average progress of each task display correctly
- In project overview:
- state button is fit correctly in report view
- In task quick create, added placeholder for name field
- In Product form view:
- service_tarcking field: rename 'don't create task' into 'don't create a task'
- display the share button if privacy_visibility should be portal
- remove the 'Documents' stat button
- In Tasks list view, allow users to edit the stage of the task in batch if the project is in the context
- In project kanban view, remove the 'profitability' link and the corresponding stat button on sale.order
task-2458123
closesodoo/odoo#68146
Related: odoo/enterprise#17201
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
When synchronizing microsoft calendar events, if the event is permanent
Microsoft says the endDate is "0001-01-01": we save that and this causes
an error when it is being parsed in javascript since we require a date
with higher than 1000 years in require('web.field_utils').parseDate
function.
With this changeset, we do not set endDate if the type of the event is
not endDate (as shown[^1] in the documentation endDate only makes sense
for event of type endDate).
[^1]: https://docs.microsoft.com/en-us/graph/outlook-schedule-recurring-events#recurrence-ranges
opw-2479029
fixes#69481closes#69944closesodoo/odoo#70009
X-original-commit: 7aa233e63a8c82cce8336adb99418a96e061268f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In the Argentinean invoices report view, we were removing the Payment
Terms and we were only showing the Payment Term name in the header.
Now we add it back following the Odoo approach but we also keep the name
of the terms on the header.
We made this modification in the invoice report with and without payment.
original commit: 6a0cf2e
closesodoo/odoo#69998
X-original-commit: bf88ef700fc0224b973f3e6142db42799a2eccb1
Signed-off-by: Josse Colpaert <jco@openerp.com>
account_payment:
- Processing fees computation was done based on the wrong country.
payment:
- The acquirer's cancel message was missing from the
/payment/confirmation page.
- `redirect_form_view_id` field was declared with attribute 'name'
instead of 'string'.
- Uninstalling a payment acquirer would fail with a traceback.
- The first acquirer was not automatically selected if it was the only
selectable payment option of a 'manage' payment form.
- Specifying a preferred acquirer to the /payment/pay page would show
not acquirer at all if the preferred option was incompatible with
the constraints, rather than falling back on showing all acquirers.
payment_adyen:
- When the value of the API URL fields is malformed (e.g., missing the
"https://"), clicking on the confirm button raised a traceback.
payment_ogone:
- There was a typo in the return route.
payment_paypal:
- PayPal acquirers were not filtered out if the currency was not not
supported.
- Returning to the webshop without paying would raise a traceback.
task-2494916
closesodoo/odoo#69996
X-original-commit: 4f7e463fb8b13506caa8aff0beeef5eb0720bf00
Related: odoo/enterprise#17997
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
This mostly an issue when trying to run just the tests of `web` (aka
`-iweb`) with only community modules available,
`TestMenusDemoLight.test_01_click_apps_menus_as_demo`, wait for the
ready code times out:
AssertionError: False is not true : The ready "odoo.isReady === true" code was always falsy
and the test suite fails.
The ready code simply checks that `odoo.isReady` is set. The web
client sets `isReady` when `webclient_started` is
triggered (specifically in `_onWebClientStarted`, which is the handler
for that event).
[The community web client only triggers `webclient_started` at the end
of `doAction`][0] meaning the community client is considered ready
until after the first action has executed.
[The first action is executed by `show_application`][1] whose process
is the following:
1. load and initialize the menus
2. if an action is specified in the URL, run that
3. otherwise if the user has a home action, run that
4. otherwise run the first menu's action
When installing only `web`, the only menus which could be available
are Apps and Settings, and the demo user has access to neither. This
means the demo user has no applications, and opening the first app is
a no-op ([`openFirstApp` has a case just for that situation to ensure
it does nothing][2]). As a result, `webclient_started` is never
triggered, `_onWebClientStarted` is never called, `odoo.isReady` is
never set, and the tour never runs.
Fix by updating `openFirstApp` to return *whether* it opened an
application, and in `show_application` the last fallback if even
opening the first application failed is to just declare the web client
ready.
While at it, rewrite `show_application` using ES6 facilities and
flatten and linearize it using guards. This means the code pretty much
tracks the process described above, with one step added:
5. otherwise complete the webclient's startup
[0]: https://github.com/odoo/odoo/blob/1eb474243b55f1b9e10c70d199bbe022e68b51d0/addons/web/static/src/js/chrome/action_manager.js#L174
[1]: https://github.com/odoo/odoo/blob/d1c56ec7c435c5baba8604feccc6116e4c25ca96/addons/web/static/src/js/chrome/web_client.js#L77-L107
[2]: https://github.com/odoo/odoo/blob/e24ab17d38fb049404f04112990e8b2fe1dd7727/addons/web/static/src/js/chrome/apps_menu.js#L44-L46closesodoo/odoo#70039
X-original-commit: a5b2146404da9ea0cd4752a21dcd230140822c86
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The changed test uses the drag&drop helper, and an operation does
not work as expected with the given params on chrome 90. The runbot
currently uses chrome 80, so it is not an issue, but if your chrome
is up-to-date, and you try to run the test suite, this test would
fail.
closesodoo/odoo#70032
X-original-commit: 43994da9980e4133274984f720bb58f3546ea0f9
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When resuming a POS session, if the latter has been opened in the past
and if its state is 'Opening Control', a incorrect UserError is raised
and prevents the session to be started.
To reproduce the error:
1. Use a French company
2. Create a POS
- Enable "Advanced Cash Control"
3. Start a new session
4. Close it
5. Set the computer's date in the future
5. Open the POS session > Continue Selling
Error: A UserError is raised ("This session has been opened another day.
To comply with the French law, [...]"), but the user does not have the
possibility to close the session. Moreover, since its state is "Opening
Control", no sales have been made yet.
This fix suggests to reset the start date in such a situation.
OPW-2488952
closesodoo/odoo#69994
X-original-commit: f7048c1de139113eb6109787e669160146319bd3
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
The media modal's document tab has cells with icons and filenames. If
the filename was too long, it would overflow its cell, which caused an
ugly design glitch. This ensures an ellipsis on the filename when it is
too long.
closesodoo/odoo#69990
X-original-commit: 8a4f4bf04bd5e5f9cf827273ea27a189a43c2515
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In this commit, we add all the data related to the Argentinean
perceptions for each jurisdiction.
For each jurisdiction (xx) we have a new:
* Tax: Percepción IIBB xx Sufrida
* Tax: Percepción IIBB Catamarca Aplicada
* Tax group: Perc IIBB xx
* Account: Saldo a favor IIBB xx
* Account: Retención IIBB xx sufrida
* Account: Percepción IIBB xx sufrida
* Account: Retención IIBB xx aplicada
* Account: Percepción IIBB xx aplicada
* Account: IIBB xx
Also, we activate some perceptions to work with demo data
closesodoo/odoo#69873
X-original-commit: 0dcc71314d41fb30559495695f7a626b4c1b20e3
Signed-off-by: Josse Colpaert <jco@openerp.com>
Have a Fiscal position FPOS which map tax A to tax B
Have products DEMO with tax A and DEMO2
Allow FPOS in POS, Open a session, activate FPOS, sell DEMO and DEMO2
Close POS
Go to Orders, select the last one, hit return, edit, delete DEMO2 line
Tax will be wrong.
This occcur because the fiscal position mapping fail an equivalence
check with a virtual record, so the tax is calculated as A and not B
opw-2485399
closesodoo/odoo#69952
X-original-commit: 983797e626f742e84710de7ec8487824d6eaa7f1
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Usecase to reproduce:
- create a product with 0 stock
- Sale order 500 units
- a RFQ is created for 500 units
- in replenishments, you have 0 units to order, OK
- RFQ --> confirm PO
- in replenishments, now the quantity to order is 500
--> should still be 0, it leads to confusions
It happens because the replenish action check the missing
quantity for today. It result by -500 units since the delivery
is planned for the next day (default supplier lead days = 1).
But since the orderpoint exist, the quantity forecasted is
already computed correctly with the right lead time.
But the action will remove the 500 missing today from the
quantity forecasted (The idea is to add the missing quantity on
the main location. e.g. I have
-10 units in WH/Stock/Shelf1
-20 units in WH/Stock
The orderpoint will only look for its own location -> 20 to reorder
The replenishment report look by warehouse and not by location -> 30
missing. So 30 missing + 20 incomming -> 10 to add (by default on
WH/Stock)
The fix is to add a step when a product is missing then compute its
virtual available with lead days (to avoid missing confirmed moves
during the lead time).
opw-2456978
closesodoo/odoo#69527
X-original-commit: f939c7b2c4143d685c25d155a164d63070d36ed2
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This revision solves two things:
- On installation of `l10n_latam_base`,
`l10n_latam_base` is set as default as `l10n_latam_identification_type_id`
for all partners in the database.
The ORM method `write` was used to do so.
With a database having a large number of partners,
such as multiple hundred of thousands,
this leaded to performance issues when `l10n_latam_base`
got installed.
I checked compute methods that could depends on this field,
and the only one I found is `_compute_l10n_ar_vat`,
which is not yet `installed/loaded` when this posthook takes place,
as it's in the module `l10n_ar` which depends on `l10n_latam_base`
and therefore is loaded after. So, it was already not executed/computed
when using the ORM `write` method before this revision.
Therefore, the use of plain SQL can be used to speed up the performance.
- Also, the ORM `write` triggered unexpected compute fields
which could raise exceptions, because of the `commercial_partner_id`
synchronization.
For instance:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line 1198, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 89, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 455, in load_modules
loaded_modules, update_module, models_to_check)
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 348, in load_marked_modules
perform_checks=perform_checks, models_to_check=models_to_check
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 239, in load_module_graph
getattr(py_module, post_init)(cr, registry)
File "/home/odoo/src/odoo/14.0/addons/l10n_latam_base/__init__.py", line 8, in _set_default_identification_type
env['res.partner'].search([]).write({'l10n_latam_identification_type_id': env.ref('l10n_latam_base.it_vat').id})
File "/home/odoo/src/odoo/14.0/addons/base_vat/models/res_partner.py", line 538, in write
return super(ResPartner, self).write(values)
File "/home/odoo/src/odoo/14.0/addons/snailmail/models/res_partner.py", line 26, in write
return super(ResPartner, self).write(vals)
File "/home/odoo/src/odoo/14.0/addons/partner_autocomplete/models/res_partner.py", line 199, in write
res = super(ResPartner, self).write(values)
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 550, in write
partner._fields_sync(vals)
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 469, in _fields_sync
self._children_sync(values)
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 478, in _children_sync
self._commercial_sync_to_children()
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 452, in _commercial_sync_to_children
sync_children._compute_commercial_partner()
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 297, in _compute_commercial_partner
partner.commercial_partner_id = partner.parent_id.commercial_partner_id
File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1127, in __set__
records.write({self.name: write_value})
File "/home/odoo/src/odoo/14.0/addons/base_vat/models/res_partner.py", line 538, in write
return super(ResPartner, self).write(values)
File "/home/odoo/src/odoo/14.0/addons/snailmail/models/res_partner.py", line 26, in write
return super(ResPartner, self).write(vals)
File "/home/odoo/src/odoo/14.0/addons/partner_autocomplete/models/res_partner.py", line 199, in write
res = super(ResPartner, self).write(values)
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 546, in write
result = result and super(Partner, self).write(vals)
File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_activity.py", line 766, in write
return super(MailActivityMixin, self).write(vals)
File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_thread.py", line 322, in write
result = super(MailThread, self).write(values)
File "/home/odoo/src/odoo/14.0/addons/website/models/mixins.py", line 182, in write
return super(WebsitePublishedMixin, self).write(values)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 3640, in write
self.modified(relational_names, before=True)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5786, in modified
tocompute = list(tocompute)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5862, in _modified_triggers
yield from records._modified_triggers(val)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5858, in _modified_triggers
records |= model.search([(key.name, 'in', real_records.ids)], order='id')
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 1708, in search
res = self._search(args, offset=offset, limit=limit, order=order, count=count)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4492, in _search
self._flush_search(args, order=order)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4470, in _flush_search
self.env[model_name].flush(field_names)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5442, in flush
self.recompute(fnames, records=records)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5908, in recompute
process(field)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5879, in process
field.recompute(recs)
File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1145, in recompute
self.compute_value(record)
File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1175, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4068, in _compute_field_value
self.filtered('id')._validate_fields(fnames)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 1260, in _validate_fields
check(self)
File "/home/odoo/src/odoo/14.0/addons/sale_project/models/project.py", line 70, in _check_sale_line_type
product_id=task.sale_line_id.product_id.display_name,
odoo.exceptions.ValidationError: You cannot link the order item SO/2019/11374 - [COMOD2H] Servicio de Correctivo dos Horas to this task because it is a re-invoiced expense.
```
upg-11324
closesodoo/odoo#69958
X-original-commit: 680bd481412823b66fcf45c9312a59c7029e200b
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This commit follows https://github.com/odoo/odoo/pull/64948
Before this commit, the mail composer was not properly used. It was not started with a model and business document ids.
This commit also reverts a keyword context value for the sms composer.
closesodoo/odoo#69910
Taskid: 2342252
X-original-commit: 14629c8e1778269dc2ccc0dedd5e39b23c78669f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
The domain for the fiscal position in the carryover lines was incorrect,
missing the required quotes.
closesodoo/odoo#69921
X-original-commit: 85c07f0f93d664bf7f6028a1dfa0f663e2999c3d
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, we would compare a lang `code` (used in context) and a lang
`url_code`. For languages where those 2 are differents, the `if` condition
would always be falsy, making the canonical URL impossible to be reached.
Technically, this condition is used to get the translated name of records to
later construct the canonical URL.
Since the canonical URL will be incorrect and unreachable, the whole system to
tell search engine/crawler about translation won't work since no
`alternate/hreflang`[1] will be set in the DOM.
[1] see https://developers.google.com/search/docs/advanced/crawling/localized-versions
--------
Technical explanation:
- italian language `code` = `it_IT`, `url_code` = `it`
- belgian french language `code` = `fr_BE`, `url_code` = `fr_BE`
Install those languages on website as secondary languages.
Translate blog `Travel` to `Voyager` in french and `Viaggi` in italian.
Visiting `/fr_BE/blog/travel-1/post/post-1` will redirect to
`/fr_BE/blog/voyager-1/post/post-1` as it should, and the canonical URL will be
set to that same URL.
Visiting `/it/blog/travel-1/post/post-1` will redirect to
`/it/blog/voyager-1/post/post-1` as it should, but the canonical URL will be
set to `/it/blog/travel-1/post/post-1`.
opw-2486918
closesodoo/odoo#69918
X-original-commit: 733411fe03b924832d6b10cadf93c8fc09cc5802
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Steps to reproduce the bug:
- Try to export mail.message records
Bug:
A traceback was raised
Wrong forward-port of 69b27ac
opw:2514584
closesodoo/odoo#69912
X-original-commit: 9cf49ba3fa60c174abffc5c048616f91397f7b9d
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The "note-editable" class was lost on the editable element when loading
it into an iframe. As a result, some selectors failed, making it so that
some options wouldn't activate when they should.
closesodoo/odoo#69908
X-original-commit: d71b7d87daa5b33f16eb9c6ade29580fb2076313
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
If a partner have two delivery address, one full filled, an other with missing
fields.
During the shopping (the first delivery address is auto selected), if the
partner go back in /shop/address to select the second address.
Then go to /shop/confirm_order, there no checks.
closesodoo/odoo#69901
X-original-commit: f8c8418bdd5b9d27b33fea3c63511297a231aa93
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When running an automated action on record creation, if the action
raises a UserError/ValidationError, the record will still be created.
To reproduce the error:
(Need website_crm,base_automation. Enable debug mode)
1. Create an Automated Action
- Model: Lead/Opportunity
- Trigger: On Creation & Update
- Trigger Fields: Phone (crm.lead)
- Action To Do: Execute Python Code
- Python Code:
```python
if record.phone:
raise UserError("Lorem ipsum")
```
2. On website, add a website form WF
- Action: "Create an Opportunity"
3. Complete and submit WF including a phone number
Error: An error message is displayed ("Lorem ispum"). However, the lead
has been created and is present in CRM Pipeline.
An on-creation automated action is executed once the record is executed,
but nothing will cancel this records creation if the action raises a
UserError/ValidationError.
OPW-2423948
closesodoo/odoo#69911
X-original-commit: 8d452ae16b7e6c3077d9eae135852bada43cec93
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
In an iframe, we need to make sure the element is using jquery on its
own window and not on the top window lest jquery behave unexpectedly.
This was apparent with tooltip which was called in snippets.editor with
the "wrong jquery", with the result that tooltip.js had a reference to
the top window/document instead of that of the iframe. Because of that,
it appended its tooltips to the top window instead of the iframe, and
as a result, said tooltips were wrongly positioned.
closesodoo/odoo#69879
X-original-commit: 19be8709efa8f690ccff8d04dd9a17e4ef4d82fd
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Nicolas Bayet <nby@odoo.com>
The overlay around an image when cropping it is positioned absolutely.
If it has no relative ancestor, it will cover the entire body. This is
what happend in mass_mailing, making it impossible to scroll the page
while cropping. This commit addresses the issue by positioning that
editable relatively so that the overlay never goes beyond its bounds.
closesodoo/odoo#69878
X-original-commit: c4d423640a9f1f9892e9d24dc08531ba0bbf8887
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When the colorpicker is in an iframe, listening to mouse events on the
global document can have unexpected effects. Namely clicking in the
colorpicker, then moving the mouse outside the iframe made it move the
color cursor.
This fixes that by binding it to the parent widget's document, with a
fallback on the global document in case it's missing.
closesodoo/odoo#69877
X-original-commit: 4fb33f7f8d6955a44fbb7c94c7d204e9baa09707
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
currently, Across Odoo, there are bugfix folder in around 13 module,
New manifest system allows to add new files in stable so the bugfix files are no
longer required.
after this commit,
all the bugfix files are removed from all module.and all the code in those file
is maintained as per New manifest system.
Task : 2510653
closesodoo/odoo#69830
Related: odoo/enterprise#17936
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This makes it possible to declare an element unsuitable as parent of the
tour tip via the "o_forbidden_tooltip_parent" class.
We then apply this class to the "o_we_customize_panel" of mass_mailing's
snippets menu so the tip is applied to its parent like in saas-14.2.
Without that, the tip is hidden by the body of the mail. The reason it
was positioned in the parent in saas-14.2 is that the theme selector
wasn't in the customize panel but positioned absolutely above it.
This is an ad-hoc fix to something of an ad-hoc situation, given the
relative weirdness of the html environment (the snippets menu is in the
padding of the body of an iframe).
closesodoo/odoo#69876
X-original-commit: 58d5af5df81926af1a5715dd57f6b5c3b40b1e16
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit is fixing two issues:
1: make ribbon translatable
2: display ribbon below smart button
closes#68438closesodoo/odoo#69838
X-original-commit: cbed573e6146a0aab6e0e9114be515a347cd10a4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Xavier Morel