Daily updates from Odoo
Tuesday, December 2, 2025
75 changes · 19.0
New functionality added to Odoo
This update introduces a new reporting feature for Irish businesses, specifically the Return of Trading Details (RTD) Report and its associated Return. This allows Irish companies to comply with local regulations and reporting requirements within Odoo, streamlining their accounting processes.
Original PR description
WIP This PR adds a new report Return of Trading Details (RTD) for Ireland and its Return. task-5184653
Enhancements to existing features
This update adds logging to the automated reconciliation process, making it easier to identify and resolve issues when it runs in a user's database. Previously, debugging this process was difficult, but these new loggers provide greater visibility into the reconciliation steps. This improves reliability and reduces potential disruptions.
Original PR description
For the moment, it's difficult to debug in users databases in the cron and the try auto reconcile. This commit will add some loggers to be more aware of what's going on. task-5358849 Forward-Port-Of: odoo/enterprise#100601
This update enhances the generation of UBL (Universal Business Language) files for key accounting formats like NLCIUS and XRechnung. By default, new, more reliable helpers are now used, ensuring accurate and compliant UBL file creation for these essential processes. This change improves the quality and reliability of our accounting data exchange.
Original PR description
Since commit 52e984037 we have enabled the new helpers by default for generating BIS3 UBLs. But we didn't enable them in the UBL formats that depend on BIS3 (NLCIUS, XRechnung, Chorus Pro etc). That was to first fix any issues in BIS3 in case the new helpers had broken something. Since the new helpers seem to be working fine for BIS3, we are now making them the default for all the formats that depend on BIS3 as well. We also add comments in the old helper methods to indicate that they are no longer used by default for BIS3 and its extensions. task-none Forward-Port-Of: odoo/odoo#237410 Forward-Port-Of: odoo/odoo#229231
This update clarifies the Peppol settings within the Odoo configuration, making it easier for users to identify the current operating mode (demo, test, or production). Previously, users lacked a visual indicator, which could lead to configuration errors. This simple label change improves usability and reduces the risk of misconfiguration.
Original PR description
Before this PR : The Peppol settings section in the settings page did not show the current mode (demo/test/prod). Users had no clear indication of the active mode, which could lead to mistakes. After this PR : A small label is now displayed in the Peppol settings section to clearly indicate the current mode when not in production. task-5149768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238039 Forward-Port-Of: odoo/odoo#236072
Resolved issues and error corrections
This update corrects a previous issue where the system incorrectly set the preferred invoice sending method based on the first 'Send & Print' action for a partner. This prevented users from easily switching to new sending methods like 'PEPPOL' without being repeatedly prompted to use email. This change ensures users have control over their sending preferences.
Original PR description
Before this commit, we were setting the preferred invoice sending method on the Contact depending on what was in the first Send & Print to this specific partner. It's a bad idea because user don't know about this setting and when they want to switch the default method (example email -> peppol) the wizard will keep propose them to send it by email only and they don't know why since they never knowingly set it to "email". task-none (feedback from AVW) Forward-Port-Of: odoo/odoo#238029 Forward-Port-Of: odoo/odoo#237956
This update resolves an issue where PayPal payments were failing due to missing country information in customer addresses. The fix ensures that a valid country code is always included in address data, preventing errors and improving payment processing reliability. It adds safeguards to handle missing address information gracefully.
Original PR description
When the address step is skipped during checkout or a partner has no country set, the PayPal address formatting would include falsey values (False/None) for country_code, which caused PayPal API requests to fail with 'Country: False' errors. This fix: 1. Adds null checks for state_id and country_code to prevent accessing attributes on missing relationships 2. Ensures only truthy values are included in the address dictionary 3. Adds fallback country code selection (company currency 'US') for public partners to guarantee a valid country code is always sent Fixes #237360 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 update corrects a bug where administrators without HR permissions could trigger an access error when attempting to create a new employee. The fix hides the 'Create Employee' button for users lacking the necessary HR rights, ensuring a smoother user experience and preventing errors.
Original PR description
**Version:** - 17.0 **Steps to reproduce:** - Make sure Marc Demo is an Administrator but has no Employees (HR) access rights. - Log in as Marc Demo. - Go to Settings → Users → Create a new user. - Enter a name and email, then Save. - You’ll see the "Create Employee" button it appears even though the user has no HR rights. - Click it → an Access Error occurs. **Isuue:** - The "Create Employee" button is visible for users who don’t have HR permissions, causing an access error when clicked. **Solution:** - Hide the "Create Employee" button for users without HR access by adding the correct group restriction. task-5212464 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#235258
This update fixes an issue where product moves after a failed repair didn't correctly reflect the selected failure location. Now, when a quality check fails during a repair, the product's destination is automatically set to the user-specified failure location, improving traceability and simplifying stock adjustments. This ensures accurate tracking of defective products.
Original PR description
Before this commit: ------------------------- - In the Repair module, when a quality check for a product was marked as failed, Even after selecting a failure location, the final product move showed…
Before this commit: ------------------------- - In the Repair module, when a quality check for a product was marked as failed, Even after selecting a failure location, the final product move showed an Incorrect destination location. - Instead of showing the selected failure location, the system displayed another location as the move destination after completing the repair process. Steps to reproduce: ------------------------- 1. Install the Repair and Quality modules. 2. In Quality, create a Control Point with: - Type = Pass-Fail - Control Per = Product - Set at least 1 Failure Location 3. Create a Repair Order for any product and start the repair process. 4. Perform a quality check, set it to Fail, and select a failure location. 5. Open the product moves, the destination location is incorrect (not the selected failure location). Cause of the issue ------------------------- The failure location was not correctly assigned when the quality check failed during the repair process because the logic relied on stock pickings to determine the destination location. However, in repairs, quality checks are performed independently of stock pickings. After this commit: ----------------------- - When a quality check fails in a repair order, the product’s destination location is correctly set to the failure location selected by the user. - This ensures accurate traceability of failed products and simplifies stock adjustments across locations. Task ID: 5254334
This update fixes an issue where styles (color, size) applied to text within a document weren't consistently reflected on list markers. Now, when converting text with multiple styles to a list, the list markers will always display the intended styles, improving the formatting of lists.
Original PR description
**Current behavior before PR:** - When applying a color or size style to the entire text and then converting it into a list, the style was reflected on the list marker. - However, if multiple styles (e.g., both color and size, or color and bold) were applied, only one style or sometimes none was reflected on the marker. **Desired behavior after PR is merged:** - When text with color, size, or both styles is converted into a list, The list markers now consistently reflect those styles. task-5097649 Forward-Port-Of: odoo/odoo#234296 Forward-Port-Of: odoo/odoo#227813
This update fixes an issue where the invoice date was unexpectedly changing after a company partner's address was modified. The fix prevents the invoice date from being recalculated when the invoice is in the 'posted' state, ensuring accurate invoice dates. This improves data consistency and reduces potential errors in financial reporting.
Original PR description
**Steps to reproduce** 1.Install Accounting, Contacts, and l10n_cz. 2.Create an invoice with a future `invoice date` and confirm it. 3.Go to Contacts → open the company (res.partner). 4.Modify any…
**Steps to reproduce** 1.Install Accounting, Contacts, and l10n_cz. 2.Create an invoice with a future `invoice date` and confirm it. 3.Go to Contacts → open the company (res.partner). 4.Modify any address field (street, zip, etc.) and save. 5.Return to the invoice → in the chatter, the `date` field has change unexpectedly > Note: The `date` field is not shown in invoice default form view. Add it manually for clearer reproduction. **Issue** - The confirmed invoice `date` changes when updating the company partner’s address. **Cause** https://github.com/odoo/odoo/blob/7a1b27e5985b3b16768bea450c51226ae3659c76/addons/l10n_cz/models/account_move.py#L20-L24 - When creating an invoice, the `date` field is correctly set based on the `taxable_supply_date` while the invoice is in the draft state. After confirming (posting) the invoice, it moves to the `posted` state. - However, when updating the partner address, the `_compute_date` method is triggered again, which calls `super()` and recomputes the `date` field using the standard logic. Since the invoice is already in the `posted` state, the CZ-specific condition is not satisfied, and the `date` gets updated incorrectly. **Solution** - Update `_compute_date` to only call super() for invoices in draft state. - This prevents unwanted recomputation of the `date` on post invoices. opw - 5086961 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238045 Forward-Port-Of: odoo/odoo#229513
This update resolves an error that prevented payslips from being printed for employees who didn't have a contract assigned. The fix ensures that a contract is required to generate a payslip, preventing template errors. This improves the reliability of payroll reporting.
Original PR description
An error occurs while printing a payslip for an employee who does not have a contract. Steps to reproduce the error: - Install the ``hr_payroll`` module - Create an employee without contract - Create a payslip for that employee > Compute Sheet > Print Traceback: ``` Error while rendering the template: TypeError: '<' not supported between instances of 'datetime.date' and 'bool' ``` https://github.com/odoo/enterprise/blob/368a81a277b2fa7c5eac7c63addd0d75ec89111b/hr_payroll/views/report_payslip_templates.xml#L70 Here, ``version_id.contract_date_start`` will be ``False`` when the employee does not have a contract, which leads to the above traceback. Solution: User can not print payslip without running contract. sentry-6922017511
This update addresses a minor timing issue that was causing automated tests for the Point of Sale (POS) module to occasionally fail. The fix ensures that key order acceptance timestamps are correctly verified, improving the reliability of our automated testing process. This resolves a specific runbot error and contributes to overall system stability.
Original PR description
in this commit: - Fixed the `_acceptOrder, _dispatchOrder, _completeOrder` test, which could fail due to minor timing delays. - Updated the assertion to only verify that `orderAcceptTime` is not empty. runbot-error-234594 Forward-Port-Of: odoo/enterprise#100942
This update allows HR staff to link portal users directly to employee records within Odoo. Previously, it was difficult to associate these users, now the system displays all portal users in the employee selection field and defaults to showing internal users in search views. This improves data accuracy and simplifies employee management.
Original PR description
- Display all portal users in the user field. - Set the default filter in the search view to show internal users. - Change the placeholder text for the `user_id`. task-5176046 Forward-Port-Of: odoo/odoo#237564
This update fixes a minor bug where closing the `/article` dialog in the Knowledge editor would cause the page to jump to the top. The fix ensures the correct element focus is maintained during dialog closure, preventing this disruptive scroll behavior. This improves the user experience when editing long articles.
Original PR description
Problem: When editing a long Knowledge article and executing the `/article` command, closing the dialog automatically scrolls the page to the top. Cause: This happens because `useActiveElement` inside the `Dialog` component runs its cleanup function when the dialog unmounts. While unmounting, `document.activeElement` is `body`, so the cleanup tries to focus back the `oldActiveElement`, which is the `editable`, and this resets the selection and causes the scroll jump. Solution: Set the selection when closing the dialog, ensuring the `editable` remains the `document.activeElement` during cleanup, preventing the focus reset. Steps to reproduce: - Edit a long article further down the page. - Use the `/article` command. - Dismiss the dialog. → The page scrolls back to the top. opw-4797567 Forward-Port-Of: odoo/enterprise#100634
This update fixes an issue where RPC failures were incorrectly handled by the system's caching mechanism. Previously, a failed RPC would resolve with 'undefined' instead of properly rejecting the promise. This change ensures that RPC failures are correctly caught and handled, preventing unexpected behavior and improving the stability of the system.
Original PR description
Let's say we trigger two times a RPC that fails. The first time, the cache is empty and we make the RPC. The ram cache is filled with `prom`. The second time, we get `prom` from the ram cache. When…
Let's say we trigger two times a RPC that fails.
The first time, the cache is empty and we make the RPC. The ram cache is filled with `prom`.
The second time, we get `prom` from the ram cache.
When the RPC actually finishes, we end up in
```js
.catch((error) => {
this.ramCache.delete(table, key);
def.reject(error);
});
```
=> the RPC failure is catched, which means `prom` itself is not rejected. Instead, it resolves with the result of `.catch(...)`, which is `undefined`
Here is a simplified toy example:
```js
const prom = Promise.resolve(
Promise.reject(new Error("fetch failed")).catch(() => {})
);
```
In this example, `prom` is successful and the result is `undefined`
"
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#238185
Forward-Port-Of: odoo/odoo#237984This update resolves an issue where duplicating an approver within an approval request caused a system error. The fix prevents the same user from being linked to multiple approvers, eliminating the traceback and ensuring approval requests can be properly processed. This improves stability and prevents disruptions to the approval workflow.
Original PR description
When User duplicates the approver for any approval request and tries to open that approval request, A traceback will appear. Steps to reproduce the error: - Activate the developer mode - Go to Approvals > Create a new approval request > add any approver > Save - Click on the ``View`` button in the approver line - Now, In the Form view > Actions > Duplicate - Go back to that approval request through breadcrumbs Traceback: ``` ValueError: Expected singleton: approval.approver(1, 3) ``` https://github.com/odoo/enterprise/blob/83b6c0e1c052b08bd23c5e009773b5a3148ddeec/approvals/models/approval_request.py#L270 When the customer duplicates the approver, ``user_id`` will be also duplicated. So, Now Same User is linked with multiple approver. So, It will lead to the above traceback. sentry-6642840799 Forward-Port-Of: odoo/enterprise#100979 Forward-Port-Of: odoo/enterprise#87164
This update resolves a crash that occurred when generating inventory valuation reports in Arabic. The issue stemmed from the system incorrectly interpreting date formats, specifically Eastern Arabic numerals. The fix ensures dates are consistently formatted as 'YYYY-MM-DD' (ASCII ISO), preventing errors and improving report reliability.
Original PR description
Steps:
- Switch UI language to Arabic.
- Accounting ▸ Review ▸ Inventory Valuation.
Before this commit:
- Crash during RPC with: ValueError: time data '٢٠٢٥-١٠-٢١' does not match format '%Y-%m-%d' (from stock_account.stock.valuation.report._get_report_data)
Cause:
- The client sent the date string with Eastern Arabic digits. Python’s strptime('%Y-%m-%d') only accepts ASCII digits.
with this commit:
When building kwargs for `get_report_values`, serialize the date with `toISODate()` (ASCII `YYYY-MM-DD`).
Replace localized formatting (`toFormat('yyyy-MM-dd')` with `toISODate()` at the call site. This is locale-independent and avoids TZ side effects for pure dates. Keeps existing behavior for empty date (send `false`).
opw-5146684
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis pull request updates the core odoo spreadsheet component to the latest version (19.0.12). It addresses several minor bugs and performance improvements related to chart rendering, data handling, and user interface elements, ensuring a smoother and more reliable spreadsheet experience. These changes enhance stability and usability for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/32203f1f8 [REL] 19.0.12 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/32203f1f8 [REL] 19.0.12 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/6fde54cb8 [FIX] chart: don't crash treemap without visible data [Task: 5365419](https://www.odoo.com/odoo/2328/tasks/5365419) https://github.com/odoo/o-spreadsheet/commit/291608938 [FIX] charts: small zoom is disabled [Task: 5058567](https://www.odoo.com/odoo/2328/tasks/5058567) https://github.com/odoo/o-spreadsheet/commit/b0c2d6628 [FIX] clickable cells: prevent overlap with grid icons [Task: 4930803](https://www.odoo.com/odoo/2328/tasks/4930803) https://github.com/odoo/o-spreadsheet/commit/45725c976 [FIX] Migration: Fix chart migration after 18.5.1 [Task: 5365954](https://www.odoo.com/odoo/2328/tasks/5365954) https://github.com/odoo/o-spreadsheet/commit/e63f36f52 [FIX] pivot: Ensure computed measure range adaptation [Task: 5358213](https://www.odoo.com/odoo/2328/tasks/5358213) https://github.com/odoo/o-spreadsheet/commit/34d4c6420 [FIX] commands: remove duplicate in invalidateEvaluationCommands [Task: 5358213](https://www.odoo.com/odoo/2328/tasks/5358213) https://github.com/odoo/o-spreadsheet/commit/b58dae95a [FIX] Charts: Ensure Chart js extension are loaded on chart creation [Task: 5214007](https://www.odoo.com/odoo/2328/tasks/5214007) https://github.com/odoo/o-spreadsheet/commit/99a94ac04 [FIX] topbar: close font size dropdown and keep focus on the grid [Task: 5263792](https://www.odoo.com/odoo/2328/tasks/5263792) https://github.com/odoo/o-spreadsheet/commit/666c6de18 [FIX] figures: fix non-deterministic figure order export [Task: 5092281](https://www.odoo.com/odoo/2328/tasks/5092281) https://github.com/odoo/o-spreadsheet/commit/7578897a4 [FIX] Demo: Fix wrapper style [Task: 5212448](https://www.odoo.com/odoo/2328/tasks/5212448) https://github.com/odoo/o-spreadsheet/commit/641d1923a [FIX] composer: keep edition mode inactive on cursor selection change [Task: 5354541](https://www.odoo.com/odoo/2328/tasks/5354541) https://github.com/odoo/o-spreadsheet/commit/c5c03e189 [FIX] BottomBarSheet: sheet name should update on foreign changes [Task: 5016252](https://www.odoo.com/odoo/2328/tasks/5016252) https://github.com/odoo/o-spreadsheet/commit/d4b38dc53 [FIX] Composer: Fix assistant position [Task: 5155838](https://www.odoo.com/odoo/2328/tasks/5155838) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update fixes an issue where Brazilian vendor bills incorrectly applied sales taxes instead of purchase taxes (like COFINS) due to a flaw in the tax selection process. The fix ensures that the correct tax type is used when calculating taxes for vendor bills within the Brazilian localization, improving financial accuracy.
Original PR description
**Steps to reproduce:** - Install accountant, l10n_br and l10n_br_avatax - Switch to a Brazilian company - In Accounting settings, configure AvaTax (require credentials) - Create a bill - Compute taxes with AvaTax **Issue:** If a tax like "COFINS Incl." should be added, the Sales tax is added instead of the Purchases one, resulting in an incorrect account for the tax line. **Cause:** Brazilian localization allows to use AvaTax for vendor bills, but the external tax feature doesn't take into account the type of the tax when searching for one. It just returns the first one based on the name, the amount and some other domains. **Solution:** Add the tax type in the domain when searching a Brazilian tax. **PR (Community):** https://github.com/odoo/odoo/pull/236930 opw-5044423 Forward-Port-Of: odoo/enterprise#100340
This update resolves an issue where the PEPPOL data neutralization script wouldn't function correctly if a required key was missing. The change ensures the script automatically inserts the key when it's not present, guaranteeing proper data processing for PEPPOL transactions. This improves the reliability of our PEPPOL integration.
Original PR description
There can be some siutations where you can not have the key account_peppol.edi.mode while having a connection. But the neutralize only updates and so, if the key is not present, it does nothing. So change it to insert the key if no present --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238184
This update resolves a technical error that was preventing proper payroll calculations within the Odoo Enterprise system. The fix involved correcting a dependency issue related to a configuration field, ensuring accurate salary processing for Belgian employees. This change improves the reliability of payroll reporting.
Original PR description
…act_salary A runbot build error was reported for one of my tests: https://runbot.odoo.com/odoo/runbot.build.error/233591 The issue was because the field `hide_in_offer` was used in a module where it did not exist. I have overridden the function to make it call the field when it was installed, and moved the logic using it to that inheriting function. task-5350522 Forward-Port-Of: odoo/enterprise#100190
This update resolves a technical issue related to the Swiss payroll module (l10n_ch_hr_payroll) by adding missing input types. These input types are crucial for accurately reflecting Swiss tax and social security regulations, ensuring the payroll calculations align with legal requirements. This fix improves the accuracy and compliance of the payroll processing for Swiss businesses.
Original PR description
Forward-Port-Of: odoo/enterprise#100992
This update fixes a critical issue where purchase taxes for Brazilian accounting were missing from the Odoo system. The changes also correct the tax tags for accurate reporting and compliance with Brazilian tax regulations. This ensures accurate financial reporting for businesses operating in Brazil.
Original PR description
**Issue:** Many purchase taxes for Brazilian localization were missing. Also some taxes have an incorrect tax tag. **PR (Enterprise)**: https://github.com/odoo/enterprise/pull/100340 opw-5044423 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236930
This update resolves a technical error that prevented the generation of payroll export files. The fix utilizes the employee's display name instead of the name field, ensuring consistent export functionality. A new test suite has been implemented to guarantee the accuracy of the Acereta payroll export process.
Original PR description
When generating the export file, a traceback occurred because the name field was empty. The logic has been updated to use the display_name field instead, ensuring the export runs correctly, as it is always set to a value. However, the display_name sometimes is just a date, so I depended on a customizable new lable to show the employee to this version. Additionally, a comprehensive test suite was added to validate Acereta code behavior, including: - validation of code length for employees, companies, and work entry types, - handling of codes across different companies, - and the complete Acereta export flow (from work entry creation and validation to export file generation). task-5153727 Forward-Port-Of: odoo/enterprise#96823
This update fixes a technical error that prevented users from accessing the date filter within mail group settings. The issue stemmed from a formatting mistake in the code, which was corrected to ensure the date filter functions correctly. This ensures all users can effectively manage their mail groups.
Original PR description
Steps to reproduce =================== 1. Open any mail group on the website side. 2. Try to access the date filter. Here https://github.com/odoo/odoo/pull/206575/commits/99ece288df1bbb98fd538479b07da14f3abf0d03, we missed wrapping the tuple in the `Domain` class. Task-5369008 Forward-Port-Of: odoo/odoo#238076
This update resolves an issue where the system was incorrectly creating multiple bank accounts from UBL invoices. The fix filters out duplicate account numbers, ensuring accurate bank information is imported into the system. This prevents potential data inconsistencies and improves the reliability of financial transactions.
Original PR description
Currently `_import_retrieve_and_fill_partner_bank_details` may try to to create multiple res partner bank with the same account. This can i.e. happen in case there are multiple `cac:PaymenMeans` nodes in the XML. After this commit we filter out duplicate bank accounts numbers. opw-5149621 Forward-Port-Of: odoo/odoo#238139 Forward-Port-Of: odoo/odoo#236676
This update corrects a bug that prevented users from mentioning colleagues in different companies within Odoo's chat functionality. The issue stemmed from a missing security check, leading to access errors. Adding a necessary security layer now allows users to correctly mention colleagues regardless of their company affiliation.
Original PR description
Steps to reproduce: 1. Create a portal user in the current company 2. Create a new company and switch to it. 3. In the Chatter of any record, mention the portal user from the previous company. Issue: - An AccessError is raised when mentioning a user belonging to another company. Cause: - The missing forward port of this commit https://github.com/odoo/odoo/commit/b1133f6a1efaef1d62f32f7f0197f2d8eb0cb191 was not merged, which caused the user to access res.users records without sudo() from version saas-18.4. Since the mentioned user belongs to a different company, the current user lacks the necessary read permissions, triggering the error. https://github.com/odoo/odoo/blob/6c35edb9dabaf8ce0b276ca26459401ac43d10e4/addons/mail/models/res_partner.py#L267 Solution: - Add sudo() to access the user. opw-5105598 Forward-Port-Of: odoo/odoo#230215
This update resolves an issue where test emails using 'view_online' would fail if the contact associated with the email was deleted. The fix ensures the system now retrieves the first contact ID, preventing errors and improving the reliability of test email generation. This ensures emails are sent correctly even after contact deletions.
Original PR description
In the email marketing, when you add "view_online" and dynamic placeholder "object.name", and try doing a test email, it creates a url token for the "view online" with the res_id as the user's id which grabs the record from the mailing_contact with that res_id. So, in case the mailing_contact with the res_id is deleted, the "view_online" gives you error saying record with id "res_id" cannot be find. Our fix is to search the mailing_contact and grab the id of the first record. This fix updates the code from this commit: [8a9981e](https://github.com/odoo/odoo/commit/8a9981e78a438ceb53a4fdc0445ebed2170c6624) opw-5049654 Forward-Port-Of: odoo/odoo#232440
This update resolves an issue where employee profile pictures were misaligned on mobile devices. The fix ensures that employee avatars display correctly, providing a consistent and professional user experience for mobile users. This improves the visual quality of the HR module.
Original PR description
The employee form view displayed misaligned avatar images on mobile screens. task-5241292 Forward-Port-Of: odoo/odoo#234537
A technical error preventing edits to the 'Document: Document Share' email template has been resolved. This issue stemmed from a recent update to the template structure, causing a syntax error. The fix ensures users can now successfully modify and save this important email template.
Original PR description
**Steps to reproduce:** 1. Install `document` and `contact` 2. Go to Settings > Technical > Email Templates 3. Search for the 'Document: Document Share' template 4. Try to edit and save it **Issue:** - Traceback occurs: `SyntaxError: t-elif directive must be preceded by t-if or t-elif directive` **Cause:** - A revamp introduced by commit: https://github.com/odoo/enterprise/commit/22446368503fadc0e0bf459dd3c8ab8b8f6624b0 Introduced an invalid template structure **Solution:** - Refactor the template to ensure valid QWeb directive order opw-5143730
This update corrects a potential issue where delivery IoT reports could be generated without verifying the existence of the associated IoT device. This prevents errors and ensures reports are only created when valid device data is available, improving report reliability. The change focuses on a critical check within the delivery IoT module.
Original PR description
As `delivery_iot.ir_action_report` is overriding `iot.ir_action_report` and bypassing the IoT device record existance check, we need to also check in delivery IoT.
This update resolves a bug that prevented users from creating replenishment orders when using the 'Buy' route in the purchase module. The fix corrects an error related to date handling during orderpoint calculations, ensuring the 'Buy' route now functions correctly. This improves the reliability of replenishment processes.
Original PR description
Currently, an error is produced when creating a new replenishment record for using the **Buy** route. **Steps to Reproduce:** 1. Install `purchase_stock` module with demo data. 2. Inventory > Operations > Replenishment. 3. Make **Route** field visible in the list. 3. Click **New**, and select the **"Buy"** in Route. **Error:** `TypeError - combine() argument 1 must be datetime.date, not bool` **Cause:** The method `_get_orderpoint_procurement_date()` expects a valid lead horizon date but receives a boolean value when the product is not set. This leads to a traceback during the computation. **Fix:** The commit handles the replenishment computation when a product is not defined. As a result, creating a replenishment with the "Buy" route works correctly even when the product is not defined. sentry-6928858334
This update resolves an error that prevented users from accessing the Time Off overview in the Gantt view when an employee lacked a defined working schedule. The fix skips unnecessary calculations when a working schedule is missing, ensuring the feature functions correctly for all employees. This improves the user experience and prevents data access issues.
Original PR description
Currently, an error occurs when an employee has no working schedule set and the user tries to open the Time Off overview in the Gantt view. **Steps to Reproduce:** 1. Install `hr_holidays_gantt` with demo data. 2. Remove the **Working Hours**(Payroll section) of **Marc Demo**. 3. Navigate to: Time off > Overview. **Error:** `AttributeError - 'bool' object has no attribute 'upper'` **Cause:** The error occurs because at [1], the contract does not have a `resource_calendar_id` (working schedule) assigned. As a result, it attempts to access attributes of a False value, causing the error. **Fix:** This commit skips the computation when the contract does not have a working schedule set. [1] - https://github.com/odoo/enterprise/blob/db049f42ad4c2c291b2d64a9e637cd2292c280e8/hr_holidays_gantt/models/hr_leave.py#L204 sentry-7017326141 Forward-Port-Of: odoo/enterprise#100730
This update resolves an issue where the mobile website preview's scrollbar appeared incorrectly during page transitions. The fix ensures the entire website document is copied to the fallback iframe, eliminating visual inconsistencies and improving the overall mobile browsing experience. This addresses a minor aesthetic problem that could potentially impact user perception.
Original PR description
### [FIX] website: copy the whole document to fallback iframe Since da85d7f8f39f43bd21603b40f357dfc572036d27, the style in head and the body of the website preview are copied to the fallback iframe's…
### [FIX] website: copy the whole document to fallback iframe Since da85d7f8f39f43bd21603b40f357dfc572036d27, the style in head and the body of the website preview are copied to the fallback iframe's document. This did not copied the attributes on the `html` node, which somtimes impacted the appearance. With this commit, the whole document is copied to the fallback iframe. Steps to reproduce: - Activate "Mobile preview" when viewing the website - Go to a page that is long enough for a scrollbar to appear - Navigate to another page - Bug: During the transition, the fallback is shown, and its scrollbar is wider than the one of the page that was shown just before task-5212287 ### [FIX] website: remove content of fallback iframe after load Since commit 7b19831e1c624b483008feb526ba773ec8b23009, an fallback iframe is shown behind the website preview to avoid flicker on navigation. Since commit 3036c7dc4720a88f2717b96a29d45d923eb6ec75, the preview for mobile has some transparency on its scrollbar. Thus the part of the fallback iframe behind the scrollbar when previewing mobile was slightly visible. This commit fixes it by removing the fallback iframe's content after the website has loaded (and the fallback is not needed anymore). Steps to reproduce: - On website, activate "Mobile preview" - Navigate to a page long enough to have a scrollbar - Navigate to another page long enough to have a scrollbar - Scroll a bit - Bug: The scrollbar of the fallback is slightly visible task-5212287 Forward-Port-Of: odoo/odoo#237810 Forward-Port-Of: odoo/odoo#233373
This update resolves an issue where links to individual tasks within the 'My Tasks' feature were broken. The fix adds a necessary field to the action definition, restoring functionality. A new test has also been implemented to prevent similar problems in the future.
Original PR description
after https://github.com/odoo/odoo/commit/bc6b363f556104e86a635325690a8061a9e9ff91 all `/my-tasks/<task-id>` links are broken because of missing path field in the corresponding action. this commit should fix the issue and add a test to avoid regression. opw-5342898 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds a 'Documents' section to the employee record form, allowing users to easily manage and view associated documents. Previously, these document fields were missing, creating a gap in the employee information available within the system. This enhancement improves record completeness and facilitates better document tracking.
Original PR description
- These fields were not available in the employee form view. - create a new section named 'Documents' under the Personal Tab in employee form view - added the fields in the employee form view task-5366982 Forward-Port-Of: odoo/enterprise#100869
This update fixes an issue where adding shifts to existing rental orders didn't correctly update the order line and total price. The fix ensures that new shifts are properly added to the order, reflecting the increased quantity and total cost. This improves the accuracy of rental order management.
Original PR description
**steps to reproduce:** - Configure a booking product as service and rental. - Confirm a shift to create a rental order. - Activate sync on the role. - Add a new shift with the same product using "Add to last order". - Open the rental order: the order line and total price are not updated. **issue:** The price and the order line were not updated when a new shift was added to the last order. **cause:** Previously, adding a new shift to a rental order did not add the order line on the corresponding order. becacuse we was not checking the state of the order and at line creation line will be created for confirmed order only. **fix:** A check is added when the getting the rental order it should be confirmed. task-5093190 Forward-Port-Of: odoo/enterprise#95314
This update fixes a bug that occurred when creating new product templates. Previously, the system incorrectly set the template's launch date, leading to errors. This change ensures the launch date is calculated accurately from the start, preventing these issues and improving data consistency.
Original PR description
If _compute_write_date is launched when creating a product.product without starting from an existing product.template, the compute may be launched before the product.template is created, hence record.product_tmpl_id.write_date is False, and comparing datetime and bool leads to an error. This completes the fix proposed https://github.com/odoo/odoo/pull/138177 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237756 Forward-Port-Of: odoo/odoo#237523
This update fixes a technical issue related to how error messages are displayed in stock order processing. Previously, the system was generating potentially infinite activity. This change ensures that error messages are handled correctly and efficiently, preventing unnecessary processes. It also improves performance by limiting the scope of searches.
Original PR description
From saas-18.2 and later, html fields has been changed the old behaviour.
Ex.
```python
model.create({'note': 'test'}) -> <p>test</p>
```
Old behaviour:
```python
model.search_count([('note', '=', 'test')]) -> 1
```
New behaviour:
```python
model.search_count([('note', '=', 'test')]) -> 0
```
To follow the new behaviour and not generate infinite activities, we need to add html elements to the error message.
Additional, we improved the performance (better to count and limit vs see all the whole table).
OPW-5266061
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#237977This update fixes a problem where website theme colors weren't consistently reflected in the highlight color picker. By using CSS variables instead of direct copying, the system now automatically keeps theme colors synchronized, ensuring a consistent brand experience across the website. This improves visual accuracy and reduces potential design inconsistencies.
Original PR description
Before this commit: 1. The colors in the _highlight_ color picker were not properly synchronized with the _theme_ colors. 2. The _theme_ colors were copied as raw values instead of using _CSS_ variables, which caused them to fall out of sync. After this commit: 1. The _solid_ tab theme colors of _highlight_ color picker now stay in sync with _theme_ colors, even when they are updated. It is achieved by setting `cssVarColorPrefix` variable to "**hb-cp-**". 2. Used CSS variables `var(--o-color-x)` instead of copying _theme_ color values. task-5079081 Forward-Port-Of: odoo/odoo#228123
This update fixes a bug where error messages weren't being properly handled during retry attempts, leading to build failures. The change ensures that traceback errors, previously logged as messages, are now correctly processed, and also addresses an OSError related to websocket handling when a browser disconnects. This improves overall system stability and reliability.
Original PR description
The auto-retry is supposed to catch error logs as well as tracebacks. In some cases a traceback is logged as a message, and not as a logger arg, bypassing the replace already in place. This pr simply replaces the traceback string in the message as well. Build error [234619](https://runbot.odoo.com/odoo/runbot.build.error/234619) Also fixes OSError while handling request paused Build error [229906](https://runbot.odoo.com/odoo/runbot.build.error/229906) Forward-Port-Of: odoo/odoo#238133
This update fixes a previous issue where document fields were missing from the employee record view. A new 'Documents' section has been added to the Personal tab, allowing HR staff to easily manage and access employee documents within the system. This improves data organization and streamlines document access for employee records.
Original PR description
- These fields were not available in the employee form view. - create a new section named 'Documents' under the Personal Tab in employee form view - added the fields in the employee form view task-5366982 Forward-Port-Of: odoo/odoo#237954
This update resolves a technical issue preventing PayPal checkout from functioning correctly when address information is incomplete. The fix ensures that valid country codes are always included in API requests, preventing errors and improving the reliability of the PayPal payment process. It adds safeguards to handle missing address details and provides a default country code for public partners.
Original PR description
When the address step is skipped during checkout or a partner has no country set, the PayPal address formatting would include falsey values (False/None) for country_code, which caused PayPal API…
When the address step is skipped during checkout or a partner has no country set, the PayPal address formatting would include falsey values (False/None) for country_code, which caused PayPal API requests to fail with 'Country: False' errors. This fix: 1. Adds null checks for state_id and country_code to prevent accessing attributes on missing relationships 2. Ensures only truthy values are included in the address dictionary 3. Adds fallback country code selection (company currency 'US') for public partners to guarantee a valid country code is always sent Fixes #237360 Description of the issue/feature this PR addresses: When checking for missing country codes during PayPal checkout, the system would include falsey values (False/None) in the address dictionary, causing API validation errors. Current behavior before PR: PayPal API requests fail with 'Country: False' or similar errors when address country or state information is missing or the address step is skipped during checkout. Desired behavior after PR is merged: The PayPal address formatter should gracefully handle missing address information by filtering out falsey values and providing fallback country codes, ensuring all API requests have valid address data. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update automatically verifies the PEPPOL status of partners when invoices are generated from the e-commerce website with automatic invoicing enabled. This ensures consistent and accurate PEPPOL status information, preventing potential issues with batch invoice submissions and improving user experience.
Original PR description
### PURPOSE
- While an order is created from the e-commerce website and The automatic invoice is on.
- The people status of the newly created partner is not verified in invoices.
- This may lead to inconsistent user behavior if users want to send invoices in a batch to peppol.
### SPECIFICATION
- Added the functionality that if
- Invoice is generated from the eCommerce
- Automatic invoice is enabled.
- than auto-verify the peppol status of the partner.
task-5025176This change removes the 'dam' registerer from the VoIP master configuration. This simplifies the VoIP setup and avoids potential conflicts, ensuring a cleaner and more reliable system. It's a technical update focused on improving VoIP stability.
This update resolves an issue where users with 'holiday responsible' permissions couldn't create multi-leave requests for employees. The fix ensures these users have the necessary access to read employee data, preventing access right errors. New tests have been added to verify this functionality across various scenarios.
Original PR description
purpose: fix the issue when a user who is `hr_holiday_responsible` creates a multi timeoff request, where an access right error appears because they don't have access on Employee. Steps to reproduce:…
purpose: fix the issue when a user who is `hr_holiday_responsible` creates a multi timeoff request, where an access right error appears because they don't have access on Employee. Steps to reproduce: - login as someone who has `group_hr_holidays_responsible` - create group leaves for employees you are responsible for - create conflicting leaves - you get access right error because you can't read field `private_name` Current behavior: - fixed access right error on creating group leaves for `group_hr_holidays_responsible` - added `test_create_conflicting_group_leave_without_hr_right` for creating conflicting group leave with `group_hr_holidays_responsible` access right - added `test_create_group_leave_form_allocation_mode_without_hr_right` for creating group leave directly from allocation mode (without choosing specific employees) with `group_hr_holidays_responsible` access right - added `test_create_differnt_calendars_group_leave_without_hr_right` for creating group leaves for employees with different calendars with `group_hr_holidays_responsible` access right task-id: 5051859 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical problem preventing users from accessing sales commission achievement reports. Previously, a temporary database view was inaccessible to other sessions, causing errors. Now, the system verifies the view's availability before attempting to retrieve report data, ensuring reliable access for all users.
Original PR description
In the commission module, the achievements are computed with a temporary SQL view. These view have limited visibility inside a SQL session. Before this commit, we checked the existence of a temporary view with the following SQL request: SELECT viewname FROM pg_catalog.pg_views WHERE viewname='sale_commission_achievement_report_view' This simple query would return the existence of the view but not its availability in the current session. As a result, when the user tried to access the report values, SELECT * FROM sale_commission_achievement_report_view would result in an error as the temporary view would not be available in all the running sessions. Only the one which created the temporary view would be able to access the data. After this commit, the existence and the availability of the view is checked to make sure that it is possible to fetch the results in the current session. task-5378382
This update resolves a potential issue where the RPCCache database could grow excessively, leading to errors and performance problems. The fix automatically clears the database when a 'QuotaExceededError' occurs, preventing Odoo from consuming excessive disk space. This ensures a stable and efficient web client experience.
Original PR description
Writing in indexeddb can throw a QuotaExceededError (or a DOMError with QuotaExceededError message in firefox). Before this commit, this error was basically ignored, so it wasn't shown to the user,…
Writing in indexeddb can throw a QuotaExceededError (or a DOMError with QuotaExceededError message in firefox). Before this commit, this error was basically ignored, so it wasn't shown to the user, but from that point, all writes in idb would fail with that same error, until a database schema change or an hard reload. This commit handles the error quite radically: when it is thrown, we delete the rpc database to start over. More elaborated strategies could be considered, like removing oldest entries, but we decided to go for the simplest solution. In master, we may introduce a more complex garbage collect strategy as for the offline mode, it might be interesting to keep some entries alive. In 19.0 though, the caches are only used to speed up the webclient, so it's not an issue to clear them completely and start over. We also want to avoid Odoo to use an unreasonable disk space. However, the storage capacity depends on the browser (e.g. 10Gb on firefox, up to 60% of disk space on chrome). To prevent Odoo from taking tens or hundreds of gigabytes on the user's disks, we limit the storage to 2Gb. Task~5217456 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 update resolves an issue where badges in the Odoo Community sidebar were appearing cropped. The change adjusts the badge's sizing to ensure they display correctly, improving the overall user experience. This ensures consistent and accurate representation of key information.
Original PR description
In community, the badges in the sidebar looked cropped. By replacing the fixed `min-width` value with the corresponding variable, the badges' shape is fixed. | Before | After | | ------------- | ------------- | | <img width="296" height="901" alt="Screenshot 2025-11-20 at 16 50 23" src="https://github.com/user-attachments/assets/5dba05a2-5a0e-4563-a555-de72e607abf6" /> | <img width="296" height="901" alt="Screenshot 2025-11-20 at 16 50 08" src="https://github.com/user-attachments/assets/28c49c5a-57e9-49cb-ba9d-c65e2f8976a0" /> | task-5223774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where users were encountering errors when creating filters in spreadsheets with broken data sources. The fix extends a previous safeguard to all filter types, allowing users to safely manage and delete invalid data sources across charts, lists, and pivots, improving spreadsheet usability.
Original PR description
Forward-Port-Of: odoo/enterprise#100887 Forward-Port-Of: odoo/enterprise#98448
This update fixes a rare error that prevented test requests from completing successfully. The fix ensures the system reliably acquires a necessary lock, preventing failures in the background request processing. This improves the stability and reliability of our core functionality.
Original PR description
In some rare cases the late_request_thread could execute so fast without releasing the GIL that assertCanOpenTestCursor was executed before the main_lock.acquire(), causing the lock to be None. In…
In some rare cases the late_request_thread could execute so fast without releasing the GIL that assertCanOpenTestCursor was executed before the main_lock.acquire(), causing the lock to be None. In this case, acquiring the lock is pointless since the late_request_thread has already finished, defeating the purpose of this quire, but we can workaround this keeping a reference to the main_lock before starting the thread. This way, even if the late_request_thread is already finished, we can still acquire the lock even if it is already released. Normal flow: - main_thread acquires main_lock - main_thread span request_thread - main_thread tries to acquire main_lock and again and blocks - request_thread runs and releases main_lock - main_thread acquires main_lock and continues When it fails - main_thread acquires main_lock - main_thread span request_thread - request_thread runs and releases main_lock - main_thread tries to acquire main_lock witch is None and fails Fixed - main_thread acquires main_lock - main_thread span request_thread - request_thread runs and releases main_lock - main_thread tries to acquire main_lock but it is already released - main_thread acquires main_lock and continues Runbot error [229827](https://runbot.odoo.com/odoo/runbot.build.error/229827) Forward-Port-Of: odoo/odoo#237886
This update resolves an issue preventing the 'fuel_type' selection field in the HR contract model from being properly translated. By directly using the variable for options, this change ensures all text within the field can be localized, improving internationalization support for our Belgian HR payroll and fleet modules.
Original PR description
The selection field `fuel_type` in the `hr.contract` model was not properly translatable, because it used a function yielding static strings for the options. This commit changes the field to use the variable directly, allowing them to be translated. Forward-Port-Of: odoo/enterprise#100990 Forward-Port-Of: odoo/enterprise#100748
This update resolves an issue where the spreadsheet feature wasn't reliably displaying error messages when data loading failed. The team removed the 'clear' button from the spreadsheet interface to simplify the user experience and prevent confusion. This ensures that users receive clear feedback about data loading problems.
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 Forward-Port-Of: odoo/odoo#237989 Forward-Port-Of: odoo/odoo#233739
This update resolves a technical issue preventing the translation of text within the demo data for Sales Order Templates in version 19.0. This ensures that all text within these templates can be localized for international users, improving the overall user experience and supporting global expansion efforts. The fix was made to ensure consistent translation capabilities across the Odoo platform.
Original PR description
This commit fixes a little issue with the `sale.order.template` demo data, where the optional section title wasn't translatable. Affected version-19.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a reporting issue where payment reports incorrectly included bank accounts with zero allocations. The change ensures that only accounts with positive allocations are displayed, providing more accurate and reliable payment information. This improves the clarity and trustworthiness of financial reports.
Original PR description
-In case of creating payment reports for an employee with multiple bank accounts, if one of the accounts has an allocation of 0%, it still appears in the report. -This approach has been changed to include only accounts with positive allocations. Backport for odoo/enterprise#100643
This update resolves an issue preventing batch payments from correctly transitioning to 'reconciled' status, particularly when dealing with complex scenarios like early payment discounts and currency differences. The fix ensures accurate reconciliation processing, streamlining the bank reconciliation workflow and improving financial reporting.
Original PR description
In the goal of fixing the batch payments with EPD in the bank rec widget, we discovered another bug that was preventing the batch payments to change their state to "reconciled". This was due to some compute not being triggered again when one of its dependences did change (during another compute). task-4681366 Forward-Port-Of: odoo/odoo#236131 Forward-Port-Of: odoo/odoo#222303
This update ensures that early payment discounts (EPD) are accurately displayed within the bank reconciliation widget when processing batch payments containing invoices. Previously, EPDs weren't correctly reflected, now the system handles partial payments and EPDs associated with invoices, providing a more accurate reconciliation view.
Original PR description
In the bank reconciliation widget, it is now possible to have batch payments containing payments linked to only invoice_ids. Such batch payment, once mounted in the widget, should reflect the invoice or move amounts of its payments, and not only the payments amount. In the case of a payment-invoice combo that's elligible for an early payment discount, the early payment discount should also be displayed in the widget. Example: Invoice of 1000$ with possible EPD of 2%. A payment (with no move) is done (paid in the "early" period) for 980$. The payment is then put into a batch payment. Once in the bank rec widget, when mounting the 980$ batch payment to a statement line of 980$, the widget should display it as a batch payment line of 1000$ and add another 20$ Early payment Discount line. task-4681366 Forward-Port-Of: odoo/enterprise#99728 Forward-Port-Of: odoo/enterprise#83077
This update fixes an issue where Shift + Click within a table cell didn't correctly select text, leading to inconsistent behavior. The fix ensures Shift + Click works as expected with standard browsers, providing a more reliable text selection experience. Additionally, the fix addresses a flickering issue when resizing tables.
Original PR description
**Current behaviour before PR:** Steps to reproduce: - Create a table - Write a sentence in one of the cell - Put your caret somewhere in your sentence (e.g. "He[]llo wold") - Shift + click in the same sentence (e.g. "Hello wor[]ld") The expect result should be "He[llo wor]ld", but it's "[Hello wor]ld". This issue happens because in `onMousedown` method of table_plugin, cursor is set to the starting of `anchorNode`, which leads to wrong selection on shift + click. **Desired behaviour after PR:** This PR ensures that Shift + Click sets the selection in the same way as the default browser behavior. task-5152807 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237499 Forward-Port-Of: odoo/odoo#230716
This update fixes an issue where the HTML editor's table selection wasn't behaving as expected when selecting all text within a cell. Now, after selecting all cell content with Shift, only the current cell is selected, allowing for more precise editing. This ensures users can accurately target and modify individual cells within tables.
Original PR description
**Current behavior before PR:** Steps to reproduce: - In an m × n table, type some text inside a cell. - Place the cursor at the end of the text. - Hold Shift and repeatedly press ArrowLeft until the entire cell becomes selected. Once the cell content is fully selected, the cell itself is selected along with its adjacent cell, instead of only the current cell. **Desired behavior after PR:** After selecting all text, the current cell alone should become selected. Pressing Shift + ArrowLeft again should then extend the selection to the adjacent cell. task-5268801 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235959
This update allows authorized users to cancel payslips, even without accountant privileges. Previously, reversing a payslip required specific accounting group settings on related financial documents. This change simplifies the process for authorized personnel, improving operational efficiency. It ensures payslips can be correctly reversed when necessary.
Original PR description
As you need to have accountant group on some fields of the account move to be able to reverse it. We need to do it as sudo.
This update fixes an issue where the ‘Late Activities’ and ‘Today’s Activities’ counters on the Recruitment dashboard didn't correctly update after an activity was marked as done. The fix ensures that inactive activities no longer skew the counts, providing more accurate reporting on outstanding tasks. This improves the reliability of the Recruitment dashboard.
Original PR description
On the Recruitment dashboard (Jobs kanban), the counters for “Late Activities” and “Today’s Activities” may not decrease after an activity is marked as done, even though completed activities no longer appear in the applicant list. Root cause: `_compute_activities` aggregates counts from `mail_activity` using the deadline and job filters but does not exclude non-running (inactive/archived) activities. If an activity is not unlinked and becomes inactive (`active = FALSE`), it still matches `date_deadline <= today` and is counted. Steps to reproduce: 1. Open Recruitment 2. Pick any job and schedule an activity with Due date is Today (also try Yesterday for “Late”). 3. Mark the activity as Done. the number of activities today or late will not decrease opw-5123947 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232722
This update eliminates misleading duplicate order warnings that appeared when renewing subscriptions. The change specifically excludes renewal quotes ('2_renewal') from the system's duplicate order checks, preventing unnecessary alerts. This ensures a smoother renewal process for users and avoids potential disruptions.
Original PR description
Version: - 19.0 Steps to reproduce: 1. Create a subscription. 2. Set a customer reference 3. Confirm the subscription and create an invoice. 4. Renew the subscription to generate a renewal quote (state '2_renewal'). Issue: A duplicate order warning is displayed when renewing a subscription Solution: Exclude renewal quotes (`subscription_state == '2_renewal'`) from the duplicate order check in `_fetch_duplicate_orders`. This prevents incorrect warnings when creating or opening renewal quotes. taskid-5258963
This update fixes a technical issue that caused a traceback when removing color from a mega menu in the website editor. The fix ensures that color styles are correctly copied during editing, preventing errors and improving the user experience when customizing mega menu colors. This resolves a reported problem impacting website customization.
Original PR description
Problem: When removing a color from a block, a traceback occurs. Cause: After https://github.com/odoo/odoo/commit/bda6835293b2b222a003b9696fa052f31539a4ef we copy only style attributes to the `newFont` but the color can be applied through a class that applies text color so we should also copy classes that changes text color. Steps to reproduce: - Open Website. - Add a mega menu. - Open the editor. - On the mega menu, enable the “eCommerce Categories” option. - Edit one of the navigation headers’ labels and save. - Observe traceback. opw-5357516 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238193
This update fixes an issue where the Total Value report for inventory products incorrectly displayed values when fractional quantities were involved. The change ensures accurate remaining quantity and value calculations, particularly when products have fractional inventory levels. This improves the reliability of inventory reporting.
Original PR description
Problem: When valued products are moved in fractional quantities, the "Valuation" report under Inventory > Reporting > Stock > Total Value will show the wrong computed value for both the Remaining Quantity and Remaining Value (`remaining_qty` and `remaining_value` on stock.move). This is due to an `int` cast while computing remaining quantity, which then affects the remaining value calculated on this report. Solution: Move the `int` cast to a more appropriate location in the `_run_fifo_get_stack` logic so that the remaining quantity is preserved. Steps to reproduce (Runbot 19.0) - Product with: - Inventory tracked by quantity - Non-zero standard price (e.g. $1) 1. Add a fractional quantity on hand with an inventory adjustment (e.g. 1.9) 2. Navigate to Inventory > Reporting > Stock, click the number for Total Value on the product (will be $1.90) On this menu with the example data, Remaining Quantity will be 1.00, and remaining value will be $1.00. opw-5230435
This update resolves a technical problem preventing invoices with Italian e-invoicing attachments from being successfully sent. The issue stemmed from incorrect file encoding, which caused errors during transmission to the Italian tax authority. Now, attachments are correctly sent, ensuring invoices are processed as intended.
Original PR description
Before this commit: Steps 1) When clients try to send invoices to Italian e-invoicing 2) And if `L10N It Edi Attachment File` is already set (Ex. already sent but using only the `by Post` option, the XML gets generated and set) => A Invalid Operation Error is raised with the message: `Error sending file from the Proxy Server to SdI: Start tag expected, '<' not found, line 1, column 1 (<string>, line 1)`, This occurs because the `_l10n_it_edi_send()` method is called with invalid `attachments_vals` as `raw` key contains encoded file instead of the raw version. Then it's encoded again in that method, so there is a double encoding and the Italian e-invoicing fails to decode it. After this commit: If the client try to send the invoice to Italian e-invoicing after generating the `L10N It Edi Attachment File`, it works well.
This update corrects a bug where duplicated subscription deliveries weren't correctly reflecting delivered quantities. The change ensures that delivery dates are properly used to calculate quantities, leading to accurate tracking of delivered items. The fix also removes redundant date updates within subscription pickings.
Original PR description
The use of date_deadline instead of date in the filter messes up the calculation of delivered quantities when you duplicate a delivery. Task: 4910572
This update resolves a bug where the website's custom favicon wasn't consistently displayed in browser tabs. Previously, the browser cached the default Odoo favicon even after changing the website's favicon settings. This change ensures that the correct favicon is always shown, improving the user experience and brand consistency.
Original PR description
When editing a website favicon in settings or switching between websites with different favicons, the browser tab always displayed the default Odoo favicon instead of the specific website's favicon.…
When editing a website favicon in settings or switching between websites with different favicons, the browser tab always displayed the default Odoo favicon instead of the specific website's favicon. the favicon were not immediately reflected due to browser caching. The browser is responsible for caching the favicon. When you load a page, the browser sees `<link rel="shortcut icon" href="...">`. If it has already downloaded the image at that URL, it will use the stored (cached) copy instead of asking the server for it again. This improves performance. but also it's responsible for the bug. Steps to reproduce: =================== 1. Set a custom favicon for your website in Settings. 2. Open the Website app. 3. Observe that the browser tab shows the default Odoo favicon instead of the custom one. Solution: ========= Retrieve the favicon URL directly from the iframe's document content (link[rel~='icon']) and update the main window's favicon opw-5126299 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237361
This update resolves several bugs preventing the website builder from functioning correctly, particularly when editing blog posts. The changes ensure accurate preview updates and correct behavior when saving or discarding edits, improving the overall user experience.
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 update fixes a bug in the shop floor component consumption process when tracking components by lot. Previously, the system incorrectly consumed large quantities (e.g., 1000kg instead of 50g). The fix addresses an issue with how lot quantities were handled, ensuring accurate consumption amounts.
Original PR description
**PROBLEM** Component consumption behavior in shop floor is buggy when the component is tracked by lot. When "selecting" a lot to take from, the consumed amount is not correct. (ex, we ask for 50g,…
**PROBLEM** Component consumption behavior in shop floor is buggy when the component is tracked by lot. When "selecting" a lot to take from, the consumed amount is not correct. (ex, we ask for 50g, and it consumes 1000kg). **STEP TO REPRODUCE** 1. create a product. 2. create a bom with: - a component tracked by lot, with kg as product uom, but g as the bom uom. - create a step, during which 50g of the component is consumed. 3. create two lots of the component, with 1kg each. 4. create a MO for the product with the bom. 5. in the shop floor, try consuming the component and select one of the lot as a source. 6. the consumed amount should be 50g, remove the move line created (pencil icon, then remove). 7. recreate the move line, the consume amount will be nonsensical (something like 1 000 000g). **CAUSE** 1. The dialog opened for selecting the lot create a new `stock.quant` record, instead of returning the existing quant for the lot. This quant will have a quantity of 0, impacting the computation we do for the quantity we should take from this quant. 2. The formula for the quantity to take from the quant was : `max(min(remaining_qty, quant.available_quantity), 1)`. The `max(...,1)` doesn't work well when `remaining_qty` is between 0 and 1. For example, when using UoM like we do in the repro steps, `remaining_qty = 50g = 0.05kg`. But instead of taking 50g, because of the max we take 1kg = 1000g. 3. There was a double UoM conversion (`_prepare_move_line_vals` already does the conversion, so we don't need to do it before passing qty_to_take as parameter). opw-5136050 Forward-Port-Of: odoo/enterprise#97005
This update resolves an internal server error that occurred when generating PDF reports for Annual Audit Reports. The fix ensures the correct custom PDF export function is used, improving the reliability of report printing. This prevents disruptions to users generating these important financial reports.
Original PR description
Steps to reproduce: - Go to "Accounting/Review/Audit/Annual Report" and create an Audit Report. - click "Print" -> Internal Server Error This happens when generating the Journal Audit pdf, this report needs to uses the `export_to_pdf` that is defined in its custom handler `account.journal.report.handler`. The solution is to use `dispatch_report_action`, as it will determine which function to use in order to export the pdf for each report. no-task
This update resolves an issue where changes to employee records in the Odoo system weren't consistently triggering related updates. The fix ensures that when you modify employee details, the appropriate changes are reflected correctly, improving data accuracy and consistency. This enhancement impacts the employee management workflow.
Original PR description
purpose: when changing fields of employee in the UI, the `_onchange` of the fields doesn't trigger because it's defined on `hr.version` -added `test_related_fields_on_version_onchange` to check if `_onchange` methods are implemented on `hr.employee` to call the corresponding methods on `hr.version` task-id: 5173389 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235093
This update fixes an issue where changing certain employee settings (like insurance or company car) didn't automatically update related sub-fields within the configuration. This resulted in incorrect default values being displayed. The update ensures that changes to master employee settings are correctly reflected in dependent fields, improving data accuracy and usability.
Original PR description
'*' = be, ch purpose: currently when you change the values of fields like insurance or company car the onchange doesn't reflect on the subfields which is the case for cars, insurances, etc. this makes the fields have wrong default values in the configurator - added `_onchange` methods for related fields of `hr_version` in `hr_employee` to call the corresponding `_onchange` in `hr_version` - optimized the method `_compute_l10n_be_mobility_budget_amount` to use binary search instead of linear loop task-id: 5173389 Forward-Port-Of: odoo/enterprise#97472
This update fixes a bug that caused the system to crash when users attempted to validate signed documents. The issue stemmed from a missing field related to document signing, which occurred after uninstalling a specific app. The fix ensures the system gracefully handles this situation and prevents errors.
Original PR description
The system will crash with an error when the user tries to validate the signature. **Steps to produce:** - Install `Sign, Employee Contracts, and Documents` apps with demo data. - Go to Apps and…
The system will crash with an error when the user tries to validate the signature.
**Steps to produce:**
- Install `Sign, Employee Contracts, and Documents` apps with demo data.
- Go to Apps and uninstall the `hr_contract_sign`module.
- Send any employee a sign request for a document.
- When the employee tries to validate and send the document, the error appears.
**Error:**
`KeyError: 'sign_request_ids'
ValueError: Invalid field hr.employee.sign_request_ids in condition ('sign_request_ids', 'in', [1])`
**Cause:**
- When `sign` route is called, then we try to search field `sign_request_ids` in `hr_employee`. but we can see the field `sign_request_ids` is defined in `hr_contract_sign` module.
- And user removed the `hr_contract_sign` module, so the field no longer exists. in the hr_employee model.
**Solution:**
- Added a graceful bypass when `sign_request_ids` is missing,
**sentry-6819182542**
Forward-Port-Of: odoo/enterprise#100796
Forward-Port-Of: odoo/enterprise#95449This update resolves issues where changes to spreadsheet data inputs were unexpectedly lost due to system updates or user actions. The fix ensures that input values are correctly saved and reflected, providing a more reliable experience for users updating sales data. This improves data accuracy and reduces potential data loss.
Original PR description
Currently, the FieldSync record input suffers from two issues: 1) The input value can be reset by parasitic renders While the user is inputting a value, if they did not confirm it and a global render occurs (other user joining the session, dragging the mouse on the grid), the input value will be reset to the one stored in the plugin, therefore erasing the last change of the user 2) In Chrome-based navigators, users can change the value of the input by using their mouse scrolling wheel. Such action *does not* trigger an `onChange` event; which means that the new value is never directly saved. Both issues are addressed in this commit by keeping an internal state inside the component `FieldSyncSidePanel` and ensure this state is properly reflected in the plugin once we stop editing the input. Task-5123069 Forward-Port-Of: odoo/enterprise#101017 Forward-Port-Of: odoo/enterprise#96431
Features or functions removed from Odoo
This update removes redundant overrides for start dates in the UK and New Zealand reporting modules. Previously, users couldn't easily set the start date themselves, rendering the field on the form view ineffective. This change simplifies the reporting process and aligns with the new user interface functionality.
Original PR description
These overrides are useless now that the user can access the return type form view and configure himself the start_date. Overriding _get_start_date_elements should be avoided as much as possible as this is making the field on the form view useless if set.