Various: im_livechat, rating, test_mail_full, website_{sale|slides}
Allows to rate any record extending mail_thread. This change was needed because
rating template could be created for any models, even those not inheriting from
rating.mixin. If sent on a record of such model, it was crashing when the
controllers using rating mixin features were used. This is no longer the case.
This commit moves the code from the mixin rating.mixin to mail.thread and
adapts the test for testing rating submission with and without the mixin.
Base behavior accepts rating and provides an access to ratings through the
'rating_ids' field. Rating.mixin inherits now from mail.thread to ease
computation, and adds statistics and some advanced capabilities.
Inheritance of some model have been reordered now that rating is build on
top of mail.thread.
Task-2674649
Part-of: odoo/odoo#103966
In an edge case the content of the field has already been
prefetched as sudo during the read of another field as sudo,
therefore it doesn't try to read the field as the normal user
closesodoo/odoo#88134
Signed-off-by: Julien Castiaux <juc@odoo.com>
To reproduce the issue:
1. Install [Accounting]
2. [Settings]: Toggle on [Batch Payments]
3. Enter [Invoices]
4. Click on several invoices and [REGISTER PAYMENT]
5. Hover over [Group Payments] to see the guide message
Impacted versions: 16.0 up to master
opw-3178431
closesodoo/odoo#113493
X-original-commit: 0866ee676084ae52e6a0b13360a24dacbccd5237
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
Report line `l10n_kz_tr_line_300_00_017` has two expressions with a duplicate expression label, which shouldn't happen. This commit merges them, with taxes being allocated into the same expression.
closesodoo/odoo#113437
X-original-commit: e758e616929e8050ebbf152207b1f45f74b8919e
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Steps to reproduce the bug:
- On the website application, add an image gallery snippet.
- Change the "Speed" parameter.
- Save.
-> Nothing happens: The displayed image is always the first one and
there is no cycle between the images of the snippet.
Since Bootstrap 5, the amount of time to delay between automatically
cycling to the next item is defined by `data-bs-interval`. The bug
comes from the fact that some parts of the code still used the old
parameter name (`data-interval`).
opw-3165570
closesodoo/odoo#113423
X-original-commit: 8368fa1f5e45a14ed8938017b2da90a810dbf0c8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Step to reproduce issue:
- Go to sales settings, activate "Unit of Measure"
- Set user define default of field "uom_id" of model "product.template"
- install "loyalty" module.
While loading file "addons/loyalty/data/loyalty_data.xml" file it will create product and gives traceback.
Or
- It will also give error while upgrade database from 14.0 to 15.0 or more
Note : This error occurs while there is user-define value for uom_id is set and any module tries to
create product from data file.
Current behavior:
- When product creates, uom_id and uom_po_id gets default uom value from
"_get_default_uom_id" method which return "Unit" uom as default.
But when user have default value for uom_id(let's suppose Days), it sets that default
value and for uom_po_id we got uom value as "Unit".
- So now as uom category of Days and Unit are not same it violates "_check_uom" constraint.
Traceback: https://pad.odoo.com/p/utpr-set_default_uom
Soultion:
- When product creates, if there is default value for field uom_id in "ir.default" then
"_get_default_uom_id" method sets same value for uom_po_id.
closesodoo/odoo#113300
X-original-commit: 33a20cf799a6cbca6a55cb82f90c4451df60fa1c
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
- l10n_it_edi: EDI receiving cron error handling fix
If we cannot receive invoices or bills from the IAP proxy we also can't
iterate over them
- l10n_it_edi: Check edi_format before trying to remove signature
The edi_format must be checked before trying to remove the eventual
PKCS#7 signature from the file, otherwise we're uselessly going to try
and remove the signature for every edi_format check (facturX etc.)
- l10n_it_edi: .p7m files can wrongly be missing the signature
In the case that the .p7m extension is put by mistake, try to use the
content of the file as it is before discarding it.
Task link: https://www.odoo.com/web#id=3189457&model=project.task
Task-3189457
closesodoo/odoo#113451
X-original-commit: 942e3c7f2b549fed86f9eb76f98f30b7e5db1ae9
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
With this revision, the label of the field of the first row groupby is
inserted as the row title.
Task-id 2901960
closesodoo/odoo#107220
Related: odoo/enterprise#37395
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
If a user decrease the SOL qty of a kit once the return is done, an
unexpcted picking will be created
To reproduce the issue:
1. Create a kit K:
- With one component
- There is one component in the stock
2. Create and confirm a SO with 1 x K
3. Process the delivery
4. Return the delivery
5. Set the SOL qty to 0
Error: a useless and unexpected picking is created to return the kit
When setting a new SOL qty, we check if we should create and run a
new procurement to adapt the qty on delivery-side. To do so, we get
the qty being delivered, and we compute the difference with the new
SOL qty. Here is the issue, when getting the qty being delivered, it
returns the old SOL qty (1.0):
https://github.com/odoo/odoo/blob/797f67bcb222142b79a9eee3e4a882ff679af9db/addons/sale_mrp/models/sale.py#L164-L167
This is not true. Since the kit has been returned, the qty being
delivered is zero. As a result, a procurement is created to
compensate that incorrect qty.
The incorrect return value (1.0) comes from [1]. However, that fix
is not correct. Here was the initial issue: To get the qty being
delivered, we use the moves of the components, include the BoM lines
qties and try to compote the kit quantity. To do so, we call
`_compute_kit_quantities` with the components' moves and the kit qty.
However, there is an error: the moves are based on the old kit
quantity, and we give the new kit quantity to the method. This is why
the result was incorrect in the use case of [1].
[1] bafad58353c562a9b79735640c23d3cca004e0b0
OPW-3077209
closesodoo/odoo#113438
X-original-commit: 0b8af1d63d496489ac1608141c9b2dbccc8b7966
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
It may happen that the response of a json rpc isn't json parsable,
for instance when the connection pool is full (PoolError). In this
case, the response is an internal server error (500) in html.
Trying to json parse it throws an error. Commit [1], backported in
15.0 by [2] aimed at throwing a more readable and meaningful error
when this happened.
However, this error occurs frequently on the saas for the moment
(see task 3193565), and users constantly report those HTTPError
tracebacks introduced by [1].
In 14.0, we were using jQuery ajax, and the legacy rpc and error
system, where those internal server errors were handled as
connection lost errors (error code -32098). So basically, a
notification was briefly displayed instead of an error dialog.
This commit restores the previous behavior in the new rpc service.
[1] https://github.com/odoo/odoo/commit/5c4a54022b320
[2] https://github.com/odoo/odoo/commit/a01122543a79cclosesodoo/odoo#113434
X-original-commit: 278686d8540a194f0af51e1a0b68b26b13eaf544
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bug
===
The number property should be formatted like a normal integer / float field,
in the form view (show 2 decimal for the float, thousands separators, etc,
even when editing).
Task-3162402
closesodoo/odoo#113449
X-original-commit: 99c251820dcf4791625fabd3fcd61db84280d408
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
product._get_rules_from_location, orderpoint._compute_lead_days
and orderpoint._compute_rules can all be performances
bottleneck. This is mostly because the rules are retrieve
one by one, i.e lots of 'SELECT ... LIMIT 1' queries
are executed.
Refactoring this in stable is difficult because
there are lots of methods involved and the rules have
some type of hierarchy based on the location_src_id field.
So there are recursive calls that are hard to refactor.
Instead of doing that, the idea of this commit is to speed up
these individual 'SELECt ... LIMIT 1' queries by adding
b-tree indexes on some of the stock.rule fields that are
used as conditions of these select queries.
opw-2773988
closesodoo/odoo#113444
X-original-commit: a76c4944d09be9cacfe8d3bac805841d84fb3f41
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Van Delft Aurélien (avd) <avd@odoo.com>
l10n_gcc_invoice implements invoice template with mixed english arabic labels.
This commit makes some clean up on text/columns direction and alignment with a
focus on RTL readers.
1.
Lines with Invoice Date, Due Date, Delivery Date, etc. are aligned to right
Before
*Invoice Date: 9/11/2001 :etaD eciovnI)* ____________________________
After
____________________________ *Invoice Date: 9/11/2001 :etaD eciovnI)*
2.
Columns of order lines are reversed
Before
*Description - QTY - ... - Total Price*
After
*Total Price - ... - QTY - Description*
3.
English/Arabic titles in the headers are inversed (Arabic is on the top now, English is on the bottom)
4.
Small table with subtotal/taxes/total has reversed columns too, so values are
just below of Total column in the main table
Before:
*Title/eltiT - Value*
After
*Value - Title/eltiT*
5.
This commit also improves Payment Reference section to comply with other
sections, i.e. print single value and two labels.
Before
Payment Reference: INV/2020/00019 INV/2020/00019 :ecnerefeR tnemyaP
After
Payment Reference: INV/2020/00019 :ecnerefeR tnemyaP
STEPS:
* install l10n_sa
* create an invoice with customer that has Arabic language
* use "Send & Print" button to get pdf file
opw-3115673
closesodoo/odoo#113443
X-original-commit: 9f6ed327fe34738740d8cb3584313972c8a0f782
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
This commit removes the default `stage_id` group in the
'All Tasks' list view, as it is causing performance issues
closesodoo/odoo#113435
X-original-commit: 759d7b1a30841535de57c19954eff3507dd61eff
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Larcin Vincent (vila) <vila@odoo.com>
The delay of tooltips opened with the tooltip service can be given
in xml, with attribute data-tooltip-delay. If not specified, there
is a fallback in the service to 400ms. Before this commit, the
fallback wasn't correctly applied, because we parsed the xml delay
into an integer, which was NaN when the delay wasn't specified,
and as NaN isn't undefined, the fallback wasn't applied. As a
consequence, we opened the tooltip in a setTimeout with NaN as
delay, and it thus opened directly.
closesodoo/odoo#113425
X-original-commit: 553b2775a4b31c75d1d246816b749e4521e25726
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Let's say there is one account with code 431 and another with code 4310,
`ODOO.BALANCE("431,4310", 2022)` counts 4310 twice.
The reason is queries are done one code at a time, one by one.
The account 4310 is counted first when using 431 as a prefix (431%) and once
more with 4310 (4310%).
Now, the query uses all codes all at once.
The original idea was to cache queries as much as we could. If you later add the
formula `ODOO.BALANCE("431", 2022)`, the result would have been cached
because queries were done code by code.
Given the issue it brings, we thing this opmitisation is not worth it and is
therefore removed. It also makes the code client-side simpler.
opw-3144473
closesodoo/odoo#113418
X-original-commit: 07bd67f3a389bde4f33e08d97967dbb70ad5a19f
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Since [1] the highlight of the focused element in the search
auto-complete has disappeared. This makes the keyboard navigation barely
usable.
This commit restrains the owl styling of dropdowns to the Owl Dropdown
components. This restores the highlight of the focused element on all
website dropdowns (e.g. also the logged-in user one and the "+" to
display more menu entries).
[1] did move the bootstrap's dropdown specific style customizations to
`webclient.scss`.
Steps to reproduce:
- Drop a "Search" snippet.
- Save.
- Type "a" in the search box.
- Navigate the suggestions with the keyboard up and down arrows.
=> Currently focused element looked the same as the other ones.
[1]: https://github.com/odoo/odoo/commit/84715436d87bb05b421bc9ccaacda67d07571690
task-3148871
closesodoo/odoo#113409
X-original-commit: e21ab2cb4904da9efeb7710a8bf8f6efec67821b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
1. Install [Manufacturing], [Sales], [Purchase] on Apps (ordered)
2. [Settings]>[Manufacturing]>[Subcontracting]: set
3. [Sales]
- [CREATE] product type [Service]
- On the tab 'Purchase' add a vendor, select [Subcontract Service]
- On the same tab add `Purchase description` then save
- [Orders]>[Quotations]
- CREATE, add the subcontract service product and set customer
- CONFIRM
4. [Purchase] - [Requests for Quotation]
- should show on the top of the list if vendor was new. click
- [Description] column does not show `Purchase description`
Desired: show relevant data
Impacted versions: 15 - master
opw-3152072
closesodoo/odoo#113407
X-original-commit: fa33657e5e134a9f412a17da4082467ec847e395
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
Steps to reproduce:
- In debug mode
- Go to a cancelled invoice in Accounting
- Click to the "Reset to draft" button in a fast timing (before the
`PopoverContainer` is mounted).
When hovering an element, a tooltip appears. If the target element
disappears before the `onMounted` of the `PopoverContainer`, then the
popover causes a crash because the target element does not exists
anymore.
This fix makes the `tooltip_service` verify that the target still exists
before adding the popover.
closesodoo/odoo#113406
X-original-commit: 589acab37a4c1b68876386b752a91c3412dc4569
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Dardenne Florent (dafl) <dafl@odoo.com>
The delivery should provide the same feature before and after
validation of the picking (however lot/package need a validation)
So the HS code should be available direclty since it's a static value
closesodoo/odoo#113390
X-original-commit: 350015088d3822cde84b5dcf83d053350beafa66
Signed-off-by: Steve Van Essche <svs@odoo.com>
When drag and dropping a grid item and then undoing the operation, it
is not undone correctly, causing the grid items to be broken. This
happens because since `observerUnactive` is called at the start of the
drag, the style (like the `grid-area`) and the grid classes changes are
not recorded and therefore, undoing does not restore them.
This issue was previously fixed in [1] by removing the call to
`observerUnactive` but it should not have been done and this call was
restored in [2].
This commit solves this issue by activating the observer for the
changes that have to be recorded when drag and dropping in grid mode,
in order to undo them properly afterwards.
[1]: https://github.com/odoo/odoo/commit/cc406afcea7bf5846233a9f97a4a8ac5f618f3ec
[2]: https://github.com/odoo/odoo/pull/106029
task-3074139
closesodoo/odoo#113384
X-original-commit: 1dfb127f70832aa9e9022ac337af343b7dc17729
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
1. Install [Manufacturing]
2. Go to [Manufacturing]
- [Configuration] > [Settings], toggle on [Work Orders]
- [Operation] > [Work Orders]
- click on Kanban view
- remove all filters, then click on [Group By] - choose any
Issue: overflowing state tag beyond each kanban card
Resolve by: ordering line by line the information to display
Impacted versions: 16.0 up to master
opw-3162947
closesodoo/odoo#113386
X-original-commit: a72dbedcb00cef76e9a85f59cc875461cf38eafe
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
In the website editor, a traceback error occurs when clicking on the
main element since the commit [1]. This is caused by the function
'_handleSelectionInTable' calling 'selection.getRangeAt(0)' without
checking if there is at least one range in the selection.
Steps to reproduce the bug:
- Open the website editor and drop a text snippet onto the page.
- Click on the snippet to activate it.
- Click on the empty area below the snippet, which corresponds to
the <main> element.
- A traceback error will appear (if it does not appear, repeat the
first three steps multiple times).
[1]: https://github.com/odoo/odoo/commit/d977bd64fe88c059c915f9eb0f8029cde65b216a
task-3196722
closesodoo/odoo#113383
X-original-commit: 6e79728c7e812458709d3a60ba37dc4c578905b2
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this PR, messages received on channels with unknown channel
types weren't displayed on discuss. This was due to the fact that
the sidebar computed its items based on the channel type.
Steps to reproduce this issue:
- Open one browser as mitchell admin (on the Discuss app).
- Open one browser as marc demo (on the Discuss app).
- Send a message from admin to demo.
- Unpin the channel on the admin browser.
- Refresh admin browser.
- Send a message from demo to admin.
- The message is not received on the admin browser.
This PR fixes the issue by fetching channel data if the channel type
is missing when receiving a new message.
closesodoo/odoo#113377
X-original-commit: 3398aa8b10a1d9ad75552871e532f57ffcdd4a7f
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
This commit, is part of a series of commits that aim to simplifie
the concrete fields API.
In this commit we will remove type prop from concrete fields. Now each
field could directly use this.props.record.fields[this.props.name].type
if they need to know the type of field.
task-id 3179751
closesodoo/odoo#112792
Related: odoo/enterprise#37118
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit, is part of a series of commits that aim to simplifie
the concrete fields API.
In this commit we will remove update prop from concrete fields. Now each
field will directly use this.props.record.update to make changes, and
handle the save in fields that need to (e.g. priority). As a consequence
of this, the record props need to be mandatory.
task-id 3179751
Part-of: odoo/odoo#112792
The ofxparse module explicitly uses an html parser instead of xml but
since bs4 4.11.0, this triggers a warning.
closesodoo/odoo#113354
X-original-commit: e81ed97c9c54c69c68c54c69b4d3d80ed0515ae8
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Babel 2.10 (provided in Debian Bookworm) changed the `medium` format at
least for fr_FR and zh_CN.
This commit adapts the tests in order to work with both versions of
Babel. A custom format is used as our unit test is made to test that our
formating methods works, not the way the Babel formats.
X-original-commit: b77eb98bbf6bc937efb7941802c0794ae3622094
Part-of: odoo/odoo#113354
Current behavior:
When you have a loyalty program with a free product, and a rule with a
minimum amout. The free product is not added to the order if the free
product is already in the order.
Steps to reproduce:
-Set a loyalty program with the following Conditions:
Minimum Qty: 1
Minimum Spend: $5
Grant: 10 Points/Order
-Reward:
Type: Free Product
Item: Any item (eg: Bacon Burger)
Exchange: 30 Points
1. Open POS that has this loyalty program.
2. Process sales with a Test User until user has 30 points.
3. Attempt to redeem the Free Product under "Reward".
Note: I modified the other test, IMO it makes sense that when triggering
the rewards it adds Product A and Product A * -1. Because if the product
that was already in the order become free, the rule to trigger the
rewards is not met anymore.
opw-3135794
closesodoo/odoo#113313
X-original-commit: 253d308a26f1e6479c1d3c5342e1cede6f635198
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
To reproduce (V16):
1. Force modify a view with an unexisting field
For example `res.users.tree` with:
`<field name="unexisting_field"/>`
( note that odoo won't allow to do so,
you will have to do it in raw PSQL * )
2. Open Settings > User & Companies > Users
=> JS traceback error:
```js
UncaughtPromiseError > TypeError
Uncaught Promise > Cannot read properties of undefined (reading 'string')
TypeError: Cannot read properties of undefined (reading 'string')
at http://localhost:8069/web/assets/debug/web.assets_backend.js:67523:84 (/web/static/src/legacy/legacy_load_views.js:67)
...
```
* : In practice, it happens to Odoo customers after
incorrect installations/removal of apps
After this commit:
The JS traceback is much clearer regarding the error:
```js
UncaughtPromiseError
Uncaught Promise > Missing field string information for the field 'unexisting_field' from the 'res.users' model
```
OPW-3071843
closesodoo/odoo#113345
X-original-commit: 33f82a60cd3bb64e67d939795b774cd332ab0508
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit:
We use the employee's manager's user's idto fetch a partner by id.
This can cause the action to fail in specific cases as well as
potentially using the wrong language for the reminder
closesodoo/odoo#113282
X-original-commit: c26db495c929d60de62a36cf920c88f6f4c855b9
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, no check was made on conditional questions to see if their
condition was valid when taking a survey.
With this commit, if the survey is not in "random mode" (in which case,
conditions do not apply), there is a check to see that a conditional question
has a valid condition. If not, it is not used in the survey.
Task-3083488
closesodoo/odoo#113303
X-original-commit: f14d1f89ee9c78d481ce1f30ef74bdad9ef0cd7e
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
# Steps to reproduce
* install account_accountant, documents and l10n_it_edi
* Switch to an Italian company
* go to Documents > Configuration > Workspaces and create a new
workspace `W` and it's child `W1`
* under Documents > Settings, activate Accounting and set `Workspace`to
`W`
* save and go back to Documents > Settings, and click `Journals` under
'Accounting'
* add a line with Journals = 'Vendor Bills' and Workspace = `W1`
* go to Accounting > Vendor > Bills and upload a Fattura PA XML bill
* now open the newly generated bill
You should see that the chatter does not load.
# Cause
When uploading a Fattura PA XML bill, a PDF attachment is created and
added to the chatter. The issue is happening because the
`ir.attachment` record ends up in an invalid state where its 'res_model'
field is false.
The 'res_model' field is actually defined when the attachment is
initially created. However, that value ends up being overwritten when a
related `documents.document` is created here: https://github.com/odoo/enterprise/blob/3f53e50989fbb9551565429aede7c0a1e4d6e5a4/documents_account/models/account_move.py#L88
Because of the following line, that `documents.document` will be
assigned a default `res_id` (but no `res_model`).
https://github.com/odoo/odoo/blob/26b2cbd4e5c73ea66456a91ea9cb36d6b174cae7/addons/l10n_it_edi/models/account_edi_format.py#L767
However, setting `res_id` (or `res_model`) on a `documents.document`
will also overwrite the related attachments' values (in this case, the
attachment's `res_model` is set to false because the document's
`res_model` is false).
This behavior happens because of this inverse compute: https://github.com/odoo/enterprise/blob/b4201e6b422e5b0bde1f04db37bcda4941d0665f/documents/models/document.py#L97-L104
opw-3119669
closesodoo/odoo#113299
X-original-commit: 6839abc79a947e30750ec535058828c190c18955
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
When the product configurator is opened, the focus is always on the
custom value input, which may scroll down the configurator and make the
user miss attributes
Steps to reproduce:
1. Install Sales
2. Go to Settings > Sales > Product Catalog and enable Product
Configurator and save
3. Go to Sales > Products > Products and open product 'Cabinet with
Doors'
4. Go to the 'Attributes & Variants' tab and create and edit an
attribute 'Custom'
5. Add a value 'Notes' and check 'Is custom value' and save
6. Add the value to the product and save
7. Open product 'Customizable Desk', in the 'Sales' tab, add 'Cabinet
with Doors' to the Optional Products and save
8. Create a new quotation and add product 'Customizable Desk'
9. The product configurator opens up with the focus on the 'Custom'
attribute input, if the window has a small height, it scrolls down to
that input
Solution:
Remove the focus on the custom value input
Problem:
The focus was made on the input of custom values
opw-3057390
closesodoo/odoo#113301
X-original-commit: dd3e5be00cc4e3408d90abb3923b6658fb1d3073
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Currently, the vat label value comes from the company's country instead of
the customer's country.
So in this commit, if customer country and current company country is same then
we set the customer's country vat label in an error message else we set default `VAT`.
closesodoo/odoo#113295
X-original-commit: 27bae2a04fd333dc54429973d396f329d3710a3d
Signed-off-by: Josse Colpaert <jco@odoo.com>
This commit fixes the shared-worker feature detection with using the
browser object alias.
Steps to reproduce:
- Log to Odoo back-end with a device without a shared-worker support
like Chrome on an Android device => traceback
link:
https://caniuse.com/mdn-api_sharedworker
opw-3198778
closesodoo/odoo#113293
X-original-commit: 4aaafd46dbe1188bf2d9c0140a916ef664d99c42
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This PR fix a traceback that occur when pressing spacebar while the confirm
dialog for deleting a link preview is open.
task-3196494
closesodoo/odoo#113274
X-original-commit: d46a5171378497992bd65634f1aded53db27e9ef
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Pierre-Yves Dufays