Odoo Changelog — 2025-12-11

Thursday, December 11, 2025

17 changes · saas-18.3

Bug Fixes(17)

Resolved issues and error corrections

[FIX] base: invalid user-defined defaults value

Coresaas-18.3base

This update resolves a bug that prevented users from setting invalid default values for certain fields. Specifically, attempting to set an integer as a default date caused an error. The fix ensures users can only define valid default values, improving data integrity and preventing unexpected system behavior.

Original PR description

Steps:
- Create a user defined defaults value
    - Model: res.partner
    - Field: date
    - Value: 1
- Create a new contact

Actual result:
- invalid field type
- 'int' object is not subscriptable (depends of field type)

Expected result:
- No error
- User is not able to put an invalid value as a default

task-3729963

Forward-Port-Of: odoo/odoo#237265
Forward-Port-Of: odoo/odoo#225991

#data integrity#defaults

[FIX] portal,website: prevent revoked portal user set as website default public user

PR #238384

Coresaas-18.3portalwebsite

This update resolves an issue where previously revoked portal users could inadvertently become the default public user for new websites. This prevented potential confidentiality risks and ensures that website public user settings are correctly managed. The fix maintains the ability to reactivate these users while preventing misconfiguration.

Original PR description

**Steps to reproduce:**
- Go to a Contact
- Go to the actions dropdown menu of the record
- Grant Portal Access
- Revoke that Access
- Create a new Website in the same Company that Portal Access was granted
- That Contact's user will be set as the Public User for the new Website
- New orders and other default public user behavior will be assigned to this user
- The user will be mentionned in non-logged interactions

**Issue:**
Archived portal user are set as public user when revoked, and the default public user of a website is set on create to the first public user it finds in `_get_public_user`:
```
public_users = self.env.ref('base.group_public').sudo().with_context(active_test=False).users
public_users_for_company = public_users.filtered(lambda user: user.company_id == self)

if public_users_for_company:
    return public_users_for_company[0]
```

This seems to be an issue as such user can be reactivated or be assigned to some transactions it has not made (confidentiality issue).

**Fix:**
Not sure of the best way to fix this. We could ensure new website always creates a new public user, or find a better way to use by default the `self.env.ref('base.public_user')` (or its company-specific copies) for the company of the website during creation (or in `_get_public_user`).

For now the fix remove the public group on the revoked portal user, to still be able to reactivate it later on, without mistaking it for the default public user of a company.

Also we can't remove the `with_context(active_test=False)` as default public user always seems to be disabled.

related: https://github.com/odoo/odoo/commit/83e22fd0636748c4fe1058fb93adfad2623fc31b

opw-4760550

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

Forward-Port-Of: odoo/odoo#236014
Forward-Port-Of: odoo/odoo#233757

[FIX] account_reports: add missing account type in balance sheet

PR #101591

Enterprisesaas-18.3account

This update fixes a bug where the 'Other Expenses' account type wasn't reflected in the Balance Sheet report. A new account type was recently added to simplify vendor bill expense tracking. This change ensures all financial data is accurately represented in the Balance Sheet.

Original PR description

In saas-18.3 a new account type was added: "Other Expenses" These accounts are excluded from the account many2one field to make it easier to find relevant expense accounts for vendor bills.

Issue: This account type is not included in the Balance Sheet report.

see comment in opw-5269456 related to
opw-5191111

#financial reporting#expense accounts#balance sheet

[FIX] accountant: prevent traceback on setting accounting period for tax returns

PR #101442

Enterprisesaas-18.3accountant

This update resolves a problem that prevented users from correctly configuring tax returns within the Accounting module. Specifically, a missing step in the installation process caused an error when setting the opening date for tax returns. The fix ensures the necessary setup is performed, allowing users to proceed with configuring their tax returns without issues.

Original PR description

