Daily updates from Odoo
Wednesday, April 1, 2026
24 changes · saas-18.3
Resolved issues and error corrections
This update fixes a bug where the wrong contacts were being added as followers to tax report entries, causing them to receive unwanted notifications. Additionally, a cron job that processes tax submission status has been improved to correctly handle multiple records instead of only processing the last one.
Original PR description
The method call that is supposed to subscribe the current user to the closing entry when posting XBLR used the User id as a Contact id. This caused random contacts to be added as followers of the chatter thread and as a result receiving notifications for it. The fix is simply using the id of the User's Contact instead. Also, as discussed with prro on Discord, fixed the cron clearing its dictionary each loop. opw-5886621 Forward-Port-Of: odoo/enterprise#107843
Fixed an issue where subscription product billing periods were not showing when products were added to website pages using the product snippet editor. The billing period information is now properly displayed on product cards, matching the behavior shown on the shop page.
Original PR description
Steps to reproduce: 1) Go to the Website app. 2) Add a product snippet to any page using the editor. 3) See product card of any subscription product. Issue: - The billing period is not displayed for subscription products in the product snippet, unlike on the shop page. Cause: - `temporal_unit_display` is not included in the `combination_info`which is passed in data used by the product snippet. Fix: - Include `temporal_unit_display` in `combination_info`. opw-6070943 Forward-Port-Of: odoo/enterprise#112171
This update fixes failing tests in the Italian XML export module by adding required tax identification fields that are now validated during the export process. Previously, tests were passing without these mandatory fields, but a recent validation improvement now requires them to be present, ensuring exported documents comply with Italian tax authority standards.
Original PR description
Description of the issue this commit addresses: Previously, the testing of the xml exports was only done by generating the file and checking its content against a hardcoded one but a fix[^1] changed that so the tests use the real export flow during which an xsd validation is done. As the tests did not expect to go trough the validation, some mandatory values were not present and it now results in a failing validation (caught in except). [^1]: https://github.com/odoo/enterprise/pull/108548 Desired behavior after this commit is merged: The tests set the l10n_it_codice_fiscale field from which are populated the mandatory CodiceFiscaleDichiarante, CodiceFiscale and CFDichiarante for the xsd validation. opw-5707544
This fix resolves an issue where the "Load more" line in financial reports was being incorrectly hidden when the "Hide lines at 0" option was enabled. The fix ensures that "Load more" lines remain visible even when hiding zero-value lines, allowing users to access additional report details as needed.
Original PR description
When activating the 'Hide if 0' option, the 'Load more' line is hidden. Fix: Filtering out the lines with empty columns (Load more lines) from the zero lines. Steps: - Open GL (occurs with other reports as well), and open configuration for this report - Set Load more limit to 1, and hide if zero to optional - Go back to GL report and select the 'Hide lines at 0' option -> Load more lines are hidden as long as the zero lines opw-5953725 Forward-Port-Of: odoo/enterprise#109380
This fix corrects an error in Pakistan payroll tax calculations that was causing inflated tax amounts for employees earning over 2.2 million annually. The tax computation was incorrectly accumulating values across tax brackets instead of properly resetting them, resulting in employees being overtaxed. This update ensures accurate tax calculations in compliance with official Pakistan tax regulations.
Original PR description
Currently, payslip computation for Pakistan localization calculates incorrect tax when the yearly cost exceeds 2,200,000. ### **Steps to Reproduce:** 1) Install…
Currently, payslip computation for Pakistan localization calculates incorrect tax when the yearly cost exceeds 2,200,000. ### **Steps to Reproduce:** 1) Install `l10n_pk_hr_payroll_account`,`hr_contract_salary` with demo data. 2) Switch to PK company. 3) Create an employee and a running contract with yearly cost 2,200,001 4) Create a payslip and compute it from the Salary Computation tab. ### **Observed Behavior:** 'Tax Bracket Yearly' is computed as `122000.24` ### **Expected Behavior:** 'Tax Bracket Yearly' should be `116000.24` ### **Root Cause:** since [commit](https://github.com/odoo/enterprise/pull/98345/commits/62f5e216518d83317618d7dbc0be4db92d1881a3), the tax computation relies on [_l10n_pk_get_tax](https://github.com/odoo/enterprise/blob/a9656336583a4d5c5b12d4d6120ec62ba1cf9151/l10n_pk_hr_payroll/models/hr_payslip.py#L9-L20) , In this method, the `result` is incorrectly accumulated with `fix` when iterating through brackets, leading to an inflated tax value. [official pakistan document](https://download1.fbr.gov.pk/Docs/20258181281745641WHT-RateCard.pdf) ### **Fix:** Use `result = fix` instead of `result += fix` so that the cumulative tax is correctly reset at each bracket. **opw-5979265** Forward-Port-Of: odoo/enterprise#110939
This fix corrects how shifts are split when using the daily view in the planning schedule. Previously, splitting a shift within a single day would incorrectly snap the resulting shifts to standard working hours (8am-5pm), creating duplicate shifts with wrong timeframes. Now, shifts are properly split at the exact time requested, preserving the original shift boundaries.
Original PR description
Since odoo/enterprise#69963, splitting a shift in Gantt view snaps the resulting shifts to the standard working hours (e.g., 08:00 to 17:00). This behavior makes sense when splitting a multi-day shift across a day off, where we want to generate a full working day for the day off as well. However, when splitting a shift within a single day (day scale), this behavior is not wanted, otherwise creating two shifts as follows: 1. A shift from [Original Start] to 5pm 2. A shift from 8am to [Original End] Clearly, the shift is duplicated with the wrong timeframes and adding time outside the original shift's hours. This commits ensures that, when splitting a shift in hours (i.e., when using `day` view scale), the shift is appropriately split at the time requested. For instance: 1. A shift from [Original Start] to [Split Time] 2. A shift from [Split Time] to [Original End] task-5387243 Forward-Port-Of: odoo/enterprise#105991
This update corrects how the Spanish Form 347 tax report handles partner thresholds and insurance operations. Partners with negative amounts are now properly included if they exceed the 3,005.06 € threshold in absolute value, and insurance operations are now correctly split between sales and purchases with amounts from both journal types properly accounted for. This ensures accurate tax reporting compliance for Spanish businesses.
Original PR description
Before this PR: - Partners were only shown if their total was positive and above 3,005.06 €. Negative totals were hidden, even if they were lower than -3,005.06 €. - Insurance operations only took Purchase journal amounts into account. Amounts from Sales journals were ignored, and there was no distinction between the two types of operations. After this PR: - The report now uses the absolute value of the total. Partners with amounts exceeding 3,005.06 €, whether positive or negative, are now shown correctly. - Insurance operations are now divided into two distinct sections: Sales and Purchases. Amounts from both Sales and Purchase journals are now correctly taken into account and reported in their respective sections. task-5214023 Forward-Port-Of: odoo/enterprise#112136 Forward-Port-Of: odoo/enterprise#100413
This fix corrects a bug where users could incorrectly change the "Recurring" setting on subscription products that have confirmed sales orders. Previously, rapid clicks on the setting could bypass the intended protection. The fix now properly validates changes against the server's current value instead of the form's temporary state, ensuring the system correctly prevents unauthorized modifications.
Original PR description
**Problem:** When attempting to change "Recurring" on products in the form view, if there are confirmed SOs, the change should be reverted and a message should appear explaining this. However, there is a bug in how the change is reverted where it takes the current form value of the field. This cannot be trusted as it's possible to trigger another onchange before the first one resolves, so the second onchange is based on the wrong value. **Steps to Reproduce:** - w/Demo Data, go to product "Office Cleaning Service (SUB)" (This is a subscription product which has confirmed SOs) - Quickly click the checkbox for "Recurring" twice -> Two warnings appear, but Recurring is False and can be saved **Solution:** Instead of reading the current form value and setting its opposite, we can revert to the current value on the server. Forward-Port-Of: odoo/enterprise#110877
This fix addresses an issue where text formatting (bold, italic, etc.) on iOS Safari was not working correctly due to improper cursor positioning. The change adjusts where the cursor is placed after applying formatting, ensuring that Safari properly recognizes and displays the formatted text. This improves the text editing experience for iOS Safari users.
Original PR description
Before this commit: when we applying format on collapsed cursor, we create a formatted element with ZWS, and set the cursor before the ZWS After this commit: we set the cursor after the ZWS, cause otherwise safari doesn't update the cursor properly leading to unformatted input task-4243977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256370 Forward-Port-Of: odoo/odoo#249253
This update fixes a problem where website assets fail to load properly after design changes in multi-database environments. When a user modifies website styling (like theme colors), the system regenerates assets but couldn't find them immediately due to database synchronization delays. The fix ensures assets are properly available right after regeneration, preventing broken website displays.
Original PR description
When `/web/assets/...` is requested on a readonly route and the bundle is missing, Odoo regenerates it on the primary using a RW cursor. It can then still try to read the freshly created…
When `/web/assets/...` is requested on a readonly route and the bundle is missing, Odoo regenerates it on the primary using a RW cursor. It can then still try to read the freshly created `ir.attachment` through the original RO/replica env. In a primary/replica setup, replication may not have caught up yet, so the new attachment is not visible on the replica. As a result, readonly `/web/assets/...` requests can fail right after asset regeneration when fetching the freshly generated bundle. Steps to reproduce: 1. Configure Odoo with a PostgreSQL primary/replica setup. 2. Open a website in edit mode. 3. Trigger an asset regeneration (for example by changing a theme color). 4. Let the resulting readonly `/web/assets/...` request fetch the freshly generated bundle. Build the response stream from the RW env after regeneration instead of rereading the fresh attachment through the RO/replica env. opw-6034833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255530
Optional product tables in sales documents were not displaying with the correct report styling due to DOM structure differences. This fix applies the proper styling to these tables so they appear consistently with other report tables. Users may need to update their document layout settings for color changes to take effect.
Original PR description
Issue: In sale_management the optional product table doesn't get the report table styling. This is due to a different DOM and missing classes. This fix applies the styling to match the optional product table structure. While the table is in `sale_management` the change is applied in `web` to avoid having to update the module for customers. Note: the color applied in `report_templates.xml` requires that the user change is layout in the document layout configurator then save again for it to apply. task-6009941 opw-5960426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252430
This fix resolves an issue where refunds created from invoices with duplicate line items (same product, price, and discount) were incorrectly matched. The system now prevents matching the same invoice line multiple times and ignores line labels during matching, ensuring accurate refund processing for Jordan EDI compliance.
Original PR description
In some cases, the users may have invoices with the same product, price unit, and discount on multiple lines. When they create refunds from such invoices, the lines ids matching algorithm would fail because it would match the first matching line over and over again. Also, lines should not match based on line label, as it can be modified in the refund. This commit solves these 2 issues by 1) Preventing matching an invoice line more than once with refund lines 2) Preventing matching based on line label The new algorithm finds the best match for a refund line from the invoice lines with the following criteria: 1) same product 2) same unit price 3) same discount 4) invoiced quantity should be at least equal to the refunded quantity 5) invoice line should not be matched before 6) from the lines that match previous criteria, we pick the one with the minium quantity task-6004207 Forward-Port-Of: odoo/odoo#256365 Forward-Port-Of: odoo/odoo#252200
This fix prevents the system from creating false absence records for employees whose employment contracts haven't started yet. Previously, when running the absence detection process, employees with future contract start dates would incorrectly be marked as absent, creating negative overtime records. The system now properly checks contract dates before flagging absences.
Original PR description
### Steps to reproduce: - Create an employee with contract starts in the future - Activate the Absence Management from attendance settings - Run the cron of Absence Detection - Notice an absence attendance got created for the emp with the future contract ### Cause: We don't check for contracts start dates when fetching absent employees and we get expected attendance for them from their working schedule so we create -ve overtime for them. ### Fix: We filter the absent employees on their running contracts. It has been fixed in since 18.4 in this commit https://github.com/odoo/odoo/commit/5db242416522524849a20eb83df3937c193c98d3 opw-5942239 Forward-Port-Of: odoo/odoo#253358
A typo in the test_views domain has been corrected in the base module's test file. This fix ensures that automated tests run correctly and helps maintain code quality by preventing test failures caused by the typo.
Original PR description
A typo was introduced in #163714 Forward-Port-Of: odoo/odoo#231897 Forward-Port-Of: odoo/odoo#228977
Users encountered an access rights error when trying to create private tasks (tasks with no project and no assigned users). This fix automatically assigns the task creator as a user when a private task is created, ensuring they have proper access to their own task. This resolves a frustrating error that prevented users from creating private tasks while maintaining the ability to modify existing tasks.
Original PR description
When users would follow the following step as they are makeing a private task, they would be hit by an incorrect access error. Steps to reproduce: 1.Open the form view to create a new task. 2.Clear…
When users would follow the following step as they are makeing a private task, they would be hit by an incorrect access error. Steps to reproduce: 1.Open the form view to create a new task. 2.Clear the Project field. When empty, it should display the Private placeholder. 3.Ensure no user is assigned to the task. 4.Create the private task. 5.An access rights error occurs, stating that the user does not have permission to create the record. ⚠️ Note: This access rights error only occurs when the task is created directly as private. If a task is created normally and then its project_id and user_ids are removed afterward, no access rights error occurs. Root cause: When a task is created without a project_id and without assigned users, Odoo checks access rights on creation. Since no project members or assigned users exist, no user has access to the record, including the creator. This results in an access rights error during creation. This issue does not occur when modifying an existing task because, after creation, the creator is automatically added as a follower. As a follower, the creator retains access to the task even if it has no project and no assigned users. Fix (implemented): Tasks that have no assigned users and are not linked to any project (private tasks) did not make sense, as they were effectively assigned to nothing. To address this, we now require at least one user to be assigned to a task when it is not attached to a project. This change was made inside of the "project_task_view.xml" file in the "view_task_form_2" record Versions : 17.0 -> master Task [5403926](https://www.odoo.com/odoo/project/4105/tasks/5403926) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242216
This update allows Odoo apps in the apps store to include additional manifest fields for price, currency, and support information. The change enables app developers to properly configure these important app store attributes without triggering validation errors.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255857
Mozambique users were seeing the incorrect Brazilian tax ID label "CPF/CNPJ" on their sales orders and invoices instead of the correct Mozambican label "NUIT". This fix adds the proper tax ID label for Mozambique so users now see the correct terminology on their business documents.
Original PR description
Currently the "Tax ID" title used e.g. on sales orders, invoices, etc. was translated as "CPF/CNPJ" in Portuguese, which is the tax ID used in Brazil. However, in Mozambique, the tax ID is called "NUIT", and there is no language variant for Portuguese in Mozambique. This caused Mozambique users to see "CPF/CNPJ" instead of "NUIT" on their documents, which was wrong. This commit adds a `vat_label` field for Mozambique to display the correct tax ID label. Issue reported by functional support. Forward-Port-Of: odoo/odoo#256603
This fix resolves an issue where replacing the contact form on the /contactus page would cause submission errors. The problem occurred because the system was using email settings from the old form configuration even after the form was deleted and recreated. The fix ensures that email settings are only applied when the original form is still present, preventing mismatches during form submission.
Original PR description
Problem: There is a data-for span in the /contactus page that sets specific values on the page's form. If this form is deleted and a new form is added, an error will occur when trying to submit the new form. This is because the value set for website_form_signature will use the email set in the data-for, which will not match with the new form. Purpose: Modify the code that sets the website_form_signature value to ensure that the original form is present as well if using the data-for values. Steps to Reproduce in Runbot: 1. Use the Website Editor to delete the form on the /contactus page and create a new one. 2. Attempt to submit the new form. opw-5956030 Forward-Port-Of: odoo/odoo#253410
This update improves the demo payment provider by adding validation checks to ensure the payment provider is properly configured before processing transactions. This prevents errors and ensures a smoother payment experience for users testing the demo payment functionality.
Original PR description
opw-3097856 Forward-Port-Of: odoo/odoo#256362
Fixed an issue where the bold formatting button would not remove bold styling when the selection included embedded components like files. The editor was incorrectly considering non-editable elements when determining whether to apply or remove bold formatting, causing the toggle to get stuck in "apply" mode. This fix ensures only editable content is evaluated when toggling text styles.
Original PR description
When determining whether the "bold" action is about adding bold or removing bold, non-editable text nodes are also taken into account. Because of this, if the selection contains an embedded component such as `/file`, it always considers bold was not applied on all nodes, and should therefore be applied. The action thus never removes bold. This commit fixes this by only taking into account the editable nodes. Steps to reproduce: - Go to a "To do" note - Add a few lines of text - Add a `/file` in the middle - Select all - Press Ctrl+B: bold is applied on the surrounding text - Press Ctrl+B again => Bold was not removed from the surrounding text task-5955977 Forward-Port-Of: odoo/odoo#249816
This fix improves how Odoo extracts embedded files from PDF documents. Previously, PDFs with a specific organizational structure (/Kids nodes) would not have their embedded attachments extracted, resulting in empty bills when uploading such PDFs to the accounting dashboard. The fix now supports both standard and hierarchical PDF file organization methods, ensuring all embedded content is properly detected and extracted.
Original PR description
Steps to reproduce: - From the accounting dashboard, upload a PDF containing intermediate /Kids nodes representing separate xml attachments Issue: No xml will be extracted, as result the bill will be empty. However, in the chatter pdf preview, the js pdf toolkit correctly show the xml attachemnts. Analysis: The PDF spec defines two ways to organize embedded files under /EmbeddedFiles in the document's name dictionary: - /Names: a flat array of pairs located directly under /EmbeddedFiles - /Kids: an array of child nodes, each of which carries its own /Names array. The extractor currently only handled the /Names case, not detecting embedded attachments in case of PDF using a /Kids tree. This change add lookup for both structures. opw-5929274 Forward-Port-Of: odoo/odoo#252523
This update prevents users from accidentally adding line breaks within section titles in quotation templates. When a quotation template is applied to a sales order, section titles will now remain as single-line text, ensuring consistent and professional formatting. Users who need multiple lines should create separate sections instead.
Original PR description
Steps to produce: --- - Install `Sales` module. - Go to `Sales > Configuration > Sales Orders > Quotation Templates`. - Create a new template and add a section. - In the section name, add text with…
Steps to produce: --- - Install `Sales` module. - Go to `Sales > Configuration > Sales Orders > Quotation Templates`. - Create a new template and add a section. - In the section name, add text with line breaks using `Shift + Enter`. - Go to sale orders > Create new SO > Set quotation template created above. Issue: --- - Line breaks entered in the quotation template section lines are stripped when the template is applied to a sale order. These intentional sections are meant to be single-line titles; users should create a new section instead of using line breaks within one. Root cause: --- - At [1], the `name` field is defined without the `section_and_note_text` widget. This widget is responsible for rendering section lines as a `CharField` instead of a `TextField`, as seen at [2]. Solution: --- - Add `widget="section_and_note_text"` to the `name` field. This ensures section lines consistently use `CharField`, preventing line breaks from being entered. [1]https://github.com/odoo/odoo/blob/951b44c0ed5ffb90cff6fa2934ca2664d2faa59d/addons/sale_management/views/sale_order_template_views.xml#L96 [2]https://github.com/odoo/odoo/blob/951b44c0ed5ffb90cff6fa2934ca2664d2faa59d/addons/account/static/src/components/section_and_note_fields_backend/section_and_note_fields_backend.js#L79-L86 opw-6034255 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a display problem in the website editor where product category previews were not showing correctly. The issue was caused by missing variable definitions that prevented proper styling from being applied. This ensures that when users preview different layout options in the editor, all visual elements display as intended.
Original PR description
The editor previews are not having the expected design due to the `c` and `p` variables being undefined. Steps to reproduce for eg. filmstrip: - Disable the `categories_opt_top` (Categories: top) - Hover the "Top" editor button - See the filmstrip is missing it's placeholder rectangle "text" due to the width style not being applied. task-6047816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where placeholder text in the editor was flickering when users updated content in other fields. The editor now only clears the placeholder hint when the cursor is actively inside the editor, preventing unnecessary blinking that distracted users during editing.
Original PR description
Problem: When the selection is updating, the hint is blinking in the editable. Cause: After 9df2662cc79c2d8277211f7ce0bdb389f783f933, `triggerDebouncedUpdateHints` clears the hint immediately and adds it back using a debounced version of `updateHints` which runs after a few seconds, thus causing this blink. Solution: We only update hint if the selection inside the editable. Steps to reproduce: - Create a new Todo. - Keep the editable empty. - Update the Todo title. - Observe the editable hint blinking. task-6025534 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr