Daily updates from Odoo
Tuesday, June 16, 2026
143 changes
10 changes
New functionality added to Odoo
This update adds support for the Hacienda Foral de Navarra tax agency within Odoo's SII invoicing system. It includes necessary configuration changes to handle the agency's specific XML format and endpoint requirements, ensuring accurate invoice submissions to the Navarra tax authorities.
Original PR description
The Hacienda Foral de Navarra uses the same SII XML format as AEAT but sends invoices to a different endpoint. Additionally, Navarra requires explicit XML namespace declarations in the SOAP envelope header, which the standard zeep serializer does not include by default. This adds the Navarra tax agency as a new option in the company SII configuration, defines its production and test endpoints, and injects the required namespaces in the request header when the Navarra agency is selected. task-5946583 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268928 Forward-Port-Of: odoo/odoo#263048
Resolved issues and error corrections
This update resolves a bug in the Website Builder module that was causing crashes during testing. By removing unnecessary definitions, the code is now more stable and reliable, ensuring a smoother experience for users building their websites. This fix improves the overall quality and stability of the Odoo website platform.
Original PR description
`this.websiteService` is defined in `WebsiteBuilder`. If it's used inside tests, it's useless to define it in `Builder` and it will crash.
This update fixes a display issue where the AI button appeared inconsistently in the Mass Mailing and Website Builders. The fix redirects patching to the Website Builder, ensuring the AI button is only visible when using the website functionality. This improves the user experience for website builders.
Original PR description
__Problem__ When opening the Mass Mailing builder after the Website Builder, the AI button is still shown. Conversely, if we open the Website Builder after the Mass Mailing builder, the AI button is never shown. This happens because Owl mounts the Builder component only once as long as we don't refresh the page. Since we patch the generic HTML Builder to put the AI button in the sidebar, the state of the first time it's mounted is preserved. __Fix__ Patch the Website Builder directly instead, as we only want the AI button to be available in the website. Community PR: odoo/odoo#270266 task-6189057
This update fixes an issue where holiday pay calculations could exceed an employee's regular wage. The system now ensures the base holiday amount is capped at the employee's standard earnings, ensuring accurate payroll processing and compliance. This change improves the reliability of holiday pay calculations.
Original PR description
The base amount should never be more than the employee's wage. Forward-Port-Of: odoo/enterprise#120681
A previous issue prevented users with limited time-off access from viewing leave information in the Attendances Gantt View. This fix ensures that the Gantt View correctly displays leave requests, even when users have specific access restrictions. The change adds a temporary access layer to ensure accurate calculations.
Original PR description
Version: - 19.0 Steps to reproduce: - Install Attendances and Time Off - Create an internal user. - Give the user: Attendances Officer access & No Time Off Officer/Manager rights - Create an employee…
Version: - 19.0 Steps to reproduce: - Install Attendances and Time Off - Create an internal user. - Give the user: Attendances Officer access & No Time Off Officer/Manager rights - Create an employee linked to the user. - Configure the employee with a Flexible Working Schedule. - Create and approve a Time Off request for the employee. - Open: Attendances -> Gantt View - Navigate to the month containing the employee's approved leave. Issue: - An access error is raised when opening a month that contains the employee's approved leave. Cause: - In `_handle_flexible_leave_interval`, the code accesses `leave.holiday_id` to read fields such as `request_unit_half`, `request_unit_hours`, and `request_hour_from/to` on the `hr.leave` model. - When the current user has Attendances Officer rights but no Time Off access(rare cases), the ORM access check on `hr.leave` raises an AccessError, even though this read is purely for internal calendar computation and does not expose leave data to the user interface. Fix: - Added sudo() on holiday_id to access the employee's leave details and compute the work interval as expected. Task-6264510 Forward-Port-Of: odoo/enterprise#120668 Forward-Port-Of: odoo/enterprise#119116
This update resolves an issue where creating payment sequences in the Accounting module would sometimes trigger a technical error. The fix ensures that date sequences are correctly formatted, preventing the traceback and allowing users to create payment sequences without interruption. This improves the stability and usability of the payment process.
Original PR description
## Issue When trying to call `dt.replace` on a `datetime.time`, a TypeError is raised ``` File "/home/odoo/Documents/src/odoo/190/odoo/addons/base/models/ir_sequence.py", line 270, in _next return…
## Issue
When trying to call `dt.replace` on a `datetime.time`, a TypeError is raised
```
File "/home/odoo/Documents/src/odoo/190/odoo/addons/base/models/ir_sequence.py", line 270, in _next
return seq_date.with_context(ir_sequence_date_range=seq_date.date_from, ir_sequence_date=dt.replace(tzinfo=None))._next()
^^^^^^^^^^^^^^^^^^^^^^^
TypeError: 'tzinfo' is an invalid keyword argument for replace()
```
## Steps to reproduce
1. Install *Accounting* (`accountant`)
2. Update the `account.payment` sequence:
- Toggle *Use subsequences per date_range* and create a range
3. In Accounting > Customers > Payments, create a payment:
- Payment Type: Receive
- Customer: Any
- Amount: Any
4. **A traceback appears**
## Cause
This error was introduced by https://github.com/odoo/odoo/commit/4b9dd7893f96.
The `AccountPayment._compute_name` method calls `_next_by_code` and passes a date as the `sequence_date`.
https://github.com/odoo/odoo/blob/337efb069f6cf2cb9478a970f075fd139c1e8e0a/addons/account/models/account_payment.py#L420-L422
In the `_next` method, the `dt` variable is set to that date (`datetime.date`), and calling the `.replace` method on that variable raises an error, as there's no tzinfo for `datetime.date`s.
opw-6303885
Forward-Port-Of: odoo/odoo#270283This update fixes a potential instability issue with the PDP registration process. By moving a key function to the company record, we ensure the registration process remains reliable even if the temporary PDP registration object is deleted. This improves the overall robustness of the system.
Original PR description
The aim of this commit is to move _get_iap_url on res.company model instead of pdp.regitration. This move is made for 2 reasons: 1. PDP registration is a transient model which means that the object could be deleted in the time. 2. PDP registration implementation was using the model (api.model) and the record (self.edi_mode) which is a bad implementation. So by moving this function on company, we ensure that we always have a record to call the function and then the function is no longer an api.model. 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#270380 Forward-Port-Of: odoo/odoo#270345 Forward-Port-Of: odoo/odoo#270386
This update fixes a potential issue where state deductions exceeding employee income could result in incorrect, negative taxable income calculations on payslips. The change ensures that taxable income defaults to zero in these scenarios, accurately reflecting state tax liabilities and preventing misleading pay statements. This improves payroll accuracy and compliance.
Original PR description
This commit simply defaults the computed taxable income amount to 0 in case the state deductions are greater than their gross income. Otherwise our payslips would imply that these employees are owed money by the state opw-5137280 Forward-Port-Of: odoo/enterprise#119208 Forward-Port-Of: odoo/enterprise#98114
This update resolves an issue where UBL import failed due to a mismatch between the product's and imported unit of measure categories. The fix allows imports to proceed without error, and users can manually correct the UoM after the import is complete. This prevents import failures and improves data accuracy.
Original PR description
The new collected_values UBL import flow sets product_uom_id from the XML unitCode without checking that the resolved UoM category matches the matched product's UoM category. When they diverge, writing the line triggers the incompatible error. Steps to reproduce: - Create a product "XYZ" with UoM "Units" (category "Unit"). - Import a Peppol UBL bill whose line has Item/Name "XYZ" and unitCode="MTK" (uom_square_meter, "Surface"). - Import fails with: "The Unit of Measure (UoM) 'm²' you have selected for product 'XYZ', is incompatible with its category : Unit." This fix will avoid setting the product_uom_id when the UoM category doesn't match the product's UoM category, allowing the line to be imported without error. The user can then manually set the correct UoM after import. opw-6121714 Forward-Port-Of: odoo/odoo#269933 Forward-Port-Of: odoo/odoo#269714
This update enhances the stability of the French PDP (Point of Departure) registration process. By moving a key function to the company record, the system now reliably accesses the necessary data, addressing a previous issue where the registration model could be deleted. This change improves the overall robustness of the PDP integration.
Original PR description
The aim of this commit is to move _get_iap_url on res.company model instead of pdp.regitration. This move is made for 2 reasons: 1. PDP registration is a transient model which means that the object could be deleted in the time. 2. PDP registration implementation was using the model (api.model) and the record (self.edi_mode) which is a bad implementation. So by moving this function on company, we ensure that we always have a record to call the function and then the function is no longer an api.model. 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#270382 Forward-Port-Of: odoo/odoo#270345
9 changes
Enhancements to existing features
This update changes the color of the 'To Review' status badge on employee records from grey to orange. This improves readability, particularly in dark mode, ensuring that HR staff can quickly identify and address employees needing review.
Original PR description
The 'To Review' status on employees uses a grey badge ('secondary'), which has poor contrast and is nearly invisible in dark mode.
Update the 'review_state' field options to change '2_to_review' to 'warning' (orange). This ensures the badge is readable in both light and dark modes.
Task: 6289919
Forward-Port-Of: odoo/enterprise#120268Resolved issues and error corrections
This update fixes a visual issue on mobile devices where an unnecessary caret appeared next to the 'Expand' button in the Inbox. It also corrected the alignment of header buttons, preventing them from wrapping onto multiple lines when the messaging menu was opened. This ensures a cleaner and more professional user experience on mobile.
Original PR description
On mobile, an unwanted caret was displayed next to the message 'Expand' button in the Inbox because the messaging menu itself opens a dropdown, causing any nested Dropdown to automatically display a caret. This commit also fixes the alignment of the Inbox header action buttons, which wrapped onto multiple lines when opening the messaging menu on mobile while the Inbox tab was already selected. In this case, the `AutoresizeInput` width was computed at its maximum size, leaving insufficient space for the header action buttons and causing them to wrap onto multiple lines. Task-[6244177](https://www.odoo.com/odoo/project/1519/tasks/6244177) Forward-Port-Of: odoo/odoo#270167 Forward-Port-Of: odoo/odoo#266343
This update enhances the stability of the French PDP registration process by moving a key function to the company record. Previously, the registration process relied on a temporary model, which could be deleted. This change ensures a reliable record is always available, improving the overall system's robustness.
Original PR description
The aim of this commit is to move _get_iap_url on res.company model instead of pdp.regitration. This move is made for 2 reasons: 1. PDP registration is a transient model which means that the object could be deleted in the time. 2. PDP registration implementation was using the model (api.model) and the record (self.edi_mode) which is a bad implementation. So by moving this function on company, we ensure that we always have a record to call the function and then the function is no longer an api.model. 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#270380 Forward-Port-Of: odoo/odoo#270345
A confusing error message related to loyalty discounts has been fixed. The update clarifies the issue for users, ensuring they understand why a discount code wasn't applied. This improves the user experience and reduces support requests related to this specific functionality.
Original PR description
Issue: Error message was ambiguous and left users wondering what was wrong. Steps to reproduce: Set a discount code where the conditional rule is set to "minimum purchase" among specified products. Then, spend an amount larger than this on unrelated products and try to apply the discount code. "A minimum of x(currency) should be purchased to get reward" Cause: Poor error message caused ambiguity Solution: Corrected the error message so that the user can better understand where the issue is. opw-6290514 Forward-Port-Of: odoo/odoo#269319
This update optimizes the MRP work order process by preventing unnecessary BoM calculations for quality points like instructions and pass/fail checks. Previously, these checks were slowing down the system, but now they're handled more efficiently, resulting in a significant performance boost. This change improves overall work order processing speed.
Original PR description
`_compute_component_ids` unconditionally called `bom.explode()` for every product variant on the BoM, even for quality point types (`instructions`, `pass_fail`, etc.) that never use the `component_id` picker. The field is only meaningful for `register_consumed_materials` and `register_byproducts`. Restrict the expensive path to those two types with an `elif` so all other types return `component_ids = False` immediately. | # Input data | Before PR | After PR | |:---:|:---:|:---:| | 10 variants, 10 components, 2 phantom BoMs, 3 ops | 841 ms | 0.1 ms | | 30 variants, 20 components, 5 phantom BoMs, 3 ops | 1,343 ms | 0.1 ms | | 80 variants, 40 components, 12 phantom BoMs, 5 ops | 8,674 ms | 0.1 ms | OPW-6210368 Forward-Port-Of: odoo/enterprise#118470
This update resolves an issue where creating payments using certain accounting sequences would trigger a technical error. The fix ensures that the system correctly handles date-only values when generating sequence numbers, preventing the traceback and ensuring payment creation functions smoothly. This improves stability and reliability for users creating payments.
Original PR description
## Issue When trying to call `dt.replace` on a `datetime.time`, a TypeError is raised ``` File "/home/odoo/Documents/src/odoo/190/odoo/addons/base/models/ir_sequence.py", line 270, in _next return…
## Issue
When trying to call `dt.replace` on a `datetime.time`, a TypeError is raised
```
File "/home/odoo/Documents/src/odoo/190/odoo/addons/base/models/ir_sequence.py", line 270, in _next
return seq_date.with_context(ir_sequence_date_range=seq_date.date_from, ir_sequence_date=dt.replace(tzinfo=None))._next()
^^^^^^^^^^^^^^^^^^^^^^^
TypeError: 'tzinfo' is an invalid keyword argument for replace()
```
## Steps to reproduce
1. Install *Accounting* (`accountant`)
2. Update the `account.payment` sequence:
- Toggle *Use subsequences per date_range* and create a range
3. In Accounting > Customers > Payments, create a payment:
- Payment Type: Receive
- Customer: Any
- Amount: Any
4. **A traceback appears**
## Cause
This error was introduced by https://github.com/odoo/odoo/commit/4b9dd7893f96.
The `AccountPayment._compute_name` method calls `_next_by_code` and passes a date as the `sequence_date`.
https://github.com/odoo/odoo/blob/337efb069f6cf2cb9478a970f075fd139c1e8e0a/addons/account/models/account_payment.py#L420-L422
In the `_next` method, the `dt` variable is set to that date (`datetime.date`), and calling the `.replace` method on that variable raises an error, as there's no tzinfo for `datetime.date`s.
opw-6303885
Forward-Port-Of: odoo/odoo#270283This update resolves an issue where UBL import failed due to a mismatch between the imported unit of measure and the product's category. The fix allows imports to proceed without error, and users can then manually adjust the UoM after the import is complete. This improves import reliability.
Original PR description
The new collected_values UBL import flow sets product_uom_id from the XML unitCode without checking that the resolved UoM category matches the matched product's UoM category. When they diverge, writing the line triggers the incompatible error. Steps to reproduce: - Create a product "XYZ" with UoM "Units" (category "Unit"). - Import a Peppol UBL bill whose line has Item/Name "XYZ" and unitCode="MTK" (uom_square_meter, "Surface"). - Import fails with: "The Unit of Measure (UoM) 'm²' you have selected for product 'XYZ', is incompatible with its category : Unit." This fix will avoid setting the product_uom_id when the UoM category doesn't match the product's UoM category, allowing the line to be imported without error. The user can then manually set the correct UoM after import. opw-6121714 Forward-Port-Of: odoo/odoo#269933 Forward-Port-Of: odoo/odoo#269714
Features or functions removed from Odoo
This update removes a redundant override related to payment processing through payment terminals. The removal of fast payments using terminals made the previous override unnecessary, streamlining the system. This change improves efficiency and reduces complexity.
Original PR description
We removed fast payments using payment terminals, making the `fastPayments` method override useless. see odoo/odoo#270240 task-6303855
This update removes a redundant, read-only column ('Extra Hours (encoded)') from the HR Attendance view. Previously, this column was introduced as a temporary fix, but it's no longer needed. This change simplifies the user interface and improves clarity.
Original PR description
The 'Extra Hours (encoded)' column was previously made read-only in a stable fix, making its presence obsolete for users in this view. This commit removes the `manual_duration` field column entirely from the view to clear interface clutter. Task: 6253553 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268873 Forward-Port-Of: odoo/odoo#266921
5 changes
Resolved issues and error corrections
This update fixes an issue where overtime details weren't correctly displayed in attendance records. The visibility condition for overtime information was reversed, preventing accurate reporting. This change ensures that overtime hours are now correctly shown when creating attendance records, providing more reliable tracking of employee time.
Original PR description
Steps: * Create an extra-hours attendance for an employee that has overtime ruleset OR * Create an extra-hours attendance for an employee that has no overtime ruleset Issue: * The overtime details in the attendance view visibility condition was flipped Solution: * Reverse the visibility condition of the XML element Task: 6295710 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#269744
A confusing error message related to loyalty discount codes has been resolved. The fix clarifies the issue for users, ensuring they understand why a discount wasn't applied when a minimum purchase requirement wasn't met. This improves the user experience and reduces potential frustration.
Original PR description
Issue: Error message was ambiguous and left users wondering what was wrong. Steps to reproduce: Set a discount code where the conditional rule is set to "minimum purchase" among specified products. Then, spend an amount larger than this on unrelated products and try to apply the discount code. "A minimum of x(currency) should be purchased to get reward" Cause: Poor error message caused ambiguity Solution: Corrected the error message so that the user can better understand where the issue is. opw-6290514 Forward-Port-Of: odoo/odoo#269319
This update simplifies accessing employee profiles from the avatar card. Previously, a confirmation dialog forced users to activate inactive companies. Now, a 'View Profile' dropdown offers two options: directly opening the employee profile (activating the company) or accessing the contact profile without company activation. This provides a smoother user experience while addressing potential concerns about broad company scope.
Original PR description
When opening a profile from the avatar card, the employee's company may not be in the user's active companies. Until now this popped a confirmation dialog that only let the user either activate the…
When opening a profile from the avatar card, the employee's company may not be in the user's active companies. Until now this popped a confirmation dialog that only let the user either activate the other company or cancel, with no way to reach the still-accessible contact profile. Replace the dialog with a less intrusive "View Profile" dropdown, shown only when the employee's company is allowed but not active. It offers two choices: - Open Employee Profile (activates the company) - Open Contact Profile (no company activation) Activating an extra company widens the active-company scope for the whole session, which is not always desirable, so keeping a non-mutating path to the contact profile is useful. In every other case (no employee, company already active, or company not allowed) the plain "View Profile" button is unchanged. task-6074597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264073
This update resolves an issue where UBL import failed due to a mismatch between the product's and imported unit of measure categories. The fix allows imports to proceed without error, and users can manually adjust the UoM after the import is complete. This improves the reliability of UBL invoice processing.
Original PR description
The new collected_values UBL import flow sets product_uom_id from the XML unitCode without checking that the resolved UoM category matches the matched product's UoM category. When they diverge, writing the line triggers the incompatible error. Steps to reproduce: - Create a product "XYZ" with UoM "Units" (category "Unit"). - Import a Peppol UBL bill whose line has Item/Name "XYZ" and unitCode="MTK" (uom_square_meter, "Surface"). - Import fails with: "The Unit of Measure (UoM) 'm²' you have selected for product 'XYZ', is incompatible with its category : Unit." This fix will avoid setting the product_uom_id when the UoM category doesn't match the product's UoM category, allowing the line to be imported without error. The user can then manually set the correct UoM after import. opw-6121714 Forward-Port-Of: odoo/odoo#269933 Forward-Port-Of: odoo/odoo#269714
This update fixes a potential instability issue with the PDP registration process. By moving a key function to the company record, we ensure the registration process remains reliable even if the temporary PDP registration model is deleted. This improves the overall robustness of the system.
Original PR description
The aim of this commit is to move _get_iap_url on res.company model instead of pdp.regitration. This move is made for 2 reasons: 1. PDP registration is a transient model which means that the object could be deleted in the time. 2. PDP registration implementation was using the model (api.model) and the record (self.edi_mode) which is a bad implementation. So by moving this function on company, we ensure that we always have a record to call the function and then the function is no longer an api.model. 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#270345
6 changes
Resolved issues and error corrections
This update ensures that text searches using the `unaccent` function in the HR recruitment module can be properly indexed in the database. Previously, the system wasn't correctly recognizing the `unaccent` function's capabilities, leading to potential performance issues with text searches. This fix guarantees optimal search performance for text-based data.
Original PR description
PostgreSQL's `unaccent` function must be marked as `IMMUTABLE` before it can be used in a functional index. The ORM usually handles this when the `unaccent` extension is missing and `odoo-bin` is…
PostgreSQL's `unaccent` function must be marked as `IMMUTABLE` before it can be used in a functional index.
The ORM usually handles this when the `unaccent` extension is missing and `odoo-bin` is started with the `--unaccent` flag during database creation.
However, it is also possible to start `odoo-bin` with an existing database where the `unaccent` extension is already installed, but the function was never marked as `IMMUTABLE`.
In that case, `unaccent` can still be used in conditions such as `WHERE` clauses, but it cannot be used in functional indexes.
`has_unaccent()` actually has three possible states:
```py
class FunctionStatus(IntEnum):
MISSING = 0 # function is not present (falsy)
PRESENT = 1 # function is present but not indexable (not immutable)
INDEXABLE = 2 # function is present and indexable (immutable)
```
Therefore, checking only `if has_unaccent()` before creating an index using `unaccent` is not enough. The index should only be created when `has_unaccent()` returns `FunctionStatus.INDEXABLE`.
task-6307060
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where fully settled customers were incorrectly prevented from generating Customer Statements. The change ensures that customers with past pay-later payments are still shown, regardless of their current outstanding balance. This improves the user experience and accuracy of reporting.
Original PR description
The override of _compute_has_moves was checking `total_due != 0` to set `has_moves` on for PoS pay_later customers. Once the customer is fully settled however, `total_due` is 0 and the check does not pass anymore, so `has_moves` goes back to `False` and the Customer Statement button hides for them, even though they had past pay_later payment lines. The fix is to check directly for any past pay_later `pos.payment` instead, which covers the cases where partner had used pay_later payment methods before, regardless if they have settled their total due or not. opw-6173760
This update corrects a problem where Google Calendar attendee information was sometimes lost when an email address matched a configured alias. The fix ensures that all attendees are correctly synchronized, preventing data loss and improving the reliability of calendar events. This resolves an internal issue (opw-6086240) that impacted event accuracy.
Original PR description
_get_sync_partner excludes partners whose email matches a configured alias, returning a list shorter than the emails/google_attendees lists. zip() stops at the shortest, silently dropping the last Google attendee instead of the alias-matched one. Fix by replacing the positional zip with a by-email dict lookup, so each attendee is resolved independently and only the unresolvable one is skipped. opw-6086240 Forward-Port-Of: odoo/odoo#263787
This update resolves an issue where UBL import failed due to a mismatch between the product's and imported unit of measure categories. The fix allows imports to proceed without error, and users can then manually adjust the UoM after the import is complete. This improves the reliability of UBL invoice imports.
Original PR description
The new collected_values UBL import flow sets product_uom_id from the XML unitCode without checking that the resolved UoM category matches the matched product's UoM category. When they diverge, writing the line triggers the incompatible error. Steps to reproduce: - Create a product "XYZ" with UoM "Units" (category "Unit"). - Import a Peppol UBL bill whose line has Item/Name "XYZ" and unitCode="MTK" (uom_square_meter, "Surface"). - Import fails with: "The Unit of Measure (UoM) 'm²' you have selected for product 'XYZ', is incompatible with its category : Unit." This fix will avoid setting the product_uom_id when the UoM category doesn't match the product's UoM category, allowing the line to be imported without error. The user can then manually set the correct UoM after import. opw-6121714 Forward-Port-Of: odoo/odoo#269933 Forward-Port-Of: odoo/odoo#269714
This update fixes a potential instability issue in the French PDP integration by moving a key function to the company record. This change addresses a previous reliance on a temporary model and a flawed implementation, ensuring the function always has a valid record to operate and improving overall system reliability.
Original PR description
The aim of this commit is to move _get_iap_url on res.company model instead of pdp.regitration. This move is made for 2 reasons: 1. PDP registration is a transient model which means that the object could be deleted in the time. 2. PDP registration implementation was using the model (api.model) and the record (self.edi_mode) which is a bad implementation. So by moving this function on company, we ensure that we always have a record to call the function and then the function is no longer an api.model. 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#270345
This update resolves an issue where sending Jordanian e-invoices would trigger a 'divide by zero' error when a line item had a quantity of zero. The fix ensures invoices with zero quantities are now processed correctly, preventing the error and allowing successful e-invoice transmission. This improves the reliability of the Jordanian e-invoicing functionality.
Original PR description
Steps to reproduce: - Ensure Jordanian e-invoicing is installed - Create an invoice where one of the lines has a 0 quantitiy - Send the e-invoice JoFotara (Jordan EDI) Current Behavior: You will get a divide by 0 error popup Expected Behavior: No error and the invoice is sent opw-6262469 Forward-Port-Of: odoo/odoo#269382 Forward-Port-Of: odoo/odoo#269341
8 changes
New functionality added to Odoo
This update enhances the company's payroll reporting for employees using eco-friendly company vehicles. It adds a new salary rule and reports contributions to the DMFA (under code 868), accurately reflecting the tax benefits associated with these vehicles. This ensures compliance and provides employees with correct financial reporting.
Original PR description
For employees benefiting from a mobility budget and using an eco-friendly company vehicle: - add a dedicated salary rule; - report the contribution amount in the DMFA under code 868; - add code 1 for eco-friendly vehicles in the list of the company cars. task-259958
This update expands the Odoo mail API to include support for 'Cc' (carbon copy) recipients. Previously, the API only supported 'To' recipients. This enhancement allows users to send emails with multiple recipients, improving email communication flexibility within Odoo.
Original PR description
We adapt the code to support "Cc" recipient in the mail API (odoo/odoo#256333). various: account_followup, ai, helpdesk, hr_contract_salary, web_studio Task-5910857
Enhancements to existing features
This update streamlines the process of managing synced calendar accounts by removing unnecessary options and simplifying the user interface. The change improves usability by focusing on the core functionality of syncing events, addressing a previous complexity that rarely benefited users.
Original PR description
The user settings contained a wizard for disconnecting a synced account. This task simplifies it, removing some of the unnecessary options. A part of the wizard relating to re-sync policies was removed - the use cases where it would be useful are minimal, and letting the user decide which events to sync and which not to could lead to inconsistencies in the events Task-5346620
This update streamlines the inventory counting process by automatically focusing on the quantity field when a user edits a product barcode. Previously, operators had to navigate through multiple steps to enter quantities, now it's reduced to just a single input. This improves efficiency and reduces wasted time during inventory operations.
Resolved issues and error corrections
This update ensures that if a warning card fails to load on the payroll dashboard, the user will see an error message instead of a traceback. Crucially, the remaining warning cards will still load and display, providing a more complete and accurate view of potential issues. This enhances the user experience and data visibility.
Original PR description
Prior to this, if loading a warning caused a traceback, the loading of the remaining warnings would be stopped and the user would only see the traceback. Now, if loading a warning card fails, the error will be shown, but the remaining cards will keep loading and be displayed as well. task-6298866
This update fixes a potential issue in the Belgian HR payroll module where the base amount for holiday pay could exceed an employee's regular wage. The change ensures that holiday pay calculations are accurately capped at the employee's standard earnings, improving payroll accuracy and compliance. This resolves a previous error that could have resulted in overpayment.
Original PR description
The base amount should never be more than the employee's wage. Forward-Port-Of: odoo/enterprise#120681
A technical issue prevented users with limited time-off permissions from accessing the Attendances Gantt View when viewing leave requests. This fix ensures that the Gantt View correctly displays leave information for all users, regardless of their specific access rights. The change involved a minor code adjustment to improve data access.
Original PR description
Version: - 19.0 Steps to reproduce: - Install Attendances and Time Off - Create an internal user. - Give the user: Attendances Officer access & No Time Off Officer/Manager rights - Create an employee…
Version: - 19.0 Steps to reproduce: - Install Attendances and Time Off - Create an internal user. - Give the user: Attendances Officer access & No Time Off Officer/Manager rights - Create an employee linked to the user. - Configure the employee with a Flexible Working Schedule. - Create and approve a Time Off request for the employee. - Open: Attendances -> Gantt View - Navigate to the month containing the employee's approved leave. Issue: - An access error is raised when opening a month that contains the employee's approved leave. Cause: - In `_handle_flexible_leave_interval`, the code accesses `leave.holiday_id` to read fields such as `request_unit_half`, `request_unit_hours`, and `request_hour_from/to` on the `hr.leave` model. - When the current user has Attendances Officer rights but no Time Off access(rare cases), the ORM access check on `hr.leave` raises an AccessError, even though this read is purely for internal calendar computation and does not expose leave data to the user interface. Fix: - Added sudo() on holiday_id to access the employee's leave details and compute the work interval as expected. Task-6264510 Forward-Port-Of: odoo/enterprise#120668 Forward-Port-Of: odoo/enterprise#119116
This update resolves a bug that occurred when sorting financial reports by account code. The issue was caused by attempting to compare numeric and string values, leading to a crash. The fix ensures correct sorting even when account codes are missing (None), improving the reliability of financial reports.
Original PR description
If you're grouping by account_code on a line using an account_code
engine, and there's a None value, it will crash.
To get that, you can (with demo data):
- install l10n_be
- set "BE Company COA" as the main, keeping "My Company (San Francisco)"
activated
- go to the profit and loss "Profit and Loss (Abbr) (BE)", set the date
as the current year
- set "Consolidation" filter
- Unfold "60/61 - Goods for Resale,..."
```
Traceback (most recent call last):
...
File "... in _compute_formula_batch_with_engine_account_codes
results_list.sort(key=lambda x: math.inf if x[0] is None else x[0])
TypeError: '<' not supported between instances of 'float' and 'str'
```
Because in case of `None`, we compare with `math.inf` but the account
codes are string.
no-task
Forward-Port-Of: odoo/enterprise#120641
Forward-Port-Of: odoo/enterprise#1205311 change
Resolved issues and error corrections
This update resolves two key issues related to attaching documents to employee records. Previously, attachments were created in the root 'Employees' folder, which was inconvenient. Additionally, creating sick leave attachments didn't always generate a document. This fix ensures attachments are correctly created in the appropriate folder and that all attachment types are properly recorded.
Original PR description
Before this commit, when adding an attachment to a leave or a employee version the mixin was configured to create the document in the root folder of Employees which was not very convenient. In addition, when creating a Sick leave with an attachment, no document was ever created. This commit fix both those bugs. Task-6095811 Forward-Port-Of: odoo/enterprise#119417 Forward-Port-Of: odoo/enterprise#112993
4 changes
Resolved issues and error corrections
This update fixes a problem where Google Calendar attendee information wasn't syncing correctly when an email address matched a configured alias. The change ensures that all Google attendees are properly synchronized, preventing missed invitations and improving event accuracy. This resolves a previous bug impacting event attendance.
Original PR description
_get_sync_partner excludes partners whose email matches a configured alias, returning a list shorter than the emails/google_attendees lists. zip() stops at the shortest, silently dropping the last Google attendee instead of the alias-matched one. Fix by replacing the positional zip with a by-email dict lookup, so each attendee is resolved independently and only the unresolvable one is skipped. opw-6086240 Forward-Port-Of: odoo/odoo#263787
This update fixes an issue where capitalized email domains in alias settings caused emails to fail to route correctly. The change prevents users from saving capitalized domain names, ensuring reliable email delivery. This resolves a technical problem that could impact email communication.
Original PR description
[FIX] mail_alias_domain: prevent capitalization in domain names to avoid email routing issues Currently, we allow capitalization in the name / display_name field for Email Domains…
[FIX] mail_alias_domain: prevent capitalization in domain names to avoid email routing issues
Currently, we allow capitalization in the name / display_name field for Email Domains (mail.alias.domain), which allows for capitalized domains in email aliases. When the system receives incoming emails via mail_thread.py's message_route,
the reply_to email addresses are sanitized (all lowercase). We then use the case-sensitive 'in' to identify
message routes, which will always fail for capitalized email domains.
This PR applies sanitizing to the name field so that users cannot save capitalized email domains.
Other options are not viable because:
1. we don't have a case-insensitive equivalent of the 'in' operator
2. altering the current logic to be case-insensitive would decrease performance
3. altering the current logic would change the structure of message_route
Fixes #opw-5401633
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where saving a job page after deleting all content from its editable HTML field (like the job description) would trigger a 'Document is empty' validation error. The fix ensures that empty HTML fields are correctly handled, preventing users from being unable to save changes. This improves the user experience and data integrity.
Original PR description
Steps to reproduce: =================== 1. Edit a job page. 2. Delete every `s_rating` block. 3. Save. => Validation Error: Document is empty. Cause: ====== Deleting the last snippet inside an…
Steps to reproduce: =================== 1. Edit a job page. 2. Delete every `s_rating` block. 3. Save. => Validation Error: Document is empty. Cause: ====== Deleting the last snippet inside an editable HTML field (e.g. the last `s_rating` block in the `website_rating` field of a job page) leaves the field's editable container with only whitespace text nodes. On save, it writes that whitespace to the record and then calls `_copy_custom_snippet_translations`, which does `html.fromstring(lang_value)` on the whitespace and raises `lxml.etree.ParserError: Document is empty`, re-raised as `ValidationError`. The user sees a "Validation Error" dialog and can't finish saving. The previous fix for the analogous "Document is empty" symptom on product description editing (commit [1]) added a `cleanupEmptyStructures` `on_removed_handlers` that strips whitespace from `.oe_empty` containers after element removal. That selector covers `oe_structure.oe_empty` containers but not editable HTML field savables (`[data-oe-type="html"]`), which don't carry an `oe_empty` class when they originally had content. As a result, fields like `hr.job.website_rating` still hit the failing parse path. Solution: ========= Extend the cleanup selector to also include `[data-oe-type="html"]` so HTML-field editables are normalized to genuinely empty after the last inner snippet is removed. [1]: https://github.com/odoo/odoo/commit/53d5cc7eed635f64038bf0315f6863011879c529 opw-6244892 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Documentation and clarification updates
This pull request formally records Adrien Didot's (Adridot) signature on the Odoo Individual Contributor License Agreement. Adding the associated documentation ensures compliance and clarifies the terms of his contributions to the Odoo project. This is a standard legal step for all individual contributors.
Original PR description
Individual Contributor License Agreement signature. Adds `doc/cla/individual/adridot.md` per the CLA signing instructions. Related contribution: #270196