Sales order lines for delivery methods now use the customer's selected language instead of the user's current language. This prevents confusing untranslated shipping descriptions on quotes and orders for multilingual customers.

When adding a SO line with a delivery method (e.g. The Post) for a customer
    with a different language that the one set on the current language, the description
    of the SO line was not translated. Inspired from function 'product_id_change' in
    model 'sale.order.line'

opw:1884114

This change removes obsolete code from the Sales module that is no longer used. It helps keep the system easier to maintain without changing how users work with sales orders.

method order_lines_layouted() no longer used.

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

The mail app's message list handling was reorganized to move more behavior into shared data models. This should make the messaging area easier to maintain and less prone to future regressions, with little direct change for end users.

Task-3004204

The backend developer tutorials now use a standard README file and a consistent folder structure for model examples. This makes the learning materials easier to follow and better aligned with Odoo's documentation guidelines.

- [REF] doc: backend - Use README.rst instead of description
 - [REF] doc: backend - Use models/models.py standard
   - Because documentation uses "models/models.py" but the patch uses "models.py"
     - <img width="1038" alt="screen shot 2017-07-17 at 00 49 58" src="https://user-images.githubusercontent.com/6644187/28256418-ed7779dc-6a87-11e7-8f25-c9e7cf962387.png">
   - Because [odoo guidelines](https://www.odoo.com/documentation/10.0/reference/guidelines.html) explain `models/` folder.

Step to reproduce : 1. Open note and create a new document. 2. Add a "5 stars" widget with the power box. 3. Move the caret using the right arrow. 4. Boom, traceback. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#103536

Step to reproduce :
1. Open note and create a new document.
2. Add a "5 stars" widget with the power box.
3. Move the caret using the right arrow.
4. Boom, traceback.


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

Forward-Port-Of: odoo/odoo#103536

If the credential of Adyen are not correct and refresh POS after a payment The cashier are unable to cancel or remove the payment line Because the longpollong continue to reach Adyen to try to get a response. This issue come from the last on POS_adyen commit: 262e50e2b2fb70d882fef536deb8ba253833639b With this commit we stop the polling if we can't reach Adyen server So the correct status is setted at the payment line and the cashier can delete it. Description of the issue/feature this PR a

If the credential of Adyen are not correct and refresh POS after a payment The cashier are unable to cancel or remove the payment line Because the longpollong continue to reach Adyen to try to get a response. This issue come from the last on POS_adyen commit: 262e50e2b2fb70d882fef536deb8ba253833639b

With this commit we stop the polling if we can't reach Adyen server So the correct status is setted at the payment line and the cashier can delete it.

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#103281

**Steps to reproduce the bug:** - Create a storable product “P1” with BOM: - Type: Kit - Quantity: 3 - Components: - product “C1”, QTY: 5 - Update the quantity of “C1” to have 10 in stock - Go to “P1” product form **Problem:** - The on-hand quantity is 2 instead of 6 → 10 (available qty of c1) / (5 / 3) = 6 In the `_compute_quantities_dict` function, the `explode` function is called to have the qty of the component necessary: https://github.com/odoo/odoo/bl

**Steps to reproduce the bug:**
- Create a storable product “P1” with BOM: 
    - Type: Kit
    - Quantity: 3
    - Components:
        - product “C1”, QTY: 5

- Update the quantity of “C1” to have 10 in stock
- Go to “P1” product form

**Problem:**
- The on-hand quantity is 2 instead of 6 → 10 (available qty of c1) / (5 / 3) = 6

In the `_compute_quantities_dict` function, the `explode` function is
called to have the qty of the component necessary:
https://github.com/odoo/odoo/blob/ef4ae7f62d6b690b4745b4145ce25ff02b6b29f6/addons/mrp/models/product.py#L151
but it is the qty necessary for 3 kit according to what is indicated
in the BOM, so we will have 5 qty needed of “C1” as a result:
https://github.com/odoo/odoo/blob/49234be3418169c8f3c928493b86a1a67ab55914/addons/mrp/models/mrp_bom.py#L289
Then the quantity available in stock of the “C1” (10) is reduced by
the quantity needed (5), so 2:
https://github.com/odoo/odoo/blob/ef4ae7f62d6b690b4745b4145ce25ff02b6b29f6/addons/mrp/models/product.py#L188
But this result must be multiplied at
the end by the quantity set in the BOM (3), to get the quantity per kit
→ (10/5)* 3 = 6

opw-3010175

Forward-Port-Of: odoo/odoo#103325

…ted in POS Steps to reproduce the bug: - Let's consider a customer C with default sale payment term 30% Now, Balance 60 Days - Go to the POS and open a session - Select a product and set C as customer - Click on Payment and select Cash and check Invoice Bug: A traceback was raised because several account move lines are created. opw:3009062 Forward-Port-Of: odoo/odoo#103421 Forward-Port-Of: odoo/odoo#103019

…ted in POS

Steps to reproduce the bug:

- Let's consider a customer C with default sale payment term 30% Now, Balance 60 Days
- Go to the POS and open a session
- Select a product and set C as customer
- Click on Payment and select Cash and check Invoice

Bug:

A traceback was raised because several account move lines are created.

opw:3009062

Forward-Port-Of: odoo/odoo#103421
Forward-Port-Of: odoo/odoo#103019

The purpose of this commit is to fix an indeterminate error in the test_03_sale_quote_tour. Error: UncaughtTypeError: Cannot read properties of undefined (reading 'unselectable') Why? In the autocomplete component, it is possible to replace the sources without it being rerender. It is therefore possible to click on a option that no longer exists. Solution? We wait that all the sources are loaded before replacing them. Description of the issue/feature this PR addresses: Current b

The purpose of this commit is to fix an indeterminate error in the test_03_sale_quote_tour.

Error: UncaughtTypeError: Cannot read properties of undefined (reading 'unselectable')

Why?
In the autocomplete component, it is possible to replace the sources without it being rerender. It is therefore possible to click on a option that no longer exists.

Solution?
We wait that all the sources are loaded before replacing them.

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#103258

This fix corrects the measure 'timesheet_revenues' calculation in the Timesheet report. It is now billable_time * aal.sol.price_unit. task-3007122 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102860

This fix corrects the measure 'timesheet_revenues' calculation
in the Timesheet report.
It is now billable_time * aal.sol.price_unit.

task-3007122

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

Forward-Port-Of: odoo/odoo#102860

Video 1 (Issue): https://drive.google.com/file/d/1oXYcDJgaT9gmhkjE08yJlXwIL1qPwS1Y/view?usp=sharing Issue: When using the register payment with a token with any of the payment acquirers, if there is a concurrent access error during the reconciliation process, the payment intent is sent multiple times to the acquirer, making the card charged multiple times. Steps to reproduce: -Have a V14 database (only tested this version) with sale_mmanagement, payment_stripe and invoicing -Configure

Video 1 (Issue): https://drive.google.com/file/d/1oXYcDJgaT9gmhkjE08yJlXwIL1qPwS1Y/view?usp=sharing

Issue:
When using the register payment with a token with any of the payment acquirers, if there is a concurrent access error during the reconciliation process, the payment intent is sent multiple times to the acquirer, making the card charged multiple times.

Steps to reproduce:

-Have a V14 database (only tested this version) with sale_mmanagement, payment_stripe and invoicing -Configure Stripe with your public and secret key (2FA is now enforced for Stripe accounts, therefore,
 we don't have a generic test account anymore. You have to create your own.It is quite fast and easy to do)
-Have a portal user PU with an already registered payment token PT -Go to Invoicing
-Create a new invoice I:
-Customer PU
-Add anything in invoice lines
-Confirm I
-Register a payment for I:
-Journal: Stripe
-Saved Payment token: PT
AT THIS STEP, YOU MUST ENSURE A CONCURRENT ACCESS ERROR WILL RAISE DURING THE RECONCILIATION -Create Payment

Log analysis:
A first payment intent is sent to Stripe. The card is charged and Stripe answers that all went as expected. We try to process the payment, but a concurrent access error occurs. A retry is done.
A payment intent is sent again to Stripe, The card is charged AGAIN and Stripe answers that all went as expected. We try to process the payment, but a concurrent access error occurs.

For each retry, the intent is sent and the card is charged.

If the first retry succeeds, then Odoo can finish the process. There will be only 1 payment transaction on Odoo's side (others have been rollbacked) but there will be 3 on Stripe's side and the card will be charged 3 times.

This PR mitigate this behaviour.
It doesn't address the root cause but by adding the idempotency key to the headers with the transaction display_name we prevent mutliple payments to happen.

OPW-2662964

Forward-Port-Of: odoo/odoo#103491
Forward-Port-Of: odoo/odoo#101243

Before this commit, multi clicking quickly on the "Ok" or "Cancel" buttons of a ConfirmationDialog would call the confirm/cancel callbacks multiple times. For instance, in "Mass mailing", create a new mailing and click "Send". In the confirm dialog, clicking quickly multiple times on "Ok" would call the "Send" button action multiple times. This commit also ensures that we wait for the promise of the confirm callback before closing the dialog. This highlighted an issue in the ORMBatcher

Before this commit, multi clicking quickly on the "Ok" or "Cancel"
buttons of a ConfirmationDialog would call the confirm/cancel
callbacks multiple times. For instance, in "Mass mailing", create
a new mailing and click "Send". In the confirm dialog, clicking
quickly multiple times on "Ok" would call the "Send" button action
multiple times.

This commit also ensures that we wait for the promise of the
confirm callback before closing the dialog. This highlighted an
issue in the ORMBatcher, as we didn't reject the promise when
the batched rpc failed. As a consequence, the confirmation dialog
never closed itself. This has been spotted by an existing test.

Fixing #74647 (from 16.0 to master)

Forward-Port-Of: odoo/odoo#103180

[FIX] web_editor, *: fix link popover position in mobile edition *: website, test_website Before this commit, the LinkPopoverWidget element was not positioned correctly in mobile edition. With [1] that introduced the website edition using an iframe, the element was appended on the global document, outside of the iframe, so that it was not overlapped by the snippets manipulators (that were also in the global document). But Bootstrap popovers are not meant to be used "on top" of if

[FIX] web_editor, *: fix link popover position in mobile edition

*: website, test_website

Before this commit, the LinkPopoverWidget element was not positioned
correctly in mobile edition.

With [1] that introduced the website edition using an iframe, the
element was appended on the global document, outside of the iframe, so
that it was not overlapped by the snippets manipulators (that were also
in the global document).

But Bootstrap popovers are not meant to be used "on top" of iframes.
Bootstrap uses the container's ownerDocument to compute placements, and
does not take into account whether or not the target is located inside
an iframe (therefore, skipping the iframe's offset and dimensions in the
placements computations).

This was leading to a visual bug in mobile edition: the iframe top, left
values were not computed by the popover, and it was not positioned
correctly.

Since [2] moved the manipulators inside the iframe, the popover can be
initialised using its target ownerDocument body, without being
overlapped by the manipulators.

Styles are adapted so that the popover stays consistent in the frontend
and the backend, and a container option is added to the widget so that
the element can be placed with other snippets manipulators from the
website builder.

[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/872bb20b3ac08cf82613e15e6634a2e7593ccf7a

task-2687506

-----

[FIX] website: adapt "Edit" and "Translate" systray items to dark mode

When the dark mode feature was merged with [1], it adapted the
EditWebsiteSystray item with the 'text-reset' class.

But this class was not removed if the website was translatable, and it
was not added on the TranslateWebsiteSystray item, which was leading to
wrongly colored systray items on a translatable website.

[1]: https://github.com/odoo/odoo/commit/ee3aa3054cdd715720466863239d5aa56186946c

-----

[FIX] web_editor: correctly position loading element

In the Website Builder, when clicking on the THEME tab, and clicking on
the "Switch theme" button, the loader behind the dialog was not placed
correctly.

After [1] moved the manipulators inside the iframe, the css rule for the
loading elements was not updated to remove its right value, used to
position the loading element next to the right panel.

[1]: https://github.com/odoo/odoo/commit/872bb20b3ac08cf82613e15e6634a2e7593ccf7a


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

Forward-Port-Of: odoo/odoo#103006

This PR ------- In Product Category, income/expense Account only select accounts with Internal Group is income/expense. But in Product, income/expense Account don't have that domain (although the domain above is not wrong). => This in my opinion causes confusion for users when using. The way to handle it, I will remove the domain part in the income/expense account to match the experience --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forw

This PR
-------
In Product Category, income/expense Account only select accounts with Internal Group is income/expense.
But in Product, income/expense Account don't have that domain (although the domain above is not wrong).
=> This in my opinion causes confusion for users when using.
The way to handle it, I will remove the domain part in the income/expense account to match the experience




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

Forward-Port-Of: odoo/odoo#102539

When choosing an image url from non-odoo pages, there is an access token sent at the end of url. Because of this, slide_course_publisher_standard didn't work as it expected jpg image name at the end. Now it will simply find a match for said jpg image and won't fail second commit takes care of the issue only in v15.3, where default image was not editable with website editor. Ticket-2908029 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/su

When choosing an image url from non-odoo pages, there is an access token
sent at the end of url. Because of this, slide_course_publisher_standard
didn't work as it expected jpg image name at the end. Now it will simply
find a match for said jpg image and won't fail       

second commit takes care of the issue only in v15.3, where default image was not editable with
website editor. 

Ticket-2908029




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

Forward-Port-Of: odoo/odoo#102667
Forward-Port-Of: odoo/odoo#100826

Purpose ======= In the case a time off is created: - In the past - Using support documents An invalid user error is raised in the interface, because the webclient is sending values for the field 'supported_attachment_ids' (Example: [(6, 0, [])]) which is writing by inverse relationship on the field 'attachment_ids'. On the other hand, it should be possible for an employee to add attachment on the time off after it has begun. TaskID: 3032232 Description of the issue/feature this

Purpose
=======

In the case a time off is created:
- In the past
- Using support documents

An invalid user error is raised in the interface, because the webclient is sending values for the field 'supported_attachment_ids' (Example: [(6, 0, [])]) which is writing by inverse relationship on the field 'attachment_ids'.

On the other hand, it should be possible for an employee to add attachment on the time off after it has begun.

TaskID: 3032232

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#103540

Before this commit a content-group was useless it is now removed, moreover the setting for the default plan needed to be changed to look like the other setting of the page. task-id: 2992668 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#100878

Before this commit a content-group was useless it is now removed, moreover the setting for the default plan needed to be changed to look like the other setting of the page.

task-id: 2992668

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

Forward-Port-Of: odoo/odoo#100878

Since the recent css change the text of the description field was no taking all the place he could, so it was impossible to read, thanks to the colspan it's now the way it was intended --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#103606

Since the recent css change the text of the description field was no taking all the place he could, so it was impossible to read, thanks to the colspan it's now the way it was intended

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

Forward-Port-Of: odoo/odoo#103606

This commit fixes a race condition spotted by the click all test, in the Lunch application. To reproduce, go to Lunch > Configuration > Products, in the list view, toggle filter "Archived" s.t. there's no record matching the domain (and nothing displayed in the search panel anymore), then switch to kanban view, and remove the filter. On a multi-build, this scenario fails ~4 times out of 10. The issue occurs because a re-rendering of the search panel is triggered by its parent (because of the

This commit fixes a race condition spotted by the click all test, in the Lunch application. To reproduce, go to Lunch > Configuration > Products, in the list view, toggle filter "Archived" s.t. there's
no record matching the domain (and nothing displayed in the search panel anymore), then switch to kanban view, and remove the filter. On a multi-build, this scenario fails ~4 times out of 10.

The issue occurs because a re-rendering of the search panel is triggered by its parent (because of the filter change), but the search panel didn't compute its active sections yet (this is done when the "update" event is triggered on the search model). The exact situation is hard to reproduce, but if there are non empty sections in the model, and the active sections haven't been computed yet in the search panel, it crashes. For instance, it happens all the time by delaying the promise returned by "_fetchSections".

This commit doesn't introduce a qunit test because we didn't manage to reproduce the exact same situation in a test. This makes the Lunch click all test pass all the time though.

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#103616

- The name of the field `provider_id` on `payment.token` should not be "provider Account" but "Provider". - The computation of the display name of tokens crashed when the field `payment_details` was empty. - The form view of tokens missed a <group/> element to better display the fields. Forward-Port-Of: odoo/odoo#103523

- The name of the field `provider_id` on `payment.token` should not be "provider Account" but "Provider".
- The computation of the display name of tokens crashed when the field `payment_details` was empty.
- The form view of tokens missed a <group/> element to better display the fields.

Forward-Port-Of: odoo/odoo#103523

Before this commit, closing an empty chat window with a non admin user would have led to an access error popup. Indeed, the `website_livechat` modules overrides the `_execute_channel_pin` method of the `mail.channel` model in order to unlink the channel if no messages were sent. The issue is that only the administrator is allowed to delete channels. This commit fixes this issue. task-3028153 Forward-Port-Of: odoo/odoo#103618

Before this commit, closing an empty chat window with a non admin user would have led to an access error popup.

Indeed, the `website_livechat` modules overrides the `_execute_channel_pin` method of the `mail.channel` model in order to unlink the channel if no messages were sent. The issue is that only the administrator is allowed to delete channels.

This commit fixes this issue.

task-3028153

Forward-Port-Of: odoo/odoo#103618

We are spammed by some accounts that don't have credits anymore. With this commit, when we try to send letters from the cron, whenever we meet the CREDIT_ERROR error_code, we stop trying to send the letter. task-2930455 Forward-Port-Of: odoo/odoo#103264

We are spammed by some accounts that don't have credits anymore.

With this commit, when we try to send letters from the cron, whenever we
meet the CREDIT_ERROR error_code, we stop trying to send the letter.

task-2930455

Forward-Port-Of: odoo/odoo#103264

[1] adapted the tour utils to the new WebsitePreview client action, but the clickOnSnippet function was not generating properly the triggers (it was creating invalid css selectors with a string argument, treating it as a class when it could be any css selector). This commit fixes this util. [1]: https://github.com/odoo/odoo/commit/99b50d18e220aedf14de806f4bf1b2d35c32de35 opw-3026167 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forwa

[1] adapted the tour utils to the new WebsitePreview client action, but the clickOnSnippet function was not generating properly the triggers (it was creating invalid css selectors with a string argument, treating it as a class when it could be any css selector).

This commit fixes this util.

[1]: https://github.com/odoo/odoo/commit/99b50d18e220aedf14de806f4bf1b2d35c32de35

opw-3026167




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

Forward-Port-Of: odoo/odoo#103439

This commit introduce a field to determine condition for reloading chatter parent view when a file has changed. This allow patching the field so that more conditions could trigger a view reload. Task-2886634 Enterprise: https://github.com/odoo/enterprise/pull/32982 Forward-Port-Of: odoo/odoo#103557

This commit introduce a field to determine condition for
reloading chatter parent view when a file has changed.

This allow patching the field so that more conditions
could trigger a view reload.

Task-2886634

Enterprise: https://github.com/odoo/enterprise/pull/32982

Forward-Port-Of: odoo/odoo#103557

# Current behavior before PR:   # Desired behavior after PR is merged:  ![image](https://user-images.githubusercontent.com/1159815/196902571-c797882c-e6d7-476d-b29

# Current behavior before PR:
![image](https://user-images.githubusercontent.com/1159815/196902902-0b9e3096-d7f5-45e3-92f1-02fa773039db.png)
![image](https://user-images.githubusercontent.com/1159815/196903055-ee62dd00-82c2-4b8c-ba2a-e1622f316b49.png)

# Desired behavior after PR is merged:
![image](https://user-images.githubusercontent.com/1159815/196904592-eb460cab-7b46-40ea-8fd5-ce6a188dcb50.png)
![image](https://user-images.githubusercontent.com/1159815/196902571-c797882c-e6d7-476d-b29c-0cc2ed9fdbbf.png)

Forward-Port-Of: odoo/odoo#103613

The emoji search bar should not be automatically focused when using odoo on mobile. This commit re-introduce the auto-focus of the search bar, and also cancel auto-focus if using odoo on mobile Task-3015386 Forward-Port-Of: odoo/odoo#103410

The emoji search bar should not be automatically focused when using odoo on mobile.

This commit re-introduce the auto-focus of the search bar, and also cancel auto-focus if using odoo on mobile

Task-3015386

Forward-Port-Of: odoo/odoo#103410

t-groups has no effect 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#103645

t-groups has no effect

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#103645

This `s_social_media` snippet option uses a variable defined in the module's scope to store social media values. This reduces the amount of RPCs needed to fetch the data as they will only be done once per edition. Prior to commit [1], this cache would only exist as long as the page lived. Which means that switching website, switching page or going in the backend would reset its value. Commit [1] moved the edition in the backend which means that the cache would persist between pages but

This `s_social_media` snippet option uses a variable defined in the
module's scope to store social media values. This
reduces the amount of RPCs needed to fetch the data as they will only be
done once per edition.

Prior to commit [1], this cache would only exist as long as the page
lived. Which means that switching website, switching page or going in
the backend would reset its value. Commit [1] moved the edition in the
backend which means that the cache would persist between pages but more
importantly, between websites, only resetting if the backend was
refreshed or left.

Steps to reproduce:
- Go on website 1
- Modify the URL for facebook in the footer
- Go on website 2
- The value is the same when it should still be facebook.com/Odoo

This commit fixes that by resetting the cache when the editor is
destroyed.

[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b

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#98710

Steps to reproduce: - Install Accounting App. - Go to the Accounting App. - Click on 'Accounting' -> 'Assets'. - Create a new asset and confirm it. - Click on 'Modify Depreciation'. - Select the 'Sell' action. - Click on the empty 'Customer Invoice' field. Observed behavior: The invoices are listed based on their name, which is not very explicit/helpful. Desired behavior: In addition to the name, the partner and the date are also displayed in the list. The search is also improv

Steps to reproduce:
- Install Accounting App.
- Go to the Accounting App.
- Click on 'Accounting' -> 'Assets'.
- Create a new asset and confirm it.
- Click on 'Modify Depreciation'.
- Select the 'Sell' action.
- Click on the empty 'Customer Invoice' field.

Observed behavior:
The invoices are listed based on their name, which is not very explicit/helpful.

Desired behavior:
In addition to the name, the partner and the date are also displayed in the list.

The search is also improved, in order to use the partner name
(in addition to the invoice name) to filter invoices.

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

Forward-Port-Of: odoo/odoo#103400

Steps to reprodue: - enable any rtl language (arabic) - move to the product page for exemple - the page is frozen (dependecy loop in css) Bug: when the CSS gets minified the missing semicolon error spreads and produce an invalid file Fix: added the missing semicolon opw-3019173 opw-3032064 opw-3032250 opw-3035077 opw-3034712 opw-3035077 opw-3023730 opw-3022962 Forward-Port-Of: odoo/odoo#103681

Steps to reprodue:
- enable any rtl language (arabic)
- move to the product page for exemple
- the page is frozen (dependecy loop in css)

Bug:
when the CSS gets minified the missing semicolon error spreads and produce an invalid file

Fix:
added the missing semicolon

opw-3019173 
opw-3032064 
opw-3032250 
opw-3035077 
opw-3034712 
opw-3035077 
opw-3023730 
opw-3022962

Forward-Port-Of: odoo/odoo#103681

This pull request updates spreadsheet-related code in the Documents area as part of NGR testing. The change appears to support testing or validation work rather than introducing a clear business-facing feature.

Some confusion during the development phase led to implement another `degressive_then_linear` method than the standard one. task-id: None - correction pad Forward-Port-Of: odoo/enterprise#32658

Some confusion during the development phase led to implement another `degressive_then_linear` method than the standard one.

task-id: None - correction pad

Forward-Port-Of: odoo/enterprise#32658

Steps to reproduce: - Install Accounting App. - Go to the Accounting App. - Click on 'Accounting' -> 'Assets'. - Create a new asset and confirm it. - Click on 'Modify Depreciation'. - Select the 'Sell' action. - Click on the empty 'Customer Invoice' field. Observed behavior: The invoices are listed based on their name, which is not very explicit/helpful. Desired behavior: In addition to the name, the partner and the date are also displayed in the list. The search is also improv

Steps to reproduce:
- Install Accounting App.
- Go to the Accounting App.
- Click on 'Accounting' -> 'Assets'.
- Create a new asset and confirm it.
- Click on 'Modify Depreciation'.
- Select the 'Sell' action.
- Click on the empty 'Customer Invoice' field.

Observed behavior:
The invoices are listed based on their name, which is not very explicit/helpful.

Desired behavior:
In addition to the name, the partner and the date are also displayed in the list.

The search is also improved, in order to use the partner name or the date to filter the invoices.

Forward-Port-Of: odoo/enterprise#32844

The web framework / owl automatically fetches records from the server when required. It is done in the low-level useModel hook, that is used by most views. Since the Account Move Line List (and batch list) are full list views embedded inside a form view - any rerender to the form view will re-render child components and therefore trigger the model.load function. On larger databases, fetching the same list of records can have a significant impact on performance. To avoid this unneccessary call

The web framework / owl automatically fetches records from the server when required. It is done in the low-level useModel hook, that is used by most views. Since the Account Move Line List (and batch list) are full list views embedded inside a form view - any rerender to the form view will re-render child components and therefore trigger the model.load function. On larger databases, fetching the same list of records can have a significant impact on performance.

To avoid this unneccessary call, an override of the relational model is used. A condition (the domain has changed) is applied before the reload of records, hence reducing the number of web_search_reads. This also ensures that users are still able to search for move lines and batches.

Forward-Port-Of: odoo/enterprise#32898

Before this commit, when uploading a file in chatter on `hr.applicant`, we had to manually reload the view to see alert to let us know an OCR process is running from this file upload. This happens because showing of alert requires reloading the view, but file upload does not reload view. This is intended behaviour for most view, as it's unnecessary. In the case of `hr.applicant`, we want to reload view. This commit fixes the problem by patching triggering rule to reload view of chatter

Before this commit, when uploading a file in chatter on `hr.applicant`, we had to manually reload the view to see alert to let us know an OCR process is running from this file upload.

This happens because showing of alert requires reloading the view, but file upload does not reload view. This is intended behaviour for most view, as it's unnecessary.

In the case of `hr.applicant`, we want to reload view.

This commit fixes the problem by patching triggering rule to reload view of chatter from a file upload, so that it always does it when it's a view on `hr.applicant`.

Note that this solution is specific to `hr.applicant`. So other models with OCR process in background won't work until they add a similar patch.

As future work, would be nice to have awareness of presence of OCR process in background, so that code relies instead on this information and it will work for any views that has this future.

Task-2886634

Community: https://github.com/odoo/odoo/pull/103557

Forward-Port-Of: odoo/enterprise#32982

This fix sets a default value to PlanningSlot.repeat_until (today + 1 week, as the default repeat_unit is 'week'). This will play the role of a 'placeholder' in the form view. task-3007122 related: https://github.com/odoo/odoo/pull/102860 Forward-Port-Of: odoo/enterprise#32615

This fix sets a default value to PlanningSlot.repeat_until (today + 1 week, as the default repeat_unit is 'week'). This will play the role of a 'placeholder' in the form view.

task-3007122
related: https://github.com/odoo/odoo/pull/102860

Forward-Port-Of: odoo/enterprise#32615

[FIX] account consolidation export xlsx Xlsx was not working on account consolidation because the headers were not generate properly. Account reports expect headers to be in a list of lists and account consolidation was not in that format. Also some function in account reports change signature so account consolidation needed to update them. Forward-Port-Of: odoo/enterprise#32234

[FIX] account consolidation export xlsx

Xlsx was not working on account consolidation because the headers were not generate properly. Account reports expect headers to be in a list of lists and account consolidation was not in that format.

Also some function in account reports change signature so account consolidation needed to update them.

Forward-Port-Of: odoo/enterprise#32234

When importing BoM, consumable products shall not be added to the MPS. Task : 2985735 Forward-Port-Of: odoo/enterprise#32949

When importing BoM, consumable products shall not be added to the MPS.
Task : 2985735

Forward-Port-Of: odoo/enterprise#32949

To avoid warnings in the click_all nightly test Forward-Port-Of: odoo/enterprise#32941

To avoid warnings in the click_all nightly test

Forward-Port-Of: odoo/enterprise#32941

In tablet view, a traceback occurs when 'set a new picture' on a step task: 2985735 Forward-Port-Of: odoo/enterprise#32922

In tablet view, a traceback occurs when 'set a new picture' on a step

task: 2985735

Forward-Port-Of: odoo/enterprise#32922