Thursday, December 18, 2025
18 changes · saas-18.4
Resolved issues and error corrections
This update resolves an issue where archived employees were still appearing in the timesheet section of helpdesk tickets. The fix ensures that only currently active employees are displayed, preventing incorrect timesheet entries and improving data accuracy. This change enhances the reliability of our helpdesk reporting.
Original PR description
**Steps to Reproduce:** - Install hekpdesk_timesheet. - Go to settings, enable timesheets - Archive an employee. - In a ticket, try to add a timesheet entry. **Isuue:** Archived employees are also appearing under timesheets tab. **Fix:** Passed a context so that only active employees appear in the selection. task-5078763 Forward-Port-Of: odoo/enterprise#95137
This update fixes an issue where product documents stopped appearing on product pages after a document version was updated. The fix ensures that the product document record is correctly linked to the latest document version, maintaining accurate product information. This improves data consistency and prevents disruptions to product listings.
Original PR description
**Steps to reproduce:** 1. Install `sale_management` and `documents`. 2. Go to settings > check `product` under Files Centralization. 3. Create a product and add a document to it using the smart button. 4. Update the version of that document from the *Manage Versions* action on the document page. **Issue:** - After updating the document version, the linked document no longer appears on the product page. **Cause:** - The product page displays records from the `product.document` model, but its `ir_attachment_id` was not updated when the document’s version changed. **Solution:** - Update the `ir_attachment_id` on the corresponding `product.document` record when the document version is updated. opw-5144041 Forward-Port-Of: odoo/enterprise#99226
This update fixes an error in how sales margins are calculated for orders using multiple currencies. The previous calculation was producing an incorrect margin figure. The fix uses brackets to ensure the correct formula is applied, resulting in a more accurate margin calculation.
Original PR description
Step to reproduce: - create new journal and a pricelist with different currency (here TWD i.e 36.833 * USD) - set that pricelist and journal in a pos - have a product with sales (here 1000$) and cost…
Step to reproduce: - create new journal and a pricelist with different currency (here TWD i.e 36.833 * USD) - set that pricelist and journal in a pos - have a product with sales (here 1000$) and cost price (300$) - create pos and finalize the order with that product - go to sales > reporting > sales > pivot view - check margin for that order Observation: - the margin is calculated wrong due to improper brackets - current calculation ( for TWD currency , multiply with currency rate) sale price - ( cost price / currency rate) i.e. `1000 * 36.833 - (300* 36.833 / 36.833) = 36833 - 300 = 36533` Fix: - fixed the calculation, used brackets - actual calculation - `(1000 * 36.833 - 300 * 36.833) / 36.833 = 1000 - 300 = 700` Before <img width="687" height="97" alt="image" src="https://github.com/user-attachments/assets/3a821a5c-eb12-4eae-9465-1702e9d4ac97" /> After <img width="679" height="110" alt="image" src="https://github.com/user-attachments/assets/d62dbb1d-6839-4099-90b1-6f9a19576721" /> opw-5166714 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239407
This update resolves an issue where ECO applications incorrectly linked product documents to attachments, leading to database errors. The fix ensures that ECOs correctly reference the associated attachments, preventing potential data inconsistencies and application failures. This improves the reliability of ECO implementation.
Original PR description
When applying an ECO, the system incorrectly sets the origin_attachment_id of a product.document to a product.document record itself instead of its related ir.attachment. As a result, if the incorrectly referenced ir.attachment is missing, the ECO will attempt to reference a record that does not exist, leading to a foreign key violation during action_apply. Steps to reproduce: 1.) Create an mrp.eco record 2.) Upload a document, take note of the product.document ID 3.) Unlink the ir.attachment with ID = (document ID + 1) (+1 is to account for the .copy within action_apply) 4.) Run eco.action_apply 5.) Observe SQL Constraint Expected result: The ECO should correctly link the product.document to its related ir.attachment. Actual result: origin_attachment_id may point to an unrelated ir.attachment, causing constraint violations when those attachments do not exist. opw-5050263 Forward-Port-Of: odoo/enterprise#94958
This update resolves an issue where removing all elements from the 'Contact Us' button in the website editor caused a website error. The fix ensures that unremovable elements, like this button, are not accidentally deleted, maintaining website stability and preventing disruptions for users.
Original PR description
Currently, an error occurs when the user edits the `Contact Us` button and removes both the label and the link.
**Steps to replicate:**
* Install `website`
* website > edit > Click on contact us > Edit Link
* replace all the fields by adding one space ' ' and apply > Save.
**Error:**
`ValueError: Element '<xpath expr='//a[hasclass('oe_unremovable')]'>' cannot be located in parent view.`
**Root cause:**
* When the user edits the `Contact Us` button and clears all the fields, then clicks `Apply` line [1] removes the button. But the button is meant to be unremovable, so this breaks the website.
**Solution:**
* Add a check before removal to verify whether the link element is removable and only remove it if it is removable.
[1]:
https://github.com/odoo/odoo/blob/674280cd86088a6cc3bd5c10dd56ece65bf5e517/addons/html_editor/static/src/main/link/link_plugin.js#L701
sentry-6639000902This update enhances the stability of the printer integration by adding exception handling for the Python escpos library. Previously, unexpected errors could cause the printer to fail, and this change ensures continued functionality. It's a routine fix to maintain reliable printing operations.
Original PR description
With python escpos library we are currently not catching some exceptions. This PR adds more exceptions to catch to keep the printer working Additional exception caught for >=v19.0 in https://github.com/odoo/odoo/pull/240429
This update resolves a bug where copying and pasting within the website builder could cause unexpected duplication of content and rendering errors. The fix prevents the copying of unnecessary elements, ensuring accurate website updates and a stable editing experience.
Original PR description
When the user copies a range of the html in the page, they may copy nodes with attributes that mark them to be saved. This happens if they select around a savable node, or if they select inside a…
When the user copies a range of the html in the page, they may copy nodes with attributes that mark them to be saved. This happens if they select around a savable node, or if they select inside a savable node and the format plugin include clones of the ancestors (to keep matching style). This commit prevents that by not copying clones at the ancestor which sets `contenteditable` to true (if any), and by treating copy with a selection outside of `contenteditable` the same as a foreign copy (for which any non-whitelisted attributes are removed). Steps to reproduce: - Open website builder - Select a link of the menu in the header - Copy - Move the selection to "normal" text (like in the footer) - Paste - Save - Bug: the website cannot render ### - Open website builder in translate mode, on a blog post - Select a word in the middle of a paragraph - Copy - Paste - Bug: The paragraph gets replicated inside itself ### - Open website builder in translate mode, on a blog post - Select from the author name to the first paragraph - Copy - Paste inside the paragraph - Bug: The paragraph gets replicated inside itself opw-5053872 task-5222402
This update corrects a display issue where task templates were incorrectly shown alongside regular tasks in the Odoo portal. The fix ensures that task templates are hidden from portal users, improving the clarity and usability of task management. This change was made to streamline the portal experience and prevent confusion.
Original PR description
Steps to Reproduce
- Log in as a portal user.
- Go to My Tasks and notice that task templates are visible with tasks.
- Share it with the portal user, giving edit access.
- Open the project sharing view and observe that task templates are visible there.
Cause
- The domains used to filter tasks in both the portal view and the project sharing view did not exclude task templates and it's sub-tasks. As a result, task templates were incorrectly shown alongside real tasks.
Solution
- Added `('has_template_ancestor', '=', False)` to the domain in the `_prepare_tasks_values` method to hide templates in the portal.
- Added `('has_template_ancestor', '=', False)` to the domain in the project sharing action to hide templates when listing tasks.
task-5079337
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#226602This update corrects a display issue in the Field Service > All Tasks view, preventing task templates and their associated tasks from appearing alongside real tasks. The fix ensures that users only see active, operational tasks, improving the clarity and usability of the Field Service interface.
Original PR description
Steps to Reproduce
- Navigate to Field Service > All Tasks.
- Observe that task templates are visible with tasks.
Issue
- Task templates are visible in the Field Service > All Tasks view, which is incorrect. Only real tasks should be listed.
Cause
- The domain in the view definition only filtered tasks by `is_fsm = True` and ` project_id != False`, but it did not exclude template tasks and sub-tasks of task templates.
Solution
- Added `('has_template_ancestor', '=', False)` to the domain so that only actual tasks are displayed in the Field Service > All Tasks view.
task-5079337
Forward-Port-Of: odoo/enterprise#94472This update fixes alignment issues within the partner forms and improves the user experience by hiding the 'MyInvois' tab for journal entries that aren't related to sales or purchases. This ensures that users only see relevant information, streamlining their workflow.
Original PR description
This commit: - Fixes alignment of the `MYINVOIS INFORMATION` section on the partner form. - Hides the `MyInvois` tab on journal entries where journal type is neither `sale` nor `purchase`. task-5356808 Forward-Port-Of: odoo/odoo#240333 Forward-Port-Of: odoo/odoo#239837
This update corrects an issue where product names were duplicated on delivery slips when a kit's component lacked a description. The fix ensures that product names appear only once on delivery slips, improving the clarity and accuracy of shipping documents. This resolves a potential confusion for customers and internal teams.
Original PR description
When creating a delivery slip, if the product sold is a kit and it's component doesn't have a description, the name will be repeated. Steps to reproduce: ------------------- * Create a product A with…
When creating a delivery slip, if the product sold is a kit and it's component doesn't have a description, the name will be repeated. Steps to reproduce: ------------------- * Create a product A with a bom of type kit * Add a product "comp" in the bom (don't give it a description) * Create a sales order with the product A and confirm it * Go on the delivery and create a delivery slip -> Issue, the name of the product "comp" appears twice. Observation: ------------- The name is added in description_picking field, since it is considered that the fallback for the description for outgoing deliveries should be display_name: https://github.com/odoo/odoo/blob/584f94e3246b6b59641bf83d4e707f2e872bc1e8/addons/stock/models/product.py#L293-L301 In _compute_description_picking, information about the bom will be added : https://github.com/odoo/odoo/blob/08c5fbbb5bc44c4810cd07188b29090c3060e14f/addons/mrp/models/stock_move.py#L235-L236 This causes the issue because the filter to prevent repeating the name on the delivery slip is implemented directly in the XML: https://github.com/odoo/odoo/blob/08c5fbbb5bc44c4810cd07188b29090c3060e14f/addons/stock/report/report_deliveryslip.xml#L83-L85 However, since we have added elements to the description (the bom information), this filter will not be applied, leading to the repeated name. opw-5265906
This update ensures that downpayments on invoices now correctly use the company's designated downpayment account, regardless of product category. Previously, invoices defaulted to the income account, causing inconsistencies with tax calculations and standard downpayment behavior. This fix aligns with expected accounting practices.
Original PR description
**Problem:** When calculating taxes externally (such as Avatax) and a downpayment is made, the line on the invoice will always use the default income account, regardless of the downpayment account set as a company default. This issue can also happen in the case where products have no category set. This is inconsistent with the standard behavior of downpayments, which will use the downpayment account set on the product's category instead of the income account (which themselves may come from company defaults). **Solution:** If there's no product category set, fall back to the company's default downpayment account. opw-5171067 Forward-Port-Of: odoo/odoo#239085
This update resolves an issue where local overlays were incorrectly persisting in the HTML editor after repeated editing and saving. The fix ensures that these overlays are properly cleared when the editor is destroyed, improving website performance and stability. This was a pre-existing issue addressed in 18.0, now resolved for all Odoo versions.
Original PR description
This commit ensures that local overlays are correctly removed when the Editor and `LocalOverlayPlugin` are destroyed. Steps to reproduce (observable after 18.4): - Go on website - Enter edit mode - Save - Repeat entering edit mode and saving - Inspect the DOM: oe-local-overlay elements keep accumulating, only one is non-empty The bug is only observable after 18.4, after the website refactoring, but the root cause has been present since 18.0, so we fix it there in case there are other use cases. task-5380409 Forward-Port-Of: odoo/odoo#239644
This update resolves an issue where assigned values in project task properties would disappear after saving. The fix ensures that property values are correctly saved and displayed, improving the usability of project task configuration. This change was made to enhance data integrity and prevent data loss.
Original PR description
**Steps to produce:** - Install project module. - Go to project > Open any project > Open any task > Click on gear icon. - Click on Add properies > Set Field type as `Many2one` and Model as…
**Steps to produce:** - Install project module. - Go to project > Open any project > Open any task > Click on gear icon. - Click on Add properies > Set Field type as `Many2one` and Model as `Contact`. - Now assign value to Property 1 > Click on `External button` > Click on `Save & Close`. **Issue:** - The assigned value disappears after saving. **Root cause:** - At [1], since `id` is not an active field (see [2]), it is not present in record.data, which is expected. However, record.data is then passed to m2oTupleFromData, which assumes that the data includes an id because it is normally used on data coming directly from the ORM. - Additionally, since display_name is also not present, m2oTupleFromData falls back to record.data.name, which is not proper. **Solution:** - Use an ORM read to retrieve the proper display_name of the record before constructing the Many2one tuple. [1]: https://github.com/odoo-dev/odoo/blob/24ccc3faf14ade70b21bf253af16a534df726fc8/addons/web/static/src/views/fields/properties/property_value.js#L87-L89 [2]: https://github.com/odoo/odoo/blob/369ca1e5a154235e80b9ea6af7b3f10442c0939f/addons/web/static/src/model/relational_model/record.js#L793-L795 Before: <img width="589" height="68" alt="bef" src="https://github.com/user-attachments/assets/b2aeba0c-1c52-4663-9f94-5c7808a882db" /> After: <img width="613" height="81" alt="after1" src="https://github.com/user-attachments/assets/a3b3d733-929d-4a24-9e17-c73d9569e9b7" /> **opw-5257819** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238052
This update improves the accuracy of Thai VAT number input within Odoo. It now ensures that only 13-digit numeric VAT numbers are accepted for Thai partners, aligning with Thai regulations. This prevents incorrect data entry and ensures compliance.
Original PR description
This PR adds a validation method check_vat_th() to verify Thai VAT numbers. In Thailand, a VAT number must consist of exactly 13 numeric digits. For partners with country set to Thailand, the system will only allow VAT numbers that are exactly 13 digits long. Total credits go to: [Saran440](https://github.com/Saran440) `<saranl@ecosoft.co.th>` (See PR: https://github.com/odoo/odoo/pull/239164) Enterprise PR: odoo/enterprise#101905 Forward-Port-Of: odoo/odoo#240293 Forward-Port-Of: odoo/odoo#239616
This update corrects a test failure related to VAT number validation for Thailand. Following the recent implementation of stricter VAT number checks, a test case now incorrectly validates a sample VAT number. This fix ensures the Thailand VAT reporting functionality continues to operate correctly and aligns with regulatory requirements.
Original PR description
Following the implementation of proper validation for VAT numbers for Thailand, this now fails as the one set in the test doesn't follow the proper format. Community PR: odoo/odoo#239616 Total credits to @vin-odoo Forward-Port-Of: odoo/enterprise#102290 Forward-Port-Of: odoo/enterprise#101905
This update simplifies the task management interface on mobile devices. The changes consolidate dropdown options and present action menus in a cleaner, more user-friendly list format. This enhances the overall mobile experience and improves task management efficiency.
Original PR description
After this commit: - A single combined dropdown is used in mobile view to avoid overlapping sliders. - The "Show Sub-Tasks" button is placed at the top of this dropdown. - Embedded action menu items are displayed directly below, as flat list items. - This improves mobile usability and ensures a cleaner, unified UI experience. task-4971617
This update removes a 'New' button from the Payslip Work Days Lines Report and Payslip Line Report. This button was causing errors and was intended for viewing data only. This fix ensures these reports function correctly for viewing payroll information.
Original PR description
Remove the “New” button from the Payslip Work Days Lines Report and the Payslip Line Report. These reports are intended for viewing only, and allowing record creation caused a traceback. task-5416416 Forward-Port-Of: odoo/enterprise#102236