**Steps to reproduce:** - Install account_accountant, sale_management and l10n_sa - Switch to a Saudi Arabian company (e.g. SA Company) - Create a payment term: * Description on the Invoice: [anything] * Display terms on invoice: [checked] * Terms: [add many lines] - Create a SO: * Customer: [any] * Payment Terms: [the created payment term] * Order lines: [anything] - Confirm the SO - Create an invoice from the SO - Confirm the invoice - Generate the invoice **Issue:

**Steps to reproduce:**
- Install account_accountant, sale_management and l10n_sa
- Switch to a Saudi Arabian company (e.g. SA Company)
- Create a payment term:
  * Description on the Invoice: [anything]
  * Display terms on invoice: [checked]
  * Terms: [add many lines]
- Create a SO:
  * Customer: [any]
  * Payment Terms: [the created payment term]
  * Order lines: [anything]
- Confirm the SO
- Create an invoice from the SO
- Confirm the invoice
- Generate the invoice

**Issue:**
The description of the payment term is displayed on the invoice but the terms are not displayed as it is the case in any other localization.

**Cause:**
"report_invoice" is replaced by the Arabic/English invoice in l10n_gcc_invoice module.
However, the logic to display the terms has not been added in the template for Arabic/English invoice.

opw-4291232



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

Forward-Port-Of: odoo/odoo#188456

**Steps to reproduce:** - Install Accounting - Create a branch - Archive the branch - Go to "Accounting / Configuration / Accounting / Chart of Accounts" - Click on the "View" button of any account **Issue:** An AccessError is raised: "Access to unauthorized or invalid companies." **Cause:** The "account.code.mapping" records are fetched for all the companies of the current user, even the archived ones. {'active_test': False} is added in the context in the read method of the One2m

**Steps to reproduce:**
- Install Accounting
- Create a branch
- Archive the branch
- Go to "Accounting / Configuration / Accounting / Chart of Accounts"
- Click on the "View" button of any account

**Issue:**
An AccessError is raised:
"Access to unauthorized or invalid companies."

**Cause:**
The "account.code.mapping" records are fetched for all the companies of the current user, even the archived ones.
{'active_test': False} is added in the context in the read method of the One2many class in fields.py

opw-4450588




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

Forward-Port-Of: odoo/odoo#193094

Before this PR, the "real-time connection lost" alert was displayed right after the disconnection was detected. This PR adds a 15s delay to avoid spamming the alert on unstable connexion. Task-4453176 Forward-Port-Of: odoo/odoo#192705

Before this PR, the "real-time connection lost" alert was displayed right after the disconnection was detected.
This PR adds a 15s delay to avoid spamming the alert on unstable connexion.

Task-4453176

Forward-Port-Of: odoo/odoo#192705

Portal users don't have access to delete attachments created by others. In this case, the trash icon shouldn't be displayed. This PR removes this icon from the attachment of a message when the message is not editable by the current user. Forward-Port-Of: odoo/odoo#192310

Portal users don't have access to delete attachments created by others. In this case, the trash icon shouldn't be displayed. This PR removes this icon from the attachment of a message when the message is not editable by the current user.

Forward-Port-Of: odoo/odoo#192310

This commit removes the existing currency rate before creating the new ones as there is a unicity constrains on the currency rate date. runbot-error: 111437 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#192831

This commit removes the existing currency rate before creating the new ones as there is a unicity constrains on the currency rate date.

runbot-error: 111437

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

The bank reconciliation widget shouldn't be allowed to work/match more than what's possible through the UI. Steps to reproduce the bug * create child company CHILD 1, with an invoice $100 * Create child company CHILD 2 with same parent company, a bank journal and a matching rule to fetch bills/invoices of same amount regardless of any other critera (for simplicity) * make sure the matching rule is applied 1st, create a bank transacation of $100 in CHILD 2 bank journal * click reconcile fr

The bank reconciliation widget shouldn't be allowed to work/match more than what's possible through the UI.

Steps to reproduce the bug
* create child company CHILD 1, with an invoice $100
* Create child company CHILD 2 with same parent company, a bank journal and a matching rule to fetch bills/invoices of same amount regardless of any other critera (for simplicity)
* make sure the matching rule is applied 1st, create a bank transacation of $100 in CHILD 2 bank journal
* click reconcile from the dashboard, on CHILD 2 bank journal => you get an access error because Odoo is trying to match invoice from CHILD 1 and bank transaction from CHILD 2

ticket-4384481


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

Forward-Port-Of: odoo/odoo#192507

Before this commit, "search more" would not find any matches if searching partners by VAT numbers. After this commit, it becomes possible to search and "load more" partners by VAT number. opw-4379852 Forward-Port-Of: odoo/odoo#190621 Forward-Port-Of: odoo/odoo#189703

Before this commit, "search more" would not find any matches if searching partners by VAT numbers.

After this commit, it becomes possible to search and "load more" partners by VAT number.

opw-4379852

Forward-Port-Of: odoo/odoo#190621
Forward-Port-Of: odoo/odoo#189703

__Current behavior before commit:__ In [`a27afdb`][1], the field `end_type` from the model `calendar.event` became computed and therefore not stored anymore. Databases that upgraded from an anterior version still have the column `end_type` in their table `calendar_event`. In [`f6df418`][2], a reference to `end_type` from the table `calendar_recurrence` has been added in the SQL query. If the field `end_type` is still in the table `calendar_event` it is ambiguous which one this query should

__Current behavior before commit:__
In [`a27afdb`][1], the field `end_type` from the model `calendar.event` became computed and therefore not stored anymore.
Databases that upgraded from an anterior version still have the column `end_type` in their table `calendar_event`.

In [`f6df418`][2], a reference to `end_type` from the table `calendar_recurrence` has been added in the SQL query. If the field `end_type` is still in the table `calendar_event` it is ambiguous which one this query should use.

Ultimately leading to this error:
```
psycopg2.errors.AmbiguousColumn: column reference "end_type" is ambiguous
LINE 22: ...                          WHEN cal.recurrency AND end_type =...
```

__Description of the fix:__
Remove the ambiguity by explicitly specifying `rrule`, the alias of the `calendar_recurrence` table.

opw-4406814

[1]: https://github.com/odoo/odoo/commit/a27afdb
[2]: https://github.com/odoo/odoo/commit/f6df418

Forward-Port-Of: odoo/odoo#192946

The current logic is not working when trying to invoice foreign customers. A few fields that could be useful are hidden, and we don't add the id information in the xml file which causes it to fail. In practice, it is valid to invoice a foreign customer and use a generic TIN if they don't have a malaysian one when reporting to the tax authorities. This change will allow just that; we add the id information to the xml which allow to correctly issue a valid invoice for a foreign customer (tested

The current logic is not working when trying to invoice foreign customers. A few fields that could be useful are hidden, and we don't add the id information in the xml file which causes it to fail.

In practice, it is valid to invoice a foreign customer and use a generic TIN if they don't have a malaysian one when reporting to the tax authorities. This change will allow just that; we add the id information to the xml which allow to correctly issue a valid invoice for a foreign customer (tested on pre- production)

opw-4438259

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

Forward-Port-Of: odoo/odoo#193091
Forward-Port-Of: odoo/odoo#193000

In modules l10n_cz and l10n_hu_edi the currency rate computation on the invoice lines was changed. Instead of using the standard date (i.e. Invoice Date) for the currency conversion we use the Taxable Supply Date (for l10n_cz / CZ) or Delivery Date (for l10n_hu_edi / HU). The way this was done conflicts with a change in 17.3: Since then we store and display the currency rate on invoices (See commit bedffa80beb61c134e8f476ef2ca71f2bd66f554 for more details). The rate for each line shoul

In modules l10n_cz and l10n_hu_edi the currency rate computation on
the invoice lines was changed. Instead of using the standard date
(i.e. Invoice Date) for the currency conversion we use the
Taxable Supply Date (for l10n_cz / CZ) or Delivery Date
(for l10n_hu_edi / HU).

The way this was done conflicts with a change in 17.3:
Since then we store and display the currency rate on invoices
(See commit bedffa80beb61c134e8f476ef2ca71f2bd66f554 for more details).
The rate for each line should then just be taken from the rate stored on the move.
Currently the rate on the invoice is still computed with the standard date (invoice date)
in any case.

So e.g. with l10n_cz installed it can happen happen that the lines of a CZ invoice
- compute the currency rate individually "themselves" instead of taking it from the invoice
  (which is one of the things the change in 17.3 wanted to prevent)
- use a different different date for the currency rate conversion than the invoice
  (in case the Taxable Supply Date is set)
I.e. the rate stored and displayed on the invoice may have nothing to do with the rate
that was actually used for the conversion.

Example that goes wrong currently for l10n_cz on runbot
  1. Install l10n_cz
  2. Select CZ Company
  3. Ensure the USD currency is as follows:
     - Starting on 2024-12-01 there is 10 units per CZK rate
     - There is no other currency rate defined
  4. Create an invoice
     - in USD
     - with invoice date 2024-11-01
     - Taxable Supply Date 2024-12-01
     - a single invoice line with price 100 and no taxes
  5. The invoice displays:
     - "1 CZK = 1.000000 USD" (Since we ignore the Taxable Supply Date)
     - total: 100 USD
  6. The "Journal Items" tab displays only 10 CZK total.
     (Since we use the Taxable Supply Date for the actual conversion)

Related commits: The currency rate computations for move lines were overridden
in commits e3bac6461500d34425697eed5a263c605f6f9de5 (l10n_cz) and
b1e07d27da27aad86049c8eae42e1803cf24bd3f (l10n_hu_edi) respectively.

This commit fixes the currency rate computation for these localizations:
We revert the changes to the currency rate computation on the lines and
adapt the date used for the currency rate computation on the invoice.
The invoice then displays the correct rate and the lines just take the (correct)
rate from the invoice.

Further for l10n_cz the taxable supply date is hidden on non-invoices and
ignored for currency computations on non-invoices.

task-4367605


related upgrade PR: https://github.com/odoo/upgrade/pull/6853

Forward-Port-Of: odoo/odoo#189023

In this commit: ==================== - The changes ensure better traceability by generating back-orders in a 'confirmed" state with serial numbers assigned, preventing unintended consumption of components. This approach enhances clarity and aligns with user expectations for managing partial production. task-4280758 Forward-Port-Of: odoo/odoo#187375

In this commit:
====================
- The changes ensure better traceability by generating back-orders in a
  'confirmed" state with serial numbers assigned, preventing unintended
  consumption of components. This approach enhances clarity and aligns with
  user expectations for managing partial production.

task-4280758

Forward-Port-Of: odoo/odoo#187375

Before this commit: creating stock lot records (multi) via the xml.rpc resulted in a bug: missing argument 'vals_list'. After this commit: It is possible to create multiple stock lot records without this bug --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193031

Before this commit: creating stock lot records (multi) via the xml.rpc resulted in a bug: missing argument 'vals_list'. 

After this commit: It is possible to create multiple stock lot records without this bug




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

Forward-Port-Of: odoo/odoo#193031

Currently when users have too many categories in their pos, their are not able to see the products and cannot scroll. Steps to reproduce: ------------------- * Add categories to the pos `> 20` * Open pos shop * Change the view size to a mobile view > Observation: We cannot see all categories, cannot scroll through them, and cannot see/select products Why the fix: ------------ In mobile view we will show only 2 rows of categories and allow to scroll to see the rest. This allows fo

Currently when users have too many categories in their pos, their are not able to see the products and cannot scroll.

Steps to reproduce:
-------------------
* Add categories to the pos `> 20`
* Open pos shop
* Change the view size to a mobile view
> Observation: We cannot see all categories, cannot scroll through them,
and cannot see/select products

Why the fix:
------------

In mobile view we will show only 2 rows of categories and allow to scroll to see the rest. This allows for space for the products to be shown.

If we have less than 3 categories and sub categories to show we will restrict the height to 1 row.

opw-4371390


## Before
![2024-12-16_mobile_before](https://github.com/user-attachments/assets/01e33d4c-0eed-4472-b64c-f53fba1edcfc)

## After
![2024-12-16_mobile_after](https://github.com/user-attachments/assets/a505df82-e45c-4448-afa8-1aea3739befb)
https://drive.google.com/file/d/1yBOEFqX6NbI-mCLjQ9aSR-yEzJ3am50E/view?usp=sharing

Forward-Port-Of: odoo/odoo#190707

Even if 5.1 is not technically supported, debuntu might switch to it any moment and we don't know if / when upstream will fix it, so it's not worth the time bomb. While technically it was always typed such, since py-pdf/pypdf#2820 it looks like `_info` is a lot more likely to be `None` as e.g. `clone_reader_document_root` now starts with unsetting `_info_obj` and never re-sets it. Except `add_metadata` was not updated to handle this case, likely because mypy interprets `assert isinstance(s

Even if 5.1 is not technically supported, debuntu might switch to it any moment and we don't know if / when upstream will fix it, so it's not worth the time bomb.

While technically it was always typed such, since py-pdf/pypdf#2820 it looks like `_info` is a lot more likely to be `None` as e.g. `clone_reader_document_root` now starts with unsetting `_info_obj` and never re-sets it.

Except `add_metadata` was not updated to handle this case, likely because mypy interprets `assert isinstance(self._info, DictionaryObject)` as a type narrowing and trusts the developer, thus does not report the type mismatch... and the assertion ends up blowing in the user's face at runtime with a simple

    >>> r = pypdf.PdfReader(some_pdf_document)
    >>> w = pypdf.PdfWriter()
    >>> w.clone_reader_document_root(r)
    >>> w.add_metadata({"/foo": "bar"})
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "lib/python3.12/site-packages/pypdf/_writer.py", line 1622, in add_metadata
        assert isinstance(self._info, DictionaryObject)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    AssertionError

This is rather inconsiderate, so monkeypatch `add_metadata` to handle the case where `_info` exists and is `None`.

Most of the credit goes to juwu for uncovering the issue.

opw-4372052
opw-4426881
Fixes #185673

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

In Odoo, an issue araised where the "Expected Arrival" date field was overlapped when zooming in. This was due to the button "action_purchase_vendor_delay_report". To adress this, the related button was encapsulated within a <div> element. This change ensure that the layout remains consistent and the elements does not overlap regardless of the zoom level. opw-4316093 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187

In Odoo, an issue araised where the "Expected Arrival" date field was overlapped when zooming in. This was due to the button "action_purchase_vendor_delay_report".

To adress this, the related button was encapsulated within a <div> element. This change ensure that the layout remains consistent and the elements does not overlap regardless of the zoom level.

opw-4316093

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

Forward-Port-Of: odoo/odoo#187179

Currently, an error is generated when the user tries to uninstall ``account`` module after installing ``account_inter_company_rules`` module. Steps to reproduce: --- - Install ``account_inter_company_rules`` module - Uninstall ``account`` module Traceback: --- ``KeyError: 'res.company.intercompany_purchase_journal_id'`` When we uninstall the account module, we set all associated fields related to 'account' (e.g., chart_template) to 'False'. Change: --- Force a recomputation by

Currently, an error is generated when the user tries to uninstall ``account`` module after installing ``account_inter_company_rules`` module.

Steps to reproduce:
---
- Install ``account_inter_company_rules`` module
- Uninstall ``account`` module

Traceback:
---
``KeyError: 'res.company.intercompany_purchase_journal_id'``

When we uninstall the account module, we set all associated fields related to 'account' (e.g., chart_template) to 'False'.

Change:
---
Force a recomputation by flushing the records.


sentry-6054886854

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

Forward-Port-Of: odoo/odoo#191154

Before this commit, a race condition could allow attempts to send peer notification to go through despite not having a call. This could happen if a `_busNotify()` call follows a promise that is resolved after the end of a call. This commit fixes this issue by ensuring that notifications can only be sent when a call is active. Forward-Port-Of: odoo/odoo#192947

Before this commit, a race condition could allow attempts to send peer notification to go through despite not having a call. This could happen if a `_busNotify()` call follows a promise that is resolved after the end of a call.

This commit fixes this issue by ensuring that notifications can only be sent when a call is active.

Forward-Port-Of: odoo/odoo#192947

Steps ----- - Have two companies A and B. - Activate Project Stages, and in the list of stages set the first one of the list as belonging to company A. - Create a project (from 'new' button in list view to be able to set a company at creation) belonging to company B (company B needs to be in the list of selected companies). - Save it: the project's company has changed to company A. Cause ----- If no stage is set on the project at creation, we default to the default stage provided by `_

Steps
-----
- Have two companies A and B.
- Activate Project Stages, and in the list of stages set the first one of the list as belonging to company A.
- Create a project (from 'new' button in list view to be able to set a company at creation) belonging to company B (company B needs to be in the list of selected companies).
- Save it: the project's company has changed to company A.

Cause
-----
If no stage is set on the project at creation, we default to the default stage provided by `_default_stage_id`, which is the first stage in sequence, regardless of its company.
We then change the company of the project to match the stage's company, which overrides the stage set at creation.

Change
-----
If the project has a company set a creation, use the first stage without a company or with the same company as the project.
This is done even if the user doesn't have multiple companies selected, since the `search` on `project.project.stage` can return a stage from another company than the one selected.

opw-4290711

Forward-Port-Of: odoo/odoo#192865
Forward-Port-Of: odoo/odoo#187635

Before this commit, when the user starts a new timer on the grid view and a timesheet is created, the timer is not marked as running on the row contained the project. Same issue when a timer is running and the user refreshes the page. This commit adds the needed data to make sure the grid view finds which row has the timer running. Forward-Port-Of: odoo/enterprise#76717

Before this commit, when the user starts a new timer on the grid view and a timesheet is created, the timer is not marked as running on the row contained the project. Same issue when a timer is running and the user refreshes the page.

This commit adds the needed data to make sure the grid view finds which row has the timer running.

Forward-Port-Of: odoo/enterprise#76717

Before this commit, when we did a search in the general ledger for an account code with alpha characters, (ex: `411EDP` in the search bar) the options resulted with `411edp`. It was changed to lowercase. And due to a change in the _name_search of account_account, it now uses like and not anymore ilike. Commit: https://github.com/odoo/odoo/commit/1f589682a9414312b8c15beec5a09e76b16c7c41 The fix is to provide to the options the original search query without lowercase. opw-4388517 Forw

Before this commit, when we did a search in the general ledger for an account code with alpha characters, (ex: `411EDP` in the search bar) the options resulted with `411edp`.

It was changed to lowercase. And due to a change in the _name_search of account_account, it now uses like and not anymore ilike.

Commit: https://github.com/odoo/odoo/commit/1f589682a9414312b8c15beec5a09e76b16c7c41

The fix is to provide to the options the original search query without lowercase.

opw-4388517

Forward-Port-Of: odoo/enterprise#76660
Forward-Port-Of: odoo/enterprise#76524

When we rename any doc without a name, it shows 'False' because the field isn't set as 'required.' Making it mandatory will trigger a red alert on save, ensuring a valid name is entered. Task-4367684 Forward-Port-Of: odoo/enterprise#76064

When we rename any doc without a name, it shows 'False' because the field isn't set as 'required.' Making it mandatory will trigger a red alert on save, ensuring a valid name is entered.

Task-4367684

Forward-Port-Of: odoo/enterprise#76064

## [FIX] knowledge: fix disappearing comments overlay This commit fixes an issue with the comments overlay when zooming and dezooming on the article. At certain sizes the overlay of the comment would disappear without reason. This is caused by the rect computations done to identify the correct overlay to draw. The target selected by the coordinates given to the `elementFromPoint` method would be incorrect. This happens because the coordinates weren't the center of the rectangle but the

## [FIX] knowledge: fix disappearing comments overlay

This commit fixes an issue with the comments overlay when zooming and dezooming
on the article.
At certain sizes the overlay of the comment would disappear without reason.
This is caused by the rect computations done to identify the correct overlay to
draw.
The target selected by the coordinates given to the `elementFromPoint` method
would be incorrect.
This happens because the coordinates weren't the center of the rectangle but the
top. Which means that for certain resolutions the element selected is the whole
body instead of the correct paragraph/text node.

Now, the coordinates are computed so that we are indeed at the center of the
rect.

## [FIX] knowledge: avoid opening new comments on click

This commit fixes an issue with the knowledge comments small UI.
When you create a comment in small UI and click on the overlay in the body of
the article, the newly created comments open its popover.

This behavior shouldn't happen in any circumstances except when in readonly
mode.

task-4463401

Forward-Port-Of: odoo/enterprise#76709

[FIX] account_reports: sections tour The sections' tour was breaking with the change of year. We use the generic tax report for doing the testing. The generic tax report has a periodicity of 1 month and opens at the previous period. Our tests where based on the current date year. It works fine except on the change of year. Indeed, we will be on January of year XXXX but the report will open on December of year YYYY. Now, we correctly remove 1 month to our dates to make sure we have

[FIX] account_reports: sections tour

The sections' tour was breaking with the change of year.

We use the generic tax report for doing the testing. The generic tax
report has a periodicity of 1 month and opens at the previous period.

Our tests where based on the current date year. It works fine except on
the change of year. Indeed, we will be on January of year XXXX but the
report will open on December of year YYYY.

Now, we correctly remove 1 month to our dates to make sure we have the
correct year.

We also took the time to replace the usage of Date of plain javascript
with DateTime of the luxon library.

Forward-Port-Of: odoo/enterprise#76606

In some cases, the default currency is set to EUR, which makes the FedEx tests fail as they are coded to work for USD. Runbot Error 107969 Forward-Port-Of: odoo/enterprise#75271

In some cases, the default currency is set to EUR, which makes the FedEx tests fail as they are coded to work for USD.

Runbot Error 107969

Forward-Port-Of: odoo/enterprise#75271

Steps to reproduce the bug: - Create a storable product “P1”: - Tracked with SN - Create a BoM: - no need to component - Add an operation “OP1” with steps - Control by product - Create a manufacturing order for one unit of P1 - Confirm the MO - Go to the shop floor and process “OP1” - Validate the MO - Go to the SN of P1 Problem: The quality checks are filtered using “search_default_lot_id = active_id”, which means only quality checks linked to th

Steps to reproduce the bug:
- Create a storable product “P1”:
   - Tracked with SN
   - Create a BoM:
       - no need to component
       - Add an operation “OP1” with steps
           - Control by product

- Create a manufacturing order for one unit of P1
- Confirm the MO
- Go to the shop floor and process “OP1”
- Validate the MO
- Go to the SN of P1

Problem:
The quality checks are filtered using “search_default_lot_id = active_id”,
which means only quality checks linked to the “search_default_lot_id”
are displayed. However, in this usecase, the "lot_id” is not set.
Instead, the "finished_lot_id" is used, causing the quality checks to be
hidden unless the filter is removed.

Solution:
the domain is properly prepared so no longer needs this filter: https://github.com/odoo-dev/enterprise/blob/33de674651017a79e4d010b054dfb2ccaf8b744c/quality_control/models/stock_lot.py#L23-L27

https://github.com/odoo-dev/enterprise/blob/33de674651017a79e4d010b054dfb2ccaf8b744c/quality_control/models/stock_lot.py#L20-L21

https://github.com/odoo-dev/enterprise/blob/33de674651017a79e4d010b054dfb2ccaf8b744c/quality_mrp_workorder/models/stock_lot.py#L10-L13

opw-4361358

Forward-Port-Of: odoo/enterprise#76376

…on sell/dispose Steps to reproduce: - Create an asset with an acquisition date on the 1st of January, 2 years ago. - Set the depreciation method to "Declining" with a duration of 2 years. - Confirm it. - Click on "Modify depreciation". - Dispose it on the 1st of January of this year (i.e. after the asset's total duration). Observed behavior: You'll be met with a division by zero error. Solution: Prevent any unnecessary computations as well as unwanted division by zero errors by

…on sell/dispose

Steps to reproduce:
- Create an asset with an acquisition date on the 1st of January, 2 years ago.
- Set the depreciation method to "Declining" with a duration of 2 years.
- Confirm it.
- Click on "Modify depreciation".
- Dispose it on the 1st of January of this year (i.e. after the asset's total duration).

Observed behavior:
You'll be met with a division by zero error.

Solution:
Prevent any unnecessary computations as well as unwanted division by zero errors by simply returning early when the asset's residual amount is zero.

A test is also added to cover this use case.

opw-4411877

Forward-Port-Of: odoo/enterprise#76733
Forward-Port-Of: odoo/enterprise#76555

In this commit, we wait the modal is shown (managed by jQuery) before to continue the tour. In these modals, if we don't wait for the modal is shown, as the tour engine can be too much fast, element in modal can be not focusable when we try to target it. In odoo/addons/website/static/src/js/content/website_root.js the class modal_show is added in _onModalShown: ```javascript _onModalShown: function (ev) { $(ev.target).addClass('modal_shown'); }, ``` This fix add classes in triggers

In this commit, we wait the modal is shown (managed by jQuery) before to continue the tour. In these modals, if we don't wait for the modal is shown, as the tour engine can be too much fast, element in modal can be not focusable when we try to target it.

In odoo/addons/website/static/src/js/content/website_root.js the class modal_show is added in _onModalShown:

```javascript
_onModalShown: function (ev) {
	$(ev.target).addClass('modal_shown');
},
```

This fix add classes in triggers to ensure modal is shown before continuing the tour.

Forward-Port-Of: odoo/enterprise#76605

Behavior Before the Commit: When generating a new payment link, the system creates a new mandate without explicitly setting the `company_id`. As a result, the default company (`company_id` of the public user, `user_id = 4`) is assigned, which may not match the intended company if the payment is being processed for a company other than the default one. This mismatch between the journal's company and the mandate's `company_id` prevents the payment from being completed. Fix: The `company_id` i

Behavior Before the Commit:
When generating a new payment link, the system creates a new mandate without explicitly setting the `company_id`. As a result, the default company (`company_id` of the public user, `user_id = 4`) is assigned, which may not match the intended company if the payment is being processed for a company other than the default one. This mismatch between the journal's company and the mandate's `company_id` prevents the payment from being completed.

Fix:
The `company_id` is properly set during mandate creation, aligning it with the payment link's associated company and preventing unexpected behavior.

Steps:
1) Configure two companies with accounting setups. 
2) Open the Payment Providers menu.
3) Select SEPA, activate test mode, and ensure it is published. 
4) Duplicate the SEPA payment provider, set the company_id to the second company, activate test mode, and ensure it is published. 
5) Go to any sales order in the first company, generate a payment link, open it, and select SEPA. Enter any fake IBAN — it will process successfully. 
6) Switch to the second company and repeat step 5. You will encounter an error message because the mandate is incorrectly assigned to the first company, preventing payment completion.

Forward-Port-Of: odoo/enterprise#76705

After creating the tax closing, users attempting to create a foreign fiscal position will see a traceback Steps to reproduce: - Go to Accounting / Reporting / Statement Reports / Tax Return - Click 'Closing Entry' and generate the report - Go to Accounting / Configuration / Accounting / Fiscal Positions - Create a new Fiscal position with: - Detect Automatically: true - Country: Germany - Foreign Tax ID: DE123456789 - Save Issue: Traceback will raise `AttributeError: 'accoun

After creating the tax closing, users attempting to create a foreign fiscal position will see a traceback

Steps to reproduce:
- Go to Accounting / Reporting / Statement Reports / Tax Return
- Click 'Closing Entry' and generate the report
- Go to Accounting / Configuration / Accounting / Fiscal Positions
- Create a new Fiscal position with:
  - Detect Automatically: true
  - Country: Germany
  - Foreign Tax ID: DE123456789
- Save

Issue: Traceback will raise
`AttributeError: 'account.fiscal.position' object has no attribute 'filter_multi_company'`

opw-4376837

Forward-Port-Of: odoo/enterprise#76492

Before this commit, the transaction row was locked when payment was performed in the subscription invoice cron. Using `SELECT FOR UPDATE` locks the entire row, primary key included (id in our case). As a result, it could prevent insertion or update or other table refering to the id too. As it is not necessary and could trigger unnecessary deadlock, it is better to rely on `SELECT FOR NO KEY UPDATE` which allow the update of foreign keys. https://www.postgresql.org/docs/16/explicit-locking.ht

Before this commit, the transaction row was locked when payment was performed in the subscription invoice cron.
Using `SELECT FOR UPDATE` locks the entire row, primary key included (id in our case). As a result, it could prevent insertion or update or other table refering to the id too. As it is not necessary and could trigger unnecessary deadlock, it is better to rely on `SELECT FOR NO KEY UPDATE` which allow the update of foreign keys.

https://www.postgresql.org/docs/16/explicit-locking.html#LOCKING-ROWS

See https://github.com/odoo/enterprise/pull/74078#discussion_r1873729342

taskid: 4391755

Forward-Port-Of: odoo/enterprise#76619

In this commit: ==================== - Adjusted the workflow to enable users to prepare manufacturing orders (MOs) for back-orders when clicking 'Produce All' for final products linked with serial numbers (SN), without blocking for quality checks when instructions are associated with any work order. task-4280758 Forward-Port-Of: odoo/enterprise#73886

In this commit:
====================
- Adjusted the workflow to enable users to prepare manufacturing orders (MOs) for back-orders when clicking 'Produce All' for final products linked with serial numbers (SN), without blocking for quality checks when instructions are associated with any work order.

task-4280758

Forward-Port-Of: odoo/enterprise#73886

The fix previously done[^1] was always removing the BIC number because it is "optional". While it should be optional, some banks require it for payments done in EUR. The reason the previous fix was done was to avoid having the `Othr` tag, but that tag won't be used outside of methods returning `False` explicitly for `_skip_CdtrAgt`. opw-4423834 [^1]: 1a221f2f3160a48dc7ba08ea59c6781071b1adf3 Forward-Port-Of: odoo/enterprise#76558

The fix previously done[^1] was always removing the BIC number because it is "optional". While it should be optional, some banks require it for payments done in EUR.
The reason the previous fix was done was to avoid having the `Othr` tag, but that tag won't be used outside of methods returning `False` explicitly for `_skip_CdtrAgt`.

opw-4423834

[^1]: 1a221f2f3160a48dc7ba08ea59c6781071b1adf3

Forward-Port-Of: odoo/enterprise#76558

Since #76586 the tour checks for exact values, if a pricelist happens to apply, then the product value will be altered and not match expectations. Reset pricelists to ensure consistent execution environment. Forward-Port-Of: odoo/enterprise#76809

Since #76586 the tour checks for exact values, if a pricelist happens to apply, then the product value will be altered and not match expectations.

Reset pricelists to ensure consistent execution environment.

Forward-Port-Of: odoo/enterprise#76809