Daily updates from Odoo
Navigate
Branch
Monday, October 6, 2025
199 changes
11 changes
Enhancements to existing features
The bank matching edit line wizard now shows only the line name instead of combining it with the reference. This keeps long references from disrupting the layout while still leaving reference details available in the kanban view.
Original PR description
Problem: - The reference field was displayed together with the bill name, causing misalignment when the reference is quite long in the edit line wizard. Solution: - Updated the edit line wizard to display only the line's name. - The reference remains visible in the kanban view, it is only removed in the edit line wizard. task-5113489 Forward-Port-Of: odoo/enterprise#95575
Resolved issues and error corrections
This fix updates the live chat test environment so it includes the same user availability status information as the real server. It helps ensure automated tests better reflect actual behavior, reducing the chance of missed issues in live chat features.
Original PR description
**Description of the issue this PR addresses:** Add missing im_status field in mock server **Current behavior before PR:** Previously, the `im_status` field was available on the server side, but it was missing in the mock server implementation used in tests. **Desired behavior after PR is merged:** This PR updates the mock `DiscussChannelMember` model to include `im_status` in the list of stored partner fields, ensuring that test scenarios accurately reflect server behavior. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229865
This fixes an issue where a chat window could open even after the user had already seen the message in Discuss. The messaging frontend now recognizes messages that are already loaded and keeps the notification silent, reducing unnecessary interruptions.
Original PR description
Before this commit, if a message was already received in the store by another medium than the bus, it was still handled not-silently when receiving the bus notification `discuss.channel/new_message`. This could lead to opening a chat window when a message was already seen by the user in the discuss app. This commit changes the handling of new messages in the frontend and overrides the silent flag when the record already exists. fixes-runbot-230700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227445
Fixes an issue where validating Register Production/Serial in the shop floor could fail when multiple related quality checks existed. This prevents an error message from interrupting manufacturing operators and helps keep production workflows moving smoothly.
Original PR description
When user tries to validate Register Production/Serial in shop floor, A traceback will appear. Steps to reproduce the error: - Install ``mrp_workorder`` and ``quality_control`` modules with demo data…
When user tries to validate Register Production/Serial in shop floor, A traceback will appear. Steps to reproduce the error: - Install ``mrp_workorder`` and ``quality_control`` modules with demo data - Go to Quality > Create a new Control point > Product: Table Top > Operations: Manufacturing > Save - Create a new MO > Product: Table Top > Confirm > Shop Floor > Click on Assembly 1 > Click on 3 dots > Update Instructions > Improvement Suggestion > Add a step > Propose Change > Validate - Click on 3 dots > Register Production/Serial > Validate - Go back to MO > Quality Checks > Duplicate the newly created quality check > Shop Floor > Click on Assembly 1 > Click on 3 dots > Register Production/Serial > Validate Traceback: ``ValueError: Expected singleton: quality.check(1, 5)`` https://github.com/odoo/enterprise/blob/5103383df3ddf23503e2c7817c5129a742a7800f/mrp_workorder/models/mrp_workorder.py#L846-L848 When User clicks on the validate, ``current_check`` may include several quality checks without a ``previous_check_id``. The code expects only one record, which causes a traceback. sentry-6839419788 Forward-Port-Of: odoo/enterprise#93624
Scheduled background tasks now refresh their view of the system after an app is uninstalled. This prevents crashes caused by tasks trying to use fields from an app that is no longer installed, improving reliability for worker-based deployments.
Original PR description
**step to reproduce:** - start a database with worker, use `--max-cron-thread=1 --workers=2` - Add a sample cron, which runs every minute(just so that we can see the status) - install helpdesk -…
**step to reproduce:**
- start a database with worker, use `--max-cron-thread=1 --workers=2`
- Add a sample cron, which runs every minute(just so that we can see the status)
- install helpdesk
- uninstall helpdesk
**Observation**
- traceback in console
```
2025-09-25 06:07:26,389 18450 ERROR ? odoo.service.server: Worker WorkerCron (18450) Exception occurred, exiting...
Traceback (most recent call last):
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/service/server.py", line 1171, in _runloop
self.process_work()
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/service/server.py", line 1270, in process_work
base.models.ir_cron.ir_cron._process_jobs(db_name)
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/addons/base/models/ir_cron.py", line 139, in _process_jobs
registry[cls._name]._process_job(db, cron_cr, job)
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/addons/base/models/ir_cron.py", line 331, in _process_job
now = fields.Datetime.context_timestamp(ir_cron, datetime.utcnow())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
....
....
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/models.py", line 3873, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/addons/base/models/res_users.py", line 546, in _fetch_query
records = super()._fetch_query(query, fields)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/models.py", line 3965, in _fetch_query
self.env.cr.execute(query.select(*sql_terms))
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/sql_db.py", line 335, in execute
res = self._obj.execute(query, params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.UndefinedColumn: column res_users.helpdesk_target_closed does not exist
LINE 1: ...s"."odoobot_state", "res_users"."odoobot_failed", "res_users...
```
Issue:
- traceback occurred, as the system is try to fetch fields related to helpdesk module
which do not exists now after uninstalling it.
- cron in case of workers, use daemon threads [1]
- the uninstalled happened with main thread and registry is updated.
- the daemon thread is unaware of this change.
- the `_process_jobs` uses the registry, without checking if it needs reload
[1]: https://github.com/odoo/odoo/blob/e82fdfaf621f45515b92c891334595250accbfbd/odoo/service/server.py#L582-L587
FIx:
- when assigning the registry, we check if needs a reload or not.
opw-5062313
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#229556
Forward-Port-Of: odoo/odoo#228515This fix prevents Odoo Studio from crashing when a user removes calendar settings such as the color field. Empty values are now handled correctly instead of being mistaken for real field names, making view customization more reliable.
Original PR description
On a calendar with studio, try to remove the "color" attribute, or any other that should contain the name of a field. Before this commit there was a crash because the value sent to the server in this case is `undefined` (`null` in JSON or `None` in python), which was stringified and yielding an actual string that was not a field name After this commit, NULL values are not stringified, instead they should represent the emptiness of the attribute. opw-4938351 Forward-Port-Of: odoo/enterprise#95439
This fix prevents manually adjusted delivery dates on invoices from being reset when invoice line quantities are changed. It helps ensure customer delivery information remains accurate after routine invoice edits.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a sale order with deliverable products & no payment terms; 2. confirm order & validate delivery; 3. create an invoice; 4. modify the delivery date; 5.…
Versions -------- - 17.0+ Steps ----- 1. Have a sale order with deliverable products & no payment terms; 2. confirm order & validate delivery; 3. create an invoice; 4. modify the delivery date; 5. save changes; 6. change product quantity of a line & confirm invoice. Issue ----- The delivery date got reset. Cause ----- The `_compute_show_delivery_date` method gets called, which triggers the recomputation of the `_compute_delivery_date` due it the latter having `line_ids.sale_line_ids.order_id` as its `depends`. Due to the way how `depends` works, if any of the fields in the record chain gets modified, the compute gets triggered. In this case, because we modified a `line_ids` record by changing the quantity, it will therefore recompute the delivery date, overwriting the custom value. Solution -------- As we only want the delivery date to be recomputed when the `effective_date` on the order changes, we should add it to the `depends` to trigger the compute in that scenario. In other scenarios, e.g. modifying the move or one of its lines, we don't want to trigger a recompute, which we can achieve by always including `delivery_date` via `_get_protected_vals` on create/write. opw-4996654 Forward-Port-Of: odoo/odoo#229932 Forward-Port-Of: odoo/odoo#223946
This fix ensures Indian e-invoices report the correct GST rate and amounts for Special Economic Zone, export, and reverse charge sales. It updates tax and fiscal position handling so reported invoice data better matches Indian GST e-invoicing rules and reduces the risk of incorrect filings.
Original PR description
[FIX] l10n_in{,_edi}: Sale RCM and SEZ(With LUT) Steps to reproduce: 1. Install `l10n_in_edi` 2. Create an invoice with a RC tax/SEZ (with LUT) tax 3. Confirm and Process for E-invoice 4. See the EDI…
[FIX] l10n_in{,_edi}: Sale RCM and SEZ(With LUT)
Steps to reproduce:
1. Install `l10n_in_edi`
2. Create an invoice with a RC tax/SEZ (with LUT) tax
3. Confirm and Process for E-invoice
4. See the EDI content, The GST rate is 0%
Before this
For RC and SEZ (with LUT) the tax rate and tax amount were sent
as `0` and (data going wrong for SEZ/Exports) for Indian E-invoicing.
Following the fix:
1. We rename the the IGST x% (SZ/EX) -> IGST x% (EX)
2. Introducing new taxes for SEZ with LUT
3. Fiscal for Export and SEZ renamed to Export (same for LUT)
4. Introducing new fiscal for SEZ and SEZ (LUT)
5. In case of Special Economic Zone normal taxes (IGST) should be applied
because as per the [API Doc](https://einv-apisandbox.nic.in/version1.03/generate-irn.html#validations)
It states -
**However, in case of Reverse charge and Export transactions (EXPWP), Total value of Item can match with either with tax values or without tax values. That is, the total value of item can include or exclude the tax values as per the business requirements.**
So SEZ without LUT should be passed as normal IGST
For Export without LUT
Label | Taxes | credit | debit| Tags
-------------------------------------------------------------------------------------------------------------
Product A | 18% IGST S (EX) | 100 | | Base IGST
IGST 18% | | 18 | | IGST
IGST Paid on SEZ/Export Sales | | | 18|
Creditor | | | 180|
Invoice Total 100
EDI with {'rate': 18.0, 'IgstAmt': 18.0, 'TotItemVal': 100}
For SEZ without LUT
Label | Taxes | credit | debit | Tags
-----------------------------------------------------------
Product A | 18% IGST S (SEZ) | 100 | | Base IGST
IGST 18% | | 18 | | IGST
Creditor | | | 118|
Invoice Total 118
EDI with {'rate': 18.0, 'IgstAmt': 18.0, 'TotItemVal': 118}
For Export/SEZ with LUT
Label | Taxes | credit | debit | Tags
-----------------------------------------------------------
Product A | 18% IGST S (SEZ) | 100 | | Base IGST
IGST 18% | | 18 | | IGST
IGST 18% | | | 18 | IGST
Creditor | | | 100|
Invoice Total 100
EDI with {'rate': 18.0, 'IgstAmt': 0.0, 'TotItemVal': 100}
For RCM
Label | Taxes | credit | debit | Tags
-------------------------------------------------------------------------------
Product A | 18% IGST S RC | 100 | | Base IGST || BASE IGST RC
IGST 18% RC | | 18 | | IGST
IGST 18% RC | | | 18| IGST RC
Creditor | | | 118|
Invoice Total 100
EDI with {'rate': 18.0, 'IgstAmt': 0, 'TotItemVal': 100}
task-4878805
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#228871
Forward-Port-Of: odoo/odoo#213931This update adds validation for Indian GSTR1 reporting when sales involve reverse charge tax and SEZ transactions with LUT. It helps ensure tax reports remain accurate for these specific compliance scenarios, reducing the risk of incorrect filings.
Original PR description
Adding GSTR1 test case with RCM tax and SEZ (with LUT) see https://github.com/odoo/odoo/pull/213931 Forward-Port-Of: odoo/enterprise#95669 Forward-Port-Of: odoo/enterprise#87486
POS receipts now display preset information, such as customer address or time slot, centered in the receipt header. This improves receipt readability and creates a cleaner, more consistent presentation for customers.
Original PR description
We now want to center preset infos on receipt header (customer address or time slot) in POS. task-id: 5048706 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226831
Fixes an issue in bank reconciliation where exchange difference details could be assigned to the wrong selected line. This helps ensure accounting records stay accurate when reconciling multiple bank lines at once.
Original PR description
When selecting multiple lines in the bank rec widget (reconcile button), it could happen that one of those lines have a exchange diff move linked to it. In this case, the exchange move id was placed on the first line all the time which could be wrong. This commit will change the use of indexes to use the reconciled line of the exchange diff move. no task id Forward-Port-Of: odoo/enterprise#94160
8 changes
Resolved issues and error corrections
Payroll document generation now skips payslips when the related employee contact is missing. This prevents scheduled PDF creation from failing and helps keep payroll document processing running smoothly.
Original PR description
Currently an error occurs when the **'Payroll: Generate pdfs'** scheduled action runs and tries to create a document for a payslip belonging to an employee who does not have a related partner.…
Currently an error occurs when the **'Payroll: Generate pdfs'** scheduled action runs and tries to create a document for a payslip belonging to an employee who does not have a related partner. **Prerequisites:** - Ensure HR is enabled in `settings>Documents` **Steps to Reproduce:** 1) Install `documents_hr_payroll` module.(with Demo) 2) Navigate to the Employees App. 3) Select any Employee(e.g Abigail Peterson) and open form view. >- click on **contacts** smart button. >- Delete that Record 4) Create a confirmed Payslip for the selected Employee(e.g Abigail Peterson). 5) Activate Developer mode and navigate to schedule Actions. >- Search for 'Payroll: Generate pdfs'. >- Run Manually. Error: `NotNullViolation: null value in column 'partner_id' of relation 'documents_access' violates not-null constraint` Root Cause: When the partner is deleted, the value received from `_get_document_partner` at [1] is `False`, which later on tries to create the `documents.access` record for the new document, it fails because no partner is available to assign access rights, resulting in the error. Solution: This commit prevent Error by ensuring `_check_create_documents` method doesn't allow document creation without valid partner. [1]: https://github.com/odoo/enterprise/blob/99a8d83edb42f172d0dd35c91743fa0c9653dcbb/documents_hr_payroll/models/hr_payslip.py#L20C1-L21 sentry-6814524392 Forward-Port-Of: odoo/enterprise#92865
This fix ensures background scheduled tasks refresh their internal app data after a module is uninstalled. It prevents worker processes from crashing when they try to use outdated fields from an app that has just been removed.
Original PR description
**step to reproduce:** - start a database with worker, use `--max-cron-thread=1 --workers=2` - Add a sample cron, which runs every minute(just so that we can see the status) - install helpdesk -…
**step to reproduce:**
- start a database with worker, use `--max-cron-thread=1 --workers=2`
- Add a sample cron, which runs every minute(just so that we can see the status)
- install helpdesk
- uninstall helpdesk
**Observation**
- traceback in console
```
2025-09-25 06:07:26,389 18450 ERROR ? odoo.service.server: Worker WorkerCron (18450) Exception occurred, exiting...
Traceback (most recent call last):
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/service/server.py", line 1171, in _runloop
self.process_work()
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/service/server.py", line 1270, in process_work
base.models.ir_cron.ir_cron._process_jobs(db_name)
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/addons/base/models/ir_cron.py", line 139, in _process_jobs
registry[cls._name]._process_job(db, cron_cr, job)
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/addons/base/models/ir_cron.py", line 331, in _process_job
now = fields.Datetime.context_timestamp(ir_cron, datetime.utcnow())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
....
....
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/models.py", line 3873, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/addons/base/models/res_users.py", line 546, in _fetch_query
records = super()._fetch_query(query, fields)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/models.py", line 3965, in _fetch_query
self.env.cr.execute(query.select(*sql_terms))
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/sql_db.py", line 335, in execute
res = self._obj.execute(query, params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.UndefinedColumn: column res_users.helpdesk_target_closed does not exist
LINE 1: ...s"."odoobot_state", "res_users"."odoobot_failed", "res_users...
```
Issue:
- traceback occurred, as the system is try to fetch fields related to helpdesk module
which do not exists now after uninstalling it.
- cron in case of workers, use daemon threads [1]
- the uninstalled happened with main thread and registry is updated.
- the daemon thread is unaware of this change.
- the `_process_jobs` uses the registry, without checking if it needs reload
[1]: https://github.com/odoo/odoo/blob/e82fdfaf621f45515b92c891334595250accbfbd/odoo/service/server.py#L582-L587
FIx:
- when assigning the registry, we check if needs a reload or not.
opw-5062313
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#229556
Forward-Port-Of: odoo/odoo#228515This fixes a crash that could happen when users removed certain calendar settings, such as the color field, in Odoo Studio. Empty values are now handled correctly, allowing users to edit views without interruption.
Original PR description
On a calendar with studio, try to remove the "color" attribute, or any other that should contain the name of a field. Before this commit there was a crash because the value sent to the server in this case is `undefined` (`null` in JSON or `None` in python), which was stringified and yielding an actual string that was not a field name After this commit, NULL values are not stringified, instead they should represent the emptiness of the attribute. opw-4938351 Forward-Port-Of: odoo/enterprise#95439
The Automation Rules trigger dropdown now uses the correct background color when dark mode is enabled. This improves visual consistency and readability for users configuring automation rules in dark mode.
Original PR description
Steps: - Install `base_automation` - Enable dark mode - Open Automation rules - Create a new rule - open trigger dropdown - the dropdown background is still in light mode This commit apply $dropdown-bg on `o_field_base_automation_trigger_selection` opw-5064357 Forward-Port-Of: odoo/odoo#226666 Forward-Port-Of: odoo/odoo#226116
This fix changes how receipt or report data is passed so existing customizations keep working after the recent IoT update. Businesses benefit from fewer errors in IoT-connected flows, especially point-of-sale printing or document sending, without changing user behavior.
Original PR description
Following commit https://github.com/odoo/enterprise/commit/ecea27f45ab58ae6f348753d94fdf89f902a43b9, the argument `data_base64` was added to the `render_and_send` function. However, adding new arguments in stable versions is not allowed, as it may break custom modules that override this function and do not expect the additional argument. This commit ensures that `data_base64` is passed through the context instead, preventing errors while keeping compatibility with existing overrides. opw-data_base64 Forward-Port-Of: odoo/enterprise#96244
Publishing planning shifts now keeps the filters users selected in the schedule view, such as a specific role, while still applying the chosen date range. This prevents unintended shifts outside the selected criteria from being published or sent, improving accuracy for planners.
Original PR description
To reproduce: ============= -Reset all planning.slot to draft -Search "Dev" role -In weekly Gantt view, click on publish & send -Change date to match the current month (or any other period) -Publish Problem: ========= We filter only by datetime and ignore domain from context : https://github.com/odoo/enterprise/blob/20b45f6c65c78a572a3f26b78f6ed458accf7c9f/planning/wizard/planning_send.py#L31-L33 Solution: ========= - Get active domain from context and override only it's date_time since it changed. opw-5017014 Forward-Port-Of: odoo/enterprise#93295
This fix prevents an error when shoppers use the browser back button immediately after starting payment and then try to pay again from the cart. It helps keep checkout stable in this edge case, avoiding a disruptive crash during payment retry.
Original PR description
This error occurs when trying to make a payment again from the cart. Steps to reproduce: --- - Install the **website_sale** module (with demo) - Activate **Demo** payment provider - Go to Website > Shop > Add a **Warranty** product to Cart > View cart - Pay with Demo > Pay - Click the back button(chrome navbar)(Instantly) - Now again Pay with Demo > Pay Traceback: --- `ValueError: Expected singleton: sale.order()` At [1], this error occurs because **order_sudo** is empty. This happens when there is no product in the cart — typically because, upon clicking **Pay**, a sale order is created for the product, and when the user navigates back, the cart is empty. [1]- https://github.com/odoo/odoo/blob/125fc3028debb311e9f6ad25d8c46699b77525f0/addons/website_sale/controllers/main.py#L1307-L1312 sentry-5682671428 Forward-Port-Of: odoo/odoo#229858
Creating a down payment invoice for an Indian sales quotation with a reseller no longer fails. This prevents invoice creation from being blocked and helps sales teams continue billing normally when reseller information is present.
Original PR description
**Issue** When creating a down payment invoice for a quotation that includes a reseller, an error is raised and the operation is aborted. **Steps to Reproduce** 1. Install Accounting, Studio, and…
**Issue** When creating a down payment invoice for a quotation that includes a reseller, an error is raised and the operation is aborted. **Steps to Reproduce** 1. Install Accounting, Studio, and l10n_in_sale 2. Open the Quotation view in Studio 3. Set the "Referrer" field (i.e., l10n_in_reseller_partner_id) to be always visible and remove group restrictions 4. Create a new quotation and set a reseller in the Referrer field 5. Confirm the quotation 6. Click "Create Invoice" 7. Choose "Down Payment (percentage)" with 10% 8. Click "Create Draft" **Root Cause** The `_prepare_invoice_values()` method was assigning the full `res.partner` record to the `l10n_in_reseller_partner_id` field instead of its ID. Since the `account.move` model expects an integer ID for many2one fields, this caused a `psycopg2.ProgrammingError` due to the database adapter not being able to serialize a recordset. **Fix** Ensure the value passed to l10n_in_reseller_partner_id is the .id of the partner record, not the recordset itself. Opw-4899919 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222324 Forward-Port-Of: odoo/odoo#220354
6 changes
Enhancements to existing features
Brazilian service products now show the correct LC116 Code label instead of the product-focused Mercosul NCM Code label. This reduces confusion when configuring fiscal information for services and improves the explanatory tooltip.
Original PR description
Purpose:- - In Brazil, NCM is a code that has an acronym to specify the Mercosul Common Name for products, and for services, the right name is LC116 (Complementary Law 116), which specifies the federal code for a service. - But we have the same field `l10n_br_ncm_code_id` to configure both NCM for goods and LC116 for services and the same table can be used for both the cases. - So while configuring fiscal information for a service, user don't understand why it still shows the NCM label instead of LC116. Before this commit:- - Label `Mercosul NCM Code` was displayed for services confusing users. After this commit:- - Label `Mercosul NCM Code` is replaced with `LC116 Code` only for services. - Tooltip is also improved for better understanding. task-5096435 Forward-Port-Of: odoo/enterprise#96101 Forward-Port-Of: odoo/enterprise#95404
Resolved issues and error corrections
Exporting a Belgian 325 PDF no longer crashes when there are no related 281.50 forms to include. Instead, users see a clear message explaining that they need to record a transaction with a 281.50 tag before generating the PDF.
Original PR description
### Problem When clicking **"Export PDF"** on a 325 form that has **no generated 281.50 forms**, Odoo raised a **server error**: This happened because the method assumed that at least one attachment…
### Problem When clicking **"Export PDF"** on a 325 form that has **no generated 281.50 forms**, Odoo raised a **server error**: This happened because the method assumed that at least one attachment would always be generated, even if no eligible transactions were present. --- ### Steps to Reproduce 1. Go to **Accounting → Reporting → 325 Form**. 2. Create a 325 form for a year without any transactions on accounts tagged with **281.50**. 3. Do not generate any 281.50 forms (`form_281_50_ids` is empty). 4. Click **Export PDF**. **Result before fix:** - Crash with `IndexError: list index out of range`. --- ### Solution - Added a safeguard check before accessing attachments. - If no attachments exist, raise a **UserError** instead of crashing. **New behavior:** > *“No 281.50 lines found to generate a PDF. Please record a transaction with a 281.50 tag first.”* This gives users a instruction on how to resolve the issue. --- ### Result After Fix - **User error message** replaces traceback. - **Normal behavior preserved** when attachments exist: - One file → direct download. - Multiple files → zipped download. --- task-5090120 Forward-Port-Of: odoo/enterprise#94877
This fix prevents Odoo Studio from crashing when users remove calendar settings such as the color field. Empty values are now handled correctly instead of being mistaken for invalid field names, making view customization more reliable.
Original PR description
On a calendar with studio, try to remove the "color" attribute, or any other that should contain the name of a field. Before this commit there was a crash because the value sent to the server in this case is `undefined` (`null` in JSON or `None` in python), which was stringified and yielding an actual string that was not a field name After this commit, NULL values are not stringified, instead they should represent the emptiness of the attribute. opw-4938351 Forward-Port-Of: odoo/enterprise#95439
This update changes how encoded document data is passed when sending reports to IoT devices, avoiding a compatibility issue with customizations. It helps prevent errors in existing customer modules while preserving the same document sending behavior.
Original PR description
Following commit https://github.com/odoo/enterprise/commit/ecea27f45ab58ae6f348753d94fdf89f902a43b9, the argument `data_base64` was added to the `render_and_send` function. However, adding new arguments in stable versions is not allowed, as it may break custom modules that override this function and do not expect the additional argument. This commit ensures that `data_base64` is passed through the context instead, preventing errors while keeping compatibility with existing overrides. opw-data_base64 Forward-Port-Of: odoo/enterprise#96244
When publishing and sending planning schedules, the system now respects filters already chosen in the planning view, such as role or team filters, while still applying the selected date range. This prevents unintended schedule entries from being published or sent and helps managers target the right employees or shifts.
Original PR description
To reproduce: ============= -Reset all planning.slot to draft -Search "Dev" role -In weekly Gantt view, click on publish & send -Change date to match the current month (or any other period) -Publish Problem: ========= We filter only by datetime and ignore domain from context : https://github.com/odoo/enterprise/blob/20b45f6c65c78a572a3f26b78f6ed458accf7c9f/planning/wizard/planning_send.py#L31-L33 Solution: ========= - Get active domain from context and override only it's date_time since it changed. opw-5017014 Forward-Port-Of: odoo/enterprise#93295
Failed attempts to send shipping labels to an unreachable IoT printer no longer show an error traceback to users. This avoids alarming employees who received a shared print request even when another user may have successfully printed the label.
Original PR description
Printing shipping labels is performed from the backend, once the shipping info are received in the chatter. The printing command is sent to the frontend via the user bus, then though longpolling to the iot box. As multiple users can receive the broadcasted message at the same time, but might not be able to reach the printer, we need to avoid displaying a traceback on failure. Note that as it is broadcasted, a user could receive the traceback even if label was already printed by the user that was on the same network as the IoT Box. Also note that we don't even display a notification as it would be displayed to every user connected that couldn't reach the IoT Box. Task: 4792491 Forward-Port-Of: odoo/enterprise#96054 Forward-Port-Of: odoo/enterprise#95794
31 changes
Security fixes and vulnerability patches
Helpdesk now prevents tickets from being linked to a customer from a different company. This helps ensure users only see and access tickets appropriate to their company, avoiding access errors and reducing data exposure risk.
Original PR description
**Issue**: It is possible to associate a partner that belongs to a different company than the ticket’s company. As a result, some users could see tickets in the list view that they should not have access to. When attempting to open those tickets, an error was raised. Even worse, in some cases (see the associated ticket), certain users were still able to access them. **Steps to reproduce**: - Create two companies (A and B) - Switch to company A - Open the Helpdesk application - Create and open a ticket - Select both companies A and B - Assign a partner linked to company B to the ticket - Save it opw-4926497 Forward-Port-Of: odoo/enterprise#96193 Forward-Port-Of: odoo/enterprise#93201
Enhancements to existing features
AI-powered URL fetching now checks each website's robots.txt rules before accessing pages, using the Odoobot identity. This helps Odoo interact more politely with external websites, avoid disallowed content, and provide clearer feedback when access is blocked.
Original PR description
### Purpose Add `robots.txt` compliance to the `_fetch_url` helper. Before fetching any URL, we now check the site's `robots.txt` and ensure that our user agent (`Odoobot/1.0`) is allowed to access the requested path. ### Changes - Added `robots.txt` validation using `urllib.robotparser` - Respect disallow rules for the `Odoobot/1.0` user agent ### Why This ensures that our crawler behaves politely, avoids fetching disallowed resources, and provides more transparent failure reporting. --- **Task-ID:** 4779962
The bank matching edit line wizard now shows only the line name, preventing long references from disrupting the layout. References remain available in the kanban view, so users keep access to the information without cluttering the edit screen.
Original PR description
Problem: - The reference field was displayed together with the bill name, causing misalignment when the reference is quite long in the edit line wizard. Solution: - Updated the edit line wizard to display only the line's name. - The reference remains visible in the kanban view, it is only removed in the edit line wizard. task-5113489 Forward-Port-Of: odoo/enterprise#95575
The website editor’s +New screen now shows the correct pictograms for content options instead of generic icons. This makes the interface more consistent with the newer Odoo visual style and easier for users to scan.
Original PR description
This PR adds missing icons to the +new screen interface. Requires : https://github.com/odoo/odoo/pull/136274 task-2941442 ### Introducing pictograms to the UI : Since we now have pictograms to represent the different purposes of a module across the backend, we replace the `fa-icons` with these pictograms. Most of these pictograms have already been added, but some were missing.
The IoT device screens no longer show the unused “last sent value” widget or a hidden IP field. The connection type is repositioned to make device forms more balanced and easier to read, especially for receipt printers.
Original PR description
This PR removes the "last sent value" widget from the iot device views + also removes the always invisible "iot ip" field + also moves the connection type to the 1st column of the view to avoid 2nd column being bigger than the 1st for devices like receipt printers. Odoo PR: https://github.com/odoo/odoo/pull/229918 Forward-Port-Of: odoo/enterprise#96276
This update aligns several automated tests with a newer testing behavior that preserves data more safely during expected error checks. It helps keep validation runs stable and reduces false failures without changing everyday user workflows.
Original PR description
See community change, now assertRaisesRegex uses savepoint by default. https://github.com/odoo/odoo/pull/229046
The field service project setup screen has been simplified by removing an unnecessary timesheet product field and its label. This reduces visual clutter and makes the interface clearer for users configuring field service sales workflows.
Original PR description
Remove the `timesheet_product_id` field from the view and hide its label to streamline the interface and improve clarity for users. task-4581748
Lithuanian payroll benefits are now managed as configurable payroll properties instead of fixed rule amounts. This gives payroll teams more flexibility to model employee benefits and helps ensure salary rules apply the right values in more complex payroll scenarios.
VoIP call handling has been improved so that each active call keeps its own state instead of sharing one global state. This reduces the risk of call mix-ups or timing issues when users perform attended transfers involving more than one simultaneous call.
Original PR description
The original VoIP code was written under the assumption that there would only ever be one session at a time. Consequently, much of the session state was stored in a global object called the UserAgent. However, Odoo 19 implemented an attended transfer in VoIP, creating situations in which two sessions occur simultaneously. For this reason, the asynchronous code should no longer update session properties stored on the global UserAgent, as the session may have changed in the meantime, which could lead to race conditions. This commit moves some logic from the UserAgent to the Session, and ensures all callbacks are properly mapped to the relevant session. Forward-Port-Of: odoo/enterprise#95417
The OdooFin bank connection flow has been cleaned up to make it easier to maintain. It also now refreshes currency information when connecting an existing account, helping prevent missing currency labels on account amounts.
Original PR description
The aim of this commit is applying a technical cleaning of OdooFin connector client action. This action exists since the beginning of Odoo Fin and in an effort of cleaning the enterprise module, this commit tries to clean the javascript code. This commit also adds a call to the reloadCurrencies function in the connect_existing_account case to make sure that we have potential newly activated currency in the session. Without that change, connecting to an existing account with a deactivated currency will lead to amounts without their currency. task-5107780
Belgian payroll now includes dedicated records for joint committees and their categories, making employee payroll setup more structured and aligned with local labor classifications. This helps businesses manage Belgian HR payroll information more accurately and consistently across employee records.
Website pages can now be served from a high-level cache when it is safe to do so, reducing page rendering time and database load. The change includes safeguards to avoid caching pages that may contain dynamic or sensitive content, such as session-related sales data.
Original PR description
This commit introduces a high-level cache on the `website.page` model, similar to the one that existed before the `t-cache` directive was implemented in `ir.qweb`. This cache is designed to…
This commit introduces a high-level cache on the `website.page` model, similar to the one that existed before the `t-cache` directive was implemented in `ir.qweb`. This cache is designed to significantly improve performance by storing the HTML response of published pages, thereby reducing rendering time and database queries. The management and logic for this cache are placed directly on the `website.page` model, as it is the source of the HTML response for these records. This approach makes it easy to control caching behavior through a few new, overridable methods: - `_allow_to_use_cache`: Determines whether a page is allowed to be served from the cache based on the current request, URL, or session. For example, a page with a `sale.order` in the session would not use the cache. - `_allow_cache_insertion`: Checks if the generated HTML content is eligible for caching. This is useful for preventing sensitive or dynamic content from being stored. For instance, a page with a reference to a `sale.order` would not be inserted into the cache. - `_post_process_response_from_cache`: A hook called after a response is retrieved from the cache. This method allows for post-processing, such as incrementing counters or modifying HTTP headers, without regenerating the entire page. see https://github.com/odoo/odoo/pull/224487 see https://github.com/odoo/odoo/pull/88276 Forward-Port-Of: odoo/enterprise#94487
Changing a folder so it is not discoverable no longer automatically makes all documents inside require a direct link. This keeps folder-level visibility choices from unexpectedly restricting access to individual files, reducing confusion for users managing shared documents.
Original PR description
Changing the discoverability to not propagate to its children. Previously setting a folder to Discoverable to 'No' would result in all the files also requiring a link to access them, which is unwanted behaviour. Task-4996667 Forward-Port-Of: odoo/enterprise#93697
Resolved issues and error corrections
Romanian SAF-T reporting now correctly identifies partners as customers or suppliers even when their balance is zero, avoiding validation errors in required tax submissions. The change also prevents empty-value ledger lines from being reported while keeping related source documents included, improving compliance and report accuracy.
Original PR description
We need to know for each partner if it is a customer or a supplier, even more for Romania[^1] where it is enfored and validated. > 1. If the element SD.P.22 CustomerID is reported with value ”0”…
We need to know for each partner if it is a customer or a supplier, even more for Romania[^1] where it is enfored and validated. > 1. If the element SD.P.22 CustomerID is reported with value ”0” (zero), then the element SD.P.23 SupplierID must be different from ”0” (zero), meaning the identity of the partner from which the purchase was made (conventionally considered ”supplier”) is reported. Else if SD.P.22 CustomerID AND SD.P.23 SupplierID are concomitantly equal to ”0” (zero), then is return a semantic validation error. (CustomerID and SupplierID can not be concomitantly 0 (zero)) In order to fix this, we don't use the Partner Ledger anymore to query the balance per partner because it is removing the partners with 0 balance automatically. To keep it simple, we query manually and locally, allowing to reduce the number of queries from 3 to 1 for that part. For the performance, the `|=` operator done in a loop has also been removed, keeping the time complexity in `O(n)` instead of `O(n²)`. opw-5122910 [^1]: https://www.anaf.ro/anaf/internet/ANAF/despre_anaf/strategii_anaf/proiecte_digitalizare/saf_t Forward-Port-Of: odoo/enterprise#96355 Forward-Port-Of: odoo/enterprise#95804
This fixes a crash that could occur when validating Register Production/Serial from the shop floor if multiple related quality checks existed. Manufacturing users can now complete production validation without being blocked by an unexpected error.
Original PR description
When user tries to validate Register Production/Serial in shop floor, A traceback will appear. Steps to reproduce the error: - Install ``mrp_workorder`` and ``quality_control`` modules with demo data…
When user tries to validate Register Production/Serial in shop floor, A traceback will appear. Steps to reproduce the error: - Install ``mrp_workorder`` and ``quality_control`` modules with demo data - Go to Quality > Create a new Control point > Product: Table Top > Operations: Manufacturing > Save - Create a new MO > Product: Table Top > Confirm > Shop Floor > Click on Assembly 1 > Click on 3 dots > Update Instructions > Improvement Suggestion > Add a step > Propose Change > Validate - Click on 3 dots > Register Production/Serial > Validate - Go back to MO > Quality Checks > Duplicate the newly created quality check > Shop Floor > Click on Assembly 1 > Click on 3 dots > Register Production/Serial > Validate Traceback: ``ValueError: Expected singleton: quality.check(1, 5)`` https://github.com/odoo/enterprise/blob/5103383df3ddf23503e2c7817c5129a742a7800f/mrp_workorder/models/mrp_workorder.py#L846-L848 When User clicks on the validate, ``current_check`` may include several quality checks without a ``previous_check_id``. The code expects only one record, which causes a traceback. sentry-6839419788 Forward-Port-Of: odoo/enterprise#93624
Payroll users can now generate payslips from a pay run without hitting an error. This fixes a broken field reference introduced after work entry dates were simplified, restoring a key payroll processing step for batches with multiple employees.
Original PR description
Steps to reproduce: - In the Payroll app, go to Pay Runs - Select a pay run with several employees in it - Click on "Generate Payslips" - Get a traceback Reason: The function responsible to generate payslips did not get updated when the fields "date_start" and "date_stop" where replaced by "date" in work entries, causing the error. How it was fixed: Changed "date_start" and "date_end" in the condition to "date" Task ID: 5084666 Forward-Port-Of: odoo/enterprise#94919
Rental product prices in the online shop now use the decimal precision configured for the website currency. This prevents public customers from seeing unnecessary decimals, such as showing whole-number currencies with two decimal places.
Original PR description
Versions -------- - 17.0 Steps ----- 1. Set currency precision to 0 decimals; 2. check prices in eCommerce as public user. Issue ----- Prices are displayed with 2 decimals Cause ----- The `_priceToStr` method used, always uses a `precision` of 2, except in editor mode when it will retrieve a different value from a hidden `.decimal_precision` element. Solution -------- Add the website's currency precision to `combination_info` via the controller, and use this value in `_priceToStr`. opw-4996878 Community PR: https://github.com/odoo/odoo/pull/224429 Forward-Port-Of: odoo/enterprise#96226 Forward-Port-Of: odoo/enterprise#95634
Odoo Studio now correctly handles clearing calendar view settings such as color fields. This prevents crashes when users remove these settings and keeps the calendar editor working smoothly.
Original PR description
On a calendar with studio, try to remove the "color" attribute, or any other that should contain the name of a field. Before this commit there was a crash because the value sent to the server in this case is `undefined` (`null` in JSON or `None` in python), which was stringified and yielding an actual string that was not a field name After this commit, NULL values are not stringified, instead they should represent the emptiness of the attribute. opw-4938351 Forward-Port-Of: odoo/enterprise#95439
This update adjusts how Studio approval rules are checked so they no longer trigger an unnecessary warning in newer database environments. It is an internal cleanup that helps keep system updates and migrations smoother without changing user-facing behavior.
Original PR description
See community change, merge `_method_or_action_not_null` into `_method_or_action_together` to avoid warning. https://github.com/odoo/odoo/pull/229287 https://github.com/odoo/upgrade/pull/8521
Fixed ESG demo data so it no longer depends on accounting records tied to a specific country setup. This prevents errors when loading demo data in fresh databases using non-US fiscal localizations, such as India.
Original PR description
**Note: issue not reproducible in runbot, but in fresh database** **Step to reproduce:** - in fresh database, install esg module - go to setting > invoicing > add india as Fiscal Localization -…
**Note: issue not reproducible in runbot, but in fresh database**
**Step to reproduce:**
- in fresh database, install esg module
- go to setting > invoicing > add india as Fiscal Localization
- change company name, ex "test"
- goto setting > load demo data
**Observation:**
- You will receive traceback
```
raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo/codebase/enterprise/saas-18.4/esg/demo/demo_data.xml:567, somewhere inside
<record id="esg_emission_factor_line_assignation_4" model="esg.assignation.line">
<field name="esg_emission_factor_id" ref="esg_zero_emission_factor"/>
<field name="account_id" model="account.account" search="[('code', '=', '630000')]"/>
</record>
2025-09-11 08:45:07,458 82617 INFO esg184 odoo.addons.base.models.ir_module: module esg: no translation for language en_IN
2025-09-11 08:45:07,479 82617 ERROR esg184 odoo.sql_db: bad query: b'INSERT INTO "esg_activity_type_esg_emission_factor_rel" ("esg_emission_factor_id", "esg_activity_type_id") VALUES (1, 2) ON CONFLICT DO NOTHING'
ERROR: insert or update on table "esg_activity_type_esg_emission_factor_rel" violates foreign key constraint "esg_activity_type_esg_emission_fact_esg_emission_factor_id_fkey"
DETAIL: Key (esg_emission_factor_id)=(1) is not present in table "esg_emission_factor".
```
**Cause:**
- The demo data relies on few account.account record which belong to [USA company](https://github.com/odoo/odoo/blob/9805d09dff64de835de0c764da8c6e213d6b88aa/addons/account/data/template/account.account-generic_coa.csv#L38)
https://github.com/odoo/enterprise/blob/b8a20b02e27322d0db5781f8d84946e54bbcbf03/esg/demo/demo_data.xml#L569
https://github.com/odoo/enterprise/blob/b8a20b02e27322d0db5781f8d84946e54bbcbf03/esg/demo/demo_data.xml#L620-L628
- when we installed `india` Localization and changed the company name, USA company could not be created when loading demo data and hence the account records were not created, causing traceback
**Fix:**
- make demo data independent of any localization
opw-5048417
Forward-Port-Of: odoo/enterprise#94540Mexican electronic invoices will no longer automatically replace a missing invoice date with the current date in the Mexico City timezone when posted. This avoids unexpected mismatches between invoice and due dates and makes invoice behavior more consistent.
Original PR description
At the moment, when an invoice that uses a CFDI is posted, the invoice date (if not already existing) is set to the current date in the Mexico City timezone. This default behaviour is just weird, and even if there might have been technical reasons for it in the past, these are no longer valid. This can also cause the default invoice date to be different from the default due date, which causes unexpected behaviour in tests. We therefore remove this override. runbot-233041 Forward-Port-Of: odoo/enterprise#96303
Swiss payroll users can once again access Individual Account reports and monthly payroll report menu entries. This restores missing navigation so payroll teams can find and use the expected reports without workarounds.
Original PR description
… menuitems Forward-Port-Of: odoo/enterprise#96162 Forward-Port-Of: odoo/enterprise#95929
The sales planning test tour was failing when run on non-working days because it focused on the current date. This fix changes the test so it selects only valid working dates, improving reliability of automated checks without changing user-facing behavior.
Original PR description
Before this commit, the tour was failing on non-working days as the focused day was the current date. This commit removes the focus on the current date so that only working dates are selected. Additionally, this commit also fixes the formatting issues of the modified file. runbot error 226741 Forward-Port-Of: odoo/enterprise#96239
A missing component was added back to the Spanish reporting setup after a forward-porting oversight. This helps ensure the related accounting return functionality is properly available when the module is initialized.
Original PR description
Little oopsie while fw-porting https://github.com/odoo/enterprise/pull/96106 Forward-Port-Of: odoo/enterprise#96354
Uploaded files added to field service worksheets are now shown correctly when customers view or sign worksheet reports in the portal. This prevents missing attachment information and helps ensure signed reports match the completed worksheet.
Original PR description
Steps to reproduce: ------- - Install industry_fsm_report module - Open FSM app - Select worksheets from settings in the configuration - Go to worksheet templates in the configuration - Create a worksheet template - Click the design template button. You arrive in the studio - Add file field and close it - Create a new task and select a newly created template in the worksheet template - Click the worksheet button in the control panel - Upload a file and save it - Click on the sign report button - Here file field is not visible Issue: ------- The file field is not visible in the worksheet portal. Cause: ------ The view of the file field is not created for the worksheet portal. Solution: ------- Created the view of the file field to display in the worksheet portal. task-3691529 Forward-Port-Of: odoo/enterprise#95970 Forward-Port-Of: odoo/enterprise#56035
Field service project settings now show the correct label for the timesheet product when a customer is selected. This prevents confusion caused by the sales order line label appearing in the wrong place.
Original PR description
Steps to reproduce: - Install the `industry_fsm_sale` module. - Open the FSM app. - Go to Projects. - Open a project’s settings. - Select a customer. Issue: The label for the timesheet product is not displayed. Instead, the label for the sale order line appears on FSM projects. Cause: In the PR, https://github.com/odoo/odoo/pull/128967 changed the project settings form structure by wrapping `sale_line_id` in a `div` and separating its label, breaking the xpath for `timesheet_product_id`. Fix: - Update the XPath for `timesheet_product_id` to target the correct container. - Hide the `sale_line_id` label on FSM projects. task-4581748 Forward-Port-Of: odoo/enterprise#96022
The Belgian 325 form PDF export now shows a helpful message instead of a server error when there are no 281.50 lines to include. This prevents a confusing crash and tells users what information is needed before exporting.
Original PR description
### Problem When clicking **"Export PDF"** on a 325 form that has **no generated 281.50 forms**, Odoo raised a **server error**: This happened because the method assumed that at least one attachment…
### Problem When clicking **"Export PDF"** on a 325 form that has **no generated 281.50 forms**, Odoo raised a **server error**: This happened because the method assumed that at least one attachment would always be generated, even if no eligible transactions were present. --- ### Steps to Reproduce 1. Go to **Accounting → Reporting → 325 Form**. 2. Create a 325 form for a year without any transactions on accounts tagged with **281.50**. 3. Do not generate any 281.50 forms (`form_281_50_ids` is empty). 4. Click **Export PDF**. **Result before fix:** - Crash with `IndexError: list index out of range`. --- ### Solution - Added a safeguard check before accessing attachments. - If no attachments exist, raise a **UserError** instead of crashing. **New behavior:** > *“No 281.50 lines found to generate a PDF. Please record a transaction with a 281.50 tag first.”* This gives users a instruction on how to resolve the issue. --- ### Result After Fix - **User error message** replaces traceback. - **Normal behavior preserved** when attachments exist: - One file → direct download. - Multiple files → zipped download. --- task-5090120 Forward-Port-Of: odoo/enterprise#94877
Chilean electronic delivery guide XML files now show the quantity actually delivered instead of the quantity originally ordered. This prevents mismatches in official DTE documents when a shipment is partially delivered without a backorder.
Original PR description
**Issue** When the delivered quantity of a product is less than the originally demanded quantity, the generated Delivery Guide XML shows the demand (product_uom_qty) instead of the actual delivered…
**Issue** When the delivered quantity of a product is less than the originally demanded quantity, the generated Delivery Guide XML shows the demand (product_uom_qty) instead of the actual delivered quantity (quantity). This results in an incorrect quantity being displayed in the DTE. **Steps to Reproduce** 1. Install the Accounting module, Chilean localization, Sales module, and l10n_cl_edi_stock. 2. Create and confirm a new Sale Order. 3. Click on the Delivery smart button. 4. Adjust the delivered quantity to a value lower than the demand, save, and validate with no backorder. 5. Generate the Delivery Guide. 6. Open the generated DTE XML and observe that the quantity is incorrect. **Root Cause** The quantity displayed in the DTE is taken from product_uom_qty, which represents the planned quantity to be moved, not the actual delivered quantity. The correct field to use is quantity, which reflects the real delivered amount. **Fix** Change the XML output to use quantity instead of product_uom_qty to accurately reflect the actual delivered quantity in the DTE. Opw-4892276 Forward-Port-Of: odoo/enterprise#93260 Forward-Port-Of: odoo/enterprise#89633
The payroll document generation process now skips payslips that cannot be linked to a valid employee contact. This prevents scheduled PDF generation from failing when an employee's related contact record has been deleted, keeping payroll document automation running smoothly.
Original PR description
Currently an error occurs when the **'Payroll: Generate pdfs'** scheduled action runs and tries to create a document for a payslip belonging to an employee who does not have a related partner.…
Currently an error occurs when the **'Payroll: Generate pdfs'** scheduled action runs and tries to create a document for a payslip belonging to an employee who does not have a related partner. **Prerequisites:** - Ensure HR is enabled in `settings>Documents` **Steps to Reproduce:** 1) Install `documents_hr_payroll` module.(with Demo) 2) Navigate to the Employees App. 3) Select any Employee(e.g Abigail Peterson) and open form view. >- click on **contacts** smart button. >- Delete that Record 4) Create a confirmed Payslip for the selected Employee(e.g Abigail Peterson). 5) Activate Developer mode and navigate to schedule Actions. >- Search for 'Payroll: Generate pdfs'. >- Run Manually. Error: `NotNullViolation: null value in column 'partner_id' of relation 'documents_access' violates not-null constraint` Root Cause: When the partner is deleted, the value received from `_get_document_partner` at [1] is `False`, which later on tries to create the `documents.access` record for the new document, it fails because no partner is available to assign access rights, resulting in the error. Solution: This commit prevent Error by ensuring `_check_create_documents` method doesn't allow document creation without valid partner. [1]: https://github.com/odoo/enterprise/blob/99a8d83edb42f172d0dd35c91743fa0c9653dcbb/documents_hr_payroll/models/hr_payslip.py#L20C1-L21 sentry-6814524392 Forward-Port-Of: odoo/enterprise#96191 Forward-Port-Of: odoo/enterprise#92865
German PoS payments are now sent to Fiskaly in the required format, preventing payment validation errors. The update also avoids creating unnecessary zero-value payment lines caused by rounding when multiple decimal payments use the same method.
Original PR description
This ticket fixes two bugs: ### Problem 1 Fiskaly requires `amounts_per_payment_type` values to be strings with 2 to 5 decimal places. After this PR: https://github.com/odoo/enterprise/pull/83300, amounts started being sent as numbers, which caused bad request error when paying a PoS order in version 19.0. ### Solution 1: Restore the use of `.toFixed(2)` to ensure amounts are sent as strings. ### Problem 2 When adding two payment lines with decimal amounts using the same payment method, the system merges both payments into a single line by adding the second amount to the first. This can cause a rounding difference and may trigger sending an additional payment line to Fiskaly with a 0.00 amount. ### Solution 2: Check if rounded change is zero before creating the change line. opw-5115157 Forward-Port-Of: odoo/enterprise#96020
This fixes how Odoo links exchange difference entries when multiple bank reconciliation lines are selected at once. It helps ensure the exchange adjustment is attached to the correct transaction line, reducing the risk of confusing or inaccurate reconciliation records.
Original PR description
When selecting multiple lines in the bank rec widget (reconcile button), it could happen that one of those lines have a exchange diff move linked to it. In this case, the exchange move id was placed on the first line all the time which could be wrong. This commit will change the use of indexes to use the reconciled line of the exchange diff move. no task id Forward-Port-Of: odoo/enterprise#95620 Forward-Port-Of: odoo/enterprise#94160
35 changes
Security fixes and vulnerability patches
This fix prevents Helpdesk tickets from being linked to a customer contact belonging to a different company than the ticket. It helps ensure users only see and access tickets for the companies they are allowed to work with, avoiding access errors and potential unauthorized visibility.
Original PR description
**Issue**: It is possible to associate a partner that belongs to a different company than the ticket’s company. As a result, some users could see tickets in the list view that they should not have access to. When attempting to open those tickets, an error was raised. Even worse, in some cases (see the associated ticket), certain users were still able to access them. **Steps to reproduce**: - Create two companies (A and B) - Switch to company A - Open the Helpdesk application - Create and open a ticket - Select both companies A and B - Assign a partner linked to company B to the ticket - Save it opw-4926497 Forward-Port-Of: odoo/enterprise#96193 Forward-Port-Of: odoo/enterprise#93201
Enhancements to existing features
The bank matching edit line wizard now shows only the line name instead of combining it with the reference. This keeps long references from disrupting the layout while still leaving the reference visible in the kanban view.
Original PR description
Problem: - The reference field was displayed together with the bill name, causing misalignment when the reference is quite long in the edit line wizard. Solution: - Updated the edit line wizard to display only the line's name. - The reference remains visible in the kanban view, it is only removed in the edit line wizard. task-5113489 Forward-Port-Of: odoo/enterprise#95575
Email handling now avoids loading large unnecessary message content into memory during common operations. This reduces the risk of out-of-memory failures and improves processing speed for mail-heavy databases, while keeping the same user-facing behavior.
Original PR description
Modifications are made around read, filtered, list comprehension. The read function usually does not prefetech fields other than stated. But in this case, since the fields are related fields from…
Modifications are made around read, filtered, list comprehension. The read function usually does not prefetech fields other than stated. But in this case, since the fields are related fields from another model, The fields of the other model are prefeteched. This includes the body which can be very big in size and cause an out of memory error. Filtered does not need other fields and keeps them unnecessarily in cache. List comprehension where it has a reference to specific field inside the model also triggers the prefetecher. Benchmark: | |Number of queries| SQL time| Python time|| |-------|----------------------------|----------------|---------------|-| |with prefetch| 82| 1.887 | 7.898| Out of memory| |Without prefetch| 120| 0.385 | 5.973| | The benchmark with the prefetch was done locally with increasing the memory limit. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211075 Forward-Port-Of: odoo/odoo#183893
This update adds documentation for an internal testing utility used by the HTML editor team. It helps developers understand and use the tool more consistently, supporting more reliable future updates without changing the user experience.
Changing a folder to not be discoverable no longer automatically makes the files inside require a direct link. This keeps folder visibility settings from unexpectedly restricting access to existing documents, making document sharing behavior more predictable for users.
Original PR description
Changing the discoverability to not propagate to its children. Previously setting a folder to Discoverable to 'No' would result in all the files also requiring a link to access them, which is unwanted behaviour. Task-4996667
Resolved issues and error corrections
This fix updates the live chat test mock so it includes the same user availability status information as the real server. It helps prevent incorrect test results and improves confidence that live chat behavior is validated accurately.
Original PR description
**Description of the issue this PR addresses:** Add missing im_status field in mock server **Current behavior before PR:** Previously, the `im_status` field was available on the server side, but it was missing in the mock server implementation used in tests. **Desired behavior after PR is merged:** This PR updates the mock `DiscussChannelMember` model to include `im_status` in the list of stored partner fields, ensuring that test scenarios accurately reflect server behavior. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229865
This fixes a crash that could occur when validating Register Production/Serial from the shop floor after duplicate quality checks were created. Manufacturing users can now complete production validation without being blocked by an unexpected error.
Original PR description
When user tries to validate Register Production/Serial in shop floor, A traceback will appear. Steps to reproduce the error: - Install ``mrp_workorder`` and ``quality_control`` modules with demo data…
When user tries to validate Register Production/Serial in shop floor, A traceback will appear. Steps to reproduce the error: - Install ``mrp_workorder`` and ``quality_control`` modules with demo data - Go to Quality > Create a new Control point > Product: Table Top > Operations: Manufacturing > Save - Create a new MO > Product: Table Top > Confirm > Shop Floor > Click on Assembly 1 > Click on 3 dots > Update Instructions > Improvement Suggestion > Add a step > Propose Change > Validate - Click on 3 dots > Register Production/Serial > Validate - Go back to MO > Quality Checks > Duplicate the newly created quality check > Shop Floor > Click on Assembly 1 > Click on 3 dots > Register Production/Serial > Validate Traceback: ``ValueError: Expected singleton: quality.check(1, 5)`` https://github.com/odoo/enterprise/blob/5103383df3ddf23503e2c7817c5129a742a7800f/mrp_workorder/models/mrp_workorder.py#L846-L848 When User clicks on the validate, ``current_check`` may include several quality checks without a ``previous_check_id``. The code expects only one record, which causes a traceback. sentry-6839419788 Forward-Port-Of: odoo/enterprise#93624
This fix prevents Odoo from opening a chat window when a message has already been received and seen through another part of the app. It reduces unnecessary interruptions for users in Discuss while keeping message notifications consistent.
Original PR description
Before this commit, if a message was already received in the store by another medium than the bus, it was still handled not-silently when receiving the bus notification `discuss.channel/new_message`. This could lead to opening a chat window when a message was already seen by the user in the discuss app. This commit changes the handling of new messages in the frontend and overrides the silent flag when the record already exists. fixes-runbot-230700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227445
This fix ensures scheduled background jobs refresh their system information before running after an app is installed or removed. It prevents worker crashes caused by jobs using outdated data, improving reliability for databases running with multiple workers.
Original PR description
**step to reproduce:** - start a database with worker, use `--max-cron-thread=1 --workers=2` - Add a sample cron, which runs every minute(just so that we can see the status) - install helpdesk -…
**step to reproduce:**
- start a database with worker, use `--max-cron-thread=1 --workers=2`
- Add a sample cron, which runs every minute(just so that we can see the status)
- install helpdesk
- uninstall helpdesk
**Observation**
- traceback in console
```
2025-09-25 06:07:26,389 18450 ERROR ? odoo.service.server: Worker WorkerCron (18450) Exception occurred, exiting...
Traceback (most recent call last):
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/service/server.py", line 1171, in _runloop
self.process_work()
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/service/server.py", line 1270, in process_work
base.models.ir_cron.ir_cron._process_jobs(db_name)
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/addons/base/models/ir_cron.py", line 139, in _process_jobs
registry[cls._name]._process_job(db, cron_cr, job)
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/addons/base/models/ir_cron.py", line 331, in _process_job
now = fields.Datetime.context_timestamp(ir_cron, datetime.utcnow())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
....
....
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/models.py", line 3873, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/addons/base/models/res_users.py", line 546, in _fetch_query
records = super()._fetch_query(query, fields)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/models.py", line 3965, in _fetch_query
self.env.cr.execute(query.select(*sql_terms))
File "/home/odoo/odoo/codebase/odoo/17.0/odoo/sql_db.py", line 335, in execute
res = self._obj.execute(query, params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.UndefinedColumn: column res_users.helpdesk_target_closed does not exist
LINE 1: ...s"."odoobot_state", "res_users"."odoobot_failed", "res_users...
```
Issue:
- traceback occurred, as the system is try to fetch fields related to helpdesk module
which do not exists now after uninstalling it.
- cron in case of workers, use daemon threads [1]
- the uninstalled happened with main thread and registry is updated.
- the daemon thread is unaware of this change.
- the `_process_jobs` uses the registry, without checking if it needs reload
[1]: https://github.com/odoo/odoo/blob/e82fdfaf621f45515b92c891334595250accbfbd/odoo/service/server.py#L582-L587
FIx:
- when assigning the registry, we check if needs a reload or not.
opw-5062313
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#229556
Forward-Port-Of: odoo/odoo#228515The employee offer form now automatically uses the correct employee when creating a new offer from the Offers button. This prevents confusion for HR users and helps ensure offers are linked to the intended employee.
Original PR description
#### Steps to reproduce Employees -> Create employee (or select employee) with offer -> Offers smart button -> New: wrong employee name in "Offer for ..." #### Reason Wrong key passed to context of the offers view via action_show_offers method #### Solution Replace key 'default_employee_version_id' with 'default_employee_id' task-5003544 Forward-Port-Of: odoo/enterprise#92073
This fixes an issue where emails or tickets containing an image formatted with a caption area but no actual caption could fail to open. Odoo now handles these images safely, preventing tracebacks for users reviewing related helpdesk tickets or messages.
Original PR description
When a image that has a figure tag without fig caption tag is rendered in a caption area it create a traceback. ### Steps to reproduce: * Write an email with an image that has a "figure" tag but no "fig caption" * Send it to an helpdesk alias to create a ticket * Open the ticket -> traceback ### Issue: When a "figure" tag was processed, it wasn't taking into account the possibility of not having "figcaption" which created the traceback. https://github.com/odoo/odoo/blob/2769717bb0632ee7b813e131a94e77885b54493f/addons/html_editor/static/src/others/embedded_components/plugins/caption_plugin/caption_plugin.js#L56-L59 opw-5080370 Forward-Port-Of: odoo/odoo#228858
This fixes a crash when users remove certain calendar view settings in Studio, such as the color field. Empty values are now handled correctly instead of being treated as invalid field names, making Studio edits more reliable.
Original PR description
On a calendar with studio, try to remove the "color" attribute, or any other that should contain the name of a field. Before this commit there was a crash because the value sent to the server in this case is `undefined` (`null` in JSON or `None` in python), which was stringified and yielding an actual string that was not a field name After this commit, NULL values are not stringified, instead they should represent the emptiness of the attribute. opw-4938351 Forward-Port-Of: odoo/enterprise#95439
Breadcrumb labels now refresh correctly when users switch the Odoo interface language. This prevents navigation labels from staying in the previous language, reducing confusion for multilingual users.
Original PR description
[FIX] web: update breadcrumb display name on language switch Versions -------- - 19.0+ Steps ----- 1. Switch the user interface language in Odoo 2. Navigate through the application using breadcrumbs…
[FIX] web: update breadcrumb display name on language switch Versions -------- - 19.0+ Steps ----- 1. Switch the user interface language in Odoo 2. Navigate through the application using breadcrumbs 3. Observe the breadcrumb display names Issue ----- When switching languages, the breadcrumb display names remain in the previous language and do not update to reflect the new language. Cause ----- The action data cached in sessionStorage retains the display names in the original language. When language is switched, the cached action data is not invalidated, causing breadcrumbs to show outdated translated text. Solution -------- Detect language changes by comparing the current user context language with the cached action's language context. When a language mismatch is detected, clear the cached action data from sessionStorage to force a fresh load with properly translated display names. Signed-off-by: PA Sitthipong <sitthipong114@gmail.com> <img width="466" height="198" alt="OdooBugLanguageSwitch" src="https://github.com/user-attachments/assets/83302c7f-bc66-40e4-a310-e7087da1e747" />
The HTML editor’s automated tests now better reflect how the editor behaves in real use after inserting HTML. This helps prevent inaccurate test results and reduces the chance of unnoticed issues reaching users.
Original PR description
The insert HTML tests were using `dom.insert` directly without consistently triggering a step afterwards, leading to results that weren't always representative of the editor's reality. This ensures consistency in that regard. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now open the AI assistant from the Physical Inventory list and ask questions without triggering an error. The fix handles pages that do not have a linked action, improving reliability for Inventory users.
Original PR description
Currently an error is generated when a user tries to send a message to AI while the current page is in `Physical Inventory`list view. Steps: - Install `Inventory` - Go to Inventory > Operations >…
Currently an error is generated when a user tries to send a message to AI while the current page is in `Physical Inventory`list view. Steps: - Install `Inventory` - Go to Inventory > Operations > Physical Inventory - Click the AI icon from the systray menu. - Ask anything in AI >>> error generated Error: ```UnboundLocalError:cannot access local variable 'current_action' where it is not associated with a value``` This issue arises because in line [1] of the code, the variable `current_action` is assigned a value inside an `if-elif` block based on `action.type`. However, since the `Physical Inventory` page does not have any associated action, the variable `current_action is` never set. Consequently, attempting to access this variable results in an error. This commit fixes the above issue by initializing the `current_action` variable as `None` outside the `if-elif` block and adding handling for cases when `current_action` is `None`. [1] - https://github.com/odoo/enterprise/blob/2ea15cc9c7c5f114b3786b256c64e269b3e3a313/ai/models/ai_agent.py#L750-L755 sentry-6913801088
Product pages now keep the selected image crop shape when shoppers open the zoom-on-click image carousel. This prevents thumbnails from unexpectedly appearing square, giving stores a more consistent and polished product display.
Original PR description
Steps ----- 1. Open a product page in eCommerce; 2. open the editor; 3. change the auto-crop setting to a non-default value; 4. enable zoom-on-click; 5. save & click to zoom. Issue ----- The thumbnails use a square aspect ratio. Cause ----- Their aspect ratio is hardcoded to be '1/1'. Solution -------- 1. When instantiating the `ProductImageViewer` dialog, get the aspect ratio used by `.oe_website_sale`, and propagate it into a class name. 2. Use the CSS rules introduced by 670b1daa2254d to apply the correct aspect ratio based on the class name. opw-4908881
This fix prevents an error when users edit a spreadsheet list and set the Medium field matching in the Sales dashboard. It improves reliability for dashboard editing by avoiding an invalid filter update that caused a traceback.
Original PR description
Steps to reproduce (in enterprise): 1. Open the Sales dashboard 2. Edit the first list 3. Try to set the "Medium" field matching => Traceback The test is in enterprise as the issue is triggered only by editing the spreadsheet. Task: 5101093 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
Fixes an issue where a manually adjusted delivery date on an invoice could be overwritten after changing product quantities and confirming the invoice. This preserves user-entered delivery information and helps keep invoicing and delivery records accurate.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a sale order with deliverable products & no payment terms; 2. confirm order & validate delivery; 3. create an invoice; 4. modify the delivery date; 5.…
Versions -------- - 17.0+ Steps ----- 1. Have a sale order with deliverable products & no payment terms; 2. confirm order & validate delivery; 3. create an invoice; 4. modify the delivery date; 5. save changes; 6. change product quantity of a line & confirm invoice. Issue ----- The delivery date got reset. Cause ----- The `_compute_show_delivery_date` method gets called, which triggers the recomputation of the `_compute_delivery_date` due it the latter having `line_ids.sale_line_ids.order_id` as its `depends`. Due to the way how `depends` works, if any of the fields in the record chain gets modified, the compute gets triggered. In this case, because we modified a `line_ids` record by changing the quantity, it will therefore recompute the delivery date, overwriting the custom value. Solution -------- As we only want the delivery date to be recomputed when the `effective_date` on the order changes, we should add it to the `depends` to trigger the compute in that scenario. In other scenarios, e.g. modifying the move or one of its lines, we don't want to trigger a recompute, which we can achieve by always including `delivery_date` via `_get_protected_vals` on create/write. opw-4996654 Forward-Port-Of: odoo/odoo#229932 Forward-Port-Of: odoo/odoo#223946
A test was added to ensure editing a Sales dashboard list no longer triggers an error when selecting the Medium field matching. This helps protect dashboard editing from regressions and supports a smoother reporting experience.
Original PR description
Steps to reproduce: 1. Open the Sales dashboard 2. Edit the first list 3. Try to set the "Medium" field matching => Traceback This commit contains only the test as the fix is in the community PR. Task: 5101093
This fixes inconsistent line breaks on IoT printer status receipts. The change makes printed status information easier to read and more predictable for users checking printer output.
Original PR description
This PR makes the newlines the same after every line on the status receipt
Point of Sale receipts now show preset information, such as customer addresses or time slots, centered in the receipt header. This makes printed receipts look cleaner and more consistent for customers.
Original PR description
We now want to center preset infos on receipt header (customer address or time slot) in POS. task-id: 5048706 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226831
This update restores a missing setup link for Spanish reports that was accidentally left out during a previous code update. It helps ensure the Spanish reporting module loads all required components correctly, reducing the risk of reporting setup issues.
Original PR description
Little oopsie while fw-porting https://github.com/odoo/enterprise/pull/96106
This fixes an issue in the Resource module where work time rate searches could behave incorrectly after a recent refactor. The correction helps prevent related automated checks or scheduling calculations from failing, keeping resource planning more reliable.
Original PR description
The `_search_work_time_rate` implimination was missed up on refactor at odoo/odoo#219608 runbot error: 231181 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in bank reconciliation where an exchange difference entry could be linked to the wrong selected line when multiple lines were reconciled together. The change helps ensure foreign currency reconciliation records are matched accurately, reducing accounting discrepancies.
Original PR description
When selecting multiple lines in the bank rec widget (reconcile button), it could happen that one of those lines have a exchange diff move linked to it. In this case, the exchange move id was placed on the first line all the time which could be wrong. This commit will change the use of indexes to use the reconciled line of the exchange diff move. no task id Forward-Port-Of: odoo/enterprise#94160
Field service project settings now show the correct label for the timesheet product when a customer is selected. This avoids confusion by preventing the sales order line label from appearing in the wrong place.
Original PR description
Steps to reproduce: - Install the `industry_fsm_sale` module. - Open the FSM app. - Go to Projects. - Open a project’s settings. - Select a customer. Issue: The label for the timesheet product is not displayed. Instead, the label for the sale order line appears on FSM projects. Cause: In the PR, https://github.com/odoo/odoo/pull/128967 changed the project settings form structure by wrapping `sale_line_id` in a `div` and separating its label, breaking the xpath for `timesheet_product_id`. Fix: - Update the XPath for `timesheet_product_id` to target the correct container. - Hide the `sale_line_id` label on FSM projects. task-4581748 Forward-Port-Of: odoo/enterprise#96022
Bank reconciliation now links exchange difference entries to the correct selected line instead of always using the first line. This prevents incorrect accounting references when reconciling multiple bank lines at once, improving accuracy for multi-currency transactions.
Original PR description
When selecting multiple lines in the bank rec widget (reconcile button), it could happen that one of those lines have a exchange diff move linked to it. In this case, the exchange move id was placed on the first line all the time which could be wrong. This commit will change the use of indexes to use the reconciled line of the exchange diff move. no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226034
The ESG module's demo data was adjusted so it no longer depends on accounting records tied to a specific country setup. This prevents installation errors when businesses use another fiscal localization, such as India, and helps new databases load demo data successfully.
Original PR description
**Note: issue not reproducible in runbot, but in fresh database** **Step to reproduce:** - in fresh database, install esg module - go to setting > invoicing > add india as Fiscal Localization -…
**Note: issue not reproducible in runbot, but in fresh database**
**Step to reproduce:**
- in fresh database, install esg module
- go to setting > invoicing > add india as Fiscal Localization
- change company name, ex "test"
- goto setting > load demo data
**Observation:**
- You will receive traceback
```
raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo/codebase/enterprise/saas-18.4/esg/demo/demo_data.xml:567, somewhere inside
<record id="esg_emission_factor_line_assignation_4" model="esg.assignation.line">
<field name="esg_emission_factor_id" ref="esg_zero_emission_factor"/>
<field name="account_id" model="account.account" search="[('code', '=', '630000')]"/>
</record>
2025-09-11 08:45:07,458 82617 INFO esg184 odoo.addons.base.models.ir_module: module esg: no translation for language en_IN
2025-09-11 08:45:07,479 82617 ERROR esg184 odoo.sql_db: bad query: b'INSERT INTO "esg_activity_type_esg_emission_factor_rel" ("esg_emission_factor_id", "esg_activity_type_id") VALUES (1, 2) ON CONFLICT DO NOTHING'
ERROR: insert or update on table "esg_activity_type_esg_emission_factor_rel" violates foreign key constraint "esg_activity_type_esg_emission_fact_esg_emission_factor_id_fkey"
DETAIL: Key (esg_emission_factor_id)=(1) is not present in table "esg_emission_factor".
```
**Cause:**
- The demo data relies on few account.account record which belong to [USA company](https://github.com/odoo/odoo/blob/9805d09dff64de835de0c764da8c6e213d6b88aa/addons/account/data/template/account.account-generic_coa.csv#L38)
https://github.com/odoo/enterprise/blob/b8a20b02e27322d0db5781f8d84946e54bbcbf03/esg/demo/demo_data.xml#L569
https://github.com/odoo/enterprise/blob/b8a20b02e27322d0db5781f8d84946e54bbcbf03/esg/demo/demo_data.xml#L620-L628
- when we installed `india` Localization and changed the company name, USA company could not be created when loading demo data and hence the account records were not created, causing traceback
**Fix:**
- make demo data independent of any localization
opw-5048417
Forward-Port-Of: odoo/enterprise#94540The sales planning test now avoids selecting the current day when that day is not a working day. This prevents false test failures and helps keep delivery checks stable without changing customer-facing behavior.
Original PR description
Before this commit, the tour was failing on non-working days as the focused day was the current date. This commit removes the focus on the current date so that only working dates are selected. Additionally, this commit also fixes the formatting issues of the modified file. runbot error 226741 Forward-Port-Of: odoo/enterprise#96239
This fix lets Spanish TicketBAI credit notes be sent even when the original invoice was issued through a previous invoicing system before TicketBAI was adopted. It prevents valid refunds from being blocked while keeping checks for newer invoices that should already be in TicketBAI.
Original PR description
…re starting to use Tbai 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#225938
Fixed an issue that could prevent some upgrades from completing when timesheet attendance reporting data was processed. The change ensures the report query uses the correct employee reference, avoiding a database comparison error.
Original PR description
In the affected query, the variable "employee_id" is undefined in the scope where it is used. This leads postgres to interpret it as a variable with default type VARCHAR and to the impossibility to compare it against an integer. We just qualify the variable name so it now works as expected. Failing upgrade requests: [3103245](https://upgrade.odoo.com/odoo/request/3103245) [3121291](https://upgrade.odoo.com/odoo/request/3121291) Fixes https://github.com/odoo/odoo/pull/192434/commits/c97ecfa7fc091f763329af589b69db2292931163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228580 Forward-Port-Of: odoo/odoo#225401
This fixes small visual issues in Odoo Mail where some thread action buttons appeared too tall and mobile messaging menu text was misaligned. The mail interface now looks more consistent and polished for users, especially on mobile devices.
Original PR description
Current behavior before PR: 1. Since [1], in thread actions like `Mark all read` and `Unstar all`, buttons had extra height because aspect-ratio was applied even when there was no icon, making the UI…
Current behavior before PR: 1. Since [1], in thread actions like `Mark all read` and `Unstar all`, buttons had extra height because aspect-ratio was applied even when there was no icon, making the UI look uneven. 2. Since [2], text in the messaging menu tab in mobile was not centered, leading to misaligned UI. Desired behavior after PR is merged: - Aspect-ratio is applied only if an icon exists in the action button, fixing the height issue. - Added a class to center text in the messaging menu tab, improving visual alignment. [1]: https://github.com/odoo/odoo/pull/225216 [2]: https://github.com/odoo/odoo/pull/228657 Task-5145022 1. Before/ After <div style="display: flex;"> <img style="margin-right: 10%;" height="145" alt="image" src="https://github.com/user-attachments/assets/a9fcffdc-5e56-454f-882a-dc5296decd47" /> <img height="136"style="margin-right: 10%;" alt="image" src="https://github.com/user-attachments/assets/105ce999-4e15-4c67-9b62-01c666c6fc2d" /> </div> 2. Before/ After <img width="691" height="114" alt="image" src="https://github.com/user-attachments/assets/6aa4965c-a34f-4058-bdb9-4d91f4ac9146" /> <img width="688" height="94" alt="image" src="https://github.com/user-attachments/assets/ce110144-9314-4b2f-aa30-bf12b7ecf1ec" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Manufacturing orders for products that include variant-specific kit components now correctly include the matching kit operations, such as the right color-related work step. This prevents missing shop floor instructions when a final product uses a specific kit variant.
Original PR description
### Steps to reproduct: - Create 2 products: Final Product (FP), Kit Product (KP) - On KP add a Color attribute with 2 values: Blue, Red - Create a KIT bom for KP wtih 2 operations: - OP: paint it…
### Steps to reproduct:
- Create 2 products: Final Product (FP), Kit Product (KP)
- On KP add a Color attribute with 2 values: Blue, Red
- Create a KIT bom for KP wtih 2 operations:
- OP: paint it Blue, apply on Color: Blue
- OP: paint it Red, apply on Color: Red
- Create a bom for FP with only one component line:
- 1 x Red Kit Product
- Create a MO for 1 unit of FP
#### > The operation was not created using the kit bom
### Cause of the issue:
Even if the bom exploded to find the operations to add on the MO: https://github.com/odoo/odoo/blob/2dfcbe53c80d2d8fe5b6d9828eea90a1d214c2e4/addons/mrp/models/mrp_production.py#L579-L599 The `_skip_operation_line`:
https://github.com/odoo/odoo/blob/2dfcbe53c80d2d8fe5b6d9828eea90a1d214c2e4/addons/mrp/models/mrp_routing.py#L164-L174 is checking if the product of the main bom has the attributes of the operation rather than the kit product used as component.
opw-5080856
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#229810
Forward-Port-Of: odoo/odoo#228032The payroll document generation process now skips payslips when the related employee contact is missing. This prevents scheduled payroll PDF generation from failing and helps keep automated payroll document handling running smoothly.
Original PR description
Currently an error occurs when the **'Payroll: Generate pdfs'** scheduled action runs and tries to create a document for a payslip belonging to an employee who does not have a related partner.…
Currently an error occurs when the **'Payroll: Generate pdfs'** scheduled action runs and tries to create a document for a payslip belonging to an employee who does not have a related partner. **Prerequisites:** - Ensure HR is enabled in `settings>Documents` **Steps to Reproduce:** 1) Install `documents_hr_payroll` module.(with Demo) 2) Navigate to the Employees App. 3) Select any Employee(e.g Abigail Peterson) and open form view. >- click on **contacts** smart button. >- Delete that Record 4) Create a confirmed Payslip for the selected Employee(e.g Abigail Peterson). 5) Activate Developer mode and navigate to schedule Actions. >- Search for 'Payroll: Generate pdfs'. >- Run Manually. Error: `NotNullViolation: null value in column 'partner_id' of relation 'documents_access' violates not-null constraint` Root Cause: When the partner is deleted, the value received from `_get_document_partner` at [1] is `False`, which later on tries to create the `documents.access` record for the new document, it fails because no partner is available to assign access rights, resulting in the error. Solution: This commit prevent Error by ensuring `_check_create_documents` method doesn't allow document creation without valid partner. [1]: https://github.com/odoo/enterprise/blob/99a8d83edb42f172d0dd35c91743fa0c9653dcbb/documents_hr_payroll/models/hr_payslip.py#L20C1-L21 sentry-6814524392 Forward-Port-Of: odoo/enterprise#96191 Forward-Port-Of: odoo/enterprise#92865
This fixes an automated mail test by clicking the enabled button instead of relying on the Enter key, which could behave inconsistently depending on focus timing. The change helps keep validation runs stable and reduces false failures without changing customer-facing functionality.
Original PR description
Pressing Enter is prone to race conditions as it requires the proper element to have the focus at the right time. Clicking on the button directly when it is enabled should be preferred. https://runbot.odoo.com/odoo/runbot.build.error/233169 Forward-Port-Of: odoo/odoo#229872
Documentation and clarification updates
A new individual contributor agreement signature was added to the project records. This supports legal clarity around contributions and helps keep the project’s licensing documentation complete.
Original PR description
closes 230023
4 changes
Enhancements to existing features
Belgian partner lookups on the Peppol network now check the two most commonly used identifier types, improving the chance of finding the right participant. The update also removes outdated warnings about recommended identifiers because the mandatory identifier handling is now managed automatically by the access point service.
Original PR description
1. For belgian partner, we now check for 0208 and 9925 which are the two most used EAS when looking for partner existence on the Peppol network. 2. Remove the warnings about the recommended EAS: 0208 is now the mandatory EAS, this will be handled directly on IAP where the Peppol Access Point will try to register 0208 in all cases with an alias system. Note that we have always computed 0208 as recommended value in registration process. task-4852903 Forward-Port-Of: odoo/odoo#227431
Resolved issues and error corrections
Belgian 325 form PDF exports no longer fail with a server error when there are no 281.50 forms to include. Users now see a clear message explaining that they need to record a transaction with a 281.50 tag before generating the PDF.
Original PR description
### Problem When clicking **"Export PDF"** on a 325 form that has **no generated 281.50 forms**, Odoo raised a **server error**: This happened because the method assumed that at least one attachment…
### Problem When clicking **"Export PDF"** on a 325 form that has **no generated 281.50 forms**, Odoo raised a **server error**: This happened because the method assumed that at least one attachment would always be generated, even if no eligible transactions were present. --- ### Steps to Reproduce 1. Go to **Accounting → Reporting → 325 Form**. 2. Create a 325 form for a year without any transactions on accounts tagged with **281.50**. 3. Do not generate any 281.50 forms (`form_281_50_ids` is empty). 4. Click **Export PDF**. **Result before fix:** - Crash with `IndexError: list index out of range`. --- ### Solution - Added a safeguard check before accessing attachments. - If no attachments exist, raise a **UserError** instead of crashing. **New behavior:** > *“No 281.50 lines found to generate a PDF. Please record a transaction with a 281.50 tag first.”* This gives users a instruction on how to resolve the issue. --- ### Result After Fix - **User error message** replaces traceback. - **Normal behavior preserved** when attachments exist: - One file → direct download. - Multiple files → zipped download. --- task-5090120 Forward-Port-Of: odoo/enterprise#94877
The accounting dashboard’s drag-and-drop upload buttons and drop zones now use theme-aware backgrounds instead of fixed grey colors. This improves visual consistency and readability for users working in both light and dark modes.
Original PR description
Current behavior before PR: - Drag & drop buttons and upload drop zones of dashboard cards had hardcoded backgrounds (#F2EDF0 / grey), which did not adapt to dark mode. Desired behavior after PR is merged: - Removed hardcoded background colors from drag & drop button and upload drop zone cards on dashboard and updated their background to adapt in light & dark modes. Changes implemented: - Removed hardcoded background color (`#F2EDF0`) from `account_drag_drop_btn` & `drag_to_card` CSS classes. - Removed overriding background-color property from `o_drop_area` CSS class. - Updated background-color of `o_drop_area` in `o_account_dashboard_kanban_view` CSS class to `o-view-background-color`. task-5092460 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents Odoo Studio from crashing when users remove calendar settings such as the color field. Empty values are now handled correctly instead of being treated as invalid field names, making view customization more reliable.
Original PR description
On a calendar with studio, try to remove the "color" attribute, or any other that should contain the name of a field. Before this commit there was a crash because the value sent to the server in this case is `undefined` (`null` in JSON or `None` in python), which was stringified and yielding an actual string that was not a field name After this commit, NULL values are not stringified, instead they should represent the emptiness of the attribute. opw-4938351 Forward-Port-Of: odoo/enterprise#95439
5 changes
Resolved issues and error corrections
The message shown after fetching bank transactions now displays correctly instead of showing raw formatting code. This makes the banking workflow clearer for users when no matching transactions are available.
Original PR description
Before this commit : - The help message shown when no transactions were fetched by the 'Fetch Transactions' button in the 'Bank' journal contained raw html tags, as markup was not getting applied. - Also, removing a filter (without reloading) and applying another filter that resulted in no matches, the same issue occurred. After this commit: - The help message is now consistently rendered with markup applied. task-4942234
This fix improves how calendar views appear when dark mode is enabled. It helps users read and navigate calendar information more comfortably by correcting visual styling issues.
Original PR description
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
This fixes visual issues in dark mode for the manufacturing work order display. It helps ensure production teams can read and use the screen comfortably when dark mode is enabled.
Fixed an issue where one-day time off requests could appear as multi-day events in the Calendar app for users in certain time zones. This helps employees and managers see accurate leave schedules and avoids confusion when planning coverage.
Original PR description
**Issue:** Single-day time off requests appear as multi-day events in the Calendar app when using certain tim> **Cause:** The `_compute_date_from_to()` method converts user-specified dates to UTC.…
**Issue:** Single-day time off requests appear as multi-day events in the Calendar app when using certain tim> **Cause:** The `_compute_date_from_to()` method converts user-specified dates to UTC. https://github.com/odoo/odoo/blob/028e7228cb830e47a9726bef4c82793ba4590cd5/addons/hr_holidays/models/hr_leave.py#L316-L317 The `_prepare_holidays_meeting_values()` method then uses these UTC datetime values (`holiday.date_from`, `holiday.date_to`) In Los Angeles timezone, and for a one day leave on september 17 2025 this leads to: - holiday.date_from: September 17, 2025 at 03:00 UTC - holiday.date_to: September 18, 2025 at 12:00 UTC causing a single-day leave to be displayed as a two-day event. **After fix:** - start_value: September 17, 2025 at 12:00 - stop_value: September 17, 2025 at 11:59 **Steps to Reproduce:** 1. Set the user timezone to "America/Los_Angeles" 2. Set the browser timezone to the same timezone 3. Create a one-day time off request (e.g., September 17, 2025) 4. Open the Calendar app: the event spans across two days opw-4744817
This fixes an internal automated test for bus notifications that could fail unpredictably. The test now checks all received notifications, helping keep validation runs stable without changing user-facing behavior.
Original PR description
This commit fixes the `test_postcommit` that fails in a non deterministic fashion. This test ensures bus notifications created in the post commit hook result in only one batch. However, the listener only consider the first notification of the batch (`conn.notifies.pop()`) and ignore the rest. When the expected notifications come as part of a bigger batch, they can be ignored thus making the test fail. This commit ensures we read every notification received. fixes runbot-233185 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