Daily updates from Odoo
Friday, December 5, 2025
120 changes
18 changes
Resolved issues and error corrections
This update ensures Odoo automatically updates remaining modules in the database, regardless of how Odoo is started. Previously, this only worked when Odoo was launched with specific command-line arguments. This change adds a configuration setting to trigger the automatic update process, improving database consistency and stability.
Original PR description
In https://github.com/odoo/odoo/pull/216025, we force auto upgrade of modules remaining in the database when `preload_registries` is called. However, this strategy doesn't work if Odoo is not started with the `-d` argument, because `preload_registries` is only called for databases specified in the `-d` argument. This commit fixes the issue by adding a special record in `ir_config_parameter` with key `base.partially_updated_database` to indicate that the next time `Registry.new` is called, it should force auto upgrade of modules remaining in the database. 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#238748 Forward-Port-Of: odoo/odoo#238320
This update fixes an issue where the 'Journal Items' link in the General Ledger Report was incorrectly displaying items not associated with the selected account group. The fix ensures that users see the correct journal items linked to their account groups, improving report accuracy and data reliability.
Original PR description
Repro steps: 1. Create account groups 2. Go to general ledger report 3. Click on 'Journal Items' of one of the account groups lines Problem: The journal items shown don't belong to the account group that it should belong to. Fix: This commit fixes this issue by adding the correct action_domain of account_id.group_id. opw-5180867 Forward-Port-Of: odoo/enterprise#100191
This update fixes an issue where application refusal emails weren't sent promptly, relying solely on a delayed queue. Now, emails are sent immediately upon refusal and a log entry is created in the applicant's chat, improving communication and transparency in the recruitment process. This ensures candidates receive timely updates.
Original PR description
**Steps to reproduce:** 1. Install `hr_recruitment` 2. Create a job position and then an application with an email address for it 3. Refuse the application with "Send Email" enabled **Issue:** 1. Refusal emails are not sent right away; they are only queued and delivered later by the scheduled action. 2. No log entry is created in the chatter. **Cause:** - During the recruitment refusal flow refactoring, mail handling was not properly adapted. The code prepared the refusal mail but never explicitly sent it, resulting in it being added to the queue only. **Solution:** - Ensure refusal mails are sent immediately instead of waiting for the queue. Log the refusal mail in the applicant’s chatter at the time of refusal. opw-5058709
This update corrects a technical issue in the Danish Nemhandel integration by ensuring that Denmark-specific document type checks are applied only to Danish partners. This prevents conflicts with standard Peppol processes and ensures consistent data flow, improving the reliability of the system.
Original PR description
Before: - The l10n_dk_nemhandel override of _check_document_type_support replaced the generic Peppol logic and did not accept process_type, causing errors when other localizations relied on the base method. After: - Aligned the method and applied the DK-specific logic only for Danish partners, falling back to the generic Peppol behavior otherwise. Impact: - Prevents unintended overrides towards standard Peppol flow. Forward-Port-Of: odoo/odoo#238543
This update prevents the creation of duplicate reversal and deferral entries when generating deferred entries from invoices. The change corrects a calculation issue introduced with a new method for handling monthly accounting dates, ensuring cleaner and more accurate journal entries.
Original PR description
When generating deferred entries from invoice lines, certain scenarios led to the creation of both a reversal and a deferral for the same amounts. These entries would effectively cancel each other out, creating unnecessary noise in the journal entries. This issue primarily occurred when the start date, end date, and accounting date all fell within the same calendar month. The problem was exacerbated by the introduction of the `full_months` computation method in https://github.com/odoo/enterprise/commit/5dca9c0c2691cba2335e110ad63a2dcc8bbf6d57. To correctly handle this method and prevent the erroneous paired entries, the end date must now be adjusted by subtracting one month when calculating the deferral period. opw-5000337 Forward-Port-Of: odoo/enterprise#101258 Forward-Port-Of: odoo/enterprise#100507
This update corrects a visual issue in the bank reconciliation widget where the activity badge was misaligned. The fix removes unnecessary styling classes, ensuring the badge now appears correctly positioned on the icon. This improves the user experience and visual consistency of the bank reconciliation process.
Original PR description
Current behavior before PR: The activity badge inside the bank reconciliation widget was misaligned, <img width="55" height="60" alt="image" src="https://github.com/user-attachments/assets/0f99ea55-fedd-401a-a65e-226296070e32" /> Desired behavior after PR is merged: The activity badge now sits in the correct position on the icon. <img width="62" height="55" alt="image" src="https://github.com/user-attachments/assets/abf96aed-73d4-4153-8e0a-56937d4ff08a" /> Changes implemented: - Removed `fa-fw` class. - Removed the unnecessary 'fa-fw' class from comment and paperclip icon. task-5354994 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#100573
This update resolves an issue where switching between different media types (like images and icons) in the HTML editor didn't correctly remove outdated class names. Previously, an image might retain a class that wasn't valid for icons. This fix ensures that the HTML editor consistently removes irrelevant classes, improving the editor's functionality and preventing unexpected styling.
Original PR description
Before this commit, switching the media type would not properly remove the classes of the element. For example, images can have the class "w-100" while icons cannot. If an image had the class "w-100", switching to an icon would keep the class "w-100", even though this class isn't valid for icons. This commit fixes the code to properly remove all invalid classes. Forward-Port-Of: odoo/odoo#238501
This update fixes an issue where debit notes generated in the Uruguayan localization were incorrectly assigned as e-invoices (type 111). The fix ensures debit notes automatically use the correct document type (113), streamlining invoice processing for Uruguayan customers. This improves data accuracy and compliance.
Original PR description
**Steps to reproduce:** * Install and activate the **Uruguayan Localization** for the company. * Create a contact located in Uruguay. * Create an invoice for this customer and set **Document Type =…
**Steps to reproduce:** * Install and activate the **Uruguayan Localization** for the company. * Create a contact located in Uruguay. * Create an invoice for this customer and set **Document Type = 111 (e-Invoice)**. * From the invoice's gear icon, create a **Debit Note**. **Observed behavior:** * The debit note is automatically assigned **Document Type 111 (e-Invoice)**, even though it should use **113 (e-Invoice Debit Note)**. * Attempting to change the document type manually only shows 113 as an option, confirming the debit note should not have been set to 111. **Cause:** * `_compute_l10n_latam_document_type()` applies a rule that assigns Document Type **111** to all Uruguay electronic invoices with RUT identification. * This logic does **not** check whether the move is a **debit note** (`m.debit_origin_id`), and therefore incorrectly overrides the expected debit note document type. * The override prevents the correct selection (internal_type == *debit_note*) from being applied. **Fix:** * Add a condition in the automatic e-Invoice assignment logic. * Debit notes now bypass the e-Invoice assignment and fall through to the parent method, which correctly assigns **Document Type 113**. opw-5154599 Forward-Port-Of: odoo/enterprise#100938
This update increases the time allowed for sending log data from the IoT box to the database, resolving previous issues that caused frequent errors. By extending the timeout to 10 seconds and increasing the log sending frequency to 12 seconds, the system is now more reliable in capturing and transmitting important data.
Original PR description
Currently the request to send logs to the db from the iot box is at 0.5s timeout. This leads to many exceptions and failed requests. This commit sets the timeout for such requests to 10s (previously 0 5s) and the frequency of sending logs to every 12s (previously 0.5s) Forward-Port-Of: odoo/odoo#238648
This update removes outdated services automatically added when connecting to the Peppol network. These services were irrelevant due to restrictions on user registration from Australia, New Zealand, and Singapore, and were likely causing confusion. This change simplifies the system and reduces potential errors.
Original PR description
When creating a new connection to the Peppol network, we add multiple services by default. This commit remove from the default (they can still be manually enabled): - the ANZ BIS3 Invoice &…
When creating a new connection to the Peppol network, we add multiple services by default. This commit remove from the default (they can still be manually enabled): - the ANZ BIS3 Invoice & CreditNote that is deprecated in favor of the PINT version, - the SG BIS3 Invoice & CreditNote that will also be deprecated soon by its PINT version. Note that anyway for the moment we don't allow to register user from AU/NZ/SG on Peppol, so we were in any case registering those services for all participants, and none of them were relevant for those two local formats ... In the future we would like to handle the received services(formats) on IAP directly to handle change better. https://github.com/odoo/odoo/blob/0af9d32e305c1f1afb51e126c1e6747879e78225/addons/account/models/company.py#L35-L50 I checked on our AP, and only 8-10 invoices were sent with these formats, between Belgians... so it is most likely errors. Let's reduce the confusion. <img width="1283" height="65" alt="image" src="https://github.com/user-attachments/assets/208bbd7e-f836-4bc9-a594-795313b06be9" /> Source: https://docs.peppol.eu/edelivery/codelists/v9.4/Peppol%20Code%20Lists%20-%20Document%20types%20v9.4.json Forward-Port-Of: odoo/odoo#238674
This update fixes an issue where short feedback messages were incorrectly wrapping the last word, creating a messy layout. The change ensures that feedback messages display cleanly, especially when combined with the rating image, resulting in a better user experience. This backport addresses a minor visual inconsistency.
Original PR description
**Current behavior before PR:** - Short feedback wraps the last word unnecessary.  **Desired behavior after PR is merged:** - Short messages wrapped unnecessarily due to block-level element conflicting with floated rating image. This fix ensures cleaner inline layout.  Backport of this: [Commit](https://github.com/odoo/odoo/commit/52a1913ea7082655009c9eca1201c8c42e4e4037) task-[4788428](https://www.odoo.com/odoo/project/1519/tasks/4788428) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215577
This update resolves an issue where users were unexpectedly redirected back into the sign flow after completing a document signature. The fix ensures users return directly to the correct record form without lingering 'Sign' breadcrumbs, improving the user experience and preventing confusion.
Original PR description
Issue:
- After signing a document, the user is redirected to the correct
record form (e.g., Offer, Invoice) but an extra "Sign" breadcrumb
remained in the navigation.
- Clicking that breadcrumb sent the user back into the sign flow,
creating confusion and breaking the expected navigation behavior.
Fix:
- Updated the close flow in the thank you dialog to use
`stackPosition: "replacePreviousAction"` when a reference document
exists, ensuring the sign dialog controller is removed cleanly.
- Fallbacks use `clearBreadcrumbs` when no reference document is
linked (standalone sign documents).
- This restores correct breadcrumb generation across all sign flows.
Impact:
- Users return to the proper parent record without leftover sign
breadcrumbs.
- Prevents unexpected navigation back into the sign request.
Task: 5175992
Forward-Port-Of: odoo/enterprise#99525This update simplifies the process of creating new signature templates in Odoo Enterprise. Now, newly created templates automatically default to the standard 'Sign' folder, eliminating the need for users to manually set this option each time. This streamlines workflow and reduces potential errors.
Original PR description
Assign a default document folder to sign templates so that each newly created template automatically points to the default "Sign" folder. task-5023107
This update resolves a technical issue that prevented the printed receipt tour from working correctly after installing the `l10n_se_pos` module for Swedish Point of Sale. The fix corrects a programming error, ensuring the receipt tour functions as expected for users.
Original PR description
in this commit: - Fixed TypeError: this.get_order is not a function raised during the `test_printed_receipt_tour` in POS after installing `l10n_se_pos`. runbot-233248 Forward-Port-Of: odoo/enterprise#97355
This update corrects a problem where email templates were not rendering correctly due to differences in how HTML is processed. The fix ensures that all HTML elements, except for specifically allowed 'void' elements, have proper closing tags, resulting in consistent and accurate email formatting. This prevents errors and ensures emails display as intended.
Original PR description
**Step to Reproduce:** - install Subscription (with demo data) - try to edit `Subscription: Payment Reminder` email template **Observation:** - Traceback for faulty template **Cause** For outgoing…
**Step to Reproduce:**
- install Subscription (with demo data)
- try to edit `Subscription: Payment Reminder` email template
**Observation:**
- Traceback for faulty template
**Cause**
For outgoing mails, we are using output_method = 'xml' when normalizing html content
https://github.com/odoo/odoo/blob/cb5176df98490ef04c0aac481f010bd2ac2f2424/odoo/orm/fields_textual.py#L580-L587
when this content is parsed using DOMParser in browser,
https://github.com/odoo/odoo/blob/cb5176df98490ef04c0aac481f010bd2ac2f2424/addons/html_editor/static/src/html_migrations/html_upgrade_manager.js#L61-L63
we might get different result.
For a very basic template like this:
```
<div>
<t t-if="ctx.get('error')">
<pre t-out="ctx['error'] or ''" />.
</t>
<t t-else="">
<span>some text</span>
</t>
</div>
```
when parsed using Domparser(), return a faulty template:
```
<div>
<t t-if="ctx.get('error')">
<pre t-out="ctx['error'] or ''">.
<t t-else="">
<span>some text</span>
</t>
</pre>
</t>
</div>
```
Issue roots because of use of self-closing tags, which are valid for xml but not for html
**Fix:**
- we forcefully replace all self-closing tags(which are not void elements) with a closing tag.
- see list of void elements https://developer.mozilla.org/en-US/docs/Glossary/Void_element
opw-5234345
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#235924This update corrects a bug where 'Other Activities' were incorrectly grouped, leading to inaccurate counts in the systray. By separating these activities, the system now correctly identifies and displays overdue, today, and planned activities, ensuring users have a precise view of their tasks. This improves the reliability of the activity tracking feature.
Original PR description
Activities without a resource model (displayed as "Other Activities") were previously grouped together. This caused the counter logic, which splits activities into 'overdue', 'today', and 'planned', to fail. It would evaluate the entire group of activities and assign all of them to the first state it encountered (e.g., all 5 activities would be marked 'overdue' even if only 1 was). This commit changes the grouping key for these "mail.activity" records so that each "Other Activity" is processed individually, allowing its state to be correctly counted and displayed in the systray menu. Task-5226403 Forward-Port-Of: odoo/odoo#234899
A test related to payroll accounting was failing when run on a database without the standard demo data. The fix added a default account to the test environment, resolving the error and ensuring the test now runs correctly. This ensures consistent test results regardless of the database setup.
Original PR description
Steps to reproduce: Install hr_payroll_account on a fresh db without demo data. Run the test test_payment_hr_payslip. The test fails. Cause: With demo data, the us payroll was installed and with it, the payroll accounts were configured. Without demo data, default account is missing. Fix: Add a default account in the test and fix the amount balance with a new debit rule to balance the credit one. Task: 5386528 Runbot Error: 161615 Forward-Port-Of: odoo/enterprise#101299
This update addresses a technical issue where form changes were causing confusing error messages. The team has implemented a fallback to gather more information about these errors, improving stability and reducing disruption for users. This change focuses on internal technical improvements.
Original PR description
Related to https://runbot.odoo.com/odoo/error/234669: somewhere somehow an onchange warning is malformed (it's not a mapping) and the Form is unable to cope with it, leading to a rather unhelpful error. TBH I don't understand how it can happen as `onchange` has a rewriting layer between the `warning` out of onchange methods and the one it sends to the client. And most of the `onchange` overrides are preprocessing not post. And the two overrides which do postprocess modify `values` in place. Add a fallback to attempt to get more insight into this error. Forward-Port-Of: odoo/odoo#238705
20 changes
Resolved issues and error corrections
This update resolves an issue where journal item links within the general ledger report were incorrectly associating items with the wrong account groups. The fix ensures that journal items are accurately linked to their respective account groups, improving the accuracy of financial reporting.
Original PR description
Repro steps: 1. Create account groups 2. Go to general ledger report 3. Click on 'Journal Items' of one of the account groups lines Problem: The journal items shown don't belong to the account group that it should belong to. Fix: This commit fixes this issue by adding the correct action_domain of account_id.group_id. opw-5180867 Forward-Port-Of: odoo/enterprise#100191
This update ensures that bills automatically received through the PEPPOL network are immediately posted to the system, rather than remaining in a draft state. This streamlines the accounting process for partners using the PEPPOL network, improving efficiency and reducing manual intervention. This change was made to address a previous issue.
Original PR description
Currently, even if a partner has auto-post bills enabled, the incoming bills stay in the draft state. This change addresses that issue. Task-5373302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238473
This update fixes a potential issue where IoT reports could be printed multiple times. The change ensures that websocket actions are not duplicated by also checking for longpolling calls, streamlining report generation and improving efficiency. This prevents wasted resources and ensures accurate reporting.
Original PR description
In order to prevent duplicate IoT actions, we now ensure that websocket actions have not already been called through longpolling. odoo/odoo#236917 Forward-Port-Of: odoo/enterprise#101257 Forward-Port-Of: odoo/enterprise#100161
This update fixes a potential issue where reports could be printed multiple times, leading to unnecessary actions. The change ensures that websocket actions are not duplicated by checking if they've already been processed via longpolling. This improves efficiency and reduces potential errors.
Original PR description
In order to prevent duplicate IoT actions, we now ensure that websocket actions have not already been called through longpolling. odoo/enterprise#100161 Forward-Port-Of: odoo/odoo#238575 Forward-Port-Of: odoo/odoo#236917
This update resolves an issue where document previews were not updating after renaming documents, displaying outdated attachment names. The fix ensures that preview names consistently reflect the current document name, regardless of how the document was renamed (via the Rename action or chatter).
Original PR description
BUG 1: --------- **steps to reproduce**: 1. Install documents 2. Open any document 3. Go to Action > Rename 4. Rename the document 5. Preview it and read the name showed there **issue**: When…
BUG 1:
---------
**steps to reproduce**:
1. Install documents
2. Open any document
3. Go to Action > Rename
4. Rename the document
5. Preview it and read the name showed there
**issue**:
When previewing the document, it still shows the old attachment name.
**observation**:
When renaming a document, only the document name was updated. The attachment name remained unchanged, which caused inconsistencies:
1. In the All Records section, the document name is displayed correctly. https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/views/documents_document_views.xml#L130
2. But in the Preview, the old attachment name was still shown, as it is taken from the attachment:
https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/static/src/views/hooks.js#L373-L383
**solution**:
Use the document name when previewing it
BUG 2:
---------
**steps to reproduce**:
1. Install Documents.
2. Open any document.
3. Rename it via the chatter.
4. Try renaming it again via the details panel.
**issue**:
After renaming a document twice through the details panel, the preview still displayed the old document name.
**cause**:
On the first rename, the [insert](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/core/document_service.js#L96-L129)) method creates a new [store.Document](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/views/hooks.js#L367-L393) record with the updated attachment name. However, The write method (used by chatter) skips reloading the record and linked attachment data on the second rename.
Unlike the Rename button, which uses web_save (and triggers a record reload via web_read), the chatter directly calls write without refreshing the attachment.
**Solution**:
Ensure the preview uses the document name from the document record, keeping it consistent after multiple renames via the details panel.
**Example:** Try to rename a "Invoice.pdf" document to "Invoice_rename.pdf"
<details>
<summary>Click here to see the results:</summary>
Before:
<img src="https://github.com/user-attachments/assets/563b7fb9-709c-4651-8492-032a7f353730"/>
After:
<img src="https://github.com/user-attachments/assets/6fc6bdfe-dd1e-4f3c-aaf7-821c44fd135d"/>
</details>
opw-5065433
Forward-Port-Of: odoo/enterprise#100539
Forward-Port-Of: odoo/enterprise#95111This update corrects a technical issue in the Danish Nemhandel integration by ensuring that specific document type checks are only applied to Danish partners. This prevents conflicts with standard Peppol processes and ensures consistent data flow, improving the reliability of the Danish integration.
Original PR description
Before: - The l10n_dk_nemhandel override of _check_document_type_support replaced the generic Peppol logic and did not accept process_type, causing errors when other localizations relied on the base method. After: - Aligned the method and applied the DK-specific logic only for Danish partners, falling back to the generic Peppol behavior otherwise. Impact: - Prevents unintended overrides towards standard Peppol flow. Forward-Port-Of: odoo/odoo#238543
This update prevents the creation of duplicate reversal and deferral entries when generating deferred entries from invoices. The change corrects a calculation issue introduced with a new method for handling monthly accounting dates, ensuring journal entries are cleaner and more accurate. This improves the overall stability and clarity of financial reporting.
Original PR description
When generating deferred entries from invoice lines, certain scenarios led to the creation of both a reversal and a deferral for the same amounts. These entries would effectively cancel each other out, creating unnecessary noise in the journal entries. This issue primarily occurred when the start date, end date, and accounting date all fell within the same calendar month. The problem was exacerbated by the introduction of the `full_months` computation method in https://github.com/odoo/enterprise/commit/5dca9c0c2691cba2335e110ad63a2dcc8bbf6d57. To correctly handle this method and prevent the erroneous paired entries, the end date must now be adjusted by subtracting one month when calculating the deferral period. opw-5000337 Forward-Port-Of: odoo/enterprise#101258 Forward-Port-Of: odoo/enterprise#100507
This update resolves an error that occurred when configuring the Tax Returns journal in Odoo. The fix ensures a default progress record is created, preventing a singleton error that arose from changes in how onboarding data is initialized. This ensures the Tax Returns journal functionality works correctly for all Odoo instances.
Original PR description
Currently, an error is produced when configuring the **Accounting Period** on the "**Tax Returns**" journal. Steps to Reproduce: 1. Install `accountant` module without demo data using `-i` command.…
Currently, an error is produced when configuring the **Accounting Period** on the "**Tax Returns**" journal. Steps to Reproduce: 1. Install `accountant` module without demo data using `-i` command. 2. Accounting > Dashboard > "**Tax Returns**" Journal, click on “Tax Returns” button. 3. Set an _Opening Date_ in the wizard and try to apply the **Accounting Periods**. **Error:** `ValueError - Expected singleton: onboarding.progress()` **Cause:** **Until saas-18.2,** The onboarding record’s `current_progress_id` was created by method `_search_or_create_progress()` - ([1]) during module initialization. This method was triggered through `_initiate_account_onboardings()`, which was called in the `_accounting_post_init()` hook for all companies - ([2]). **From saas-18.3,** `_accounting_post_init()` was modified to call `_initiate_account_onboardings()` only for companies having a `chart_template` - ([3]). As a result, companies without a chart template never receive a default progress record, leaving `current_progress_id` unset. When rendering onboarding values, this leads to a singleton error. **Fix:** This commit ensures that a progress record exists by creating it when missing before rendering onboarding values. [1]: https://github.com/odoo/odoo/blob/b2558e92e627a0efd975a402b77a6b53810c4c41/addons/onboarding/models/onboarding_onboarding.py#L107-L111 [2]: https://github.com/odoo/enterprise/blob/2f2b53f1c6f31ae22351d22cf4bf59ef01a63691/accountant/__init__.py#L22-L25 [3]: https://github.com/odoo/enterprise/blob/37dd63580967c1186618d7340a21539a6c98dbba/accountant/__init__.py#L22-L24 sentry-7064593163
This update corrects a bug where 'Other Activities' were incorrectly grouped, leading to inaccurate counts in the systray. By separating these activities, the system now correctly identifies and displays overdue, today, and planned tasks, ensuring users have a precise view of their workload. This improves the reliability of the task management interface.
Original PR description
Activities without a resource model (displayed as "Other Activities") were previously grouped together. This caused the counter logic, which splits activities into 'overdue', 'today', and 'planned', to fail. It would evaluate the entire group of activities and assign all of them to the first state it encountered (e.g., all 5 activities would be marked 'overdue' even if only 1 was). This commit changes the grouping key for these "mail.activity" records so that each "Other Activity" is processed individually, allowing its state to be correctly counted and displayed in the systray menu. Task-5226403
This update resolves an issue where switching between different media types (like images and icons) in the HTML editor didn't correctly remove outdated class names. This ensures that the editor consistently uses the appropriate classes for each media type, improving the user experience and preventing potential display inconsistencies. It's a minor fix that enhances the editor's reliability.
Original PR description
Before this commit, switching the media type would not properly remove the classes of the element. For example, images can have the class "w-100" while icons cannot. If an image had the class "w-100", switching to an icon would keep the class "w-100", even though this class isn't valid for icons. This commit fixes the code to properly remove all invalid classes. Forward-Port-Of: odoo/odoo#238501
This update increases the time allowed for sending log data from the IoT box to the database, resolving frequent errors and failures. By extending the timeout to 10 seconds and increasing the log sending frequency to 12 seconds, the system is now more reliable in capturing and transmitting important data.
Original PR description
Currently the request to send logs to the db from the iot box is at 0.5s timeout. This leads to many exceptions and failed requests. This commit sets the timeout for such requests to 10s (previously 0 5s) and the frequency of sending logs to every 12s (previously 0.5s) Forward-Port-Of: odoo/odoo#238648
This update removes outdated services automatically added when connecting to the Peppol network, specifically those for ANZ and SG. This simplifies the system and reduces potential confusion, as these services were never actually used. The change aligns with future plans for more flexible service handling.
Original PR description
When creating a new connection to the Peppol network, we add multiple services by default. This commit remove from the default (they can still be manually enabled): - the ANZ BIS3 Invoice &…
When creating a new connection to the Peppol network, we add multiple services by default. This commit remove from the default (they can still be manually enabled): - the ANZ BIS3 Invoice & CreditNote that is deprecated in favor of the PINT version, - the SG BIS3 Invoice & CreditNote that will also be deprecated soon by its PINT version. Note that anyway for the moment we don't allow to register user from AU/NZ/SG on Peppol, so we were in any case registering those services for all participants, and none of them were relevant for those two local formats ... In the future we would like to handle the received services(formats) on IAP directly to handle change better. https://github.com/odoo/odoo/blob/0af9d32e305c1f1afb51e126c1e6747879e78225/addons/account/models/company.py#L35-L50 I checked on our AP, and only 8-10 invoices were sent with these formats, between Belgians... so it is most likely errors. Let's reduce the confusion. <img width="1283" height="65" alt="image" src="https://github.com/user-attachments/assets/208bbd7e-f836-4bc9-a594-795313b06be9" /> Source: https://docs.peppol.eu/edelivery/codelists/v9.4/Peppol%20Code%20Lists%20-%20Document%20types%20v9.4.json Forward-Port-Of: odoo/odoo#238674
This update corrects a previous error in the EPF (Employee Provident Fund) calculation for our Malaysian payroll system. Specifically, it now accurately accounts for rounding of tax amounts to the nearest ringgit and incorporates the latest legislative rate changes. This ensures accurate and compliant EPF deductions.
Original PR description
Previous behavior did not account for the rounding of the amount of tax to the next ringgit. Also the employee's rate has been updated in accordance to the legislation. task-5286179 Forward-Port-Of: odoo/enterprise#100736
This update resolves an issue where users were unexpectedly redirected back into the sign flow after completing a document signature. The fix ensures users return directly to the correct record (like an Offer or Invoice) without lingering 'Sign' breadcrumbs, improving the user experience and navigation.
Original PR description
Issue:
- After signing a document, the user is redirected to the correct
record form (e.g., Offer, Invoice) but an extra "Sign" breadcrumb
remained in the navigation.
- Clicking that breadcrumb sent the user back into the sign flow,
creating confusion and breaking the expected navigation behavior.
Fix:
- Updated the close flow in the thank you dialog to use
`stackPosition: "replacePreviousAction"` when a reference document
exists, ensuring the sign dialog controller is removed cleanly.
- Fallbacks use `clearBreadcrumbs` when no reference document is
linked (standalone sign documents).
- This restores correct breadcrumb generation across all sign flows.
Impact:
- Users return to the proper parent record without leftover sign
breadcrumbs.
- Prevents unexpected navigation back into the sign request.
Task: 5175992
Forward-Port-Of: odoo/enterprise#99525This update resolves a visual issue in the mobile preview where a shadow appeared around the device image, particularly at the corners. The fix ensures the device image's border-radius is correctly aligned, resulting in a cleaner and more professional look on larger mobile screens. This improves the overall user experience for mobile visitors.
Original PR description
This PR aims to fix an issue about the shadow around the device in the mobile preview, specifically in the corners, when the height of the viewport is bigger than 1080px. Prior to this, the border-radius property was not correctly aligned with the radius of the mobile device image (in `.o_mobile_preview_layout`). | Before | After | |--------|--------| | <img width="468" alt="image" src="https://github.com/user-attachments/assets/1d8aaba4-2e8f-45fd-a6b8-853c82051a51" /> | <img width="468" alt="image" src="https://github.com/user-attachments/assets/b3a10e9b-ac53-429d-8780-a03120316df4" /> | task-4795450 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the 'Contact Us' button in the website editor would duplicate after multiple undo/redo actions. The fix prevents unnecessary data syncing during editor operations, ensuring a smoother editing experience. This improves stability and reduces potential user confusion.
Original PR description
*=website Steps to Reproduce : 1. Go to `edit` mode. 2. Drop at least four block snippets. 3. Drop a badge in the header next to the _Contact Us_ button. 4. Undo twice → the _Badge_ reappears. 5.…
*=website Steps to Reproduce : 1. Go to `edit` mode. 2. Drop at least four block snippets. 3. Drop a badge in the header next to the _Contact Us_ button. 4. Undo twice → the _Badge_ reappears. 5. Undo twice more → the _Badge_ reappears again. 6. Redo three times → the _Contact Us_ button is duplicated. Issue: The `Contact Us` button in the header was duplicated after multiple undo/redo actions. Moreover, the `Badge` snippet did not behave as expected during undo/redo. Reason: When the uncommitted draft was cleared before undo/redo, the `OdooEditor` observer triggered the `OdooField` observer to roll back and flush mutations. However, this rollback was considered a new mutation by the `OdooEditor` observer. On the next undo, the `OdooField` observer tried to sync with these artificial mutations, causing duplication of buttons and badges. Fix: Deactivate the `OdooEditor` observer during undo/redo operations to prevent recording unnecessary mutations. After discarding the draft, reactivate the `OdooEditor` observer. This avoids redundant syncs and resolves the duplication issue. task-4558376 Forward-Port-Of: odoo/odoo#233002 Forward-Port-Of: odoo/odoo#223579
This update corrects a technical issue where automatic PEPPOL endpoint filling for Belgian companies was failing due to invalid characters in the company registry. The fix adds specific valid characters for EAS, ensuring accurate PEPPOL endpoint generation and preventing data entry errors. This improves the reliability of our system for handling Belgian VAT transactions.
Original PR description
When company registry contains characters such as dots (.), automatic fill-up of peppol_endpoint field fails because dots are valid peppol identifier characters, but are clearly not part of belgian VAT identifier. The solution is therefore to add an EAS-specific set of valid characters to prevent this situation no-task
This update addresses a technical issue where form changes were causing confusing error messages. The team added a fallback to capture more information about these errors, providing better insight for developers. This improves the stability and reliability of the Odoo platform.
Original PR description
Related to https://runbot.odoo.com/odoo/error/234669: somewhere somehow an onchange warning is malformed (it's not a mapping) and the Form is unable to cope with it, leading to a rather unhelpful error. TBH I don't understand how it can happen as `onchange` has a rewriting layer between the `warning` out of onchange methods and the one it sends to the client. And most of the `onchange` overrides are preprocessing not post. And the two overrides which do postprocess modify `values` in place. Add a fallback to attempt to get more insight into this error. Forward-Port-Of: odoo/odoo#238705
This update resolves an issue where notifications triggered by the 'Data Merge' action within the Data Cleaning app weren't functioning correctly in the messaging menu. The fix ensures that notifications are properly routed to the correct inbox, improving the user experience when identifying duplicate records.
Original PR description
**Steps to reproduce:** - Install `Data Cleaning` app - Activate notification in Odoo in the admin user profile - Create a few duplicate contacts - Go the the "Data Merge: Find Duplicate Records"…
**Steps to reproduce:**
- Install `Data Cleaning` app
- Activate notification in Odoo in the admin user profile
- Create a few duplicate contacts
- Go the the "Data Merge: Find Duplicate Records" scheduled action
- Run the action manually
- You should see new notifications telling you that they found potential duplicates
- In the top right MessaginMenu click on the notification, it opens a chatter
- Try to send a message in the chat window
- Traceback : `AttributeError: 'data_merge.model' object has no attribute '_get_thread_with_access'`
**Issue:**
The model doesn't inherit `mail.thread` so it uses `self.env['mail.thread']` directly to send notification:
```
self.env['mail.thread'].sudo().message_notify(
...
model=self._name,
notify_author=True,
partner_ids=partner_ids,
res_id=self.id,
)
```
But when sending the information with the `model` and `res_id` parameters the newly created `Store` uses `self.add("mail.thread", {"id": data.id, "model": data._name, **values})` and the message is assigned to a non-existing thread in the frontend.
**Fix:**
Explicitly check if the message is a `user_notification` and redirect the user to the discuss inbox if it's the case by reapplyng part of https://github.com/odoo/odoo/commit/b3be992c57dc5e412a127d05fc50b059814523aa
opw-5101510
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#238563
Forward-Port-Of: odoo/odoo#234737This update resolves a technical issue within the HTML Editor plugin that caused a traceback when users selected and colored links, specifically when the selection landed on a 'feff' character. The fix ensures the editor correctly handles cursor positioning after selections, preventing errors and improving the overall user experience.
Original PR description
Problem: When the user selects a link to color and the selection falls on a `feff` character, a traceback occurs. Cause: After commit 927f4b973932d14961c148e13473017651a60dc0, we preserve the…
Problem: When the user selects a link to color and the selection falls on a `feff` character, a traceback occurs. Cause: After commit 927f4b973932d14961c148e13473017651a60dc0, we preserve the selection at: https://github.com/odoo/odoo/blob/bee7fc1f955c52a88b527ad9a2ddf0021529bbc7/addons/html_editor/static/src/main/font/color_plugin.js#L247-L247 and then call `getFonts()`, which internally uses `this.dependencies.split.splitAroundUntil()`. If the selection is on a `feff` node, `splitAroundUntil()` can clear those nodes because `splitElement()` inside it dispatches to `clean_handlers` with the selected element containing the `feff`. Since the preserved cursor offset refers to the node before the `feff` was removed, restoring it throws: `The offset x is larger than the node's length (y).` Solution: After `splitAroundUntil()`, adjust the preserved cursor offsets if the nodes were mutated to ensure they remain valid. Steps to reproduce: It is difficult to reproduce manually, but the issue occurs when coloring a link with the selection on a `feff`. A test case replicating the situation can be based on the original failing template in the customer’s database. opw-4953943 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234328
6 changes
Resolved issues and error corrections
This update fixes an issue where journal items displayed in financial reports were incorrectly linked to the wrong account groups. The fix ensures that journal items are accurately associated with the corresponding account group, improving the accuracy of financial reporting.
Original PR description
Repro steps: 1. Create account groups 2. Go to general ledger report 3. Click on 'Journal Items' of one of the account groups lines Problem: The journal items shown don't belong to the account group that it should belong to. Fix: This commit fixes this issue by adding the correct action_domain of account_id.group_id. opw-5180867 Forward-Port-Of: odoo/enterprise#100191
This update eliminates a technical issue that caused duplicate reversal and deferral entries in the accounting system, particularly when invoice dates fell within the same month. By adjusting the deferral period calculation, this fix reduces accounting noise and improves the accuracy of financial reports.
Original PR description
When generating deferred entries from invoice lines, certain scenarios led to the creation of both a reversal and a deferral for the same amounts. These entries would effectively cancel each other out, creating unnecessary noise in the journal entries. This issue primarily occurred when the start date, end date, and accounting date all fell within the same calendar month. The problem was exacerbated by the introduction of the `full_months` computation method in https://github.com/odoo/enterprise/commit/5dca9c0c2691cba2335e110ad63a2dcc8bbf6d57. To correctly handle this method and prevent the erroneous paired entries, the end date must now be adjusted by subtracting one month when calculating the deferral period. opw-5000337 Forward-Port-Of: odoo/enterprise#101258 Forward-Port-Of: odoo/enterprise#100507
This update resolves a test failure related to user switching in the MRP work order module. The fix ensures the test waits for shop floor records to fully load before checking their presence, preventing intermittent failures. This improves the reliability of the test suite.
Original PR description
The test `test_shop_floor_my_wo_filter_with_pin_user` sometimes fails on these steps:…
The test `test_shop_floor_my_wo_filter_with_pin_user` sometimes fails on these steps: https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L177-L190 https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L196-L206 https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L212-L221 This happends since changing the user requires some time to display the related shopfloor records, but the steps check the number of visible records as soon as it has switched rather than when it is sure that the records are displayed. #### Fix: Since switching employees will first empty the recordset and later display the related records, we can split the steps in two. We first check that we switched users, then we check the existence of a record that is not present for the previous user, and only then perform the related checks. #### runbot-226734 Forward-Port-Of: odoo/enterprise#100908 Forward-Port-Of: odoo/enterprise#100746
This update fixes an issue where IoT reports were sometimes printed multiple times. The change ensures that report actions are only executed once, whether through a standard websocket or a previous longpolling method. This improves report reliability and avoids unnecessary printing.
Original PR description
In order to prevent duplicate IoT actions, we now ensure that websocket actions have not already been called through longpolling. odoo/odoo#236917 Forward-Port-Of: odoo/enterprise#101257 Forward-Port-Of: odoo/enterprise#100161
This update resolves an issue where users were unexpectedly redirected back into the sign flow after completing a document signature. The fix ensures users return directly to the correct record (like an Offer or Invoice) without lingering 'Sign' breadcrumbs, improving the user experience and navigation.
Original PR description
Issue:
- After signing a document, the user is redirected to the correct
record form (e.g., Offer, Invoice) but an extra "Sign" breadcrumb
remained in the navigation.
- Clicking that breadcrumb sent the user back into the sign flow,
creating confusion and breaking the expected navigation behavior.
Fix:
- Updated the close flow in the thank you dialog to use
`stackPosition: "replacePreviousAction"` when a reference document
exists, ensuring the sign dialog controller is removed cleanly.
- Fallbacks use `clearBreadcrumbs` when no reference document is
linked (standalone sign documents).
- This restores correct breadcrumb generation across all sign flows.
Impact:
- Users return to the proper parent record without leftover sign
breadcrumbs.
- Prevents unexpected navigation back into the sign request.
Task: 5175992
Forward-Port-Of: odoo/enterprise#99525This update resolves an issue where the SAFT export process would fail when a journal entry lacked a partner but included a receivable account. The fix ensures the system can now correctly generate SAFT files in these scenarios, addressing a potential reporting error. This improves compliance with accounting standards.
Original PR description
If we try to export a SAF-T file when a line doesn't have any partner but having a receivable account, then a traceback is displayed.
(Backport of #98240)
How to reproduce?
1. Use a company with a localization using SAF-T (e.g. l10n_dk)
2. Create and post a journal entry with no partner, and with a line having a receivable account.
3. Go on the general ledger, and export in the SAF-T format
opw-5260937
Forward-Port-Of: odoo/enterprise#100667
Forward-Port-Of: odoo/enterprise#10029612 changes
Resolved issues and error corrections
This update fixes an issue where the payroll system was incorrectly referencing employee version records instead of the main employee records. This change ensures accurate calculations and reporting related to employee compensation, particularly in Switzerland. The fix was triggered by a recent update to the Odoo Enterprise system.
Original PR description
Commit [46052c4](https://github.com/odoo/enterprise/commit/46052c4bc5ad1bd2549a6125202e0671b56beac8) introduced the `hr.version` model, which contains historical information about an employee record. Some of the updated lines use the hr.version ID when they should use `hr.employee`. Ticket [5218215](https://www.odoo.com/odoo/project.task/5218215) Forward-Port-Of: odoo/enterprise#100079
This update fixes an issue where the 'Journal Items' link in the General Ledger report incorrectly displayed items not associated with the selected account group. The fix ensures that users see the correct journal items linked to their account groups, improving report accuracy and data reliability.
Original PR description
Repro steps: 1. Create account groups 2. Go to general ledger report 3. Click on 'Journal Items' of one of the account groups lines Problem: The journal items shown don't belong to the account group that it should belong to. Fix: This commit fixes this issue by adding the correct action_domain of account_id.group_id. opw-5180867 Forward-Port-Of: odoo/enterprise#100191
This update fixes an issue where debit notes created in Uruguay were incorrectly assigned as e-invoices (type 111). The fix ensures debit notes automatically use the correct document type (113), streamlining invoice processing for Uruguayan customers. This improves data accuracy and compliance.
Original PR description
**Steps to reproduce:** * Install and activate the **Uruguayan Localization** for the company. * Create a contact located in Uruguay. * Create an invoice for this customer and set **Document Type =…
**Steps to reproduce:** * Install and activate the **Uruguayan Localization** for the company. * Create a contact located in Uruguay. * Create an invoice for this customer and set **Document Type = 111 (e-Invoice)**. * From the invoice's gear icon, create a **Debit Note**. **Observed behavior:** * The debit note is automatically assigned **Document Type 111 (e-Invoice)**, even though it should use **113 (e-Invoice Debit Note)**. * Attempting to change the document type manually only shows 113 as an option, confirming the debit note should not have been set to 111. **Cause:** * `_compute_l10n_latam_document_type()` applies a rule that assigns Document Type **111** to all Uruguay electronic invoices with RUT identification. * This logic does **not** check whether the move is a **debit note** (`m.debit_origin_id`), and therefore incorrectly overrides the expected debit note document type. * The override prevents the correct selection (internal_type == *debit_note*) from being applied. **Fix:** * Add a condition in the automatic e-Invoice assignment logic. * Debit notes now bypass the e-Invoice assignment and fall through to the parent method, which correctly assigns **Document Type 113**. opw-5154599 Forward-Port-Of: odoo/enterprise#100938
This update fixes a problem where annotations in PDF exports of Balance Sheet reports were not displayed in chronological order. Now, the oldest annotations will appear first, ensuring a more accurate and understandable report. This improves the clarity and reliability of financial reporting.
Original PR description
We expect the oldest annotations to appear first when exporting to a PDF.
To reproduce:
- Go to any report such as the Balance Sheet
- Open the chatter for an account
- Post 2 messages ("first" and "second" for exemple)
- Export the report to PDF
This was introduced in https://github.com/odoo/enterprise/pull/95307
Forward-Port-Of: odoo/enterprise#100475This update resolves a test failure that occurred when the demo data was used. The fix ensures the test no longer interferes with the demo environment, preventing disruptions and maintaining the accuracy of the demo setup. This improves the reliability of the demo for testing and demonstration purposes.
Original PR description
Some tests were failing when the demo data were installed. This commit fixes the test so that it doesn't interfere with demo data. Related build error: https://runbot.odoo.com/odoo/runbot.build.error/234529 task-5386529 Forward-Port-Of: odoo/enterprise#101301
This update resolves an issue where bank statement creation would fail when the Chart of Accounts wasn't properly configured. The fix ensures the system only attempts to match accounts when valid accounts are present, preventing a syntax error and improving the reliability of bank statement processing.
Original PR description
**Steps to Reproduce:** 1. Install the **Accounting** module without demo data. 2. In "**Chart of Accounts**", change the type of all accounts (e.g.; Expenses). 3. In "**Bank**" Journal, create a new bank statement line and try to save it. **Error:** ``` SyntaxError - syntax error at or near ")" LINE 19: AND aml.account_id IN () ``` **Cause:** A **IN** condition is evaluated with an empty tuple `AND aml.account_id IN ()`. This is due to that there are no `account_ids`. **Fix:** This commit only executes the SQL query when there are valid accounts to consider. sentry-7059353053 Forward-Port-Of: odoo/enterprise#100931 Forward-Port-Of: odoo/enterprise#100459
This update corrects a visual issue where the activity badge within the bank reconciliation widget was misaligned. The fix removes a styling class that was causing the misalignment, ensuring the badge now appears correctly positioned on the icon. This improves the user experience and visual consistency of the bank reconciliation feature.
Original PR description
Current behavior before PR: The activity badge inside the bank reconciliation widget was misaligned, <img width="55" height="60" alt="image" src="https://github.com/user-attachments/assets/0f99ea55-fedd-401a-a65e-226296070e32" /> Desired behavior after PR is merged: The activity badge now sits in the correct position on the icon. <img width="62" height="55" alt="image" src="https://github.com/user-attachments/assets/abf96aed-73d4-4153-8e0a-56937d4ff08a" /> Changes implemented: - Removed `fa-fw` class. - Removed the unnecessary 'fa-fw' class from comment and paperclip icon. task-5354994 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#100573
This update resolves an issue where the ChatGPT plugin button was disabled when no text selection was made in the HTML editor. Now, the button consistently enables the ChatGPT window, regardless of whether a selection is present, ensuring users can always access the AI features.
Original PR description
This PR fixes an issue with the toolbar button. Before when no selection were applied in the HTML Editor, the button would be disabled. This PR introduce a fix that makes the button enabled in two scenarios: - Either the user has no selection, clicking the button will then open the chat window without any AI button, as it does with the powerbox buttons, - Or the user has a selection, then clicking the button will result in opening the chat window with the AI buttons as it was already the case. If the user has a selection that is empty, then the button remains visible but is disabled. Forward-Port-Of: odoo/enterprise#101332
This update corrects a technical error in how Odoo processes webhook events related to virtual expense cards. Specifically, it addresses a situation where 'None' shipping values were incorrectly treated as dictionaries, preventing proper expense tracking. This fix ensures accurate expense reporting data.
Original PR description
Add a fix to a pattern of error found in webhook events where virtual cards whose shipping value is "None" would be accessed as dict Forward-Port-Of: odoo/enterprise#100703
This update fixes a technical issue that caused duplicate journal entries (reversals and deferrals) to be created, leading to confusing accounting reports. The change ensures that deferred entries are calculated correctly, particularly when invoice dates fall within the same month, resulting in cleaner and more reliable financial records.
Original PR description
When generating deferred entries from invoice lines, certain scenarios led to the creation of both a reversal and a deferral for the same amounts. These entries would effectively cancel each other out, creating unnecessary noise in the journal entries. This issue primarily occurred when the start date, end date, and accounting date all fell within the same calendar month. The problem was exacerbated by the introduction of the `full_months` computation method in https://github.com/odoo/enterprise/commit/5dca9c0c2691cba2335e110ad63a2dcc8bbf6d57. To correctly handle this method and prevent the erroneous paired entries, the end date must now be adjusted by subtracting one month when calculating the deferral period. opw-5000337 Forward-Port-Of: odoo/enterprise#101258 Forward-Port-Of: odoo/enterprise#100507
This update prevents Odoo from endlessly checking the status of NFS-e invoices if the city hall hasn't responded after 10 days. This reduces unnecessary user credit consumption and ensures a smoother process for users. The system now automatically flags invoices that haven't been processed, notifying the user.
Original PR description
Previously, when an NFS-e was submitted to the city hall, a cron job was continuously checking its status. However, if the city hall never responded, the system kept checking indefinitely, leading to unnecessary consumption of user credits. To address this, a limit has now been introduced on these cron checks. If more than 10 days have passed since the invoice was submitted, the invoice is moved to an error status (thereby excluding it from further cron checks), and a log note is posted informing the user. **task**-4776548
This update resolves a skipped test related to map view links within the documents_spreadsheet module. The fix involves adding the `web_enterprise` module as a dependency, ensuring the test now runs correctly and accurately validates the functionality. This improves the reliability of our testing process.
Original PR description
Map view link test was skipped because it depended on `web_enterprise` module, which is not a dependency of `documents_spreadsheet` module. To fix this, we move this test to `test_spreadsheet_edition` module, with `documents_spreadsheet` and `web_enterprise` as new dependencies.
34 changes
Resolved issues and error corrections
This update resolves a problem where images set to a percentage width in the document footer were not being displayed correctly when using wkhtmltopdf. The fix reverts a previous change that caused this issue, ensuring images resize properly and appear as intended. This improves the visual quality of documents generated from the HTML editor.
Original PR description
Problem: wkhtmltopdf doesn't render images with both width and height set in percentage. Solution: When resizing in percentage, set only the width. This effectively reverts a change introduced in 920cea5ff567c9113370174570d0ead0bbfa767a. Steps to reproduce: - Add an image to the document footer. - Set the image size to 50%. - Print the document. - The image does not appear. opw-5168087 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update clarifies the ESIC contribution rules within the payroll system. The tooltip now specifies that employee and employer contributions are calculated when gross wages are below ₹21,000. This ensures accurate reporting and compliance with ESIC regulations.
Original PR description
We are updating the field tooltip. Before: - l10n_in_esic_employee_amount: Employee contributions towards ESIC(Employees’ State Insurance Corporation) are calculated based on their gross wages. - l10n_in_esic_employer_amount: Employer contributions towards ESIC (Employees’ State Insurance Corporation) are calculated based on the employee’s gross wages. After: - l10n_in_esic_employee_amount: Employee contributions apply when the gross wage is below ₹21,000 - l10n_in_esic_employer_amount: Employer contributions apply when the gross wage is below ₹21,000 Task: 5383839
This update resolves an issue where invalid PDF tests would fail due to compatibility problems with different versions of the PyPDF library. The fix standardizes error handling, ensuring the test consistently passes regardless of the PyPDF version used, improving the reliability of the sign document process.
Original PR description
## Case 1: When `pypdf2_2` is not installed, it falls back to using the pypdf package. (Ref1) This triggers a warning during the test case when it tries to parse an invalid PDF. This commit…
## Case 1: When `pypdf2_2` is not installed, it falls back to using the pypdf package. (Ref1) This triggers a warning during the test case when it tries to parse an invalid PDF. This commit suppresses the warning to ensure the test runs without warnings. Ref1: https://github.com/odoo/odoo/blob/26a5384af0af8fc6e6b5a10bea277f937e2b3481/odoo/tools/pdf/__init__.py#L42-L46 ## Case 2: With **PyPDF2===1.26.0**, the line at [1] raises a `PyPDF2.utils.PdfReadError: EOF marker not found`. This exception is not handled by the same except block but is instead handled later in the flow at [2]. As a result, the test raises a **UserError**, causing the assertion to fail. On the other hand, when `pypdf2_2` or `pypdf` is installed, the _PdfFileReader_ raises a **UnicodeDecodeError**, which is then handled as a **ValidationError**, allowing the test to pass as expected. This commit adds handling for **PdfReadError** in method `get_valid_pdf_data()` to unify the behavior across all supported PyPDF versions. 1: https://github.com/odoo/enterprise/blob/f79601c62ca629dc01a5c1ad5520b0bb44a169d0/sign/utils/pdf_handling.py#L27 2: https://github.com/odoo/enterprise/blob/f79601c62ca629dc01a5c1ad5520b0bb44a169d0/sign/models/sign_document.py#L433-L437 Runbot-234021, 234022
This update resolves a crash issue that occurred within the website builder when a form contained a Many2One field with no associated records. The fix mirrors the approach used for many2many and one2many fields, displaying a disabled input when a field has no data. This ensures a stable and reliable user experience for website form creation.
Original PR description
With the [website builder refactor], the code was not robust in case there were no records for a many2one field in a form.
Steps to reproduce:
- Open website builder on a form in a new database
- Set action "Send an email"
- Add a field with type "Alias Domain" ("Option List" must be empty)
- Change "Selection type" to "Radio"
- Bug: crash
[website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
task-5238496
Forward-Port-Of: odoo/odoo#234586This update corrects an error in the Belgian VAT return XML generation, preventing rejections by the government. The issue stemmed from an outdated filter within the accounting module, leading to incorrect grid numbers being included. This fix ensures accurate VAT return submissions for Belgian companies.
Original PR description
**Steps to reproduce:** - Install accountant and l10n_be_reports - Switch to a Belgian company (e.g. BE Company CoA) - Create an Intra-Community invoice: * Customer: [EU customer] * Invoice Date:…
**Steps to reproduce:** - Install accountant and l10n_be_reports - Switch to a Belgian company (e.g. BE Company CoA) - Create an Intra-Community invoice: * Customer: [EU customer] * Invoice Date: [last month] * Fiscal Position: [Intra-Community] * Invoice Lines: [a product with "0% EU M" tax] - Confirm the invoice - Go to "Accounting / Accounting / Closing / Tax Returns" - Open the period containing the created invoice - Mark all lines as "Reviewed" - Validate the VAT Return **Issue:** In the generated XML, there is a line for grid number "46L", which should not appear. Therefore, the XML is rejected by the government. Same issue with grid number "46T". These 2 grids are sub-section of grid number "46" and should not appear in the XML. Cause: Previously, they were filtered out, but since this commit https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b, the formula has changed from "46L" to "-46L" but the excluding filter has not been updated. opw-5344566
This update fixes an issue where annotations in PDF exports of Balance Sheet reports were not displayed in chronological order. The changes ensure that the oldest annotations appear first, providing a more accurate and user-friendly report. This improves the clarity and reliability of financial reporting.
Original PR description
We expect the oldest annotations to appear first when exporting to a PDF.
To reproduce:
- Go to any report such as the Balance Sheet
- Open the chatter for an account
- Post 2 messages ("first" and "second" for exemple)
- Export the report to PDF
This was introduced in https://github.com/odoo/enterprise/pull/95307This update prevents the website's product shop from showing an empty "alternative products" section. Previously, even when no alternatives were listed, the section would still appear. This change ensures a cleaner user experience by only displaying relevant product options.
Original PR description
### Issue: In this issue, alternative products section will continue to be shown in website_sale, even if the product has no alternative products, due to editing alternative products using Editor. #### To reproduce: 1- Create a product with an at least one alternative product. 2- On product shop page, using Editor, edit the description of alternative products section. 3- Remove alternative products of the product. 4- As seen, the alternative products section is still shown, even though it is empty. #### Cause: This is caused due to 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 which commented out `display: none` for empty snippets. https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/website/static/src/snippets/s_dynamic_snippet/000.scss#L2-L5 opw-5253884 Forward-Port-Of: odoo/odoo#237117
This update resolves a technical error that prevented the generation of payroll export files. The fix corrects a field name mismatch, ensuring accurate retrieval of employee data. A new test suite has been implemented to guarantee the reliability of the export process and data integrity.
Original PR description
The export generation crashed due to a mismatch between field names — the code was referencing employee_ids, while the model actually defines employee_id. Since the Prisma code is now stored on the employee model, the logic was updated to correctly access the employee_id field and retrieve the related Prisma code. Additionally, a comprehensive test suite was added to validate Prisma code behavior, including: - validation of code length for employees, companies, and work entry types, - handling of codes across different companies, - and the complete Prisma export flow (from work entry creation and validation to export file generation). task-5153727 Forward-Port-Of: odoo/enterprise#101039 Forward-Port-Of: odoo/enterprise#96743
This update resolves a bug where the 'lock' action in the document previewer's action menu wasn't updating correctly. The fix ensures that the action menu reflects the current document status, providing consistent functionality for users. This improves the overall document management experience.
Original PR description
Steps to reproduce =================== - Preview any documents. - Click on the actions menu and lock the document. - Now go to the actions menu again. => The set of options is not updated. Technical =========== - The action menu, which we are using inside the file previewer, is passed explicitly inside the FileViewer component of the document. We were using the `record.load()`, which will not have any effect on the FileViewer component and that's why the action menu was not updating. After this commit ================== - Used the `this._notifyChange()` method, which closes the preview and loads the model to align with the same behaviour as other actions. Task-4988116 Forward-Port-Of: odoo/enterprise#100255 Forward-Port-Of: odoo/enterprise#91760
This update fixes an issue where PDF payslips generated from payruns were named 'new payslip' instead of including the employee's name and pay period. Now, payslips will correctly display 'Salary Slip - <employee name> - <time period>', ensuring accurate and professional payroll documentation. This improves the user experience and clarity of payroll reports.
Original PR description
[FIX] hr_payroll: write full name on payslip generated from payrun _ ## Short functional explanation of the error When generating a payslip from a payrun for an employee, the name of the PDF payslip…
[FIX] hr_payroll: write full name on payslip generated from payrun _ ## Short functional explanation of the error When generating a payslip from a payrun for an employee, the name of the PDF payslip is simply "new payslip" instead of "Salary Slip - <name of employee> - <time period of the slip>" ## Reproduction Steps 1. Go to Payroll and click on the Payslips tab > payslips. 2. Click on Pay Run. Select Regular Pay and click Continue. 3. Select an employee for which you'd like to generate the payslip. 4. Click on the employee row in the list view. 5. Click Compute sheet > Print. ## Expected behavior A PDF with name "Salary Slip - <employee name> - <time period>" is generated. ## Unexpected Behavior A PDF with name "new Payslip" is generated. ## Origin of the issue When printing the slip with this flow, we don't call the method ```_compute_name()``` used to compute the name of the current slip. Therefore, it stays at 'New Slip', which is the default name. Henceforth, we have to call this method manually when printing the slip. _ opw-5216796 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#101056
This update prevents a critical error that occurred when users created or modified fields with incorrect domain settings. The fix wraps domain evaluations in a try-except block, gracefully handling invalid domains and providing a clear error message to the user. This ensures a smoother user experience and prevents data loss.
Original PR description
Currently an error is generated when the user tries to create or write fields with wrong domain. Steps to produce an error - Install sale_management and create a new field with the below detail -…
Currently an error is generated when the user tries to create or write fields
with wrong domain.
Steps to produce an error
- Install sale_management and create a new field with the below detail
- Model: `Sales order`
- Field Type: `one2many`
- Related Model: `sale.order`
- Relation Field `partner_id`
- Domain: `[('sale_order_id', 'in', sale_order_ids)]`
- Click on save
This error occurs because we have a constraint in the domain, and it is triggered
when the user modifies the domain at code line [1]. Inside this constraint, we use
`safe_eval` to evaluate the domain. During this evaluation, an error is raised because
the user entered an incorrect domain.
This commit fixes the above issue by wrapping `safe_eval` inside a `try–except`
block and raising a `ValidationError` with an appropriate message when an error occurs during domain evaluation.
[1]- https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/odoo/addons/base/models/ir_model.py#L651-L654
sentry-6964956583
Forward-Port-Of: odoo/odoo#237937
Forward-Port-Of: odoo/odoo#236891This fix resolves an issue where the website page URL input field would become unstable with slow connections, causing data loss. It also corrects a related problem where the 'Redirect Old Url' element wasn't hidden when reverting to the original URL. The update ensures a smoother and more reliable user experience when editing website pages.
Original PR description
Scenario: - edit a website page (eg: /test that you create) - go to Site > Properties - have a slow connection and write in field "Page URL" for some seconds Result: the input jitter, if going too…
Scenario: - edit a website page (eg: /test that you create) - go to Site > Properties - have a slow connection and write in field "Page URL" for some seconds Result: the input jitter, if going too fast the text can be removed to get previous version. Secondary issue: if we cancel our change and set back the original URL, the "Redirect Old Url" part is not hidden. Reason: we trigger onchange at each input event, so if we write 20 letters we will possibly still have 20 onchange that are ongoing and will set back older version of the field value. The secondary issue is because we are using a field using useInputField and FieldUrl but we are hacking it to remove the "/" prefix inside the input. So when the invisible modifier is checked, we check eg. "old_url=/test" against "url=test" that are always different. With this fix: Since the triggered onchange were only to update quicker the condition `invisible="old_url == url"`, we trigger them only if that condition will change, and debounce it to prevent the now single onchange of happening in the middle of text input. And for the secondary issue, we add and remove the / when triggering the onchange. opw-4517181 Forward-Port-Of: odoo/odoo#238544 Forward-Port-Of: odoo/odoo#200016
This update resolves an issue where animation options would unexpectedly reset when re-selecting text within the website builder. The fix normalizes text formatting to ensure consistent comparisons, preventing incorrect mismatches and maintaining the intended animation state. This improves the user experience and stability of the website builder.
Original PR description
Steps to reproduce: case 1: 1. Select all text in the footer. 2. Apply an animation (e.g. slide). 3. Re-select the same text (e.g. by triple-clicking or drag-selecting). 4. Observe that the animation…
Steps to reproduce: case 1: 1. Select all text in the footer. 2. Apply an animation (e.g. slide). 3. Re-select the same text (e.g. by triple-clicking or drag-selecting). 4. Observe that the animation option resets unexpectedly. Case 2: 1. Select all text in a paragraph. 2. Apply a text highlight. 3. Re-select the same text (e.g. by triple-clicking or drag-selecting). 4. Apply an animation (e.g. on scroll). 5. Re-select the same text again. 6. Observe that the animation option resets unexpectedly. Cause: The previous comparison between `selection.textContent()` and `ancestor.innerText` did not account for differences in whitespace and formatting, leading to false mismatches even when the selected and ancestor text appeared identical. Fix: Normalized both the selection and ancestor text by collapsing multiple whitespace characters and trimming leading/trailing spaces before comparison. This ensures that visually identical text is treated as equal, maintaining the animation option state when re-selecting the same text. Forward-Port-Of: odoo/odoo#227780
This update corrects a bug in the vehicle availability calculations for the l10n_be_hr_payroll_fleet module. It now accurately excludes vehicles flagged for change (plan_to_change_car or plan_to_change_bike) with a 'False' status, ensuring they are correctly marked as unavailable. This prevents incorrect vehicle availability reporting.
Original PR description
Refine _get_available_vehicles_domain to consider only vehicles with plan_to_change_car or plan_to_change_bike set to True as available. This ensures vehicles planned for change but marked False are treated as unavailable. Related task: 4963484. Forward-Port-Of: odoo/enterprise#101266 Forward-Port-Of: odoo/enterprise#90812
This update resolves an issue preventing bank statement creation when the chart of accounts isn't properly configured. The fix ensures the system correctly identifies and associates accounts with bank statements, preventing a syntax error and improving the reliability of bank statement processing.
Original PR description
**Steps to Reproduce:** 1. Install the **Accounting** module without demo data. 2. In "**Chart of Accounts**", change the type of all accounts (e.g.; Expenses). 3. In "**Bank**" Journal, create a new bank statement line and try to save it. **Error:** ``` SyntaxError - syntax error at or near ")" LINE 19: AND aml.account_id IN () ``` **Cause:** A **IN** condition is evaluated with an empty tuple `AND aml.account_id IN ()`. This is due to that there are no `account_ids`. **Fix:** This commit ensures that the SQL query is executed only when there are remaining statement lines and valid account IDs to process. If either is missing, the method now returns early and updates `cron_last_check`. sentry-7059353053 Forward-Port-Of: odoo/enterprise#100459
This update fixes a reporting issue where journal items weren't correctly linked to the associated account groups. The fix ensures that reports accurately display the correct financial items for each group, improving the accuracy of financial reporting. This resolves a data discrepancy impacting financial analysis.
Original PR description
Repro steps: 1. Create account groups 2. Go to general ledger report 3. Click on 'Journal Items' of one of the account groups lines Problem: The journal items shown don't belong to the account group that it should belong to. Fix: This commit fixes this issue by adding the correct action_domain of account_id.group_id. opw-5180867 Forward-Port-Of: odoo/enterprise#100191
This update corrects a bug in the aged receivable report that prevented accurate data display when invoices lacked a due date. The fix ensures the report correctly identifies outstanding invoices by aligning the date comparison logic, resolving a discrepancy between the report query and the filtering method.
Original PR description
step to reproduce: - create a invoice and confirm it - remove due date from it and save it - ensure the confirmed invoice do not payment term or due date - open aged receivable report - open this…
step to reproduce: - create a invoice and confirm it - remove due date from it and save it - ensure the confirmed invoice do not payment term or due date - open aged receivable report - open this entry <img width="1599" height="238" alt="image" src="https://github.com/user-attachments/assets/010f97f4-0d50-4e5a-9366-ae67d17e2bb7" /> Observation: - on clicking the entry, when redirected to list view, there are `0` records. Issue: - The query which is used to display data on report uses `COALESCE(account_move_line.date_maturity, account_move_line.date)` https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L222-L226 - while the method `_build_domain_from_period` uses only `date_maturity` in domain redirecting to list view - This creates inconsistencies between two. https://github.com/odoo/enterprise/blob/ffc329e4ff2bd6512164ecd4206210fd5c9264b9/account_reports/models/account_aged_partner_balance.py#L383-L394 opw-5237298 Forward-Port-Of: odoo/enterprise#99883
This update ensures that bills received through the PEPPOL network are automatically posted to the accounting system, even when auto-post functionality is enabled for the partner. Previously, these bills remained in a draft state, requiring manual processing. This change streamlines the billing process and improves efficiency.
Original PR description
Currently, even if a partner has auto-post bills enabled, the incoming bills stay in the draft state. This change addresses that issue. Task-5373302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238473
This update ensures that a checkered background is consistently displayed in the color preset preview area, regardless of whether a gradient or custom color is selected. Previously, custom colors lacked this visual indicator of transparency. This improves the user experience when customizing website themes.
Original PR description
[*]=html_builder Steps to reproduce: 1. Go to website and click edit. 2. Switch to the _Theme_ tab and click on _Color Presets_. 3. Click on first color preset, then open the background color picker.…
[*]=html_builder Steps to reproduce: 1. Go to website and click edit. 2. Switch to the _Theme_ tab and click on _Color Presets_. 3. Click on first color preset, then open the background color picker. 4. Switch to gradient tab, select any gradient, and adjust the opacity. 5. Now, click on second color preset, open the background color picker. 6. Switch to the custom tab, select any color, and adjust its opacity. Issue: When a gradient is selected (first color preset), the color preset preview area correctly displays a checkered background to indicate transparency. However, when a plain custom color is selected (second color preset), the checkered transparency background is missing from the color preset preview area. Fix: Set the value of `--PreviewAlphaBg-background-size` variable as `32px`. Moreover, extended the `%o-preview-alpha-background` placeholder in the `color_picker_theme_tab.scss` file to ensure the checkered background is consistently applied for both gradient and custom color selections. | Before | After | |-----------------------------|---------------------------------| | <img width="363" height="308" alt="image" src="https://github.com/user-attachments/assets/dbb64116-70d6-4475-9d41-90c0b591efcd" /> | <img width="363" height="308" alt="image" src="https://github.com/user-attachments/assets/ea8caa90-3518-4219-a980-a2a22f2f427d" /> | task-5226064 Forward-Port-Of: odoo/odoo#234083
This update fixes a potential issue where users could inadvertently modify approval requests, leading to unpredictable system behavior. The change prevents any edits to approval requests, ensuring data integrity and stability within the approval workflow. This resolves a technical concern that could have impacted the reliability of the system.
Original PR description
There is no legitimate use case that should modify the approval request. This would result in unexpected behaviour. task-5269982 Forward-Port-Of: odoo/enterprise#101132 Forward-Port-Of: odoo/enterprise#100273
This update corrects a technical issue in the l10n_dk_nemhandel module by ensuring that Denmark-specific document type checks are applied only to Danish partners. This prevents conflicts with standard Peppol processes and ensures consistent data flow, improving the stability of the system.
Original PR description
Before: - The l10n_dk_nemhandel override of _check_document_type_support replaced the generic Peppol logic and did not accept process_type, causing errors when other localizations relied on the base method. After: - Aligned the method and applied the DK-specific logic only for Danish partners, falling back to the generic Peppol behavior otherwise. Impact: - Prevents unintended overrides towards standard Peppol flow. Forward-Port-Of: odoo/odoo#238543
This update corrects a technical issue that caused duplicate reversal and deferral entries to be created when generating deferred entries from invoices. The fix ensures that deferral periods are calculated correctly, reducing unnecessary noise in financial reports and improving data accuracy. This change primarily impacts the account accounting module.
Original PR description
When generating deferred entries from invoice lines, certain scenarios led to the creation of both a reversal and a deferral for the same amounts. These entries would effectively cancel each other out, creating unnecessary noise in the journal entries. This issue primarily occurred when the start date, end date, and accounting date all fell within the same calendar month. The problem was exacerbated by the introduction of the `full_months` computation method in https://github.com/odoo/enterprise/commit/5dca9c0c2691cba2335e110ad63a2dcc8bbf6d57. To correctly handle this method and prevent the erroneous paired entries, the end date must now be adjusted by subtracting one month when calculating the deferral period. opw-5000337 Forward-Port-Of: odoo/enterprise#101258 Forward-Port-Of: odoo/enterprise#100507
This update corrects a visual issue where the activity badge within the bank reconciliation widget was misaligned. The fix removes unnecessary styling code, ensuring the badge now correctly aligns with the icon. This improves the user experience and visual consistency of the bank reconciliation feature.
Original PR description
Current behavior before PR: The activity badge inside the bank reconciliation widget was misaligned, <img width="55" height="60" alt="image" src="https://github.com/user-attachments/assets/0f99ea55-fedd-401a-a65e-226296070e32" /> Desired behavior after PR is merged: The activity badge now sits in the correct position on the icon. <img width="62" height="55" alt="image" src="https://github.com/user-attachments/assets/abf96aed-73d4-4153-8e0a-56937d4ff08a" /> Changes implemented: - Removed `fa-fw` class. - Removed the unnecessary 'fa-fw' class from comment and paperclip icon. task-5354994 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#100573
This update enhances the clarity of test error messages by including the specific URL being requested during fetch operations. This helps developers quickly identify and resolve difficult-to-reproduce issues, leading to faster bug fixes and improved stability.
Original PR description
Prior to this commit, when a fetch occured during a test at a timing where `mockedFetchFn` was already cleaned, the resulting error message did not give a clue as to what request was attempted. In order to help investigations of difficult to reproduce non-deterministic errors, the url "input" is now also provided.
This update resolves an issue where switching between different media types (like images and icons) in the HTML editor didn't correctly remove outdated class names. This ensures that the HTML editor consistently uses the appropriate classes for each media type, improving the user experience and preventing potential display problems. It's a minor fix for internal consistency.
Original PR description
Before this commit, switching the media type would not properly remove the classes of the element. For example, images can have the class "w-100" while icons cannot. If an image had the class "w-100", switching to an icon would keep the class "w-100", even though this class isn't valid for icons. This commit fixes the code to properly remove all invalid classes. Forward-Port-Of: odoo/odoo#238501
This update ensures Odoo automatically updates remaining modules in the database, regardless of how Odoo is started. Previously, this only worked when Odoo was launched with specific command-line arguments. This change adds a configuration setting to trigger the automatic update process, improving database consistency and preventing potential issues.
Original PR description
In https://github.com/odoo/odoo/pull/216025, we force auto upgrade of modules remaining in the database when `preload_registries` is called. However, this strategy doesn't work if Odoo is not started with the `-d` argument, because `preload_registries` is only called for databases specified in the `-d` argument. This commit fixes the issue by adding a special record in `ir_config_parameter` with key `base.partially_updated_database` to indicate that the next time `Registry.new` is called, it should force auto upgrade of modules remaining in the database. 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#238785 Forward-Port-Of: odoo/odoo#238320
This update allows non-administrator users to validate return requests, previously blocked by access restrictions. The change simplifies the return process by removing a technical hurdle, though preventative checks could still be implemented. This is a functional improvement designed for ease of use.
Original PR description
Before this fix, trying to validate a return with lesser accounting rights than admin raised an access error, stating that the user could not revoke lock date exceptions (whether such exception existed or not). The function used to revoke exceptions was called with sudo(), with the intent of bypassing any such check, but it relied on checking the user group, which sudo() has no impact on. We just patch the condition so that calling the function with sudo() does not block anymore, and revokes the exceptions as expected. Note that this means a non-admin user could revoke a lock date exception set by an admin this way. This is a functional choice, to make the flow easier for everyone. In practice, such a situation could be prevented by checks, and just regular communication and work processes between users.
This update corrects a bug where an extra 'Sign' breadcrumb remained after users completed document signing, leading to confusing navigation. The fix ensures users are correctly redirected back to the original record without being looped back into the sign flow, improving the user experience.
Original PR description
Issue:
- After signing a document, the user is redirected to the correct
record form (e.g., Offer, Invoice) but an extra "Sign" breadcrumb
remained in the navigation.
- Clicking that breadcrumb sent the user back into the sign flow,
creating confusion and breaking the expected navigation behavior.
Fix:
- Updated the close flow in the thank you dialog to use
`stackPosition: "replacePreviousAction"` when a reference document
exists, ensuring the sign dialog controller is removed cleanly.
- Fallbacks use `clearBreadcrumbs` when no reference document is
linked (standalone sign documents).
- This restores correct breadcrumb generation across all sign flows.
Impact:
- Users return to the proper parent record without leftover sign
breadcrumbs.
- Prevents unexpected navigation back into the sign request.
Task: 5175992
Forward-Port-Of: odoo/enterprise#99525This update resolves an issue preventing the monthly payroll summary report from generating accurately. The fix involved correcting how the report template accessed company information, ensuring correct data is displayed. This ensures accurate financial reporting for payroll data.
Original PR description
Step to Reproduce: - install l10n_ch_hr_payroll with demo - create a employee - create a payslip for it, move it to paid stage. - go to Reporting > Monthly summary and generate summary for same period/month Observation: - traceback for faulty template Fix: - After this commit [1] `t-call` is now parametric and cannot not accept its child variables. - to fix this, we pass set res_company for company variable [1] https://github.com/odoo/odoo/commit/eb6e88a25050fff2bd09317739dd51ba451450df opw-5243792
This update ensures that the total account return balance is always displayed when it differs from the current period amount. Previously, this information was only shown if the return amount was lower. This change provides a more complete and accurate view of account return data.
Original PR description
When this https://github.com/odoo/enterprise/pull/91886 got merged, It removed the accumulation of the balance in the return amount. Showing only the amount of the current period. Additionally, the total amount was shown if the amount was different. But, it was only being shown if it was less than the current period amount. The fix ensures it is always shown if the amount is different. task-5172274
This update fixes an issue where short feedback messages were incorrectly wrapping the last word, causing a messy layout. The change ensures that feedback messages display cleanly, particularly when paired with floating rating images, resulting in a better user experience. This resolves a visual inconsistency.
Original PR description
**Current behavior before PR:** - Short feedback wraps the last word unnecessary.  **Desired behavior after PR is merged:** - Short messages wrapped unnecessarily due to block-level element conflicting with floated rating image. This fix ensures cleaner inline layout.  task-[4788428](https://www.odoo.com/odoo/project/1519/tasks/4788428) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238180 Forward-Port-Of: odoo/odoo#215577
This update addresses a technical issue where form changes were causing confusing error messages. The fix adds a fallback to capture more information about these errors, providing better diagnostics for developers. This improves the stability and reliability of Odoo forms.
Original PR description
Related to https://runbot.odoo.com/odoo/error/234669: somewhere somehow an onchange warning is malformed (it's not a mapping) and the Form is unable to cope with it, leading to a rather unhelpful error. TBH I don't understand how it can happen as `onchange` has a rewriting layer between the `warning` out of onchange methods and the one it sends to the client. And most of the `onchange` overrides are preprocessing not post. And the two overrides which do postprocess modify `values` in place. Add a fallback to attempt to get more insight into this error. Forward-Port-Of: odoo/odoo#238705
This update resolves an issue where the 'Returns' button in the tax report was failing due to a misunderstanding of company branch selection. By making the button 'branch_allowed', it now correctly checks for all companies within the branch hierarchy, allowing users to generate returns accurately.
Original PR description
To reproduce the issue: - Create a company with a branch - Give the company and its branch different VAT numbers - Make sure both companies have an opening date, so that they generate returns - Make both companies active in the company selector - Open the tax report - Click on the "Returns" button ===> The following error is raised: "Please select the main company and its branches in the company selector to proceed." This is because the tax report's options only consider one of the two companies (because they have different VAT numbers). The button is not declared as branch_allowed, so when clicked, it checks whether all the companies of the branch hierachy are in the options => they're not => error. We can fix this by simply making the "Returns" button branch_allowed. task-5369592
This update resolves an issue where sorting pivot dimensions in the MRR Breakdown report was not functioning correctly after the introduction of grouping sets. The fix ensures that all dimensions are properly included in the sorting process, allowing users to accurately sort data by Salesperson or other dimensions.
Original PR description
Since the introduction of grouping sets, the order of dimensions was incorrect as soon as an order was set on a dimensions: all the dimensions without order were ignored. Steps to reproduce: - Go to Subscriptions > Reporting > MRR Breakdown - Go the pivot view and group by Event Date and Salesperson - Insert in spreadsheet - Replace all the static formulas by a dynamic PIVOT(1) - Sort the Salesperson dimension by "Descending" => the dates are not sorted This commit fixes the issue by ensuring that all dimensions are included in the order parameter sent to the backend. Task: 5263233 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
5 changes
Resolved issues and error corrections
This update fixes an issue where the 'Journal Items' link in the general ledger report incorrectly displayed items not associated with the selected account group. The fix ensures that the report accurately shows journal items belonging to the correct account group, improving report accuracy and data reliability.
Original PR description
Repro steps: 1. Create account groups 2. Go to general ledger report 3. Click on 'Journal Items' of one of the account groups lines Problem: The journal items shown don't belong to the account group that it should belong to. Fix: This commit fixes this issue by adding the correct action_domain of account_id.group_id. opw-5180867 Forward-Port-Of: odoo/enterprise#100191
This update increases the time allowed for sending log data from the IoT box to the database, resolving previous issues that caused frequent errors. By extending the timeout to 10 seconds and increasing the log sending frequency to 12 seconds, the system is now more reliable in capturing and transmitting data, leading to better operational stability.
Original PR description
Currently the request to send logs to the db from the iot box is at 0.5s timeout. This leads to many exceptions and failed requests. This commit sets the timeout for such requests to 10s (previously 0 5s) and the frequency of sending logs to every 12s (previously 0.5s) Forward-Port-Of: odoo/odoo#238648
This update resolves a test issue where the system relied on pre-existing demo data. The fix removes this dependency, ensuring tests accurately reflect real-world scenarios by no longer using the default, always-present test partner. This improves the reliability and accuracy of our testing process.
Original PR description
## Versions 18.0 to saas-18.2 Fixed from saas-18.3 in PR #237375 ## Issue The test relies on demo data presence and tries to create an SO with an existing partner instead of creating a new partner, always present in the testing environment ## Cause PR #230644 added the test counting on Deco Addict's presence
This update resolves an issue where triple-clicking a checkbox in a checklist would incorrectly select the entire list item. The change ensures that triple-clicking only checks the box, improving the user experience and preventing unintended selections.
Original PR description
**Current behavior before PR:** Currently, triple clicking on a checkbox in a checklist item ends up selecting the list content. This happens because in `selection_plugin` `onTripleClick` handler selects the whole list item. **Desired behavior after PR is merged:** This PR ensures that `onTripleClick` in `selection_plugin` does nothing if tripleclick is triggered when checking a box. task-5361579 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
In the Accounting app (with the *Spain - Veri\*factu* module installed), when a user who is **not** part of the *Accounting / Invoicing* (`account.group_account_invoice`) group would be blocked by an Access Error when trying to open an invoice. Among the Accounting groups, only *Accounting / Read-only* does not inherit from *Accounting / Invoicing*, which means that only the users in *Accounting / Read-only* could not access the invoices. By granting read rights to both *Accounting / Invoici
Original PR description
In the Accounting app (with the *Spain - Veri\*factu* module installed), when a user who is **not** part of the *Accounting / Invoicing* (`account.group_account_invoice`) group would be blocked by an…
In the Accounting app (with the *Spain - Veri\*factu* module installed), when a user who is **not** part of the *Accounting / Invoicing* (`account.group_account_invoice`) group would be blocked by an Access Error when trying to open an invoice. Among the Accounting groups, only *Accounting / Read-only* does not inherit from *Accounting / Invoicing*, which means that only the users in *Accounting / Read-only* could not access the invoices. By granting read rights to both *Accounting / Invoicing* and *Accounting / Read-only*, we ensure that any user belonging to an Accounting group can see the invoices from the Veri\*factu module. ### Steps to reproduce: 1. Install *Accounting* (`accountant`) and *Spain - Veri\*Factu* (`l10n_es_edi_verifactu`). 2. Go to Settings > Users & Companies > Users and select a user. 3. In the *Access Rights* tab, set the user's *Accounting* access right to *"Read-only"*. 4. Log out, then log back in as the user selected in step 2. 5. Go to Accounting > Customers > Invoices and select any invoice. 6. An access error pops up. opw-5343391 Forward-Port-Of: odoo/odoo#238291
5 changes
Resolved issues and error corrections
This update resolves a rare issue where Odoo would crash when attempting to schedule messages without a linked model. The fix ensures that necessary variables are always defined, preventing these scheduling errors and improving overall system stability. This change primarily impacts the mail functionality.
Original PR description
In rare case when we would like to schedule messages without model a variable is not defined in that scope. Forward-Port-Of: odoo/odoo#238762
This update ensures the Frontdesk kiosk always displays the correct company logo. Previously, switching companies caused a display issue due to a permissions problem. The fix automatically includes the selected company in the kiosk's access settings, resolving the logo display issue.
Original PR description
When switching companies in a Frontdesk station and opening the kiosk URL, the company logo does not appear. **Steps to produce:** - Install the `frontdesk` module. - Ensure the database has at least…
When switching companies in a Frontdesk station and opening the kiosk URL, the company logo does not appear. **Steps to produce:** - Install the `frontdesk` module. - Ensure the database has at least two companies, each with a logo configured. - `Enable multi-company` access (user has access to all companies). - Open any Frontdesk station configuration and change the company to one different from the currently active company. - Copy the kiosk URL and open it in an incognito/private window. - The kiosk opens, but the company logo is missing. **Issue:** - Company logo not comes on frontdesk kiosk. **Root cause:** - When the kiosk URL is accessed, Odoo logs an `Access Denied by record rules`. - This happens because the selected company on the station is not included in the `Public User’s companies`. - As a result, the public user cannot read the company record, so the logo does not load. **Solution:** - Added an `onchange` on `company_id` to automatically include the selected company in the Public User’s `company_ids` if it is not already present. - This ensures the kiosk always has access to correct company record and logo. - Also added an XML-side fix to prevent an access error that occurs when a company is not activated and we attempt to select it in the company field. **Before:** <img width="500" height="500" alt="frontdesk_image_before" src="https://github.com/user-attachments/assets/b002ac6e-5271-4561-bf03-542a3feeefd1" /> **After:** <img width="500" height="500" alt="frondesk_image_after" src="https://github.com/user-attachments/assets/7b5bffe4-ccbf-48f5-ad9c-d5e6d2e7678e" /> **opw-5138980**
This update resolves an issue where removing a video URL in the website editor would create a broken link, leading to a 404 error. The fix ensures that the 'Add' button is disabled when a video URL is empty, preventing the creation of invalid links and improving the user experience. This ensures consistent and functional video embedding.
Original PR description
*=website **Steps to reproduce:** 1. Drop a video 2. Reopen the media dialog 3. Remove the URL 4. Confirm **Issue:** When the URL was removed and confirmed, an iframe without a valid source was saved, leading to a 404 error. **Fix:** When the video URL is cleared, VideoSelector component calls selectMedia with an empty object. MediaDialog did not previously handle this case, so the media selection was not cleared. Now we Update MediaDialog to treat an empty object as a clear-selection signal and disable the Add button accordingly. task-5190485
This update resolves an issue where trailing spaces were automatically removed from config parameters, even when the 'trim=False' setting was intended to prevent this. This restriction limited the ability to create parameters with separators like '; ' for reporting and other configurations. The fix ensures that whitespace is handled correctly according to the 'trim=False' setting, allowing for more flexible configuration options.
Original PR description
Description of the issue/feature this PR addresses: Allow creating config_parameters in res.config setting, with trailing whitespace, by using the 'trim' attribute already existing in Char fields. This problem may also exist in other versions, but has currently only been tested in Odoo 17. Current behavior before PR: When creating a config_parameter all trailing whitespaces are removed even when the field specifies trim=False, which is meant to allow trailing whitespaces. This restricts the creation of separator config_parameters e.g for name computations, qweb reports, etc. Desired behavior after PR is merged: When creating a config_parameter all trailing whitespaces are removed by default, to avoid bugs. However when the field has specified trim=False, the whitespace is not removed as per the original intention of the attribute. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where large .docx files weren't being correctly identified by their file type. The change increases the amount of data sent to the mimetype guesser, ensuring accurate detection, particularly when the python-magic library is used. This prevents misinterpretation of file types and ensures proper handling of documents like Word files.
Original PR description
### Description of the issue/feature this PR addresses: The current number of bytes (1024) sent to the mimetype guesser function is not enough for a correct guess on big .docx files (maybe other open…
### Description of the issue/feature this PR addresses: The current number of bytes (1024) sent to the mimetype guesser function is not enough for a correct guess on big .docx files (maybe other open office files too) whenever `python-magic` is installed. If `python-magic` is not installed, it falls back to a [simpler implementation (by odoo)](https://github.com/odoo/odoo/pull/233266/files#diff-706296f6593337a9ff88c0e33e0e090eec75f63a22f9825dd31833ba17922840R145) that actually works correctly. But in odoo.SH it seems that `python-magic` is always installed and in that case, it returns the mimetype "application/zip" for big .docx files. The issue is not reproducible in runbot, so I'm assuming `python-magic` is not present in that environment. I've tested it with double the amount of bytes and it seems to work correctly. Please check the [following ticket](https://www.odoo.com/odoo/project.task/5125592) for more details. ### Current behavior before PR: <img width="1141" height="674" alt="image" src="https://github.com/user-attachments/assets/a3d28757-c55a-4b0f-9ee5-042777943635" /> ### Desired behavior after PR is merged: The uploaded file's mimetype is correctly identified for big (>40mb) open office files. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr