Odoo Changelog — 2025-01-23

Thursday, January 23, 2025

143 changes

Branch: saas-17.2

17 changes

Bug Fixes(2)

Resolved issues and error corrections

[FIX] stock: compute accurate consumed quantities for lots

PR #194539

Coresaas-17.2stockMEDIUM

Manufacturing consumption totals now reflect only the quantities actually registered when users manually change lots in Shop Floor. This prevents incorrect over-consumption warnings, helping operators close production orders without false alerts.

Original PR description

Issue ----- When manually changing the quantity and lot consumed through the Shop Floor, the consumed quantity is computed wrong and the user gets a "Consumption Warning". Steps to reproduce ----- -…

Issue
-----
When manually changing the quantity and lot consumed through the Shop Floor, the consumed quantity is computed wrong and the user gets a "Consumption Warning".

Steps to reproduce
-----
- Install MRP
- Create a "Cons" product, tracked by lot
- Change the "Cons" on hand quantity, create lot 1 with 10 units & lot 2 with 20
- Create a "Final" product
- Create a Bill of Materials for "Final"
    - Add "Cons" as a component of the BoM
    - Add an operation to the BoM
        - Add an instruction to the operation with "Type" set to "Register Consumed Materials" & "Product To Register" set to "Cons"
- Create a Manufacturing Order for 20 of "Final" & confirm it (the "Cons" consumption should be split 10/10 between the 2 lots)
- Go to the Shop Floor
    - Register the production of the 20 units
    - Open the instruction
        - Change the consumed quantity to 20
        - Change the lot number to use the 2nd one
    - Mark as done & close the 

-> A pop-up appears because the consumed quantity is registered as 30 instead of the 20 that were actually used

Cause
-----
A stock move is automatically created with the manufacturing order for all of the required components. The problem arises when one of these components is tracked by lots. The move line for this component is created using the first available lot found. If this lot isn't sufficient, the remaining necessary quantity is taken from the next lot (through another move line). If the user manually changes the consumed quantity for a lot, it only updates the corresponding line.

When updating the line, it sets 'picked' as True so we can use this field to only use the actually registered consumed quantities for computing the total.

-----
Ticket:
opw-4357996

#manufacturing#shop-floor#inventory#lots

[FIX] account: do not affect base of tax without "is_base_affected"

PR #193451

Coresaas-17.2accountl10n_in_edil10n_in_edi_ewaybillMEDIUM

This fixes an invoicing issue where a later tax could be calculated on a base increased by an earlier tax even when that later tax was configured not to be affected. Businesses get more accurate invoice tax amounts and avoid incorrect totals in accounting and related Indian e-invoicing outputs.

Original PR description

**Steps to reproduce:**
- Install Accounting
- Create a first tax:
  * Tax Name: Tax1
  * Tax Computation: Percentage of Price
  * Tax Type: Sales
  * Amount: 20%
  * Label on Invoices: Tax1
  * Tax Group: Tax1
  * Affect Base of Subsequent Taxes: [Checked]
- Create a second tax:
  * Tax Name: Tax2
  * Tax Computation: Percentage of Price
  * Tax Type: Sales
  * Amount: 20%
  * Label on Invoices: Tax2
  * Tax Group: Tax2
  * Base Affected by Previous Taxes: [Not checked]
- Create an invoice
- Add an invoice line
- Add Tax1
- Add Tax2

**Issue:**
Base amount of Tax2 is affected by Tax1 when it should not.

opw-4450494




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

#taxes#invoicing#accounting

Other(15)

Miscellaneous changes

[FW][FIX] hw_drivers: detect Star printers again

PR #194754

Coresaas-17.2hw_drivers

Our "supported" method filtering detected printers had a condition introduced in v17 which was too strict and filtering out the STAR printers, so they were never detected anymore. This PR fixes this issue related PR: #174436 Forward-Port-Of: odoo/odoo#190367

Original PR description

Our "supported" method filtering detected printers had a condition introduced in v17 which was too strict and filtering out the STAR printers, so they were never detected anymore.

This PR fixes this issue
related PR: #174436

Forward-Port-Of: odoo/odoo#190367

[FW][IMP] l10n_mu: PDF invoice requirements

PR #194535

Coresaas-17.2l10n_mu_account

This commit add few data on the report_invoice for Mauritius localization. task-4379202 Forward-Port-Of: odoo/odoo#190723

Original PR description

This commit add few data on the report_invoice for Mauritius localization.

task-4379202

Forward-Port-Of: odoo/odoo#190723

[FW][IMP] mail: improve quote reply detection

PR #194689

Coresaas-17.2

We update quote detection for gmail and outlook: - gmail has simple wrapper divs with explicit classes - outlook has a mix of div ids and simple pattern-based quoting (everything under "<hr><div id="divRplyFwdMsg"/> seems to be considered a quote) Previously gmail just used blockquote, which still works but does not capture "On xx:xx:xx X <X@gmail.com> wrote:" headers, which are caught for outlook. Previously outlook had a wrapper div around divRplyFwdMsg which would set data-o-mail-quot

Original PR description

We update quote detection for gmail and outlook:
- gmail has simple wrapper divs with explicit classes
- outlook has a mix of div ids and simple pattern-based quoting (everything under "<hr><div id="divRplyFwdMsg"/> seems to be considered a quote)

Previously gmail just used blockquote, which still works but does not capture "On xx:xx:xx X <X@gmail.com> wrote:" headers, which are caught for outlook.

Previously outlook had a wrapper div around divRplyFwdMsg which would set data-o-mail-quote-container on it, and propagate to children. However it seems that outer div was either removed or is not always present, a heuristic is thus needed.

task-4381505

Forward-Port-Of: odoo/odoo#194615
Forward-Port-Of: odoo/odoo#192875

[FW][FIX] web: hide tooltip on html fields in calendar popover

PR #194749

Coresaas-17.2web

To reproduce: ============= - create an event on calendar with description containing html - on calendar view, click on the event to open the popover and hover on the description field -> the tooltip is displayed with raw html content Fix: ==== hide the tooltip on html fields in calendar popover as it's not needed opw-4356581 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194605 Forward-Port-Of: odoo/odoo#192104

Original PR description

To reproduce:
=============
- create an event on calendar with description containing html
- on calendar view, click on the event to open the popover and hover on the description field
-> the tooltip is displayed with raw html content

Fix:
====
hide the tooltip on html fields in calendar popover as it's not needed

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

Forward-Port-Of: odoo/odoo#194605
Forward-Port-Of: odoo/odoo#192104

[FW][FIX] hr_holidays: allow date modification for unapproved time off requests

PR #194744

Coresaas-17.2hr_holidays

Steps to Reproduce: • Install the Time Off app. • Create a new user and corresponding employee without any group in Time Off. • Create a new time off request with a start date < today's date. • Attempt to change the date, which results in a validation error. Issue: - Users are unable to modify time off requests, even if they are not yet approved. Fix: - Added a check to ensure that modifications are allowed for time off requests that are not in an approved state. task-4236572

Original PR description

Steps to Reproduce:
• Install the Time Off app.
• Create a new user and corresponding employee without any group in Time Off. 
• Create a new time off request with a start date < today's date. 
• Attempt to change the date, which results in a validation error.

Issue:
- Users are unable to modify time off requests, even if they are not yet approved.

Fix:
- Added a check to ensure that modifications are allowed for time off requests that are not in an approved state.

task-4236572

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

Forward-Port-Of: odoo/odoo#194718
Forward-Port-Of: odoo/odoo#190944

[FW][FIX] l10n_in: hide QR if upi id is not set

PR #194767

Coresaas-17.2l10n_in

**Steps to reproduce:** 1) Select the QR Codes option in settings (IN Company) 2) Do not enter an upi id in the company profile. 3) Go to invoice and preview/print the invoice. 4) Show that QR code without upi id and upi logos visible. **Cause:** - The condition of the upi id is not properly set to hide the block if upi is not set. **Fix:** - With this PR, the upi QR code and upi logos will not be visible if the upi id is not set. **task**-4426634 Forward-Port-Of: odoo/odoo#19206

Original PR description

**Steps to reproduce:**
1) Select the QR Codes option in settings (IN Company)
2) Do not enter an upi id in the company profile.
3) Go to invoice and preview/print the invoice.
4) Show that QR code without upi id and upi logos visible.

**Cause:**
- The condition of the upi id is not properly set to hide the block if upi is not set.

**Fix:**
- With this PR, the upi QR code and upi logos will not be visible if the upi id is not set.

**task**-4426634

Forward-Port-Of: odoo/odoo#192068

[FW][IMP] odoo: add config for cron connection time

PR #194742

Coresaas-17.2

Adds a configuration that can be used to mitigate PostgreSQL transactional errors with long-living connections and the `LISTEN/NOTIFY`[^1] functionality by re-establishing the database connection periodically. In the case that a connection outlives the transaction wraparound[^2] mechanism of postgres, the `LISTEN/NOTIFY` internal queue might contain references to transactions that have already been deleted by the system's (or a manual) `VACUUM`[^3] as it has its own transaction validit

Original PR description

Adds a configuration that can be used to mitigate PostgreSQL transactional errors with long-living connections and the `LISTEN/NOTIFY`[^1] functionality by re-establishing the database connection…

Adds a configuration that can be used to mitigate PostgreSQL
transactional errors with long-living connections and the
`LISTEN/NOTIFY`[^1] functionality by re-establishing the database
connection periodically.

In the case that a connection outlives the transaction wraparound[^2]
mechanism of postgres, the `LISTEN/NOTIFY` internal queue might contain
references to transactions that have already been deleted by the
system's (or a manual) `VACUUM`[^3] as it has its own transaction
validity mechanisms (roughly comparing transaction ids).

This can be reproduced by:
 - Triggering a wraparound _AND_ cleaning of pg_xact between the cron's
   `LISTEN` + `COMMIT` and its recyling.
 - Having done at least one `NOTIFY` during that time period (?).
 - Try to `LISTEN` to the same channel on the same database (transcation
   id must be < than the first connection's transaction id).

The following is an example error message:
```
ERROR database odoo.service.server: Worker (3194772) Exception occurred, exiting...
Traceback (most recent call last):
  File "/home/user/odoo/service/server.py", line 1089, in run
    self.start()
  File "/home/user/odoo/service/server.py", line 1235, in start
    self.dbcursor.commit()
  File "/home/user/odoo/sql_db.py", line 480, in commit
    result = self._cnx.commit()
             ^^^^^^^^^^^^^^^^^^
psycopg2.errors.UndefinedFile: could not access status of transaction 1194816979
DETAIL:  Could not open file "pg_xact/0473": No such file or directory.
```

[LISTEN/NOTIFY code](https://github.com/postgres/postgres/blob/REL_16_STABLE/src/backend/commands/async.c)

[Connection being kept](https://github.com/postgres/postgres/blob/REL_16_STABLE/src/backend/commands/async.c#L2167-L2191)

[See more](https://www.postgresql.org/message-id/flat/VE1PR03MB531295B1BDCFE422441B15FD92499%40VE1PR03MB5312.eurprd03.prod.outlook.com#7e36d1fdca921b5292e92c7017984ffa)

[^1]: https://www.postgresql.org/docs/current/sql-notify.html
[^2]: https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND
[^3]: https://www.postgresql.org/docs/17/sql-vacuum.html

Forward-Port-Of: odoo/odoo#194705
Forward-Port-Of: odoo/odoo#194141

[FW][ADD] l10n_ro_edi_etransport: send transport data to eTransport platform

PR #194724

Coresaas-17.2accountl10n_ro_edi_stockl10n_ro_edi_stock_batch

Romania requires its companies to send information of all transports of goods on Romanian territory to a specific web service on their eTransport platform. This commit implements a way to gather all the necessary data needed to send the eTransport document and the actual sending of this document to the eTransport platform. Authentication: the authentication needed to interact with the eTransport platform is the same as (and was already implemented in) the l10n_ro_efactura module. see [eFa

Original PR description

Romania requires its companies to send information of all transports of goods on Romanian territory to a specific web service on their eTransport platform.

This commit implements a way to gather all the necessary data needed to send the eTransport document and the actual sending of this document to the eTransport platform.

Authentication:
the authentication needed to interact with the eTransport platform is the same as (and was already implemented in) the l10n_ro_efactura module. see [eFactura PR](https://github.com/odoo/odoo/pull/144061)

eTransport flow:
- Add the necessary eTransport data to a delivery
- send the eTransport document to ANAF
- the document gets processed by ANAF
- Fetch the status of the document:
    - which can result in an error, in which case the flow starts again from the beginning with the corrected data
    - or in a success

 task-id: 3810735

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

Forward-Port-Of: odoo/odoo#170080

[FW][FIX] hr_attendance: kiosk images out of box

PR #194817

Coresaas-17.2hr_attendance

Issue: When using the kiosk in versions 17.0 & 17.2, 2 visual issues arise: - when trying to identify manually, the "Go back" arrow is cropped out of its' container - when identified, the user's profile picture is cropped out of the greeting container Steps to reproduce: - Install the attendance module - Go to Kiosk Mode - Identify Manually Cause: For the "Go back arrow", its' position in the container is set to the top left corner (absolute 0;0). The problem is that these coordinat

Original PR description

Issue:
When using the kiosk in versions 17.0 & 17.2, 2 visual issues arise:
- when trying to identify manually, the "Go back" arrow is cropped out of its' container
- when identified, the user's profile picture is cropped out of the greeting container

Steps to reproduce:
- Install the attendance module
- Go to Kiosk Mode
- Identify Manually

Cause:
For the "Go back arrow", its' position in the container is set to the top left corner (absolute 0;0). The problem is that these coordinates are set for the center of the button and not its' top-left end. For the profile pictures, there is some V16 styling still present that wrongly sets the image's absolute position.

Notes:
I also changed the back button on the PIN screen since it had the same problem. It isn't pretty but everything is visible now...
![image](https://github.com/user-attachments/assets/6eee3958-e12c-44a8-bd8c-42d2f36119f6)


Ticket:
opw-4366047

Forward-Port-Of: odoo/odoo#191234

[FW][FIX] point_of_sale: handle inaccessible paid orders

PR #193418

Coresaas-17.2point_of_sale

Before this commit, when a user without access to certain orders attempted to load paid orders, the process would fail and result in an error. This was particularly problematic if a POS order was linked to a sale order that the user did not have permission to access, causing the entire loading process to halt. This commit addresses the issue by filtering out paid orders that the user cannot access. opw-4108044 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.c

Original PR description

Before this commit, when a user without access to certain orders attempted to load paid orders, the process would fail and result in an error. This was particularly problematic if a POS order was linked to a sale order that the user did not have permission to access, causing the entire loading process to halt.

This commit addresses the issue by filtering out paid orders that the user cannot access.

opw-4108044

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

Forward-Port-Of: odoo/odoo#192702
Forward-Port-Of: odoo/odoo#177592

[FW][FIX] web_editor: prevent adding empty `p` when deleting an image

PR #194849

Coresaas-17.2web_editor

**Problem**: When an image inside a `` tag (e.g., `<img>`) is deleted using the toolbar delete button, the selection is not properly restored, leaving an empty `` in the DOM and the selection in the editor root. **Solution**: Restore the selection to the correct position after deleting the image to avoid leaving an empty ``. **Steps to Reproduce**: 1. Open an empty editor and add an image. 2. Delete the image using the toolbar delete button. 3. Inspect the DOM: - A

Original PR description

**Problem**:
When an image inside a `<p>` tag (e.g., `<p><img></p>`) is deleted using the toolbar delete button, the selection is not properly restored, leaving an empty `<p>` in the DOM and the selection in the editor root.

**Solution**:
Restore the selection to the correct position after deleting the image to avoid leaving an empty `<p>`.

**Steps to Reproduce**:
1. Open an empty editor and add an image.
2. Delete the image using the toolbar delete button.
3. Inspect the DOM:
   - An empty `<p>` remains, and the selection is in the editor root.

opw-4472173

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

Forward-Port-Of: odoo/odoo#193396

[FW][FIX] stock: prioritize routes by sequence in extract_rule

PR #194706

Coresaas-17.2stock

### Description of the issue/feature this PR addresses: When a product is configured with both buy and manufacture routes, the manufacture route is always prioritized, regardless of the sequence defined in the routes. ### Current behavior before PR: The method extract_rule stops evaluating routes once it finds a valid rule, even if other rules with a lower sequence exist. This leads to the manufacture route being prioritized over buy, which is not the intended behavior. ### Desired behav

Original PR description

### Description of the issue/feature this PR addresses:
When a product is configured with both buy and manufacture routes, the manufacture route is always prioritized, regardless of the sequence defined in the routes.

### Current behavior before PR:
The method extract_rule stops evaluating routes once it finds a valid rule, even if other rules with a lower sequence exist. This leads to the manufacture route being prioritized over buy, which is not the intended behavior.

### Desired behavior after PR is merged:
The routes are now evaluated based on their sequence, ensuring that rules associated with routes of lower sequence are considered first.



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

Forward-Port-Of: odoo/odoo#188846

[FW][FIX] sale_purchase: read service_to_purchase from the order's company

PR #194432

Coresaas-17.2sale_purchase

Steps to reproduce: 1. Create two companies: Company A and Company B 2. Create a service product 3. Configure the product to be purchased on Company A and not on Company B 4. Create a sales order on Company B, while logged in Company A 5. Confirm the order Expected result: The service PO is created on Company B, even though it was configured not to. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192561 For

Original PR description

Steps to reproduce:

1. Create two companies: Company A and Company B
2. Create a service product
3. Configure the product to be purchased on Company A and not on Company B
4. Create a sales order on Company B, while logged in Company A
5. Confirm the order

Expected result:

The service PO is created on Company B, even though it was configured not to.



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

Forward-Port-Of: odoo/odoo#192561
Forward-Port-Of: odoo/odoo#177659

[FW][FIX] auth_ldap: add email on new res.partner

PR #193800

Coresaas-17.2auth_ldap

Before this commit, when a new res.user is created after signing in with auth_ldap, there was no email on the linked res.partner, which may cause issues in modules such as helpdesk, where partner email is used to find related tickets. res.users created through the form view will trigger the onchange which sets the 'email' = 'login', which does not happen when creating a user directly through the ORM. This commit adds 'email' as a key which is returned by the method _map_ldap_attributes, wh

Original PR description

Before this commit, when a new res.user is created after signing in with auth_ldap, there was no email on the linked res.partner, which may cause issues in modules such as helpdesk, where partner email is used to find related tickets.

res.users created through the form view will trigger the onchange which sets the 'email' = 'login', which does not happen when creating a user directly through the ORM.

This commit adds 'email' as a key which is returned by the method _map_ldap_attributes, which is used to create new partners with the correct email associated with the res.user login.

opw-4378487



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

Forward-Port-Of: odoo/odoo#193495

[FW][FIX] mrp: bypass set_qty_producing on lot creation for MO

PR #194847

Coresaas-17.2mrp

### Steps to reproduce: - Create a product tracked by LOT (not SN) - Create a BOM for that product and a BOM line with a tracked product - Put a an SN for your component in STOCK. - Create an MO for 1 unit of your product and confirm. > The SN should be set on your component line. - Set an LOT on the finished product with the create option but without clicking on the [+] #### > The quantity of the component line was updated to 0 and the SN of the comp was removed. ### Cause of the is

Original PR description

### Steps to reproduce:

- Create a product tracked by LOT (not SN)
- Create a BOM for that product and a BOM line with a tracked product
- Put a an SN for your component in STOCK.
- Create an MO for 1 unit of your product and confirm.
> The SN should be set on your component line.
- Set an LOT on the finished product with the create option but without clicking on the [+]
#### > The quantity of the component line was updated to 0 and the SN of the comp was removed.

### Cause of the issue:

Changing the lot on the MO form will trigger the `_onchange_producing` which will in turn `_set_qty_producing`:
https://github.com/odoo/odoo/blob/83445d91a588958417fef8a04d1187974d4b3d9a/addons/mrp/models/mrp_production.py#L797-L799 In case the product is tracked by SN this `_set_qty_producing` will set a qty_producing of 1 and the move raws will reserve a quantity accordingly but if the product is tracked by lot or not tracked at all the quantities of the move raw will just be adapted to match the `qty_producing` (that was at 0 from the start):
https://github.com/odoo/odoo/blob/83445d91a588958417fef8a04d1187974d4b3d9a/addons/mrp/models/mrp_production.py#L1217-L1227

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

Forward-Port-Of: odoo/odoo#192932

Branch: master

7 changes

Improvements(6)

Enhancements to existing features

[IMP] account_reports: make extra option filter getters smarter

PR #75878

Enterprisemasteraccount_reportsaccount_disallowed_expenses_fleetaccount_reports_cash_basisl10n_ph_reports

Accounting report extra option filters are now configured in one place and displayed automatically. This reduces repetitive setup work when adding new filters, making future report improvements faster and less error-prone.

Original PR description

This is kind of bad that each time we add a new filter in the Extra
Option section, we also have to manually override
`hasExtraOptionsFilter` to add that new filter.

With this commit, some intelligence is given to the extra options
filters ,by documenting them in the new getter `filterExtraOptionsData`.
So now, the dev that wants to add a new filter will just have to extends
this getter.
He will not need to extend `hasExtraOptionsFilter` or to create the
component manually, this is now done automatically.

task-3676838

#accounting#reports#filters#maintenance

[IMP] hr_appraisal: simplifiy UI

PR #75305

Enterprisemasterhr_appraisalhr_appraisal_skillsMEDIUM

The appraisal interface is streamlined to reduce clutter and make important statuses easier to understand. Users see clearer appraisal cards and landing pages, with low-value meeting, ready, and cancelled indicators removed to make day-to-day appraisal management simpler.

Original PR description

- make landing screen more clear by removing the searchpanel
- change the ribbon color code to be expressive
- Remove the cancel state as it does not have a real meaning in the appraisal case and the ralted demo data to show the action
- clean up the kanban card by removing thr meeting line and move the activity to right
- remove meetings stat button as it does not add real value just more complexity
-  remove the Ready indecation and it also does not add any real value

Task: 4387891

#appraisals#user interface#employee experience

[IMP] hr_payroll: make rate editable in edit payslip line wizard

PR #76207

Enterprisemasterhr_payroll

Payroll users can now manually adjust the rate when editing payslip lines. This gives payroll teams more flexibility to correct or customize individual line calculations without needing a workaround.

Original PR description

There is no reason for the rate to be readonly here. The user may want to change
 the rate manually on any line.

 Task: 4432908

#payroll#payslips#manual adjustment

[IMP] hr_payroll: Single refund open in form view

PR #76371

Enterprisemasterhr_payroll

Payroll users creating a single refund are now taken directly to the refund form instead of first seeing a list view. This reduces an unnecessary step and makes the refund workflow smoother for routine payroll processing.

Original PR description

- edit `refund_sheet` to return differnt action when the refund is singular to directly open the form view without the intermediate list one

Task: 3853337

#payroll#refund#usability

[IMP] web_gantt: simplify expand/collapse buttons

PR #77479

Enterprisemasterweb_ganttMEDIUM

The Gantt view now shows either the expand or collapse rows button, instead of both at once, with clearer icons. This makes row controls easier to understand and keeps row expansion behavior more consistent with other list-style views.

Original PR description

We make only one of the buttons "Expand rows"/"Collapse rows" appear and use
different icons. Now the button "Collapse rows" only appears when no row is
folded. For this to work correctly, we have to clear more often the set
closedRows. Roughly speaking, we clear that set in such a way that an automatic
expand happens when it would happen in similar situations in the list view.

Task ID: 4500469

#gantt#usability#row controls

[IMP] l10n_*_hr_payroll: improve demo data

PR #76847

Enterprisemasterl10n_eg_hr_payrolll10n_jo_hr_payrolll10n_pk_hr_payrolll10n_sa_hr_payrolll10n_tr_hr_payroll

Demo payroll setups were expanded for Egypt, Jordan, Pakistan, Saudi Arabia, and Turkey. Each localization now includes a sample company, departments, jobs, employees, and contracts, making it easier for users and evaluators to explore payroll features with realistic examples.

Original PR description

*: sa, eg, jo, tr, pk

Add a demo company for each payroll localization.
Add two demo departments, two demo jobs, two demo employees, and two demo contracts for each payroll localization.

task-4184929

#payroll#demo data#localization

Other(1)

Miscellaneous changes

[FW][FIX] account_followup: report not used

PR #77693

Enterprisemaster

The test breaks https://github.com/odoo/odoo/pull/184482 In 18.0, partner ledger is used for the followup. Keep the test as it still assess we recover the lines correctly. Forward-Port-Of: odoo/enterprise#73668

Original PR description

The test breaks https://github.com/odoo/odoo/pull/184482

In 18.0, partner ledger is used for the followup. Keep the test as it still assess we recover the lines correctly.

Forward-Port-Of: odoo/enterprise#73668

Branch: 18.0

76 changes

New Features(2)

New functionality added to Odoo

[IMP] spreadsheet_account: Add formula ODOO.RESIDUAL and ODOO.PARTNER.BALANCE

PR #194567

Core18.0spreadsheet_accountMEDIUM

Odoo spreadsheets can now calculate residual account amounts and partner balances directly with new formulas. This helps finance users analyze receivables, payables, and partner activity over selected periods without leaving the spreadsheet.

Original PR description

Problem --------- There is currently no formula to get the residual amount of accounts nor to get the balance of a partner in a given period of time in spreadsheets. Objective --------- Add the…

Problem
---------
There is currently no formula to get the residual amount of accounts nor to get the balance of a partner in a given period of time in spreadsheets.

Objective
---------
Add the formula ODOO.RESIDUAL and ODOO.PARTNER.BALANCE that do just that

ODOO.RESIDUAL should take the following parameters:
- account_codes (mandatory)(can be more than one separate by ,): could be optional, in that case it could set the domain to all receivables/payables accounts
- due_date_range or expected_date (optional): date range referred to due dates (not AML date)
- offset (optional): adding the possibility of the offset to be not only “Year” but also, a specific date or other periods like Month, Quarter.
- company_id (optional)
- include_unposted (optional) (default: false)

ODOO.PARTNER.BALANCE should take the following paramters:
- partner_ids (mandatory) (can be more than one separate by ,)
- accound_codes (optional) (the prefix of the account(s))
- date_range (optional) (21/12/2022,Q1 2022, 12/2022, 2022)
- offset (optional) (default: 0)
- company_id (optional)
- include_unposted (optional) (default: false)

Solution
---------
1. Define the spreadsheet function with the correct parameters in `accounting_function.js`
2. Hook it to the data source so that it can perform server calls
3. Craft that server python function to returns the list a residual amounts for the given list of parameters.
4. Adds some tests.

Task-3679808

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

#spreadsheets#accounting#reporting

[IMP] account_reports: Add Customer Statement Variant

PR #76727

Enterprise18.0account_reportsaccount_followupaccount_saftMEDIUM

A new customer statement report variant is available in accounting, making it easier to review a customer's outstanding balances and account activity. This helps finance teams share clearer account status information with customers and follow up on payments more efficiently.

Original PR description

task-4328333

#customer statements#accounting#reporting#payments

Improvements(5)

Enhancements to existing features

[IMP] l10n_mx_hr_payroll: add mexican localisation

PR #189466

Core18.0l10n_mxl10n_mx_hr_payrollHIGH

The Mexican payroll localization has been reworked to better meet local authority requirements. This delivers a compliant payroll setup for full-time employment, with other employment cases planned separately.

Original PR description

This is a rework of the mexican localisation to make it compliant with the local
 authorities. In our case, it will be a working system only for the full-time
 jobs. The other cases will be coming separately.

Task: 3673251

#mexico#payroll#localization#compliance

[IMP] crm: add link to Ringover in settings

PR #194678

Core18.0crm

CRM settings now include a link to Ringover, a partner browser extension for VoIP calling. This makes it easier for users to discover and set up calling integration from the most relevant app area.

Original PR description

We now partner with Ringover to provide VOIP capabilities using a browser extension for integration.

We add a link to that extension in the "integrations".

This is done in CRM because this is the most relevant app for VOIP usage.

task-4488082

#Ringover#VoIP#settings#integrations

[IMP] Sign: Improve PDF viewer styling for signing documents

PR #76589

Enterprise18.0signMEDIUM

The signing document viewer has been visually improved to reduce overlapping controls and make the signing flow easier to use. The side panel now appears on the right and selects the first option by default, helping users preview and complete documents more smoothly.

Original PR description

**Purpose ========** This PR handles overriding the default PDF.js viewer styling to enhance the user experience while signing documents. Specifically, it addresses the issue where overlapping…

**Purpose
========**
This PR handles overriding the default PDF.js viewer styling to enhance the user experience while signing documents. 

Specifically, it addresses the issue where overlapping elements, such as the "Click to Start" prompt and the sign panel, create a visually unappealing interface.

**Specification
=========**
1. Moves the side panel to the right side of the viewer for improved accessibility.
2. Ensures the first option in the side panel is selected by default, simplifying the document preview process (refer to: https://link.excalidraw.com/l/65VNwvy7c4X/o1Mtd7yyXD).


**Screenshots
=========**

#### Before:
![image](https://github.com/user-attachments/assets/8ef795af-fddf-4849-a43e-5300b774a035)


#### After:
![image](https://github.com/user-attachments/assets/8356460c-9cbf-49f8-b78d-efe45463a20b)

__________________________________________________________________________________________________________
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

task-id: 4369079

#signing#pdf-viewer#user-experience

[IMP] l10n_mx_hr_payroll: add mexican localisation

PR #73381

Enterprise18.0hr_payroll_accountl10n_mx_hr_payrolll10n_mx_hr_payroll_accountl10n_mx_hr_payroll_localisationHIGH

The Mexican payroll localization has been reworked to better align payroll calculations, rules, and accounting with local authority requirements. This helps businesses in Mexico process payroll more accurately and remain compliant with statutory obligations.

Original PR description

This is a rework of the mexican localisation to make it compliant with the local
 authorities.

 Task: 3673251

#mexico#payroll#localization#compliance

[IMP] sale_shopee: introduce app icon

PR #77407

Enterprise18.0sale_shopee

The Shopee sales module now includes its own app icon. This makes the module easier to recognize in Odoo and improves the visual consistency of the app list.

Original PR description

This commit introduces the app icon for the `sale_shopee` module.

task-4492921

#shopee#app icon#branding

Bug Fixes(37)

Resolved issues and error corrections

[FIX] sale_loyalty: calculate proper discount amount when tax included

PR #194889

Core18.0sale_loyaltyMEDIUM

Discount codes now calculate against the full tax-included price when products are priced with tax included. This prevents discounts from being limited to only the untaxed portion, so customers receive the intended discount amount.

Original PR description

If user had set to have tax included in their price and tried to apply
 discount code only the untaxed amount could be discounted even if discount
 code was higher than untaxed amount.

opw-4486030

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

#discounts#tax included#loyalty#sales

[FIX] account_check_printing: print info on checks without entry

PR #194404

Core18.0account_check_printingMEDIUM

Check printouts now include the related bill information even when no accounting entry is created for the check payment. This helps users send complete checks in configurations where the check payment method has no outstanding payment account.

Original PR description

**Steps to reproduce:**
- Install Accounting
- Configure a Check Layout in Accounting settings
- Go to Bank journal configuration
- Make sure that "Checks" payment mehtod doesn't have an Outstanding Payment account
- Create a bill
- Register a Check payment for the bill
- Print the check

**Issue:**
All the data about the bill are missing from the check.

**Cause:**
These data were retrieved from the journal entry linked to the check payment.
As there is no journal entry in this case, they cannot be computed.

**Solution:**
Compute these data from the amount of the check and the linked bills.

opw-4482589




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

#checks#payments#bill details#accounting

[FIX] stock,product_expiry,point_of_sale: cron progress in scheduler

PR #189708

Core18.0stockproduct_expirypoint_of_sale

The scheduler now reports progress as it completes key background tasks for inventory, point of sale, and expiry alerts. This makes long-running automated maintenance easier to monitor and helps administrators understand whether scheduled work is moving forward.

Original PR description

This commit makes use of the ir.cron.progress feature in the stock scheduler. The first approach is to simply count how many tasks have been completely done among the 5 currently available

* stock
    - trigger orderpoints
    - merge quant & delete 0 quant
    - reserve confirm stock move
* point_of_sale
    - close session
* product_expiry
    - make alerts on expired lots

They will be split in 5 different crons later to be able to count exactly the remaining records number to manage in each sub tasks.

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

#scheduler#progress#inventory#pos#expiry

[FIX] sale,website_sale: fix configurable products in combo configurator

PR #191130

Core18.0salewebsite_saleMEDIUM

Combo product options now correctly show only choices customers can configure, while required single-choice options are preselected automatically. This helps prevent confusing product setup flows and reduces incorrect combo orders in Sales and eCommerce.

Original PR description

The combo configurator works with `product.product` records, so previously, we
only allowed to configure `no_variant` PTALs. However, we should also allow to
configure the `product.product`'s custom PTAVs (which can be `always` or
`dynamic`).

Moreover, we always allowed to configure `no_variant` PTALs, even if they
weren't configurable (i.e. PTALs with a single, non-custom, non-multicheckbox
PTAV). However, such PTAVs should be preselected and non-configurable in the
combo configurator.

#combo products#product configurator#ecommerce#sales

[FIX] mail: missing message formatting when creating a subchannel

PR #194732

Core18.0mail

Messages that start a sub-thread now keep their intended formatting when users open and participate in that thread for the first time. This prevents HTML formatting from appearing as plain text, improving readability in Mail discussions.

Original PR description

Before this commit, when a user accesses a sub-thread of channel made from a message for the 1st time, the format of the message body shows html as textcontent rather as inner html. Steps to…

Before this commit, when a user accesses a sub-thread of channel made from a message for the 1st time, the format of the message body shows html as textcontent rather as inner html.

Steps to reproduce:
- Post a message as user A
- Create a thread from this message as user B
- User A accesses this sub-thread and posts a new message
-> User A sees 1st message with bad formatting

This happens because on sub-thread join, the data of sub-thread info are fetched, and since the sub-thread is created from a message, the channel info data also contains the message data. This data was inserted without `html: true`, leading to message body being inserted in a non-trusted way in JS models, causing this formatting issue.

This commit fixes the issue by flagging the insert with `html: true`, as this is from trusted origin and content is trusted, so the message body is inserted to be used properly in message component. Note that this behaviour applies to html fields, which message body is. The insert `html: true` is assessed for data on all targeted html fields.

task-4506489

#mail#discuss#formatting#sub-thread

[FIX] sale_loyalty: traceback when coupon applied on so

PR #194839

Core18.0sale_loyaltyMEDIUM

Sales orders can now accept discount coupons even when the Delivery module is not installed. This prevents an unexpected error during coupon application, making sales discount workflows more reliable for users.

Original PR description

Steps to reproduce:
- Create SO and add a product.
- Apply  discount coupon to SO.

Issue:
- Traceback occurs when the delivery module is not installed.

Cause:
- The line.is_delivery attribute is not accessible when the delivery module is not installed, leading to an error.

Fix:
- Use the line._is_delivery() method to correctly check for delivery lines.

opw-4509360

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

#coupons#sales-orders#discounts

[FIX] mail: ensure selection updates correctly after mention insertion

PR #194480

Core18.0mail

This fixes an issue in the Mail chatter where choosing a mention after replacing selected text could trigger an error. The editor now refreshes its selection correctly, making mention insertion more reliable for users composing messages.

Original PR description

**Problem**: When typing `@` in a non-collapsed selection (`a[b]`) and selecting an item from the mention list, the selection state becomes stale. This happens because `handleObserverRecords` calls…

**Problem**:
When typing `@` in a non-collapsed selection (`a[b]`) and selecting an item from the mention list, the selection state becomes stale. This happens because `handleObserverRecords` calls `updateHints`, which relies on `getSelectionData`. However, `this.activeSelection` retains the outdated selection due to conditions like `documentSelectionIsInEditable` and `!this.activeSelection.anchorNode.isConnected` being `false`.

As a result, `this.activeSelection` reflects `a[b]` while the DOM selection has already updated to `a[]`, leading to invalid offsets.

**Solution**:
Call `this.dependencies.selection.focusEditable();` during `onSelect` to ensure the selection is updated to reflect the editor state rather than the mention state.

**Steps to Reproduce**:
1. Open the chatter.
2. Add some text.
3. Select a portion of the text.
4. Type `@`.
5. Select an item (person) from the mention list.
6. Observe a traceback error.

opw-4498165

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

#mentions#chatter#message composer

[FIX] point_of_sale: fix closing session popup

PR #194876

Core18.0point_of_sale

Closing a Point of Sale session no longer incorrectly shows a warning that another user is closing it. This avoids unnecessary page reload prompts and makes the end-of-day closing flow smoother for store staff.

Original PR description

- The `login_number` can be a string so we need to use "==" to avoid unexpected behaviour.
- This fix an issue where each time you close a PoS session a popup appears with the message "The session is being closed by another user. The page will be reloaded". This was caused by the comparison of a string and an integer.

task-id: 4485659

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

#point-of-sale#session-closing#popup

[FIX] stock_account: fix standard_price on _svl_replenish_stock

PR #193770

Core18.0stock_accountMEDIUM

This fix keeps lot-specific standard prices aligned when stock valuation entries are replenished. It prevents valuation discrepancies when lot-valued inventory is later reduced to zero, improving the accuracy of stock accounting.

Original PR description

## How to reproduce:
- Create product P, tracked by lot, cost_method = 'standard', standard_price = 1
- Create quant with lot L1, 10 units on hand
- Set L1 standard_price = 2
- Set lot_valuated to True => lot value_svl is $10 for 10 units (product.standard_price * quantity)
- Set L1 quantity to 0 => lot value_svl is $-10 for 0 units

## Issue
When the svl is replenished for the lot, the product.standard_price is used. However, the lot.standard_price is not updated; hence, when the stock is emptied, and the lot.standard_price is used, a discrepancy is created.

## Solution
When the svl is replenished, we u se the product.standard_price and update the lot.standard_price

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

#inventory valuation#lot tracking#standard price#accounting

[FIX] cli/*: fix script converting tree to list (regression)

PR #194319

Core18.0upgrade_code

This corrects an upgrade script that was producing inconsistent view definitions when converting older tree views to list views. It helps ensure system upgrades apply cleanly and avoids malformed configuration in updated installations.

Original PR description

since the pr https://github.com/odoo/odoo/pull/189883, the file updates made are not consistent:

'list<editable="bottom">'.

#upgrade#cli#views#regression

[FIX] pos_hr, point_of_sale: fix error when re-entering payment screen

PR #193238

Core18.0point_of_salepos_hr

This fixes an issue where employee logins in Point of Sale could trigger a console error after locking and re-entering a session from the payment screen. Cashiers can now resume the session more reliably without encountering that disruption.

Original PR description

Before this commit:
- Enable the "Log in with employees"
- Log in as any employee, add a product, and go to the payment screen
- Lock the session
- Enter the session again

This sequence of actions would result in an error in the console.

opw-4435559

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

#point of sale#employee login#payment screen#session lock

[FIX] point_of_sale: delete silently in localDeleteCascade

PR #192118

Core18.0point_of_saleMEDIUM

Cancelled point of sale orders now remove related order lines cleanly, preventing leftover data from interfering with syncing new orders. This helps reduce synchronization errors and keeps checkout operations more reliable.

Original PR description

Before this commit, cancelling an order would result in keeping the removed orderlines in the unlink command, causing issues in different cases when trying to sync a new order.

opw-4403100

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

#pos#orders#sync#cancellation

[FIX] loyalty: parse reward_product_domain as JSON

PR #193425

Core18.0pos_loyalty

This fixes an issue where certain loyalty reward product rules could fail to load because the system read them in the wrong format. Loyalty promotions using true/false conditions should now work reliably in Point of Sale without triggering errors.

Original PR description

Before this commit, `domain['reward_product_domain']` was being evaluated with `ast.literal_eval` while containing JSON-style booleans (`true/false`). That caused a `ValueError` because `true/false` are invalid in Python syntax.

With this commit, we now use `json.loads` to parse the domain string, which correctly handles JSON booleans without error.

opw-4458627

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

#loyalty#point-of-sale#rewards

[FIX] l10n_latam_check: existing third party check outgoing payment method.

PR #194713

Core18.0l10n_latam_checkMEDIUM

This update ensures the “Existing Third Party Checks” outgoing payment method is only added to the appropriate Argentine check journals, instead of all Argentine cash journals. It also lets users add the method back if it was accidentally removed from the Third Party Checks journal.

Original PR description

**Description of the issue/feature this PR addresses**: 1) It is necessay not to set "Existing Third Party Checks" outgoing payment method in all argentinean cash journals. It is only needed to be…

**Description of the issue/feature this PR addresses**: 
1) It is necessay not to set "Existing Third Party Checks" outgoing payment method in all argentinean cash journals. It is only needed to be set on "Third Party Checks" and "Rejected Third Party Checks" Argentinean journals that are created when the module is installed or a new argentinean company is created. 
2) Also when a user mistakenly remove the 'Existing Third Party Checks' payment method from the 'Third Party Checks' journal then is not able to add it back. This bug was introduced on this commit https://github.com/odoo/odoo/pull/188451/commits/0618fff9f9bb4716d22dc2ce8950cada824b90f4.

**Current behavior before PR**:
1) "Existing Third Party Checks" outgoing payment method is set in all argentinean cash journals.
2) When a user mistakenly remove the 'Existing Third Party Checks' payment method from the 'Third Party Checks' journal then is not able to add it back.

**Desired behavior after PR is merged**:
1) "Existing Third Party Checks" outgoing payment method is set only in "Third Party Checks" and "Rejected Third Party Checks" argentinean journals.
2) When a user mistakenly remove the 'Existing Third Party Checks' payment method from the 'Third Party Checks' journal then is able to add it back.

_Ticket Adhoc side_: 83443
_Task Latam side_: 1309



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

#argentina#checks#payments#journals

[FIX] pos_self_order_stripe: fix Stripe payments

PR #194691

Core18.0pos_self_order_stripeHIGH

Stripe terminal payments now work again in self-order mode, preventing customers from seeing a generic payment error. The fix also ensures the point of sale receives the correct confirmation when a Stripe payment is completed.

Original PR description

Currently in v18 Stripe payments are broken and don't work anymore. This PR adjusts the code so that Stripe works again in self order mode. It fixes the error "An error has occured" seen when sending a payment to a Stripe terminal + it also fixes the response sent to PoS to confirm Stripe payments.

opw-4283413
opw-4358017

#stripe#payments#self-order#point-of-sale

[FIX] hr_attendance: negative overtime for flexible employee

PR #193523

Core18.0hr_attendanceMEDIUM

Flexible schedule reporting now correctly uses the planned daily hours even when an employee works less than expected. This prevents expected hours from being shown as equal to worked hours and improves overtime and attendance reporting accuracy.

Original PR description

Steps to reproduce:
1. Set a flexible working schedule with 40h / week and 8h / day for an employee
2. Record an attendance for the employee
3. Go to reporting, the expected hours is the same as the worked hours

Expected behavior:
The expected hours should be what was set in the schedule, which is 8 hours

Explanation:
The calculation of expected hours is based on the difference between overtime hours and worked hours. This is done to ensure the overtimes are always computed correctly. However if the overtime duration is negative, it is not taken into account in `_update_overtime`. This commit allows negative amounts for overtime hours.

opw-4388707


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

#attendance#overtime#flexible schedules#reporting

[FIX] sale_pdf_quote_builder: better support RTL scripts

PR #190335

Core18.0sale_pdf_quote_builderMEDIUM

This fix improves how sales quote PDFs handle right-to-left languages such as Arabic or Hebrew. Businesses using these languages should see more readable, correctly presented quote documents for customers.

Original PR description

opw-4289424

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

#RTL#PDF quotes#sales

[FIX] point_of_sale, pos_sale: fix lots selection in POS

PR #194752

Core18.0point_of_salepos_saleMEDIUM

Point of Sale now correctly considers available lot quantities when users select tracked products. This helps prevent staff from choosing unavailable or incorrect lots, improving checkout accuracy and inventory reliability.

Original PR description

Lots selection in POS was not working properly. It was not takin into account lot quantity when selecting it.

#POS#inventory#lots#stock accuracy

[FIX] mail,base: avoid creep in tag_quote

PR #190525

Core18.0mailbaseMEDIUM

Fixes an issue where repeated email cleanup could incorrectly treat the whole message as a hidden quote or signature. This helps users see the actual message content reliably while still hiding genuine signatures and quoted sections as intended.

Original PR description

Since html_normalize is now run multiple times on the same body in mail it has become apparent that the heuristics for tag_quote are not suited to multiple passes on the same body. tag_quote is used…

Since html_normalize is now run multiple times on the same body in mail it
has become apparent that the heuristics for tag_quote are not suited to multiple
passes on the same body.

tag_quote is used to detect and tag nodes in a document that are likely
mail signatures. So that they may be hidden in the front-end.

The detection of the signature using the "-- <br>" sets the parent of the element
where is is detected to be a "quote container". However a quote container will
set all of its children to be quotes too. If the signature is in the main div of
the email, as is the case in most templates this means the whole content is
marked as being inside a "quote container".

Because the processing of the elements is done in order of their appearance in
the document, this does not lead to the entire document becoming a quote the
first time html_normalize is called. As the signature is typically
the last element, the "container" attribute is only set after the whole body
was already processed.

However if the body is normalized again, the main div is now marked as a
"quote container" and the whole body becomes a quote.

- `<div><p>body</p><div>--<br>John</div></div>`
- `<div quote-container><p>body</p><div quote>--<br quote>John</div></div>`
- `<div quote-container><p quote>body</p><div quote>--<br quote>John</div></div>`

We now check whether a quoted sibling exists in the container before marking a
node as "quote". All nodes following the original quote and their children will
be quoted as before, all nodes before will not be quoted anymore.

triggered by https://github.com/odoo-dev/odoo/commit/24731938f75358fd3c72b91465b72ab80d62d208

task-4381505

#email#signatures#quotes#message display

[FIX] account: fix autopost of bills

PR #194595

Core18.0account

This fixes how imported vendor bills are classified as manually edited, so users are only prompted to enable automatic posting when the system has correctly detected repeated unchanged bills. It also prevents localization-related background processing from incorrectly marking bills as edited, improving reliability for companies using Egyptian e-invoicing features.

Original PR description

In b1046c8156ee3d3699d5b229720134cc3b2532d4, we introduced a new feature to allow autoposting of bills. When a user does not modify the imported bill for 3 consecutive times, we ask the user if he…

In b1046c8156ee3d3699d5b229720134cc3b2532d4, we introduced a new feature to allow autoposting of bills. When a user does not modify the imported bill for 3 consecutive times, we ask the user if he wants to activate the feature.

To detect whether the user has modified the imported bill or not, we use a new field `is_manually_modified` which is always set to `True` when the bill is edited except for automatic flows (OCR, CRON, email).

test_autopost_bills will fail when the l10n_eg_edi_eta module is installed. This is due to fact that calling import_facturx will end up calling _extend_with_attachments, which in turn changes the value of l10n_eg_eta_json_doc_id.raw which triggers the computes that depend on it. This is why we add the context key before calling _extend_with_attachments. Moreover, in the same function, a savepoint is created, triggering a flush that triggers the recomputes. A savepoint is created without the context, therefore we flush right before we create the savepoint.

runbot-110629

#vendor bills#automatic posting#import#localization

[FIX] point_of_sale: set default nb_print value for offline orders

PR #194527

Core18.0point_of_saleMEDIUM

The point of sale now gives offline restaurant orders a default receipt print count when they sync back online. This prevents a system error when closing the register after printing full receipts during an internet outage, improving reliability for restaurant staff.

Original PR description

Currently, an exception is generated in the log when the users create a POS order as follows: - Install ``pos_restaurant`` module. - Open the register for the restaurant. - Stay connected to Wi-Fi…

Currently, an exception is generated in the log when the users create a POS order as follows:
- Install ``pos_restaurant`` module.
- Open the register for the restaurant.
- Stay connected to Wi-Fi but disconnect from the internet (Inspect > Network > Go Offline). connection (Inspect > Network > Go offline)
- Make two or more orders in offline mode and use ``Print Full Receipt``.
- Reconnect to the internet, make one order, and ``Print Full Receipt``.
- Close the register (Traceback appears in the terminal).

``error: `invalid literal for int() with base 10: 'null'``

Before commit :
---
- ``nb_print`` is initialized in Python with fields.Integer(default=0)
- When syncing data between the server and the client, nb_print is being sent as ``null`` instead of an integer.
- The Python side is trying to convert ``null`` into an integer, which causes the error. 

 After commit :
---
- Added ``this.nb_print = vals.nb_print || 0;`` in ``pos_order.js`` to ensure it initializes to 0 for offline orders, aligning with the server-side default.

sentry-6055024846

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

#pos#offline#restaurant#receipts

[FIX] crm: add translation for ringover settings

PR #194786

Core18.0crm

[1] adds a settings entry in CRM for ringover As this was done in stable the .pot file should have been updated [1] f2a384dd3b8ac2d358a9d8ea3fcec577b3e86859

Original PR description

[1] adds a settings entry in CRM for ringover

As this was done in stable the .pot file should have been updated

[1] f2a384dd3b8ac2d358a9d8ea3fcec577b3e86859

[FIX] payment_worldline: make API request not depend on locale variable

PR #194004

Core18.0payment_worldlineMEDIUM

This fixes a payment issue where Worldline transactions could fail if the server used certain regional language settings. The request date is now formatted consistently, helping businesses avoid failed payments caused by server locale configuration.

Original PR description

Versions
--------
- 18.0+

Steps
-----
1. Set locale variable `LC_TIME` to `be_FR.UTF-8` via command line;
2. do the same for `LC_ALL`;
3. start Odoo server;
4. attempt to make a payment via Worldline.

Example updating locale for a single shell session:
```bash
$ export LC_TIME=be_FR.UTF-8
$ export LC_ALL=$LC_TIME
$ ./odoo-bin
```

Issue
-----
Invalid API request: ACCESS_TO_MERCHANT_NOT_ALLOWED

Cause
-----
The date string sent to the Worldline API is formatted via the `datetime.strftime` method to be RFC 1123 compliant. The issue is that the result of this method is locale-dependent. If it's not set to `en_US.UTF-8`, it no longer adheres to the format expected by Worldline.

Solution
--------
Use the `format_date_time` method from the Python's standard `wsgiref` library. This method will always return a RFC 1123 compliant date string, regardless of locale setting.

opw-4472440

#payments#worldline#locale

[FIX] mail: correctly restart scheduled message cron

PR #194233

Core18.0mailMEDIUM

Fixes an issue where the scheduled mail process could fail when more than 50 messages were waiting to be sent. This helps ensure queued customer or internal messages continue processing without manual intervention.

Original PR description

Before this commit, `mail.ir_cron_post_scheduled_message` fails with a traceback when there are a lot of scheduled messages to be sent.

Steps to reproduce
-----
1. Create a scheduled message from the chatter full composer
2. Duplicate it 50+ times
3. Run the scheduled action "Mail: Post scheduled messages"
4. Traceback occurs
```
File "/home/odoo/src/odoo/odoo/api.py", line 553, in __new__
assert isinstance(cr, BaseCursor)
^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError
```

Cause
-----
This commit (df18d5257cef737f3e1d245a8b85769e1fe1a032) introduced this cron which posts past-due scheduled messages with a default `limit=50`. If there are more messages than the limit, the cron is triggered again. However, there is a typo when restarting the cron that incorrectly calls `env`.

Solution
-----
Change the line to use `env.ref()` to correctly access the xml_id and restart the cron.

opw-4474171

#scheduled messages#cron#reliability

[FIX] pos_viva_wallet: mark endpoint as read/write

PR #193371

Core18.0pos_viva_wallet

The Viva Wallet payment webhook is now correctly marked as able to update records. This prevents unnecessary warning messages in logs while keeping payment processing behavior unchanged.

Original PR description

Since #584a172, controller endpoints can specify `readonly=False` if they are expected to write to the DB. The webhook endpoint for Viva Wallet was previously not specified this way, which leads to a warning being logged.

This commit simply adds `readonly=False` to the webhook endpoint to prevent the warning.

task-4472274

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

#point-of-sale#payments#viva-wallet#logging

[FIX] documents: fix the chatter and the inspector in the list view

PR #76699

Enterprise18.0documentsMEDIUM

The Documents list view now opens the discussion panel for the correct folder or selected document. It also shows the proper parent folder name in the inspector instead of displaying “Unnamed,” making document navigation clearer for users.

Original PR description

Bug 1
=====
The chatter in the list view never open on the current folder / selected document.

Bug 2
=====
If we are in the list view, and we are inside a folder, when selecting a document, it
will show "Unnamed" for the folder. The reason is that with `column_invisible=1`, the
display name is not loaded. To solve that, we can put the field in `optional="hide"`.

Task-4461038

#documents#list view#chatter#inspector

[FIX] l10n_in_reports_gstr: Improve GSTR-1 exception activity assignment

PR #77002

Enterprise18.0l10n_in_reports_gstrMEDIUM

GSTR-1 error activities are now assigned more reliably to the right responsible user, and the needed activity type is created automatically if missing. This helps Indian GST reporting teams track and resolve filing issues with fewer assignment gaps or execution errors.

Original PR description

In this PR: - Introduced a new method `_get_gstr_responsible_activity_and_user` to dynamically retrieve or create the GSTR-1 exception mail activity type and determine the responsible user for…

In this PR:
- Introduced a new method `_get_gstr_responsible_activity_and_user` to
dynamically retrieve or create the GSTR-1 exception mail activity type and
determine the responsible user for handling GSTR-1 errors.
- Ensured that the activity type is created on-the-fly if it does not exist,
avoiding potential errors during execution.
- Updated `check_gstr1_status` to utilize the new method for assigning the
responsible user and activity type when scheduling activities for invoices
with GSTR-1 errors.
- Improved logic to determine the responsible user:
  - Default to the activity type's `default_user_id` if they belong to the
appropriate group and company.
  - Fallback to the last relevant `mail.message` for identifying a responsible
user.
- Enhanced activity scheduling to use the identified activity type and
responsible user, improving traceability and accountability.

This change improves error handling in the GSTR-1 process and ensures better
alignment with user responsibilities.

#GSTR-1#India localization#activity assignment#tax reporting

[FIX] pos_restaurant_appointment: correct Gantt view model usage

PR #77447

Enterprise18.0pos_restaurant_appointment

Fixes an issue where opening the Gantt view for restaurant appointments could use the wrong underlying record type. This prevents potential loading errors and helps staff access appointment scheduling views reliably.

Original PR description

Before this commit, opening the calendar event Gantt view called the `calendar.event` model, but the `appointment.type` ID was passed. This mismatch could lead to an error when attempting to load the view.

opw-4493685

#appointments#restaurant#gantt#point-of-sale

[FIX] account_followup: report not used

PR #73668

Enterprise18.0account_followup

This update adjusts an internal test so it matches how follow-up reporting works in version 18.0, where the partner ledger is used. It helps prevent false test failures while still checking that the right accounting lines are recovered.

Original PR description

The test breaks https://github.com/odoo/odoo/pull/184482

In 18.0, partner ledger is used for the followup. Keep the test as it still assess we recover the lines correctly.

#follow-up#partner ledger#tests

[FIX] l10n_au_hr_payroll_account : fix performance test

PR #77473

Enterprise18.0l10n_au_hr_payroll_account

This fixes a payroll accounting test setup issue that could appear when Belgian payroll was installed before Australian payroll. The change ensures contract creation uses the correct payroll structure information, making the test reliable across localization combinations.

#payroll#australia#testing#localization

[FIX] sale_subscription_timesheet: fix stale delivered qty on SOL

PR #77059

Enterprise18.0sale_subscription_timesheetMEDIUM

Fixed an issue where timesheet hours on subscription sales orders were not reflected in the delivered quantity after the first recurring invoice was generated. This helps sales and billing teams see accurate delivered quantities and invoice customers correctly.

Original PR description

The issue: The delivered qty is not reflected on the order line after creating the first recurring invoice by the cron job. Steps to reproduce: 1. Create a product with the following configuration:…

The issue:
The delivered qty is not reflected on the order line after creating
the first recurring invoice by the cron job.

Steps to reproduce:
1. Create a product with the following configuration:
Product Type: Service
Create on Order: Nothing
Invoicing Policy: Based on Timesheets
Product Category: Sellable and Subscription Product
2. Set up a recurring subscription plan for the product
3. Create a Sales Order (SO) for the product and confirm it
4. Add hours to a task linked to the SO
5. From Settings > Technical > Automation > Scheduled Actions,
manually trigger the cron job "Sale Subscription: generate
recurring invoices and payments" to update the `next_invoice_date`.

Observed behavior:
On the SO page, the smart button of the tasks reflects the hours added
correctly. However, the delivered quantity field in the SO line does not
update based on the added hours.

The reason:
The delivered quantity for timesheet based services is computed taking
into account the current period [1], however, `next_invoice_date` was not
added as a dependency to the compute method of `qty_delivered`, causing
this latter to have a stale value when `next_invoice_date` gets updated
when creating the first recurring invoice by `_create_recurring_invoice` [2].

The fix:
Added `next_invoice_date` as a dependency for the compute function of
`qty_deliverd`.

[1]: https://github.com/odoo/enterprise/blob/e990d101cce90311f3e2c5d9be4d480b329f9f2a/sale_subscription_timesheet/models/sale_order_line.py#L39
[2]: https://github.com/odoo/enterprise/blob/07f01f39cb46f1763637b50e628dfb613b0d2266/sale_subscription/models/sale_order.py#L1168

opw-4378914
opw-4426787
opw-4463512

#subscriptions#timesheets#sales orders#invoicing

[FIX] l10n_mx_edi: Fix rounding issue with even numbers and 50% discount

PR #75381

Enterprise18.0l10n_mx_ediMEDIUM

Corrects a rounding problem in Mexican electronic invoicing when invoice lines use even-numbered amounts with a 50% discount. This helps ensure generated tax documents match required totals and reduces the risk of invoice validation errors.

Original PR description

See the test in this commit.

#mexico#invoicing#rounding#discounts

[FIX] documents,documents_{*}: fix document folder protection

PR #77162

Enterprise18.0documentsdocuments_hrdocuments_projectMEDIUM

This change prevents users from deleting document folders that are reserved for company processes, even when those folders belong to another company they cannot normally access. It also fixes cases where users were incorrectly blocked from moving or deleting their own documents when project folder permissions were restricted.

Original PR description

[FIX] documents, documents_hr: fix company folder protection How to reproduce: - install documents_hr - In Document, create a folder prjComp2 in /Marketing/Brand 2 - create a second company:…

[FIX] documents, documents_hr: fix company folder protection

How to reproduce:
- install documents_hr
- In Document, create a folder prjComp2 in /Marketing/Brand 2
- create a second company: SecondCompany
- Select SecondCompany
- Activate centralization of document for HR and select prjComp2 folder
- Log as Marc Demo and delete the folder Brand 2 (Move to Trash + delete)

There is no error while this folder should have been protected by the method _raise_if_used_folder called when archiving or deleting a folder.

The cause is that Marc user doesn't have access to SecondCompany and as the check is not done in sudo in _raise_if_used_folder, the folder is not identified as a folder to be protected. We solve the issue by running the check in sudo.

Technical note: the protection mechanism is defined in the documents app but tested in documents_hr because there is no company folder defined in documents that could be used in a test.

[FIX] documents,documents_project: fix document deletion

How to reproduce (Move to the Trash):
- Install documents_project
- Remove any access to the project folder (except to Mitchel Admin)
- Login as Marc Demo
- Upload a file in Marketing
- Move that file to the Trash

You get an access error while you should be able to move that document to the
Trash.

How to reproduce (Delete):
- install documents_project
- Login as Marc Demo
- Upload a file in Marketing
- Move it to the Trash
- Remove any access to the project folder (except to Mitchel Admin)
- As Marc Demo, go to the Trash and delete the document

You get an access error while you should be able to delete that document.

We solve the problem by doing the check in sudo (in unlink_except_project_folder).

Technical note: We haven't done that test in documents (where there are already delete tests) because we had to change the test so that they are executed after all the modules are installed and that cause query count issue in performance tests.

Task-4480581

#documents#folders#permissions#multi-company

[FIX] account_reports: Executive Summary: use proper line of P&L in formula

PR #77524

Enterprise18.0account_reports

The Executive Summary report now uses the correct revenue line when calculating net profit margin. This helps businesses see a more accurate profitability percentage after recent Profit and Loss report changes.

Original PR description

The REV line was introduced in 18.0 when revamping the P&L, here: https://github.com/odoo/enterprise/commit/cbe74884b937f630cf1d2ccf475a04e70b6f4669

Following this change, this line should be used in the formula of the Net profit margin of the Executive Summary, as stated here https://www.investopedia.com/terms/n/net_margin.asp

#executive-summary#profit-and-loss#net-profit-margin

[FIX] l10n_sa_hr_payroll: Fixed Settings Bank Fields

PR #75609

Enterprise18.0l10n_sa_hr_payroll

Saudi payroll bank details are now managed only from the relevant bank or bank account form, avoiding duplicate editing places. The settings page now warns users when required bank information is missing, helping prevent payroll configuration mistakes without blocking setup unnecessarily.

Original PR description

Task URL: https://www.odoo.com/odoo/project.task/4184694

Changes:
- Remove fields l10n_sa_bank_account_id, l10n_sa_bank_establishment_code, & l10n_sa_sarie_code from res.config.settings so that it can only be edited in the bank/bank acc. form view.
- Show warning if one of the fields (l10n_sa_bank_id, l10n_sa_bank_establishment_code, l10n_sa_sarie_code) is not set.
- Adjust width for l10n_sa_bank_account_id

#payroll#saudi-arabia#bank-settings

[FIX] documents: fix portal

PR #77281

Enterprise18.0documentsMEDIUM

Portal users now only see document actions they can actually use, reducing errors and confusion when managing shared documents. Duplicated documents also keep their own attachment links, preventing copies from disappearing or affecting the original record.

Original PR description

[FIX] documents: clean portal action We disable action that portal user cannot perform: In the preview: - hide Split Pdf in the preview In the cog menu: - remove "Move to Trash" as portal user can't…

[FIX] documents: clean portal action

We disable action that portal user cannot perform:

In the preview:
- hide Split Pdf in the preview

In the cog menu:
- remove "Move to Trash" as portal user can't archive document (and can't create folder nor access to the trash anyway)
- Info&Tags as it opens the chatter which is disabled for portal user

In action:
- Info&Tags as it opens the chatter which is disabled for portal user
- Duplicate only present if it doesn't lead to an error (canDuplicateSelection method). We also remove the line separator in the action if the user is not internal otherwise it leads sometimes to an empty section.

In the "New" drop down button:
- hide "Folder" (create Folder)
- hide "Link" (create link):
fails because of (users | folders.owner_id).fetch(['partner_id']) in _prepare_create_values (no access to user)

Hide share button for portal user: Although the portal users could share any documents they have access to (by sending them by email for example), we remove the share action (for document and folder) for them as the only thing they could do was to change the rights for user that had already a link to that document.

[FIX] documents: fix attachment not pointing to the copied document

When copying a document, the copied attachment still points to the orginal record:
- if it is a document with an attachment associated to an other record (ex.: hr.expense). The attachment of the copied document is pointing to the same record as the orginal document. Ex.: for an expense, the expense has now
2 attachments linked (one linked to the original document and one linked to the copied one).
- if it is a pure document, the attachment points to the orginal document

We solve that problem here by always making the copied attachment to the copied document.

How to reproduce case 1:
- Install documents_hr_expense
- Upload a document in the Document App
- Create an expense from that document
- Duplicate that document
- Open the expense App
- The expense related to the document has now 2 attachments instead of one

How to reproduce case 2:
- Install documents
- Log in as admin and open Documents App
- In Marketing -> Brand 1, duplicate "LA landscape.jpg"
- Move "LA landscape.jpg" to the Trash and delete it (from the Trash)
- Return to Marketing -> Brand 1

The copy has disappeared as well and shoudln't.

It means that deleting the original document deletes all copies. It works also if we delete the copy (it deletes the original).

[IMP] documents: allow portal user to delete their own documents

Instead of enabling the Trash for the portal user, we add the delete action for
their own documents only so that a user that have uploaded a document by
mistake can delete it. Indeed, as portal user don't have access to the Trash,
moving a document to the Trash like an internal user would do is no use.

Task-4221258

#portal#documents#attachments#user experience

[FIX] account_reports: allow moving more than 365 years

PR #77098

Enterprise18.0account_reports

Accounting reports with period-based date selectors now handle jumps of more than 365 years correctly. This prevents incorrect dates when users navigate very far backward or forward in reports such as tax reports or profit and loss statements.

Original PR description

In accounting reports that use periods (like the tax report or profit and loss), the date selector is broken when you try to go back or forward for more than 365 years.

The reason is that it was computing the resulting year by looping over the number of years to go back/forward, and each time adding or subtracting the number of years as days. When over 365, it would go back/forward more than 1 year per iteration.

This commit fixes the issue.

[task-4410887](https://www.odoo.com/odoo/project.task/4410887)

#accounting#reports#date selector

Other(32)

Miscellaneous changes

[FW][IMP] odoo: add config for cron connection time

PR #194937

Core18.0

Original PR description

Adds a configuration that can be used to mitigate PostgreSQL transactional errors with long-living connections and the `LISTEN/NOTIFY`[^1] functionality by re-establishing the database connection…

Adds a configuration that can be used to mitigate PostgreSQL
transactional errors with long-living connections and the
`LISTEN/NOTIFY`[^1] functionality by re-establishing the database
connection periodically.

In the case that a connection outlives the transaction wraparound[^2]
mechanism of postgres, the `LISTEN/NOTIFY` internal queue might contain
references to transactions that have already been deleted by the
system's (or a manual) `VACUUM`[^3] as it has its own transaction
validity mechanisms (roughly comparing transaction ids).

This can be reproduced by:
 - Triggering a wraparound _AND_ cleaning of pg_xact between the cron's
   `LISTEN` + `COMMIT` and its recyling.
 - Having done at least one `NOTIFY` during that time period (?).
 - Try to `LISTEN` to the same channel on the same database (transcation
   id must be < than the first connection's transaction id).

The following is an example error message:
```
ERROR database odoo.service.server: Worker (3194772) Exception occurred, exiting...
Traceback (most recent call last):
  File "/home/user/odoo/service/server.py", line 1089, in run
    self.start()
  File "/home/user/odoo/service/server.py", line 1235, in start
    self.dbcursor.commit()
  File "/home/user/odoo/sql_db.py", line 480, in commit
    result = self._cnx.commit()
             ^^^^^^^^^^^^^^^^^^
psycopg2.errors.UndefinedFile: could not access status of transaction 1194816979
DETAIL:  Could not open file "pg_xact/0473": No such file or directory.
```

[LISTEN/NOTIFY code](https://github.com/postgres/postgres/blob/REL_16_STABLE/src/backend/commands/async.c)

[Connection being kept](https://github.com/postgres/postgres/blob/REL_16_STABLE/src/backend/commands/async.c#L2167-L2191)

[See more](https://www.postgresql.org/message-id/flat/VE1PR03MB531295B1BDCFE422441B15FD92499%40VE1PR03MB5312.eurprd03.prod.outlook.com#7e36d1fdca921b5292e92c7017984ffa)

[^1]: https://www.postgresql.org/docs/current/sql-notify.html
[^2]: https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND
[^3]: https://www.postgresql.org/docs/17/sql-vacuum.html

Forward-Port-Of: odoo/odoo#194822
Forward-Port-Of: odoo/odoo#194141

[FW][FIX] hr_holidays: allow date modification for unapproved time off requests

PR #194814

Core18.0hr_holidays

Original PR description

Steps to Reproduce:
• Install the Time Off app.
• Create a new user and corresponding employee without any group in Time Off. 
• Create a new time off request with a start date < today's date. 
• Attempt to change the date, which results in a validation error.

Issue:
- Users are unable to modify time off requests, even if they are not yet approved.

Fix:
- Added a check to ensure that modifications are allowed for time off requests that are not in an approved state.

task-4236572

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

Forward-Port-Of: odoo/odoo#194747
Forward-Port-Of: odoo/odoo#190944

[FW][FIX] account: no frequent accounts

PR #194303

Core18.0account

The name search on the account field (account.account on account move line) looks for frequently used accounts for the partner. When no search text is provided, the name search suggests accounts that were previously used. When there are no frequent accounts, the name search returns nothing. To reproduce - create a vendor bill - select a partner that has never been billed - add a line - click the account many2one field dropdown Since no account options are available, the dropdown flas

Original PR description

The name search on the account field (account.account on account move line) looks for frequently used accounts for the partner. When no search text is provided, the name search suggests accounts that were previously used. When there are no frequent accounts, the name search returns nothing.

To reproduce

- create a vendor bill
- select a partner that has never been billed
- add a line
- click the account many2one field dropdown

Since no account options are available, the dropdown flashes open and quickly disappears.

Forward-Port-Of: odoo/odoo#193999

[FW][FIX] web_editor: delete backward on lists

PR #192446

Core18.0html_editorweb_editor

Current behavior before PR: When multiple types of lists were selected and the deleteBackward operation was performed, the list type remained unchanged. Desired behavior after PR is merged: When deleteBackward is pressed with multiple types of lists selected, and all selected content is removed, if the anchor node's list item is empty, that list item type will change to match the type of the list where the deleteBackward operation started. task:4187739 Forward-Port-Of: odoo/odoo#191

Original PR description

Current behavior before PR:

When multiple types of lists were selected and the deleteBackward operation was performed, the list type remained unchanged.

Desired behavior after PR is merged:

When deleteBackward is pressed with multiple types of lists selected, and all selected content is removed, if the anchor node's list item is empty, that list item type will change to match the type of the list where the deleteBackward operation started.

task:4187739

Forward-Port-Of: odoo/odoo#191915
Forward-Port-Of: odoo/odoo#180687

[FW][IMP] l10n_mu: PDF invoice requirements

PR #194590

Core18.0l10n_mu_account

This commit add few data on the report_invoice for Mauritius localization. task-4379202 Forward-Port-Of: odoo/odoo#190723

Original PR description

This commit add few data on the report_invoice for Mauritius localization.

task-4379202

Forward-Port-Of: odoo/odoo#190723

[FW][FIX] account: prevent setting wrong partner_id.payment_term

PR #184482

Core18.0account

Steps to reproduce: - have two companies A and B - create a new partner - create a new payment term for Company A - In Company A, set the customer's payment term the newly created one - Configure aliases for invoice in company A and B - Make sure the default company for OdooBot is COmpany A - Send an email to company B Issue: Access Error Cause: payment_term is pre-compute and the company context is the one of OdooBot opw-4103229 Forward-Port-Of: odoo/odoo#182986 Forward-Port-

Original PR description

Steps to reproduce:
- have two companies A and B
- create a new partner
- create a new payment term for Company A
- In Company A, set the customer's payment term the newly created one
- Configure aliases for invoice in company A and B
- Make sure the default company for OdooBot is COmpany A
- Send an email to company B

Issue:
Access Error

Cause:
payment_term is pre-compute and the company context is the one of OdooBot

opw-4103229

Forward-Port-Of: odoo/odoo#182986
Forward-Port-Of: odoo/odoo#178829

[FW][FIX] hr_timesheet: make default measures translatable

PR #193609

Core18.0hr_timesheet

In the Tasks' and Tasks Analysis' chart and pivot views, some default measures were not translatable after [this commit]. The [previous fix] only solved one case. We make them translatable again here so they can be localized. [this commit]: https://github.com/odoo/odoo/commit/e82567f9d5842bd95fe01ba3b9f54a65437e313f [previous fix]: https://github.com/odoo/odoo/commit/e7381c3a09014567a8bdb0802c6964cc35ffddd2 [opw-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of:

Original PR description

In the Tasks' and Tasks Analysis' chart and pivot views, some default measures were not translatable after [this commit]. The [previous fix] only solved one case.

We make them translatable again here so they can be localized.

[this commit]: https://github.com/odoo/odoo/commit/e82567f9d5842bd95fe01ba3b9f54a65437e313f
[previous fix]: https://github.com/odoo/odoo/commit/e7381c3a09014567a8bdb0802c6964cc35ffddd2

[opw-4421055](https://www.odoo.com/odoo/project.task/4421055)

Forward-Port-Of: odoo/odoo#193517

[FW][FIX] purchase: fix tour by providing appropriate class

PR #194780

Core18.0purchase

Before this commit: =================== - The purchase tour was failing because the tour's JavaScript used an incorrect class selector (targeting 'partner_id'), which prevented it from locating the intended DOM element. Consequently, the sequence of actions was interrupted, causing the tour to break midway. After this commit: =================== - The issue has been resolved by updating the tour to use the correct and unique class selector. This ensures the tour accurately tar

Original PR description

Before this commit:
===================
- The purchase tour was failing because the tour's JavaScript used
  an incorrect class selector (targeting 'partner_id'), which prevented
  it from locating the intended DOM element. Consequently,
  the sequence of actions was interrupted, causing the tour to break midway.

After this commit:
===================
- The issue has been resolved by updating the tour to use the correct and
  unique class selector. This ensures the tour accurately targets the
  intended element, allowing it to proceed without interruptions.
  As a result, the purchase tour runs successfully and achieves its intended purpose.

TaskId: 4268662

Forward-Port-Of: odoo/odoo#194681
Forward-Port-Of: odoo/odoo#184735

[FW][IMP] mail: improve quote reply detection

PR #194722

Core18.0mail

Original PR description

We update quote detection for gmail and outlook:
- gmail has simple wrapper divs with explicit classes
- outlook has a mix of div ids and simple pattern-based quoting (everything under "<hr><div id="divRplyFwdMsg"/> seems to be considered a quote)

Previously gmail just used blockquote, which still works but does not capture "On xx:xx:xx X <X@gmail.com> wrote:" headers, which are caught for outlook.

Previously outlook had a wrapper div around divRplyFwdMsg which would set data-o-mail-quote-container on it, and propagate to children. However it seems that outer div was either removed or is not always present, a heuristic is thus needed.

task-4381505

Forward-Port-Of: odoo/odoo#194615
Forward-Port-Of: odoo/odoo#192875

[FW][FIX] account_peppol: remove peppol registration migration button

PR #194524

Core18.0account_peppol

Peppol migration creates more issues than it solves. A lot of users issue migration requests to move to another SMP but later discover that the SMP they wanted to migrate to does not support migration keys. This creates a state that we need to handle manually. Most SMP do not support migrating away and force users to deregister and reregister again on another one. This commit adds a fix in stable for that issue by removing the button from the res_config_settings_buttons and adding a deprecate

Original PR description

Peppol migration creates more issues than it solves. A lot of users issue migration requests to move to another SMP but later discover that the SMP they wanted to migrate to does not support migration keys. This creates a state that we need to handle manually. Most SMP do not support migrating away and force users to deregister and reregister again on another one.

This commit adds a fix in stable for that issue by removing the button from the res_config_settings_buttons and adding a deprecated warning when the user tries to call the `button_migrate_peppol_registration` method.

task-4394408

Forward-Port-Of: odoo/odoo#194171
Forward-Port-Of: odoo/odoo#193794

[FW][FIX] l10n_in: hide QR if upi id is not set

PR #194778

Core18.0l10n_in

Original PR description

**Steps to reproduce:**
1) Select the QR Codes option in settings (IN Company)
2) Do not enter an upi id in the company profile.
3) Go to invoice and preview/print the invoice.
4) Show that QR code without upi id and upi logos visible.

**Cause:**
- The condition of the upi id is not properly set to hide the block if upi is not set.

**Fix:**
- With this PR, the upi QR code and upi logos will not be visible if the upi id is not set.

**task**-4426634

Forward-Port-Of: odoo/odoo#192068

[FW][FIX] point_of_sale: synchronisation latence with connected printers

PR #194739

Core18.0point_of_sale

Previously, when some printers were connected to the PoS, the synchronisation of the order was slow because we were waiting for the response of each printer. Now we don't wait for the response of the printer, we just send the order to the printer and we continue the process. Forward-Port-Of: odoo/odoo#194690

Original PR description

Previously, when some printers were connected to the PoS, the synchronisation of the order was slow because we were waiting for the response of each printer.

Now we don't wait for the response of the printer, we just send the order to the printer and we continue the process.

Forward-Port-Of: odoo/odoo#194690

[FW][FIX] hw_drivers: detect Star printers again

PR #194763

Core18.0hw_drivers

Original PR description

Our "supported" method filtering detected printers had a condition introduced in v17 which was too strict and filtering out the STAR printers, so they were never detected anymore.

This PR fixes this issue
related PR: #174436

Forward-Port-Of: odoo/odoo#190367

[FW][FIX] pos_sale: separate downpayment for fixed tax

PR #194031

Core18.0pos_sale

When a product has a fixed tax, there should be a separate downpayment line for the fixed tax amount. Steps to reproduce: ------------------- * Create a fixed tax of 1€ * Assign this tax to any product * Create a sale order with this product * Open PoS and make a downpayment of 10% > Observation: There is only one downpayment line with the total amount of the product and the fixed tax combined. opw-4252104 Forward-Port-Of: odoo/odoo#193732 Forward-Port-Of: odoo/odoo#192208

Original PR description

When a product has a fixed tax, there should be a separate downpayment line for the fixed tax amount.

Steps to reproduce:
-------------------
* Create a fixed tax of 1€
* Assign this tax to any product
* Create a sale order with this product
* Open PoS and make a downpayment of 10%
> Observation: There is only one downpayment line with the total amount
  of the product and the fixed tax combined.

opw-4252104

Forward-Port-Of: odoo/odoo#193732
Forward-Port-Of: odoo/odoo#192208

[FW][IMP] event: clarify the Timezone field name and tooltips

PR #194354

Core18.0event

### Issue: The current descriptions and naming of the `Date` fields (`date_begin`, `date_end`) and the `Timezone` field (`date_tz`) can be confusing in the form view of the event model. Specifically: The timezone used for converting the form dates to the database is determined by the context and not by the `Timezone` field present on the form. However, this `Timezone` field determines the timezone used for displaying the event's date/time on the website. This change tries to clarify the si

Original PR description

### Issue:

The current descriptions and naming of the `Date` fields (`date_begin`, `date_end`) and the `Timezone` field (`date_tz`) can be confusing in the form view of the event model. Specifically:

The timezone used for converting the form dates to the database is determined by the context and not by the `Timezone` field present on the form. However, this `Timezone` field determines the timezone used for displaying the event's date/time on the website. This change tries to clarify the situation.

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

Forward-Port-Of: odoo/odoo#193587
Forward-Port-Of: odoo/odoo#190867

[FW][FIX] point_of_sale: remove custom properties 'nodestroy' to avoid warning

PR #192798

Core18.0point_of_sale

-This commit remove custom properties 'nodestroy' to avoid warning like this: `odoo.addons.web.controllers.utils: Action 'Customer Invoice' contains custom properties 'nodestroy'`. Passing them via the `params` or `context` properties is recommended instead 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:

Original PR description

-This commit remove custom properties 'nodestroy' to avoid warning like this: `odoo.addons.web.controllers.utils: Action 'Customer Invoice' contains custom properties 'nodestroy'`. Passing them via the `params` or `context` properties is recommended instead

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

[FW][FIX] l10n_fr_pos_cert: fix hidden old unit price on products screen

PR #191732

Core18.0l10n_fr_pos_cert

Description of the issue/feature this PR addresses: Current behavior before PR: The "Old unit price" text in the POS products screen is not showing properly when the l10n_fr_pos_cert is installed. Desired behavior after PR is merged: The "Old unit price" text will be showing up properly using simular code to what is on https://github.com/odoo/odoo/blob/a0ab0ce39bf4cba5e90eae109bcd006b39e31c6c/addons/l10n_fr_pos_cert/static/src/xml/OrderReceipt.xml#L14 --- I confirm I have si

Original PR description

Description of the issue/feature this PR addresses:

Current behavior before PR:
The "Old unit price" text in the POS products screen is not showing properly when the l10n_fr_pos_cert is installed.

Desired behavior after PR is merged:
The  "Old unit price" text will be showing up properly using simular code to what is on https://github.com/odoo/odoo/blob/a0ab0ce39bf4cba5e90eae109bcd006b39e31c6c/addons/l10n_fr_pos_cert/static/src/xml/OrderReceipt.xml#L14 
 



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

Forward-Port-Of: odoo/odoo#184840

[FW][FIX] web_editor: fix video option in media dialog

PR #193741

Core18.0web_editor

After merging of this PR [1], video tab will not be visible in media dialog in report as `allowCommandVideo` is false. But this will override `noVideos` option from `params` to false if `allowCommandVideo` is true and video tab will be visible even if `noVideos` is `true`. This PR makes sure that `noVideos` property from `params` should be checked if `allowCommandVideo` is true. [1]: 187251 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Fo

Original PR description

After merging of this PR [1], video tab will not be visible in media dialog in report as `allowCommandVideo` is false. But this will override `noVideos` option from `params` to false if `allowCommandVideo` is true and video tab will be visible even if `noVideos` is `true`.

This PR makes sure that `noVideos` property from `params` should be checked if `allowCommandVideo` is true.

[1]: 187251



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

Forward-Port-Of: odoo/odoo#192838

[FW][IMP] point_of_sale, bus: ensure websocket connection

PR #194487

Core18.0point_of_salepos_adyenpos_eventpos_mercado_pagopos_online_paymentpos_viva_wallet

This commit ensures that the websocket connection is established when receiving a connect or initialized event. This can happen in multitab use of Odoo. Forward-Port-Of: odoo/odoo#194343

Original PR description

This commit ensures that the websocket connection is established when receiving a connect or initialized event.

This can happen in multitab use of Odoo.

Forward-Port-Of: odoo/odoo#194343

[FW][FIX] website: Fix hreflang website test

PR #194247

Core18.0website

The Issue: Prior to this commit, invoking _get_frontend resulted in the get_current_website function returning a different website than the one specified in the MockRequest. The Fix: To resolve this, we ensure the function selects the correct website by explicitly passing it in the context. runbot-64729 Forward-Port-Of: odoo/odoo#189705

Original PR description

The Issue:
Prior to this commit, invoking _get_frontend resulted in the get_current_website function returning a different website than the one specified in the MockRequest.

The Fix:
To resolve this, we ensure the function selects the correct website by explicitly passing it in the context.

runbot-64729

Forward-Port-Of: odoo/odoo#189705

[FW][FIX] web_editor: fix custom block translations

PR #194635

Core18.0web_editorwebsite

Steps to reproduce: - Add a "Call To Action" block on the homepage > Save it as a custom snippet. - Add a new page > Drop the saved custom block on it > Drop Also another "Title" block. - Translate the custom block in the new page > At this point, the translation is fine. - Go to "Edit" mode > Edit the other block ("Title") > Save. - The translations for the custom "Call To Action" is lost. Starting from [1], the translation of custom snippets was supported and when dropping a save

Original PR description

Steps to reproduce:

- Add a "Call To Action" block on the homepage > Save it as a custom
snippet.
- Add a new page > Drop the saved custom block on it > Drop Also
another "Title" block.
- Translate the custom block in the new page > At this point, the
translation is fine.
- Go to "Edit" mode > Edit the other block ("Title") > Save.
- The translations for the custom "Call To Action" is lost.

Starting from [1], the translation of custom snippets was supported and
when dropping a saved custom snippet in a page/view, the snippet will
copy its translation from the saved view (see:
`_copy_custom_snippet_translations()`). This code will always update the
terms in the translation dictionary, even when the page has its custom
translation for them.

The goal of this commit is to fix this behavior by only allowing the
update of a term translation when the page has no custom translation
for it.

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

opw-3930862
opw-4141290

Forward-Port-Of: odoo/odoo#194234
Forward-Port-Of: odoo/odoo#177960

[FW][FIX] crm: onboarding tour bubble fix

PR #193395

Core18.0crm

Tour bubble points to every New button in kanban. Fixed it to only point at New button in crm lead kanban view. Task-4377574 Forward-Port-Of: odoo/odoo#190937

Original PR description

Tour bubble points to every New button in kanban.
Fixed it to only point at New button in crm lead kanban view.

Task-4377574

Forward-Port-Of: odoo/odoo#190937

[FW][FIX] hr_holidays: allow search on name

PR #194522

Core18.0hr_holidays

Steps to reproduce: - Go in time off app -> overview - Search on name Issue: When searching on name, the search does not work. This is due to the name being computed and not stored. Directly related to the [recent changes](https://github.com/odoo/odoo/commit/7a65a1b6ac34f214) Fix The field has now a search method on the different component of the name separetly. opw-4351362 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forwa

Original PR description

Steps to reproduce:

 - Go in time off app -> overview
 - Search on name

Issue:

When searching on name, the search does not work. This is due to the
name being computed and not stored. Directly related to the [recent
changes](https://github.com/odoo/odoo/commit/7a65a1b6ac34f214)

Fix

The field has now a search method on the different component of the name
separetly.

opw-4351362

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

Forward-Port-Of: odoo/odoo#188433

[FW][FIX] hr_payroll_account{,_sepa}: verify iban if SEPA

PR #77685

Enterprise18.0

Scenario: - have non IBAN bank account for an employee - generate payment slips - create for payment slip a Payment Report of type CSV => An error is raised because the employee doesn't have a valid IBAN bank account Issue: We verify in all cases that the employee accounts are valid IBAN, but we should only check if they are IBAN if this is a SEPA report. Fix: Move the code to only do it in case we are generating a SEPA report. Note: without the fix, the added tests fail

Original PR description

Scenario:

- have non IBAN bank account for an employee
- generate payment slips
- create for payment slip a Payment Report of type CSV

=> An error is raised because the employee doesn't have a valid IBAN
bank account

Issue:

We verify in all cases that the employee accounts are valid IBAN, but we
should only check if they are IBAN if this is a SEPA report.

Fix:

Move the code to only do it in case we are generating a SEPA report.

Note: without the fix, the added tests fails with:

> UserError: Invalid IBAN for the following employees: John

when generating the CSV payment report.

opw-[4371726](https://www.odoo.com/web#id=4371726&view_type=form&model=project.task)

Forward-Port-Of: odoo/enterprise#76230

[FW][FIX] test_sale_subscription: make uninstall possible

PR #77657

Enterprise18.0

The uninstallation of this test module, which is a standard step during upgrades, requires the removal of the test product `product_fire_insurance`. This product is referenced by sale orders and invoices and deferred invoices created dynamically and have no xmlids, blocking the removal of the record. This commits adds the xmlids to the dynamically created orders and moves so they can be removed as well during the module uninstallation. The target sale orders are those created via 'copy' and whe

Original PR description

The uninstallation of this test module, which is a standard step during upgrades, requires the removal of the test product `product_fire_insurance`. This product is referenced by sale orders and invoices and deferred invoices created dynamically and have no xmlids, blocking the removal of the record. This commits adds the xmlids to the dynamically created orders and moves so they can be removed as well during the module uninstallation.
The target sale orders are those created via 'copy' and when doing upsell and renew for subscriptions.
The target moves are the regular invoices for the sale orders and their deferred moves.

Forward-Port-Of: odoo/enterprise#77587
Forward-Port-Of: odoo/enterprise#76813

[FW][IMP] l10n_be_hr_payroll: fix schedule change warning visual

PR #77658

Enterprise18.0

- add `alert alert-warning` as classes instead of adding style color to unify the warning visual Task: 4432816 Forward-Port-Of: odoo/enterprise#77596 Forward-Port-Of: odoo/enterprise#77161

Original PR description

- add `alert alert-warning` as classes instead of adding style color to unify the warning visual

Task: 4432816

Forward-Port-Of: odoo/enterprise#77596
Forward-Port-Of: odoo/enterprise#77161

[FW][FIX] [16.0] account_accountant: Remove unnecesary group on account.payment form

PR #77583

Enterprise18.0

# Issue Account Manager permission is required to access the payment journal. # Expected In previous and later versions of Odoo this permission was given by ‘account.group_account_user’. # FIX This PR removes XPATH because original groups of the [Base View](https://github.com/odoo/odoo/blob/16.0/addons/account/views/account_payment_view.xml#L234) are capable to see Journal Entries/Items. Removing `account.group_account_readonly` via account_accountant module inheritance is unnecessary

Original PR description

# Issue
Account Manager permission is required to access the payment journal.

# Expected
In previous and later versions of Odoo this permission was given by ‘account.group_account_user’.

# FIX
This PR removes XPATH because original groups of the [Base View](https://github.com/odoo/odoo/blob/16.0/addons/account/views/account_payment_view.xml#L234) are capable to see Journal Entries/Items.
Removing `account.group_account_readonly` via account_accountant module inheritance is unnecessary and it's more restrictive. If some restriction wants to be applied, should be done in Base View.

# Additional Context/Explanation
This PR was done 3 months ago https://github.com/odoo/enterprise/commit/06e95b281dc000e5f3904b6051fe81afe8db3989 on v18, but the XPATH overrides the original group removing the `account.group_account_readonly`, which has enough permissions to see Journal Entries (even with a Menu Item). Reasoned with @hupo-odoo on https://github.com/odoo/enterprise/pull/76802#issuecomment-2586509116 that we need to get rid of the xpath instead of backport the functionality.

## Explaining briefly involved groups:
- `account.group_account_invoice`: You can see payments (with menu) and invoices, but you can't see journal entries on a menu.
- `account.group_account_readonly`: You can see Journal Entries/Items menu and Payments.
- `account.group_account_user`: Inherits from `account.group_account_readonly`.
- `account.group_account_manager`: Inherits from `account.group_account_user`.

# Available Forward Ports
## v17:
account_accountant xpath: https://github.com/odoo/enterprise/blame/17.0/account_accountant/views/account_payment_views.xml#L8-L10
base view:
https://github.com/odoo/odoo/blob/17.0/addons/account/views/account_payment_view.xml#L242
## v18
account_accountant xpath: https://github.com/odoo/enterprise/blame/18.0/account_accountant/views/account_payment_views.xml#L8-L10
base view:
https://github.com/odoo/odoo/blob/18.0/addons/account/views/account_payment_view.xml#L232

---

MT-8088 @moduon @edlopen @hupo-odoo @yajo @rafaelbn please review if you want :)

OPW-4465140

Forward-Port-Of: odoo/enterprise#77129

[FW][FIX] pos_settle_due: make total_due visible when searching for more customers

PR #77604

Enterprise18.0

Currently, simple pos users can see the due amount of the customers, unless the customer wasn't loaded and we need to search for a customer that isn't loaded. Steps to reproduce: ------------------- * Create a new customer, make a sale order and invoice it. This will set an amount due for that customer * Connect to the shop with a user that has the `point_of_sale.group_pos_user` but not the `account.group_account_readonly` group * Open customer list > Observation: You can see the amount

Original PR description

Currently, simple pos users can see the due amount of the customers, unless the customer wasn't loaded and we need to search for a customer that isn't loaded.

Steps to reproduce:
-------------------
* Create a new customer, make a sale order and invoice it. This will set an amount due for that customer
* Connect to the shop with a user that has the `point_of_sale.group_pos_user` but not the `account.group_account_readonly` group
* Open customer list
> Observation: You can see the amount due for multiple customers
* Search for the customer created
* Select search more
> You can't see the amount due for that customer

Why the fix:
------------
Since simple pos users are allowed to see the amount due for the loaded customer, there is no reason they shouldn't see it as well for a customer they need to load.

Commit allowing simple pos users to see (and settle) customer accounts: https://github.com/odoo/enterprise/commit/37fa4d5f4ed7c7d77f73395a53b7b3ab7006afc4

When loading the pos session `_loader_params_res_partner` is called first and later is called `_get_pos_ui_res_partner`. It is in the function `_get_pos_ui_res_partner` that the amount due is compted if the user does not belong to the group `account.group_account_readonly`.

https://github.com/odoo/enterprise/blob/a35a4755cdf86bcfeda0aca6c06397748ba27362/pos_settle_due/models/pos_session.py#L22-L28

However when we load a customer that wasn't previously loaded, only `_loader_params_res_partner` is loaded. And since the users does not belong to the group `account.group_account_readonly`, the field witll not get loaded.

We now compute the amount due with the same logic as in `_get_pos_ui_res_partner`.

opw-4141955

Forward-Port-Of: odoo/enterprise#77247
Forward-Port-Of: odoo/enterprise#73671

[FW][IMP] account_followup: follow-up level next reminder tool tip

PR #77486

Enterprise18.0

The tool tip is being replaced with a more concise message. task-4437887 Forward-Port-Of: odoo/enterprise#77436 Forward-Port-Of: odoo/enterprise#76474

Original PR description

The tool tip is being replaced with a more concise message.

task-4437887

Forward-Port-Of: odoo/enterprise#77436
Forward-Port-Of: odoo/enterprise#76474

[FW][FIX] account_asset: allow to create asset models

PR #77603

Enterprise18.0

**Steps to reproduce:** - Install Accounting - Go to "Accounting / Configuration / Management / Asset Models" - Create an asset model **Issue:** Upon save, the following UserError is raised: "You cannot add or remove bills when the asset is already running or closed." **Cause:** A check has been added to prevent adding bills to a running asset. The check is excluding draft assets but not asset models that are assets in "model" state. **Issue:** Exclude asset models from the chec

Original PR description

**Steps to reproduce:**
- Install Accounting
- Go to "Accounting / Configuration / Management / Asset Models"
- Create an asset model

**Issue:**
Upon save, the following UserError is raised:
"You cannot add or remove bills when the asset is already running or closed."

**Cause:**
A check has been added to prevent adding bills to a running asset.
The check is excluding draft assets but not asset models that are assets in "model" state.

**Issue:**
Exclude asset models from the check.

opw-4479698

Forward-Port-Of: odoo/enterprise#77472

[FW][IMP] pos_restaurant_appointment: ensure websocket connection

PR #77477

Enterprise18.0

This commit ensures that the websocket connection is established when receiving a connect or initialized event. This can happen in multitab use of Odoo. Forward-Port-Of: odoo/enterprise#77416

Original PR description

This commit ensures that the websocket connection is established when receiving a connect or initialized event.

This can happen in multitab use of Odoo.

Forward-Port-Of: odoo/enterprise#77416

[FW][REF] hr_payroll_account: create account moves in batch

PR #77544

Enterprise18.0

Before this commit, created moves were not done in batch making the amount of queries go up uselessly. This commit makes that creation in batch and adapts the query counters in tests. task-4299915 Forward-Port-Of: odoo/enterprise#77287 Forward-Port-Of: odoo/enterprise#73145

Original PR description

Before this commit, created moves were not done in batch making the amount of queries go up uselessly.

This commit makes that creation in batch and adapts the query counters in tests.

task-4299915

Forward-Port-Of: odoo/enterprise#77287
Forward-Port-Of: odoo/enterprise#73145

Rows:Rows per page:

10 25 50 100

1 / 2Page 1 of 2 · 143 days total