Uploading a WEBP or SVG file disguised with a proper file extension (JPG, PNG) will cause a traceback because img.image is not populated when there is an empty source, SVG, or WEBP file uploaded as this code should not be reached with these file types. The reason this occurs is because we check for the file extension when deciding to post process an image, but when we get to initializing the ImageProcess object, we then check the actual file structure to verify the type of file. This is a

Uploading a WEBP or SVG file disguised with a proper file extension (JPG, PNG) will cause a traceback because img.image is not populated when there is an empty source, SVG, or WEBP file uploaded as this code should not be reached with these file types.

The reason this occurs is because we check for the file extension when deciding to post process an image, but when we get to initializing the ImageProcess object, we then check the actual file structure to verify the type of file.

This is a workaround for the time being, but should not be a final solution in future versions.

Adding a null check on img.image in the _postprocess_contents method in order to avoid attempting to access the size of this image when it is null.

Raises a user error in order to trigger the catch and exit the code while logging the error and 'Post processing ignored:'.

opw-3672250
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#156209

To reproduce: * Add a bank account to Employee, and a bank account to your company. * Set the company on the employee's contact to yours. * Create an expense to be reimbursed to the employee, submit it and try to "Register Payment". Current behaviour: the recipient bank account in the wizard is set to the company's. Expected behaviour: the bank account in the wizard should be set to the employee's bank account. This commit solves this. task-3837305 Forward-Port-Of: odoo/odoo#162698

To reproduce:
* Add a bank account to Employee, and a bank account to your company.
* Set the company on the employee's contact to yours.
* Create an expense to be reimbursed to the employee, submit it and try to "Register Payment".

Current behaviour: the recipient bank account in the wizard is set to the company's.
Expected behaviour: the bank account in the wizard should be set to the employee's bank account.

This commit solves this.

task-3837305

Forward-Port-Of: odoo/odoo#162698
Forward-Port-Of: odoo/odoo#160749

The chatter in documents was not flex, which made it take a lot of space without any wrapping. As a result, usually chatter took all the screen and content was massively overflowing, resulting in poor UX. This was caused by a specific stylerule in documents with chatter that made sense in a earlier version of chatter CSS, but this is no longer needed. Also we actually want to reuse most style of chatter in form view. This commit adds `o-mail-ChatterContainer` classname on same HTML node as

The chatter in documents was not flex, which made it take a lot of space without any wrapping. As a result, usually chatter took all the screen and content was massively overflowing, resulting in poor UX.

This was caused by a specific stylerule in documents with chatter that made sense in a earlier version of chatter CSS, but this is no longer needed.

Also we actually want to reuse most style of chatter in form view. This commit adds `o-mail-ChatterContainer` classname on same HTML node as `o-mail-Form-Chatter` and adapts style, so that Document can set this classname to reuse style.

opw-3681435

https://github.com/odoo/enterprise/pull/60772

Before
<img width="1278" alt="before" src="https://github.com/odoo/odoo/assets/6569390/ec3c2004-dee2-4367-85bf-0806e07cb424">

After
<img width="1280" alt="after" src="https://github.com/odoo/odoo/assets/6569390/0bcdc4af-0487-46e7-a245-4aa37028ead6">

Forward-Port-Of: odoo/odoo#161940

This PR fixes two translation issues when launching a chat bot with a different language than the user's: - Wrong translation for `question_selection` answers - Wrong translation for the `question_email` answers 1. The answers to a `question_selection` could be mistranslated because the `post_welcome_steps` method overwrites the context's language when calling `message_post`. As a result, the `discuss.channel/new_message` notification would have the wrong answers format. Steps to

This PR fixes two translation issues when launching a chat bot with a different language than the user's:

- Wrong translation for `question_selection` answers
- Wrong translation for the `question_email` answers


1. The answers to a `question_selection` could be mistranslated because the `post_welcome_steps` method overwrites the context's language when calling `message_post`. As a result, the `discuss.channel/new_message` notification would have the wrong answers format.

   Steps to reproduce the issue:
   - Go to the test chat bot page
   - Switch the website language to the one that is not used by the user.
   - Check the return result of `post_welcome_steps`: answers are in the correct language.
   - Check the corresponding `discuss.channel/new_message` notification received through the websocket: the language is the one of the user.

2. The chat bot language is not specified when calling the `validate_email` route so the lang is the one of the user by default.

   Steps to reproduce the issue:
   - Go to the chatbot test page
   - Activate another language than the one of the user
   - Select "I have a pricing question" with no operator available
   - Enter an invalid email
   - The answer is in the user's language while it should not

opw-3862125

Forward-Port-Of: odoo/odoo#162655

__Current behavior before commit:__ Sometimes the following tracebacks are popping up when an RTC connection is being established between two users trying to edit the same document. ```log InvalidStateError: Failed to execute 'setLocalDescription' on 'RTCPeerConnection': Called in wrong signalingState: stable ``` ```log InvalidStateError: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection': Called in wrong signalingState: stable ``` __Description of the fix:__ These er

__Current behavior before commit:__
Sometimes the following tracebacks are popping up when an RTC connection is being established between two users trying to edit the same document.
```log
InvalidStateError: Failed to execute 'setLocalDescription' on
'RTCPeerConnection': Called in wrong signalingState: stable
```

```log
InvalidStateError: Failed to execute 'setRemoteDescription' on
'RTCPeerConnection': Called in wrong signalingState: stable
```

__Description of the fix:__
These errors are not blocking and don't impact the successful ensuing RTC connection. Thus, we can just catch the error and log it in the console instead of showing it to the user.

__Steps to reproduce the issue (in 17):__
- Go to a knowledge article
- Open a new tab and open the same article
- On this new tab, quit the article and come back multiple times

Eventually a traceback will appear on one of the tab. Note that this error seems to occur very randomly. It is similar to the one dealt by [this commit][1] and it is probably due to a similar cause i.e. a browser bug when the RTC connection is under stress.

It is however possible to trigger it in a more consistent way by calling [_createClient][2] repeatedly.

opw-3778272

[1]: https://github.com/odoo/odoo/pull/158861/commits/0eca324
[2]: https://github.com/odoo/odoo/blob/a1afcc8/addons/web_editor/static/src/js/wysiwyg/PeerToPeer.js#L374

Forward-Port-Of: odoo/odoo#162709
Forward-Port-Of: odoo/odoo#161518

Before this commit: ------------------------- the log message did not clearly indicate who attempted to request a payment. After this commit: ----------------------- the message specifies whether the payment request was initiated by the customer or by the system. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161252

Before this commit:
-------------------------
the log message did not clearly indicate who attempted to request a payment.

After this commit:
-----------------------
the message specifies whether the payment request was initiated by the customer or by the system.




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#161252

Issue ----- If an invoice is created, but not yet "Send & Print", the portal preview shows a normal invoice, but when "Download"ed from the portal preview, a proforma invoice is downloaded. The download behavior is intended since the client shouldn't be able to get a "final" invoice themselves, before the accountant generates one with "Send & Print". However, the HTML preview should also show a proforma invoice to be consistent with this, so the user downloads what they see. Steps -----

Issue
-----

If an invoice is created, but not yet "Send & Print", the portal preview shows a normal invoice, but when "Download"ed from the portal preview, a proforma invoice is downloaded. The download behavior is intended since the client shouldn't be able to get a "final" invoice themselves, before the accountant generates one with "Send & Print". However, the HTML preview should also show a proforma invoice to be consistent with this, so the user downloads what they see.

Steps
-----

 - Create a new invoice: Accounting -> Customers -> Invoices -> New -> ...
 - Go to portal by clicking on "Preview".
 - You'll see a normal invoice. Now click "Download".
 - A proforma invoice is downloaded.

Cause
-----

The HTML-rendered invoice in the portal preview isn't configured to be proforma.

opw-3848049

Forward-Port-Of: odoo/odoo#161726

A few x2many list embedded in form views have the "editable" attr set to "1". Normally, the valid values for this attribute are "top" and "bottom". Regular list views are validated, but not list inside form views. When set to "1", some features of the model aren't enabled. For instance, when the current page is full and the user adds a record, the limit isn't temporarilly increased for the added to be dusplayed on the current page, like it would be in editable="bottom" lists, so the user does

A few x2many list embedded in form views have the "editable" attr set to "1". Normally, the valid values for this attribute are "top" and "bottom". Regular list views are validated, but not list inside form views.

When set to "1", some features of the model aren't enabled. For instance, when the current page is full and the user adds a record, the limit isn't temporarilly increased for the added to be dusplayed on the current page, like it would be in editable="bottom" lists, so the user doesn't see the record he just added.

The issue can be observed in the stock move form view for instance.

This commit is only good for stable versions: we add a fallback on "bottom" s.t. if the editable attribute is set, it's always either "top" or "bottom".

In master, we'll probably rethink the API.

opw~3860903

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

Forward-Port-Of: odoo/odoo#162832

A lot of users don't understand why they can't reserve after moving a product with an immediate transfer. It's due to the double check of _action_assign that check where the move orig stored the product and check the quants for this exact location. In our case the product was moved so the match doesn't work. We introduce an new parameter to check if modifying the behavior on those cases would work. When _free_reservation is call on a move.line we expect to never find it at this place anymore

A lot of users don't understand why they can't reserve after moving a product with an immediate transfer. It's due to the double check of _action_assign that check where the move orig stored the product and check the quants for this exact location. In our case the product was moved so the match doesn't work.

We introduce an new parameter to check if modifying the behavior on those cases would work. When _free_reservation is call on a move.line we expect to never find it at this place anymore (except if we bring it back). Then we drop the reservation base on MTO process and only check if there is a quantity in a sub location of the stock.move

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

Forward-Port-Of: odoo/odoo#155118
Forward-Port-Of: odoo/odoo#154912

**Steps to reproduce the issue:** - Create a storable product “P1”: - Route: dropship - Vendor: Azure interior and deco addict - Create a sales order with one unit of P1 - Confirm the sales order - A purchase order is generated with a dropship-picking (linked to the SO) - Create an alternative PO and confirm it **Problem:** The alternative PO is linked to the SO, but the dropship-picking is not linked. This is because the procurement is not propagated when creating the alt

**Steps to reproduce the issue:**
- Create a storable product “P1”:
    - Route: dropship
    - Vendor: Azure interior and deco addict

- Create a sales order with one unit of P1
- Confirm the sales order

- A purchase order is generated with a dropship-picking (linked to the SO)
- Create an alternative PO and confirm it

**Problem:**
The alternative PO is linked to the SO, but the dropship-picking is not linked. This is because the procurement is not propagated when creating the alternative PO.

opw-3828132

Forward-Port-Of: odoo/odoo#162072
Forward-Port-Of: odoo/odoo#160354

With this commit, on several form view (gantt, calendar and form view) the status bar does not overlap and the text is no longer truncated. task-3849814 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161359

With this commit, on several form view (gantt, calendar and form view)
the status bar does not overlap and the text is no longer truncated.

task-3849814
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#161359

In case a quant for a product tracked by lot/sn exists but without any lot/sn set and have some quantity, `_action_done()` should update it instead of a quant with the correct lot but without any quantity 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 Forward-Port-Of: odoo/odoo#162683 Forward-Port-Of: odoo/odoo#159935

In case a quant for a product tracked by lot/sn exists but without any lot/sn set and have some quantity, `_action_done()` should update it instead of a quant with the correct lot but without any quantity

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

Forward-Port-Of: odoo/odoo#162683
Forward-Port-Of: odoo/odoo#159935

Steps to reproduce the bug: - Create a storable product “P1” - UoM: gram - Create an internal picking with 0.01g of P1 - Validate the picking - Create a return and try to validate it Problem: A UserError is triggered: “Please specify at least one non-zero quantity.” When creating a return, we check if the quantity is not zero using the “float_is_zero” function, but we mistakenly use rounding as precision_digits. opw-3862142 Forward-Port-Of: odoo/odoo#162389

Steps to reproduce the bug:
- Create a storable product “P1” - UoM: gram

- Create an internal picking with 0.01g of P1
- Validate the picking
- Create a return and try to validate it

Problem:
A UserError is triggered: “Please specify at least one non-zero quantity.”

When creating a return, we check if the quantity is not zero using the “float_is_zero” function, but we mistakenly use rounding as precision_digits.

opw-3862142

Forward-Port-Of: odoo/odoo#162389

This reverts commit 8a5541d16caa793c7549d78c082f7879d3aba233. It's a too big change for stable. It breaks the flow for poeple that want to be in just in time but want to consider the future deliveries to order all at once. Due to reverted commit they see their reorder in advance. The fixed use case, could be achieve with the security days or the global lead days system parameter. opw-crl Forward-Port-Of: odoo/odoo#158336 Forward-Port-Of: odoo/odoo#157218

This reverts commit 8a5541d16caa793c7549d78c082f7879d3aba233.

It's a too big change for stable. It breaks the flow for poeple that want to be in just in time but want to consider the future deliveries to order all at once. Due to reverted commit they see their reorder in advance.

The fixed use case, could be achieve with the security days or the global lead days system parameter.

opw-crl

Forward-Port-Of: odoo/odoo#158336
Forward-Port-Of: odoo/odoo#157218

### Version - 16.0 ### Steps to reproduce - Create a event from odoo calendar with privacy 'Available' - Open google calendar and open that event ### Issue - When the user sets privacy as 'Available' in Odoo, it is not properly synchronized in Google Calendar. ### Solution - Syncing privacy value changes between odoo and Google Calendar will be correct after this commit by passing the `transparency` value. task-3667696 --- I confirm I have signed the CLA and re

### Version
- 16.0

### Steps to reproduce
- Create a event from odoo calendar with privacy 'Available'
- Open google calendar and open that event 

### Issue
- When the user sets privacy as 'Available' in Odoo, it is not properly 
synchronized in Google Calendar.

### Solution
- Syncing privacy value changes between odoo and Google Calendar will be
correct after this commit by passing the `transparency` value.

task-3667696






---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#157545