From **saas-18.3**, when installing the accountant module, after [this PR](https://github.com/odoo/enterprise/commit/49aca723c2422fedcc8bda963a6346a172825617#diff-c703c688dc3f80644a43c96657cb2db0122b83cee9bcfa417554b0c7f1e4f550L22) the `_initiate_account_onboardings()` was not called anymore for companies that already had a chart template.

This caused a traceback while configuring the Accounting Period on the Tax Returns journal: 
`ValueError - Expected singleton: onboarding.progress()`

We now fix this behavior by ensuring that `_initiate_account_onboardings()` is called when installing the chart_template, filling the gap that was introduced.

**Steps to Reproduce:**
1. Install `accountant` module without demo data.
2. Accounting > Dashboard > _Tax Returns_ Journal, click on the **"Tax Returns"** button.
3. Set an **Opening Date** in the wizard and try to apply the **Accounting Periods**.

sentry-7064593163

#accounting#tax returns#configuration

[FIX] l10n_cl_edi: prevent setting false sequence with no document

PR #101826

Enterprisesaas-18.3l10n_cl_edi

This update fixes a potential issue in the Chilean VAT (l10n_cl_edi) module where incorrect sequence numbers could be generated for VAT documents. Previously, if a specific journal setting wasn't used, the system might have produced sequences starting with 'False'. This change ensures accurate and reliable sequence generation, preventing potential reporting errors.

Original PR description

Before this commit, if the journal is not set to using the document (l10n_latam_use_documents), the method _get_last_sequence could return a sequence that starts with False.

opw-5404813

Forward-Port-Of: odoo/enterprise#101824

#vat#reporting#accounting

[FIX] base, l10n_tr_nilvera: update translations when installing language

PR #239556

Coresaas-18.3l10n_tr_nilvera

This update ensures that Turkish translations are properly applied when installing the 'l10n_tr_nilvera' language pack in new Odoo databases. Previously, translations weren't automatically updated, requiring manual intervention. This fix streamlines the language installation process for Turkish users.

Original PR description

### Issue: When installing "l10n_tr_nilvera" on a new DB the Turkish language is installed but the translation of previously installed modules are not updated. ### Steps to reproduce: - Install…

### Issue:
When installing "l10n_tr_nilvera" on a new DB the Turkish language is installed but
the translation of previously installed modules are not updated.

### Steps to reproduce:
- Install 'l10n_tr_nilvera' and switch to a Saudi company
- Check the view "report_invoice_document"
- Click the translation icon on the view
- No Turkish translations are loaded

### Cause:
When installing "l10n_gcc_invoice" the Arabic language is installed ([src](https://github.com/odoo/odoo/blob/70404624d7ea6f971182cbe4f4fe8fc064d2afd8/addons/l10n_gcc_invoice/__init__.py#L4-L5)). But the method [`_activate_lang()`](https://github.com/odoo/odoo/blob/70404624d7ea6f971182cbe4f4fe8fc064d2afd8/odoo/addons/base/models/res_lang.py#L161-L169) only activates the language, it does not update the translations.

### Solution:
Create a new method that activate the language and calls `_update_translations()` on the installed modules.

opw-5219783

Forward-Port-Of: odoo/odoo#239310
Forward-Port-Of: odoo/odoo#237041

[FIX] account: don't show entries in filtered invoices

PR #239511

Coresaas-18.3account

This update resolves a problem where imported invoices were incorrectly displayed in filtered invoice views, even when already reconciled. The fix ensures that filters accurately exclude imported entries, providing a cleaner and more reliable view of unpaid invoices for users. This improves data accuracy and simplifies invoice management.

Original PR description

Error steps:
- Create or import "miscellaneous" entries in a sales journal (through the FEC import e.g.)
- Have at least one late or unpaid invoice in the same journal.
- The journal dashboard view should display a "X Unpaid" or "X Late" suggestion -> click on it
=> The filtered view shows the correct unpaid or overdue invoices/bills AS WELL as the imported entries, even if the latter are fully reconciled already.

Now the filters correctly filter out the entries.

opw-5215997

Forward-Port-Of: odoo/odoo#237092

#invoice#filtering#reporting

[FIX] mrp: fix printing multiple generated sn labels

PR #239553

Coresaas-18.3mrp

This update resolves an issue where SN labels weren't generated when producing multiple units of a product through the manufacturing process. Previously, MOs with quantities greater than one would fail to print the required labels. This fix ensures that SN labels are consistently printed for all produced units, streamlining tracking and traceability.

Original PR description

This commit fixes the issue of not printing Lot/SN labels when generating them on the MO that has more than 1 unit on the quantity to produce.

To reproduce the bug:
1- Go to Operation Types → Manufacturing → Hardware → activate the print `Lot/SN Label` (Print When "Create New Lot/SN")
2- Create an MO with quantity of 5 for a tracked product. 
3- Click on `Produce All` and use the wizard to generate SNs and produce or confirm the MO.

= SNs should be printed but they are not.

opw-5347787

Forward-Port-Of: odoo/odoo#238739

#manufacturing#lot-sn#production

[FIX] website_event_track_gantt: prevent crash when event dates is cleared

PR #101870

Enterprisesaas-18.3website_event_track_gantt

This update resolves an issue where the Gantt chart would crash when event start or end dates were cleared. The fix ensures the Gantt calculation only runs when a valid date range exists, preventing a type error that occurred when comparing dates with boolean values. This improves stability and usability of event scheduling.

Original PR description

When removing the start or end date on an Event, the system raises a traceback during Gantt information computation.

**Steps to Reproduce:**
1. Install `website_event_track_gantt` module.
2. Create a new Event.
3. Add at least one **Track** with a track **Date** and **Duration**.
4. In the Event form, clear the Start or End Date field.

**Error:**
`TypeError: '<' not supported between instances of 'datetime.datetime' and 'bool'`

**Cause:**
When the event start or end date is removed, those fields become False. During computation, the system attempts to compare these False values with the track dates (which are real datetimes), resulting in an invalid datetime-boolean comparison, causing the error.

**Fix:**
This commit ensures the Gantt calculation only executes when the event has a valid date range, avoiding comparisons that include missing values.

no id

Forward-Port-Of: odoo/enterprise#101541

#gantt#events#scheduling

[FIX] l10n_cl: prevent traceback when confirming an invoice

PR #239247

Coresaas-18.3l10n_cl

This update fixes a bug that caused invoices with zero amounts to crash during confirmation. The fix prevents a division-by-zero error by adding a check to ensure the invoice total is not zero before calculating currency rates. This ensures invoices can be processed correctly, regardless of the currency or line item values.

Original PR description

Steps to reproduce:
--------------------
1. Install l10n_cl and switch to the CL company
2. Create a new invoice:
   - Change the currency to a value different from the company currency
     (e.g., from CLP to USD)
   - Add an invoice line with a price value of 0
   - Remove the default tax value
3. Try to confirm the invoice

Issue:
------
A traceback occurs:
`ZeroDivisionError: float division by zero`

Cause:
------
Since the price value is 0, the `amount_total` of the move becomes 0. 
When computing the currency rate, it tries to divides by `amount_total`, resulting in a ZeroDivisionError.

Solution:
---------
Add a conditional check before division to ensure the `amount_total` is non-zero

Related enterprise PR: https://github.com/odoo/enterprise/pull/99518

opw-5247058

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

Forward-Port-Of: odoo/odoo#239063
Forward-Port-Of: odoo/odoo#235252

#invoice#currency#cl

[FIX] l10n_cl_edi: add test to prevent traceback when confirming an invoice

PR #101695

Enterprisesaas-18.3l10n_cl_edi

This update fixes a potential error that could prevent invoices from being confirmed when specific currency and pricing settings are used. The fix adds a check to ensure invoice amounts are non-zero before currency calculations, preventing a division-by-zero error. This ensures smoother invoice processing and avoids disruptions to financial operations.

Original PR description

Steps to reproduce:
--------------------
1. Install l10n_cl and switch to the CL company
2. Create a new invoice:
   - Change the currency to a value different from the company currency
   (e.g., from CLP to USD)
   - Add an invoice line with a price value of 0
   - Remove the default tax value
3. Try to confirm the invoice

Issue:
------
A traceback occurs:
`ZeroDivisionError: float division by zero`

Cause:
------
Since the price value is 0, the `amount_total` of the move becomes 0.
When computing the currency rate, it tries to divides by `amount_total`, resulting in a ZeroDivisionError.

Solution:
---------
Add a conditional check before division to ensure the `amount_total` is non-zero

Related community PR: https://github.com/odoo/odoo/pull/235252

opw-5247058

Forward-Port-Of: odoo/enterprise#101587
Forward-Port-Of: odoo/enterprise#99518

#invoice#currency#error

[FIX] stock_account, sale_stock: avoid recomputing delivery date

PR #238948

Coresaas-18.3sale_stockstock_account

This update prevents the delivery date from being automatically recalculated when an invoice is reset to draft. Previously, this could overwrite user-entered delivery dates, causing confusion and requiring manual corrections. This change ensures accurate delivery date tracking for invoices.

Original PR description

**PROBLEM**
Resetting to draft an invoice can sometimes recompute the delivery date, overwritting any value the user may have enter.

**STEP TO REPRODUCE**
1. Enable anglo-saxon accounting
2. have a product category with automated AVCO
3. assign category to a deliverable product
4. set product to invoice on delivery
5. add product to a sales order
6. confirm order & delivery
7. create invoice
8. change the delivery on the invoice
9. confirm the invoice.
10. reset the invoice to draft.

**CAUSE**
button_draft() unlinks some account.move.lines, triggering the compute on delivery_date.

see for more info : https://github.com/odoo/odoo/pull/231186
opw-5347939

Forward-Port-Of: odoo/odoo#237612

#delivery date#invoice#automation

[FIX] portal: Redirect after confirming address

PR #239036

Coresaas-18.3portalwebsite_event_sale

This update resolves a bug that prevented users from completing the address confirmation process after purchasing a ticket. The issue stemmed from a problem with how the system handled missing customer names during the confirmation step. The fix ensures a smooth redirect after address confirmation, improving the user experience.

Original PR description

Steps to reproduce:
===================
1. On an event, make sure to:
- Have at least one paying ticket;
- Remove any "name" or "email" type of question.
2. Go to the event website page as a public visitor and buy one ticket.
   Fill in the form and click on "Go to payment".

-> Nothing happens.

Cause:
======
Clicking on "Go to payment" triggers the registration_confirm function:
https://github.com/odoo/odoo/blob/e91c3817574af8bd48a634e3fb0b2f0e08b21ee9/addons/website_event_sale/controllers/main.py#L78

Triggering `_create_or_update_address` for the first time will create
a partner without a `name`:
https://github.com/odoo/odoo/blob/fa137d08669db2f10cf735a2bc1278b3f1b4f5a9/addons/portal/controllers/portal.py#L543

When clicking on the confirm button, it will re-trigger
`_create_or_update_address`. At that moment, `partner_sudo.name` is
`False`, so the confirmation breaks on: `partner_sudo.name.strip()`
because you cannot call `.strip()` on a `False` value.

Solution:
=========
If the name is not set, simply treat it as unchanged and continue.
In the registration form, a name should normally be provided by default.

opw-5357924

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

[FIX] point_of_sale: allow product archive if unrelated to point_of_sale

PR #239490

Coresaas-18.3point_of_sale

This update resolves an issue preventing non-POS users from archiving products. Previously, a lack of POS access rights triggered an error, even if the product wasn't used in a POS session. This change ensures that all users can archive products, regardless of their POS access, improving workflow efficiency.

Original PR description

### Steps to reproduce:

- With Admin open a pos session
- With an other user without pos access rights archive a product unrelated to pos (e.g. not used in the session)
#### > Access error: You are not allowed to access 'Point of Sale Session' (pos.session) records. This operation is allowed for the following groups: - Point of Sale/User

### Cause of the issue:

Since 985fd5821fe1e8633503d713f1f1c3650bcf0c91 the `action_archive` of products, check that the product is not used by an order of any opened `pos.session` before allowing the user to archive it: https://github.com/odoo/odoo/blob/2011885246f5473ddc16fe5bd17db98ebff712f3/addons/point_of_sale/models/product_product.py#L51-L53 https://github.com/odoo/odoo/blob/2011885246f5473ddc16fe5bd17db98ebff712f3/addons/point_of_sale/models/product_template.py#L313-L320 However, if the user does not have any pos access rights he can not access the pos session to check if the product is used which raises an access error even if the product is un-used.

### Note:

This is notably problematic as it makes it impossible to archive products via the `action_archive` in unrelated stock tests relying on a non-admin user.

opw-stock-tests

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

[FIX] esg: emission stat button display in account move

PR #101906

Enterprisesaas-18.3account

This update allows the 'Emissions stat' button to be displayed on a wider range of accounting documents, including Purchase Receipts, previously it was limited to Vendor Bills. This expands the data available for tracking and reporting environmental impact within our accounting processes.

Original PR description

Prior to this PR, we limited the display of the Emissions stat button of 'account.move' to Vendor Bills and Credit Vendor Bills ('in_invoice' and 'in_refund'). But emissions could be reported in other types of moves (e.g. Purchase Receipt), so we remove that condition.

task-5407761

#sustainability#reporting#account

[FIX] html_editor: fix non-deterministic test fail

PR #239479

Coresaas-18.3html_editor

A minor bug causing test failures in the HTML Editor has been resolved. The fix updated a test selector to avoid unintended targeting of elements within the toolbar, ensuring consistent test results. This improves the reliability of the HTML Editor functionality.

Original PR description

Because of the toolbar being sometimes opened, the test added in odoo#238735 would sometimes failed. This was due to the selector "span" also targetting the elements in the toolbar.

To prevent this test from failing, the selector "span" was updated to be more specific.

Forward-Port-Of: odoo/odoo#239174

#testing#html_editor

[FIX] tools/translate: Missing confirm-title as translatable attribute

PR #239328

Coresaas-18.3mass_mailing

This update corrects a technical issue where the text displayed in a confirmation window was not being included in the translation files for Odoo's mass mailing feature. This meant the text "Ready to unleash emails?" was not available for translation into other languages. The fix ensures this text is properly identified as translatable, allowing for accurate localization and a consistent user experience across different languages.

Original PR description

Description of the issue/feature this PR addresses:
The texts from the "confirm-title" attribute of a tag are missing from the POT files.

Current behavior before PR:
In this line there is a text (the caption of the confirmation window): https://github.com/odoo/odoo/blob/19.0/addons/mass_mailing/views/mailing_mailing_views.xml#L66
"Ready to unleash emails?" - This text is missing from the POT file.

Desired behavior after PR is merged:

* These texts will apeear in POT files
* Someone needs to translated them
* It will show up as translated texts in UI

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

Forward-Port-Of: odoo/odoo#239183
Forward-Port-Of: odoo/odoo#239034

#translation#localization#UI

Steps: - Create a user defined defaults value - Model: res.partner - Field: date - Value: 1 - Create a new contact Actual result: - invalid field type - 'int' object is not subscriptable (depends of field type) Expected result: - No error - User is not able to put an invalid value as a default task-3729963 Forward-Port-Of: odoo/odoo#237265 Forward-Port-Of: odoo/odoo#225991

**Steps to reproduce:** - Go to a Contact - Go to the actions dropdown menu of the record - Grant Portal Access - Revoke that Access - Create a new Website in the same Company that Portal Access was granted - That Contact's user will be set as the Public User for the new Website - New orders and other default public user behavior will be assigned to this user - The user will be mentionned in non-logged interactions **Issue:** Archived portal user are set as public user when revoked, and the default public user of a website is set on create to the first public user it finds in `_get_public_user`: ``` public_users = self.env.ref('base.group_public').sudo().with_context(active_test=False).users public_users_for_company = public_users.filtered(lambda user: user.company_id == self) if public_users_for_company: return public_users_for_company[0] ``` This seems to be an issue as such user can be reactivated or be assigned to some transactions it has not made (confidentiality issue). **Fix:** Not sure of the best way to fix this. We could ensure new website always creates a new public user, or find a better way to use by default the `self.env.ref('base.public_user')` (or its company-specific copies) for the company of the website during creation (or in `_get_public_user`). For now the fix remove the public group on the revoked portal user, to still be able to reactivate it later on, without mistaking it for the default public user of a company. Also we can't remove the `with_context(active_test=False)` as default public user always seems to be disabled. related: https://github.com/odoo/odoo/commit/83e22fd0636748c4fe1058fb93adfad2623fc31b opw-4760550 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236014 Forward-Port-Of: odoo/odoo#233757

In saas-18.3 a new account type was added: "Other Expenses" These accounts are excluded from the account many2one field to make it easier to find relevant expense accounts for vendor bills. Issue: This account type is not included in the Balance Sheet report. see comment in opw-5269456 related to opw-5191111

From **saas-18.3**, when installing the accountant module, after [this PR](https://github.com/odoo/enterprise/commit/49aca723c2422fedcc8bda963a6346a172825617#diff-c703c688dc3f80644a43c96657cb2db0122b83cee9bcfa417554b0c7f1e4f550L22) the `_initiate_account_onboardings()` was not called anymore for companies that already had a chart template. This caused a traceback while configuring the Accounting Period on the Tax Returns journal: `ValueError - Expected singleton: onboarding.progress()` We now fix this behavior by ensuring that `_initiate_account_onboardings()` is called when installing the chart_template, filling the gap that was introduced. **Steps to Reproduce:** 1. Install `accountant` module without demo data. 2. Accounting > Dashboard > _Tax Returns_ Journal, click on the **"Tax Returns"** button. 3. Set an **Opening Date** in the wizard and try to apply the **Accounting Periods**. sentry-7064593163

Before this commit, if the journal is not set to using the document (l10n_latam_use_documents), the method _get_last_sequence could return a sequence that starts with False. opw-5404813 Forward-Port-Of: odoo/enterprise#101824

### Issue: When installing "l10n_tr_nilvera" on a new DB the Turkish language is installed but the translation of previously installed modules are not updated. ### Steps to reproduce: - Install 'l10n_tr_nilvera' and switch to a Saudi company - Check the view "report_invoice_document" - Click the translation icon on the view - No Turkish translations are loaded ### Cause: When installing "l10n_gcc_invoice" the Arabic language is installed ([src](https://github.com/odoo/odoo/blob/70404624d7ea6f971182cbe4f4fe8fc064d2afd8/addons/l10n_gcc_invoice/__init__.py#L4-L5)). But the method [`_activate_lang()`](https://github.com/odoo/odoo/blob/70404624d7ea6f971182cbe4f4fe8fc064d2afd8/odoo/addons/base/models/res_lang.py#L161-L169) only activates the language, it does not update the translations. ### Solution: Create a new method that activate the language and calls `_update_translations()` on the installed modules. opw-5219783 Forward-Port-Of: odoo/odoo#239310 Forward-Port-Of: odoo/odoo#237041

Error steps: - Create or import "miscellaneous" entries in a sales journal (through the FEC import e.g.) - Have at least one late or unpaid invoice in the same journal. - The journal dashboard view should display a "X Unpaid" or "X Late" suggestion -> click on it => The filtered view shows the correct unpaid or overdue invoices/bills AS WELL as the imported entries, even if the latter are fully reconciled already. Now the filters correctly filter out the entries. opw-5215997 Forward-Port-Of: odoo/odoo#237092

This commit fixes the issue of not printing Lot/SN labels when generating them on the MO that has more than 1 unit on the quantity to produce. To reproduce the bug: 1- Go to Operation Types → Manufacturing → Hardware → activate the print `Lot/SN Label` (Print When "Create New Lot/SN") 2- Create an MO with quantity of 5 for a tracked product. 3- Click on `Produce All` and use the wizard to generate SNs and produce or confirm the MO. = SNs should be printed but they are not. opw-5347787 Forward-Port-Of: odoo/odoo#238739

When removing the start or end date on an Event, the system raises a traceback during Gantt information computation. **Steps to Reproduce:** 1. Install `website_event_track_gantt` module. 2. Create a new Event. 3. Add at least one **Track** with a track **Date** and **Duration**. 4. In the Event form, clear the Start or End Date field. **Error:** `TypeError: '<' not supported between instances of 'datetime.datetime' and 'bool'` **Cause:** When the event start or end date is removed, those fields become False. During computation, the system attempts to compare these False values with the track dates (which are real datetimes), resulting in an invalid datetime-boolean comparison, causing the error. **Fix:** This commit ensures the Gantt calculation only executes when the event has a valid date range, avoiding comparisons that include missing values. no id Forward-Port-Of: odoo/enterprise#101541

Steps to reproduce: -------------------- 1. Install l10n_cl and switch to the CL company 2. Create a new invoice: - Change the currency to a value different from the company currency (e.g., from CLP to USD) - Add an invoice line with a price value of 0 - Remove the default tax value 3. Try to confirm the invoice Issue: ------ A traceback occurs: `ZeroDivisionError: float division by zero` Cause: ------ Since the price value is 0, the `amount_total` of the move becomes 0. When computing the currency rate, it tries to divides by `amount_total`, resulting in a ZeroDivisionError. Solution: --------- Add a conditional check before division to ensure the `amount_total` is non-zero Related enterprise PR: https://github.com/odoo/enterprise/pull/99518 opw-5247058 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239063 Forward-Port-Of: odoo/odoo#235252

Steps to reproduce: -------------------- 1. Install l10n_cl and switch to the CL company 2. Create a new invoice: - Change the currency to a value different from the company currency (e.g., from CLP to USD) - Add an invoice line with a price value of 0 - Remove the default tax value 3. Try to confirm the invoice Issue: ------ A traceback occurs: `ZeroDivisionError: float division by zero` Cause: ------ Since the price value is 0, the `amount_total` of the move becomes 0. When computing the currency rate, it tries to divides by `amount_total`, resulting in a ZeroDivisionError. Solution: --------- Add a conditional check before division to ensure the `amount_total` is non-zero Related community PR: https://github.com/odoo/odoo/pull/235252 opw-5247058 Forward-Port-Of: odoo/enterprise#101587 Forward-Port-Of: odoo/enterprise#99518

**PROBLEM** Resetting to draft an invoice can sometimes recompute the delivery date, overwritting any value the user may have enter. **STEP TO REPRODUCE** 1. Enable anglo-saxon accounting 2. have a product category with automated AVCO 3. assign category to a deliverable product 4. set product to invoice on delivery 5. add product to a sales order 6. confirm order & delivery 7. create invoice 8. change the delivery on the invoice 9. confirm the invoice. 10. reset the invoice to draft. **CAUSE** button_draft() unlinks some account.move.lines, triggering the compute on delivery_date. see for more info : https://github.com/odoo/odoo/pull/231186 opw-5347939 Forward-Port-Of: odoo/odoo#237612

Steps to reproduce: =================== 1. On an event, make sure to: - Have at least one paying ticket; - Remove any "name" or "email" type of question. 2. Go to the event website page as a public visitor and buy one ticket. Fill in the form and click on "Go to payment". -> Nothing happens. Cause: ====== Clicking on "Go to payment" triggers the registration_confirm function: https://github.com/odoo/odoo/blob/e91c3817574af8bd48a634e3fb0b2f0e08b21ee9/addons/website_event_sale/controllers/main.py#L78 Triggering `_create_or_update_address` for the first time will create a partner without a `name`: https://github.com/odoo/odoo/blob/fa137d08669db2f10cf735a2bc1278b3f1b4f5a9/addons/portal/controllers/portal.py#L543 When clicking on the confirm button, it will re-trigger `_create_or_update_address`. At that moment, `partner_sudo.name` is `False`, so the confirmation breaks on: `partner_sudo.name.strip()` because you cannot call `.strip()` on a `False` value. Solution: ========= If the name is not set, simply treat it as unchanged and continue. In the registration form, a name should normally be provided by default. opw-5357924 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

### Steps to reproduce: - With Admin open a pos session - With an other user without pos access rights archive a product unrelated to pos (e.g. not used in the session) #### > Access error: You are not allowed to access 'Point of Sale Session' (pos.session) records. This operation is allowed for the following groups: - Point of Sale/User ### Cause of the issue: Since 985fd5821fe1e8633503d713f1f1c3650bcf0c91 the `action_archive` of products, check that the product is not used by an order of any opened `pos.session` before allowing the user to archive it: https://github.com/odoo/odoo/blob/2011885246f5473ddc16fe5bd17db98ebff712f3/addons/point_of_sale/models/product_product.py#L51-L53 https://github.com/odoo/odoo/blob/2011885246f5473ddc16fe5bd17db98ebff712f3/addons/point_of_sale/models/product_template.py#L313-L320 However, if the user does not have any pos access rights he can not access the pos session to check if the product is used which raises an access error even if the product is un-used. ### Note: This is notably problematic as it makes it impossible to archive products via the `action_archive` in unrelated stock tests relying on a non-admin user. opw-stock-tests --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Prior to this PR, we limited the display of the Emissions stat button of 'account.move' to Vendor Bills and Credit Vendor Bills ('in_invoice' and 'in_refund'). But emissions could be reported in other types of moves (e.g. Purchase Receipt), so we remove that condition. task-5407761

Because of the toolbar being sometimes opened, the test added in odoo#238735 would sometimes failed. This was due to the selector "span" also targetting the elements in the toolbar. To prevent this test from failing, the selector "span" was updated to be more specific. Forward-Port-Of: odoo/odoo#239174

Description of the issue/feature this PR addresses: The texts from the "confirm-title" attribute of a tag are missing from the POT files. Current behavior before PR: In this line there is a text (the caption of the confirmation window): https://github.com/odoo/odoo/blob/19.0/addons/mass_mailing/views/mailing_mailing_views.xml#L66 "Ready to unleash emails?" - This text is missing from the POT file. Desired behavior after PR is merged: * These texts will apeear in POT files * Someone needs to translated them * It will show up as translated texts in UI --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239183 Forward-Port-Of: odoo/odoo#239034