Forward port [commit](https://github.com/odoo/odoo/pull/132219) because the [request](https://upgrade.odoo.com/web#id=1454059&cids=1&menu_id=107&action=150&model=upgrade.request&view_type=form) is failing when we try to rename [ref](https://github.com/odoo/odoo/blob/17.0/addons/l10n_de/migrations/2.0/pre-migrate.py#L24) the tag due to the duplicate name constraint. The implementation of forward porting has become necessary as the script attempts execution with each version, encounter failure

Forward port [commit](https://github.com/odoo/odoo/pull/132219) because the [request](https://upgrade.odoo.com/web#id=1454059&cids=1&menu_id=107&action=150&model=upgrade.request&view_type=form) is failing when we try to rename [ref](https://github.com/odoo/odoo/blob/17.0/addons/l10n_de/migrations/2.0/pre-migrate.py#L24)  the tag due to the duplicate name constraint. 
The implementation of forward porting has become necessary as the script attempts execution with each version, encounter failure due to the presence of the existing tag 'tag_de_liabilities_bs_B_1'. To prevent duplication, we have introduced a pre-check. If the 'B1' tag already exists, script execution is skipped. 

Note: The [request](https://upgrade.odoo.com/web#id=1454059&cids=1&menu_id=107&action=150&model=upgrade.request&view_type=form) is failing for the 17.0 version. However, if we migrate to the version saas-16.3, it also fails. Therefore, we are creating a PR in the saas-16.3 version to forward port it for subsequent versions as well.
Upgrade request traceback group: 813
```
File "/home/odoo/src/odoo/17.0/addons/l10n_de/migrations/2.0/pre-migrate.py", line 45, in migrate
    rename_tag(cr, "tag_de_liabilities_bs_C_1", "tag_de_liabilities_bs_B_1")
  File "/home/odoo/src/odoo/17.0/addons/l10n_de/migrations/2.0/pre-migrate.py", line 5, in rename_tag
    cr.execute(
  File "/home/odoo/src/odoo/17.0/odoo/sql_db.py", line 332, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "ir_model_data_module_name_uniq_index"
DETAIL:  Key (module, name)=(l10n_de, tag_de_liabilities_bs_B_1) already exists.
```

In odoo#126249 the german balance sheet report was updated and
 during the 15.2 FW port, some issues needed fixing. The
issues and their fixes are:

- Deleted tags: As the script didn't run, some tags (like F and all D tags) would be deleted and not renamed. As the tag might already be used as a FK in another table, we remove it from ir_model_data so it's not deleted by the ORM. Also, this means that the tags xml adds the B1 as a new tag which means renaming C1 to B1 will not work in the script due to the unique name constraint, this is handled by checking if B1 exists and if it does we do not run the script.

Enterprise PR: odoo/enterprise/pull/45899

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

Forward-Port-Of: odoo/odoo#161629

Fix the demo user input lines which were considering "Pinaceae" as a correct answer to the question "Dogwood is from which family of trees ?" even though the suggested answer was declared as incorrect for the question. Dogwood is indeed from the "Cornaceae" family of trees, not the "Pinaceae". Fixing the issue by updating the user input lines to be incorrect. related: odoo/odoo#72298 Task-3856668 Forward-Port-Of: odoo/odoo#162392 Forward-Port-Of: odoo/odoo#160911

Fix the demo user input lines which were considering "Pinaceae" as a correct answer to the question "Dogwood is from which family of trees ?" even though the suggested answer was declared as incorrect for the question.
Dogwood is indeed from the "Cornaceae" family of trees, not the "Pinaceae". Fixing the issue by updating the user input lines to be incorrect.

related: odoo/odoo#72298

Task-3856668

Forward-Port-Of: odoo/odoo#162392
Forward-Port-Of: odoo/odoo#160911

Currently, an error occurs when the user tries to add an order with toppings. error: ``` IndexError: list index out of range File "odoo/http.py", line 2157, in __call__ response = request._serve_db() File "odoo/http.py", line 1732, in _serve_db return service_model.retrying(self._serve_ir_http, self.env) File "odoo/service/model.py", line 133, in retrying result = func() File "odoo/http.py", line 1759, in _serve_ir_http response = self.dispatcher.dispatch(rul

Currently, an error occurs when the user tries to add an order with toppings.

error:
```
IndexError: list index out of range
  File "odoo/http.py", line 2157, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1732, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "odoo/service/model.py", line 133, in retrying
    result = func()
  File "odoo/http.py", line 1759, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1960, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 722, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 24, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 20, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 466, in call_kw
    result = _call_kw_multi(method, model, args, kwargs)
  File "odoo/api.py", line 453, in _call_kw_multi
    result = method(recs, *args, **kwargs)
  File "addons/web/models/models.py", line 73, in web_save
    self = self.create(vals)
  File "<decorator-gen-413>", line 2, in create
  File "odoo/api.py", line 414, in _model_create_multi
    return create(self, [arg])
  File "addons/lunch/models/lunch_order.py", line 129, in create
    'toppings': self._extract_toppings(vals),
  File "addons/lunch/models/lunch_order.py", line 99, in _extract_toppings
    topping_1 = values['topping_ids_1'][0][2] if topping_1_values else []
```

This is because before 17.0, [1] got values like `[6, False (1, 2)]`, where
we found the `values['topping_ids_1'][0][2] (ids (1,2))`.  But after 17.0,
[1] got values like `[[4, 1], [4, 2]]`. As a result, it cannot be found in
the `[0][2]` index at [1].

This commit fixes the above issue by using 'convert_to_cach()', which returns
the keys from [[4, 1], [4, 2]].

[1]-https://github.com/odoo/odoo/blob/039407cf2954ce6298aa8af7aff251a1cefdc39b/addons/lunch/models/lunch_order.py#L99

sentry-4627940064


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#142701

While searching for a similar attachment, as the fallback url pattern is the same as the url pattern, the condition is never satisfied. With this commit, the ignore_params parameter is used to find a similar attachment. This was broken in a previous refactoring, `ignore_params=True` was added at the wrong place breaking this mechanism. We also don't have to recompute the url in this case. If we didn't ignore the version, the url_pattern should be the exact url. A test was adapted to

While searching for a similar attachment, as the fallback url pattern is the same as the url pattern, the condition is never satisfied.

With this commit, the ignore_params parameter is used to find a similar attachment.

This was broken in a previous refactoring, `ignore_params=True` was added at  the wrong place breaking this mechanism. 
We also don't have to recompute the url in this case. If we didn't ignore the version, the url_pattern should be the exact url.

A test was adapted to test this fix.

Forward-Port-Of: odoo/odoo#162654

When in demo mode, we always want to be able to change the CoA * to remove friction when demoing: no need to be overly safe * to ensure that `test_all_l10n` always works even if we load a CoA in `<res.company>.create` 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 Forward-Port-Of: odoo/odoo#162299 Forward-Port-Of: odo

When in demo mode, we always want to be able to change the CoA
* to remove friction when demoing: no need to be overly safe
* to ensure that `test_all_l10n` always works even if we load a CoA in `<res.company>.create`

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

Forward-Port-Of: odoo/odoo#162299
Forward-Port-Of: odoo/odoo#159488

From 17.0 we switched from browsable object to dictionaries. This the following syntax is incorrect: result = inputs.SALARY_ARREARS Instead: result = 'SALARY_ARREARS' in inputs This commit fixes these errors Forward-Port-Of: odoo/enterprise#61213

From 17.0 we switched from browsable object to dictionaries. This the following syntax is incorrect:
result = inputs.SALARY_ARREARS
Instead:
result = 'SALARY_ARREARS' in inputs

This commit fixes these errors

Forward-Port-Of: odoo/enterprise#61213

Steps to reproduce: - Confirm an SO with a storable product - in barcode app open the created picking - Scan a different product confirm the picking and create a backorder Bug: the new product is not added to the SO and the original picking isn't linked the SO anymore Fix: when new moves are created in the inventory app default_picking_id is set in the context and is used in _default_group_id to set the group do the same for the barcode app opw-3644773 Forward-Port-Of: odoo/enterp

Steps to reproduce:
- Confirm an SO with a storable product
- in barcode app open the created picking
- Scan a different product confirm the picking and create a backorder

Bug:
the new product is not added to the SO and the original picking isn't linked the SO anymore

Fix:
when new moves are created in the inventory app default_picking_id is set in the context and is used in _default_group_id to set the group do the same for the barcode app

opw-3644773

Forward-Port-Of: odoo/enterprise#60278
Forward-Port-Of: odoo/enterprise#57408

With an MX company setup Accounting > Reporting > Tax Report Choose "Generic Tax Report", select last fiscal year period Generate Closing Entry (Tax accounts needs to be configured) Post the closing entry Traceback will raise AttributeError: 'account.report' object has no attribute 'action_periodic_vat_entries' It is caused by a wrong inheritance of the MX tax report opw-3846942 Forward-Port-Of: odoo/enterprise#61251

With an MX company setup
Accounting > Reporting > Tax Report
Choose "Generic Tax Report", select last fiscal year period
Generate Closing Entry (Tax accounts needs to be configured)
Post the closing entry

Traceback will raise
AttributeError: 'account.report' object has no attribute 'action_periodic_vat_entries'

It is caused by a wrong inheritance of the MX tax report

opw-3846942

Forward-Port-Of: odoo/enterprise#61251

The chatter in documents was not flex, which made it take a lot of space without any wrapping. As a result, usually chatter took all the screen and content was massively overflowing, resulting in poor UX. This was caused by a specific stylerule in documents with chatter that made sense in a earlier version of chatter CSS, but this is no longer needed. Also we actually want to reuse most style of chatter in form view. This commit adds `o-mail-ChatterContainer` classname on same HTML node

The chatter in documents was not flex, which made it take a lot of space without any wrapping. As a result, usually chatter took all the screen and content was massively overflowing, resulting in poor UX.

This was caused by a specific stylerule in documents with chatter that made sense in a earlier version of chatter CSS, but this is no longer needed.

Also we actually want to reuse most style of chatter in form view.
This commit adds `o-mail-ChatterContainer` classname on same
HTML node as `o-mail-Form-Chatter` and adapts style, so that
Document can set this classname to reuse style.

opw-3681435

https://github.com/odoo/odoo/pull/161940

Before
![before](https://github.com/odoo/enterprise/assets/6569390/de86fd5f-f28a-4b1f-8dcc-cc94984a0bcd)

After
![after](https://github.com/odoo/enterprise/assets/6569390/f79af937-bcb6-4b2c-b816-1dbe7cdc6bb5)

Forward-Port-Of: odoo/enterprise#60772

Before this commit: When exporting a report to a pdf if we were not using tax units there was no VAT After this commit: When exporting a report as pdf company VAT is shown if no tax unit is used. If we are using tax units, then tax units VAT will be shown instead task: 3864218 see: #58361 Forward-Port-Of: odoo/enterprise#61146 Forward-Port-Of: odoo/enterprise#61011

Before this commit:
When exporting a report to a pdf if we were not using tax units there was no VAT

After this commit:
When exporting a report as pdf company VAT is shown if no tax unit is used. If we are using tax units, then tax units VAT will be shown instead

task: 3864218
see: #58361

Forward-Port-Of: odoo/enterprise#61146
Forward-Port-Of: odoo/enterprise#61011

With FR localization installed and FR company setup Create an invoice to an EU partner Check the intrastat report Issue: "Codes" filter is visible but it is only supported in some localizations. Currently: - Selecting 'Goods' will toggle on/off all lines as all taxes are grouped under that section - 'Triangular' and 'Services' are no use This occurs because we always show the 'Codes' filter while we should display it only when relevant opw-3777753 Forward-Port-Of: odoo/enterp

With FR localization installed and FR company setup
Create an invoice to an EU partner
Check the intrastat report

Issue: "Codes" filter is visible but it is only supported in some
localizations.
Currently:
- Selecting 'Goods' will toggle on/off all lines as all taxes are
  grouped under that section
- 'Triangular' and 'Services' are no use

This occurs because we always show the 'Codes' filter while we should
display it only when relevant

opw-3777753

Forward-Port-Of: odoo/enterprise#60416

In this [commit](https://github.com/odoo/enterprise/pull/60205/commits/c903c38952fdbc12af611b0f95c037b411291363), we introduced a small typo when processing the partner's address, resulting in a traceback. opw-3883752 Forward-Port-Of: odoo/enterprise#61215

In this [commit](https://github.com/odoo/enterprise/pull/60205/commits/c903c38952fdbc12af611b0f95c037b411291363), we introduced a small typo when processing the partner's address, resulting in a traceback.

opw-3883752

Forward-Port-Of: odoo/enterprise#61215

Purpose ======= Currently, if someone sends a sticker in a Facebook comment, a blank bubble is displayed in the feed view. Instead we want to display the sticker. Task-3595484 Forward-Port-Of: odoo/enterprise#61169 Forward-Port-Of: odoo/enterprise#54188

Purpose
=======
Currently, if someone sends a sticker in a Facebook comment, a blank bubble is displayed in the feed view. Instead we want to display the sticker.

Task-3595484

Forward-Port-Of: odoo/enterprise#61169
Forward-Port-Of: odoo/enterprise#54188

Steps to reproduce 1. Select a PDF 2. From the Inspector click on the split button 3. Press Control+k (opens command palette) 4. Type s or press the space/backspace key 5. It closes the dialog Issue: Special hotkeys like "Backspace," "Space", and "S". Instead of being counted as regular characters during searches, they're being used for other functions, which is the default behavior of the useCommand. Fix: To fix this, we need to give these hotkeys more meaningful names than no dia

Steps to reproduce
1. Select a PDF
2. From the Inspector click on the split button
3. Press Control+k (opens command palette)
4. Type s or press the space/backspace key
5. It closes the dialog

Issue:
Special hotkeys like "Backspace," "Space", and "S".  Instead of being counted as regular characters during searches, they're being used for other functions, which is the default behavior of the useCommand.

Fix:
To fix this, we need to give these hotkeys more meaningful names than no dialog will close while searching.

Task:3725189

Forward-Port-Of: odoo/enterprise#60143

How to reproduce: - Go to documents - Click on a workspace with documents - Click on a document to preview it - Click on another workspace/select a tags/select a tag group, change the filter/domain The preview is still displayed but shouldn't as we can't see the content of the newly selected/filtered. This fix ensures that the preview is closed in such circumstances. Technical note: the event was already trigerred but on the wrong bus. This fix triggers it on the right one. Solving th

How to reproduce:
- Go to documents
- Click on a workspace with documents
- Click on a document to preview it
- Click on another workspace/select a tags/select a tag group, change the filter/domain

The preview is still displayed but shouldn't as we can't see the content of the newly selected/filtered. This fix ensures that the preview is closed in such circumstances.

Technical note: the event was already trigerred but on the wrong bus. This fix triggers it on the right one.
Solving this problem introduces a new bug because when the new filter excludes the document selected, the first selection is unselect while there are no selection anymore. in that case, we just skip that operation.

Task-3624235

Forward-Port-Of: odoo/enterprise#60959
Forward-Port-Of: odoo/enterprise#57237

We don't want to block deleting a journal because there is a rule targetting it. It prevents changing the CoA easily if a transfer model was created while loading the template. Forward-Port-Of: odoo/enterprise#60993 Forward-Port-Of: odoo/enterprise#59547

We don't want to block deleting a journal because there is a rule targetting it.
It prevents changing the CoA easily if a transfer model was created while loading the template.

Forward-Port-Of: odoo/enterprise#60993
Forward-Port-Of: odoo/enterprise#59547

Steps to reproduce the bug: - In Website edit mode. - Drag & drop a "inner content" search snippet into the footer. - Save the page. - Enter the letter "h" in the input. - Bug: The dropdown doesn't adapt properly and increases the height of the page. This commit fixes this issue by detecting if the searchbar menu overflows at the bottom of the page when it's open. If it does, we reduce its height, and if it still overflows despite the reduced height, then we move it above the searc

Steps to reproduce the bug:

- In Website edit mode.
- Drag & drop a "inner content" search snippet into the footer.
- Save the page.
- Enter the letter "h" in the input.
- Bug: The dropdown doesn't adapt properly and increases the height of
the page.

This commit fixes this issue by detecting if the searchbar menu
overflows at the bottom of the page when it's open. If it does, we
reduce its height, and if it still overflows despite the reduced height,
then we move it above the search bar instead of below.

task-3751401

Forward-Port-Of: odoo/odoo#156480

Before this commit, several qunit load state tests sometimes failed. They all follow the same pattern: - trigger an "hashchange" event to simulate an update of the url - wait twice for nextTick - check the DOM reflects the url change However, waiting for 2 ticks isn't enough. Indeed, when the url hash is set, our mock location object dispatches a "real" hashchange event on window, but it does it after a setTimeout [1]. Then, the webclient is notified (via the router service) of the u

Before this commit, several qunit load state tests sometimes failed. They all follow the same pattern:
  - trigger an "hashchange" event to simulate an update of the url
  - wait twice for nextTick
  - check the DOM reflects the url change

However, waiting for 2 ticks isn't enough. Indeed, when the url hash is set, our mock location object dispatches a "real" hashchange event on window, but it does it after a setTimeout [1]. Then, the webclient is notified (via the router service) of the url change, and reacts by loading the appropriate action. This then requires 2 ticks, because we first clear the DOM with the BlankComponent, and then we mount the requested action/view.

This commit makes those tests more robust by waiting for a setTimeout before the 2 nextTicks.

[1] https://github.com/odoo/odoo/blob/1882d8f89f760bd1ff8a2bf0ae798939402647a3/addons/web/static/tests/setup.js#L52

Runbot issue~37030

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

Forward-Port-Of: odoo/odoo#162939

Steps to reproduce: - Confirm an SO with a storable product - in barcode app open the created picking - Scan a different product confirm the picking and create a backorder Bug: the new product is not added to the SO and the original picking isn't linked the SO anymore Fix: when new moves are created in the inventory app default_picking_id is set in the context and is used in _default_group_id to set the group set the context key during the write to ensure moves are created with the

Steps to reproduce:
- Confirm an SO with a storable product
- in barcode app open the created picking
- Scan a different product confirm the picking and create a backorder

Bug:
the new product is not added to the SO and the original picking isn't linked the SO anymore

Fix:
when new moves are created in the inventory app default_picking_id is set in the context and is used in _default_group_id to set the group

set the context key during the write to ensure moves are created with the correct group
test: https://github.com/odoo/enterprise/pull/57408

opw-3644773

Forward-Port-Of: odoo/odoo#160812
Forward-Port-Of: odoo/odoo#157255