Daily updates from Odoo
Navigate
Branch
Thursday, December 18, 2025
156 changes
16 changes
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
21 changes
Resolved issues and error corrections
This update corrects a technical issue that was preventing the correct sizing of columns in the expense report list view. Previously, the column widths were calculated incorrectly due to lost classnames in the override. Now, the column widths will be accurately determined, ensuring a better user experience for viewing expense reports.
Original PR description
Before this commit, some classnames set on the list renderer were lost in the expense override. As a consequence, the column width logic couldn't be applied correctly. The widths were computed with a wrong available width (the width of table's parent element, which is the renderer itself). 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#240270
This update resolves an issue that previously caused errors when processing invoices with reverse charge accounting (BIS3) in Japan. The fix ensures invoices are correctly generated and transmitted, improving the reliability of financial reporting. This change impacts how invoices are handled for businesses using the Odoo accounting module.
Original PR description
opw-5419227 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240275
This update addresses a bug in the spreadsheet component, specifically preventing issues with empty matrices during evaluation. The team has implemented the latest version of the o_spreadsheet library, ensuring improved stability and performance for spreadsheet functionality within Odoo. This change is a routine maintenance update.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/bbf6be118b [REL] 18.3.30 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/2764f730cc [FIX] evaluation: do not spread empty matrix [Task: 5421196](https://www.odoo.com/odoo/2328/tasks/5421196) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update 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 the task management interface. This change prevents confusion and streamlines task organization for users.
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-prThis update corrects a display issue in the Field Service module where task templates were incorrectly shown alongside real tasks. The fix ensures that only actual tasks are listed in the 'All Tasks' view, improving clarity and preventing confusion for users. This change enhances the user experience within Field Service.
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-5079337This update fixes an issue where invoice reports for KE clients were not displaying prices with commas, leading to potential confusion. The fix removes a duplicate XPath and correctly formats the total and taxable amounts, ensuring accurate reporting and compliance with KRA regulations. This improves clarity and accuracy for financial reporting.
Original PR description
Steps to reproduce: 1. install `l10n_ke` 2. Switch to KE Company 3. Create a product with all KRA eTIMS details set on the Accounting page. 4. Create an invoice to KE Company with that product and set unitprice > 10000 5. Confirm the invoice and send it. Now, see the invoice report Issue: 1. xpath for `td_subtotal` was duplicated 2. The total amount and taxable amount were not formatted as prices (no commas). Before: <img width="771" height="397" alt="image" src="https://github.com/user-attachments/assets/492fe911-18d6-4e01-a16d-d7450c17373f" /> After: <img width="766" height="389" alt="image" src="https://github.com/user-attachments/assets/bbe5d4e2-b337-445c-833a-06492a8c827d" /> Solution: Updated the invoice report to: - Remove the duplicated `td_subtotal` xpath. - Properly format the total and taxable amounts with `t-options`. opw-5341578 Forward-Port-Of: odoo/enterprise#101794 Forward-Port-Of: odoo/enterprise#100279
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 retained, improving the usability of the project task management feature. This change was made to enhance data integrity and prevent user frustration.
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 ensures that Thai VAT numbers entered into Odoo are valid, requiring exactly 13 numeric digits. This improves data accuracy and prevents incorrect VAT number entries, particularly for customers and partners in Thailand. The change was made by Saran440 and is part of the Odoo 18.3 release.
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#240112 Forward-Port-Of: odoo/odoo#239616
This update corrects a test case within the Thailand localization reporting module (l10n_th_reports) that failed due to an incorrect VAT number format. Following the recent implementation of stricter VAT validation rules for Thailand, the test now accurately reflects the required format. This ensures the reporting functionality remains reliable and compliant.
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#102172 Forward-Port-Of: odoo/enterprise#101905
This update resolves a bug where currency conversion rates weren't being created with the correct date, leading to inaccurate tax calculations for non-UYU currencies. The fix ensures all rates are now generated with today's date, improving data accuracy and financial reporting for companies using currencies other than UYU.
Original PR description
When the company's currency is not UYU we will get an error when doing the convention of the rate return by (UY) BCU (Banco Central Uruguay). All the rates should be used the same date in order to…
When the company's currency is not UYU we will get an error when doing the convention of the rate return by (UY) BCU (Banco Central Uruguay). All the rates should be used the same date in order to properly do the conversions. ### Steps 1. Create a new Company with country Uruguay 2. Change current logged company to new Company 3. Change the currency to USD 4. Go to Settings, option Automatic Currency rate and configure provider yo [UY] Uruguayan Central Bank 5. Click manual synchronization 6. Check rates ### Current behavior before PR All currencies except UYU currency has created taxes with date today. Only one error in UYU currency that is created with yesterday rate  ### Desired behavior after PR is merged: All the currencies are created with the same date, the correct day that is today rate. References: LATAM 1341 / ADHOC Task 51716 Forward-Port-Of: odoo/enterprise#85065
This update fixes an issue where videos added to product descriptions in the online store would disappear after saving. The fix ensures that the system correctly recognizes and preserves video embeds, improving the presentation of product information for customers. The change addresses a technical detail related to how the system clears 'empty' descriptions.
Original PR description
Versions
--------
- 18.0+
Steps
-----
1. Open website editor on a product page;
2. edit the ecommerce description;
3. add a video using the `/video` command;
4. save & close editor.
Issue
-----
The video disappears.
Cause
-----
The `write` override in `website_sale` uses the `is_html_empty` method to clear "empty" descriptions. When adding a video, it gets added as a `<div data-oe-expression="URL" class="media_iframe_video"></div>` element, i.e. an "empty" `div` element according to `is_html_empty`, hence getting cleared on write.
Solution
--------
In the `write` override, don't clear the ecommerce description if it contains "media_iframe_video".
Also, for 18.0, add `options="{'embedded_components': false}"` to the product view in the back-end to disable adding video there, as it gets formatted in a way that isn't supported by the front-end. For 18.2, this was already done in 6339f261e7161.
opw-5218018
Forward-Port-Of: odoo/odoo#240080This update resolves an issue where local overlays within the HTML editor were incorrectly persisting after edits, leading to performance problems. The fix ensures that these overlays are properly cleared when the editor is destroyed, improving stability and responsiveness. This change was proactively implemented to address a root cause identified since 18.0.
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 fixes alignment issues within the partner record view 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 resolves an issue where archived employees were still appearing in the timesheet section of helpdesk tickets. The fix ensures that timesheet entries are only populated for currently active employees, improving data accuracy and usability. This prevents confusion and ensures timesheet reporting reflects the current team roster.
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 would stop appearing on product pages after a document version was updated. The fix ensures that the link between the product and its document is automatically updated whenever a document version change occurs, maintaining accurate product information. This improves data consistency and simplifies document management.
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 multi-currency transactions. The previous calculation was producing an incorrect margin figure due to a bracket issue. The fix ensures accurate margin reporting by applying the correct formula, resulting in a more reliable view of sales profitability.
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 application failures and data inconsistencies. 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 a bug preventing users from adding products to invoices when navigating from a project task using the invoice smart button. The issue stemmed from differing context settings between accessing the invoice from a sale order versus a task, impacting the product search domain. This ensures consistent functionality across all invoice access methods.
Original PR description
On a fsm task, using the smart button to go to the invoice, will not give the same domain for the products, if you go from the sale order or directly from the task Steps to reproduce:…
On a fsm task, using the smart button to go to the invoice, will not give the same domain for the products, if you go from the sale order or directly from the task Steps to reproduce: ------------------- * Create a product - Purchase: False - Sale : True * Create a fsm task * Add products * Go to the sale order * Create the invoice (regular invoice) * Go back to the task * Go to the invoice using the invoices smart button * Try to add your product -> issue it's not possible. Observation: --------------- The domain of the search is not the same if we go from the sale order or from the task. This is because the domain depend on the context and the context is not the same : [Domain](https://github.com/odoo/odoo/blob/8258ddf12ed6c0495628f7a480d1e2424e756540/addons/account/views/account_move_views.xml#L1134-L1141) When using the smart button on the SO, some elements will be added to the context, the important one is: default_move_type : "out_invoice": [SO context](https://github.com/odoo/odoo/blob/18.0/addons/sale/models/sale_order.py#L1453) Instead when using it on the task, the context does not have that element: https://github.com/odoo/enterprise/blob/cb79d565031ee0e1bec9db82aa35deb2e1c03576/industry_fsm_sale/models/project_task.py#L325-L327 This will be calculate here in the js files: [evalContext](https://github.com/odoo/odoo/blob/c3367bd7c6900e42394b006ccf48c3b36a1b87e9/addons/web/static/src/views/fields/field.js#L400) opw-5135567 Forward-Port-Of: odoo/enterprise#101938 Forward-Port-Of: odoo/enterprise#98612
This update corrects a bug that prevented accurate reporting when calculating periods that spanned leap years. The fix adjusts date calculations to properly handle February 29th, ensuring reports are generated correctly for all years. This improves the reliability of financial data.
Original PR description
To reproduce: Set the start_date to 2024-02-29 then try to compute periods for 2025. This causes a crash as the start date is only valid in a leap year. Ths fix is to offset back the start_day to a valid start_date.
This update removes a 'New' button from the Payslip Work Days Lines Report and Payslip Line Report. This change prevents errors that occurred when users attempted to create new records from these reports, ensuring the reports function correctly for viewing existing payroll data.
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
This update resolves an issue where images floated within website builder rows caused layout problems. The fix adds a 'clear: both;' rule to ensure rows always appear below floated elements, maintaining consistent website alignment and improving the user experience. This prevents visual disruptions for website visitors.
Original PR description
Steps to reproduce: - Open the website builder. - Drag and drop the s_key_benefits snippets in the page. - Drag and drop an image below the title, above the 3 columns. - Set the 'alignement' option of the image to left. - Observe that the `.row` appears next to the image instead of below it. Previously, when a user dragged and dropped an image into the container above a `.row`, and applied the `float-start` class (via the builder), the floated image caused the `.row` to wrap around it instead of appearing below as expected. This broke the layout and alignment of content inside the `.row`. I fixed this by adding `clear: both;` to the `.row` element, ensuring it always starts below any floated elements above it. This prevents layout breakage even when users insert floated images above rows.
4 changes
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 timesheets only display entries for currently active employees, improving data accuracy and usability. This prevents confusion and ensures timesheet reporting reflects the current team roster.
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 would stop 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 resolves an issue where ECO applications were failing due to incorrect references to attached documents. Specifically, the system was pointing to the wrong attachment record, leading to database errors. This fix ensures ECO applications run smoothly by correctly linking documents.
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 document previews weren't loading correctly when accessing documents through the 'Activities' icon. The fix ensures the correct custom document view is loaded, restoring full functionality for users accessing documents from this common navigation point. This improves the user experience and prevents disruptions to document workflows.
Original PR description
When navigating to documents from the 'Activities' systray icon, the system would load an action that correctly filtered for "My Activities" but lacked the specific view definitions of the main Documents app. This caused the 'List' view-switcher to load the default list view instead of the custom one, breaking features like document preview that depend on the custom view's JavaScript. This patch fixes the issue by ensuring that the correct, custom view definitions from the main Documents app are loaded. This guarantees that the custom list view and all its features work correctly, regardless of how the user navigates to it. This ensures the correct custom list view is loaded while preserving the "My Activities" filter. Task-5187045 Forward-Port-Of: odoo/enterprise#98979
17 changes
New functionality added to Odoo
This update automatically links vehicle documents (like license plates) to the corresponding vehicle records in Odoo. This streamlines document management and reduces manual data entry for fleet administrators, improving accuracy and efficiency.
Original PR description
This PR adds the option to automatically link the document containing the license plate number to the vehicle in the `fleet.vehicle` model. AI will search for the license plate in the contents of the document and link it to the vehicle with the matching license plate. task-id: 5049329
Enhancements to existing features
This update enhances the depreciation schedule report by utilizing a new, more efficient engine. Previously, the report generated dynamic lines, which has now been replaced with pre-defined variants, streamlining the report generation process and improving performance.
Original PR description
This PR changes the depreciation schedule report to use custom engine instead of using dynamic lines. The group by custom filter is removed and instead the different grouped reports are variants of the depreciation schedule. task-4900446
This update enhances the performance of reports, particularly those with large datasets, by introducing a 'Load More' mechanism. It addresses previous issues with slow loading times and memory usage when generating detailed reports, now allowing users to load data in batches as needed.
Original PR description
======== CONTEXT ======== When unfolding a line of a report (typically for a groupby), it is possible many lines need to be rendered. When this number grows too big, it can create performance issues…
======== CONTEXT ========
When unfolding a line of a report (typically for a groupby), it is possible many lines need to be rendered. When this number grows too big, it can create performance issues (too much time and memory server-side ; too many lines to render in the browser client-side).
To alleviate those issues, two mechanisms had been implemented in previous versions of Odoo:
=> "Load more" (enabled via the load_more_limit field of account.report)
This feature was used by all report engines (so, it does not work for reports using a _dynamic_lines_generator), to essentially run a SQL LIMIT when computing the report. When the limit was reached, a limited number of sublines was shown, with an additional "load more" line at the end, allowing loading a new batch of them when clicked (possibly with another "load more" line for a next batch).
LIMITS:
- The "load more" line had no amount whatsoever; impossible to know what it contains with expanding it
- Navigation was poor, with the multiple successive "load more" lines
- The need to handle LIMIT and OFFSET in engines required additional complexity
- In case of multi-level groupby ("account_id,id", for example), only the terminal groupby
used the limit. If any intermediate groupby returned too many lines, we still displayed them all
=> Prefix groups (enabled via the prefix_groups_threshold field of account.report
Prefix groups worked on both engines and some reports with dynamic lines (typically the Partner Ledger, for which they were originally implemented). They basically always generated all the lines (without any kind of limit) server-side, before grouping them under unfoldable summary lines, that would do that recursively when unfolded, until the number of lines to show became manageable.
LIMITS:
- All lines were always generated before trimming them, so that means we still used a lot of memory. Also
time-wise, this was not optimal, as many calls to dict's get() function would be run for each line
(we had cases where it took a few seconds, just for that).
- Prefix were generated from line names ; it didn't work well when some records' display name did not
match their name in db (to compute the domain when expanding prefix lines)
- Depending on the content of db and field used in the line names, too many breaking corner cases were possible
======== NEW APPROACH ========
Prefix groups entirely disappear. They were still used by the Partner Ledger and Depreciation Schedule, which have just been rewritten (in different commit merged together with this one) to use custom engines instead, so that they can benefit from the "load more" instead.
"Load more" is now fully rewritten, and works very differently than before. It's essentially a hybrid approach mixing both previous features. Here are the key changes:
1) We don't use LIMIT and OFFSET at all in the engines anymore (both parameters disappear from engine functions). Instead, we generate all results and trim them, but we do that earlier than what prefix groups used to do. Here, we act on the engine's results, before generating the lines.
2) The "load more" line now displays how many sublines it summarizes, and sums the appropriate columns of those lines in order to display a relevant value in the report and improve clarity for the user.
3) "load more" now also works on intermediate levels, when using multi-level groupby. Reports wanting to modify this behavior for certain levels can do that through a custom handler, shadowing _report_expand_unfoldable_line_with_groupby, like the General Ledger and Trial balance do.
======== ADDITIONAL BENEFITS ========
This refactoring also paves the way for future possible improvements, because of the removal of offset and limit parameters from the engines:
- batching of groupby computations in SQL
- support groupby on aggregations
We'll work on those in the future.
task-4346024This update enhances asset reporting within Odoo Enterprise by incorporating data from the Enterprise-specific asset models. This change expands the reporting capabilities, providing a more complete view of asset information for financial analysis and management. The update maintains compatibility with the existing Community version.
Original PR description
Override the Community asset display helper to include logic based on `account.asset_model_ids`. This extends the base behavior while keeping the Community implementation independent from Enterprise-specific fields.
Resolved issues and error corrections
This update ensures that rental product availability in our e-commerce system accurately reflects when employees are on time off. Previously, the system didn't account for employee absences, leading to incorrect availability displays. This fix corrects this issue, providing a more reliable view of available resources for rental bookings.
Original PR description
…navailabilties Before this commit, when an human resource is linked to rental product thanks to his role and take a time off at a certain day. The user inside ECommerce should be able to add that product when the resource is off (since there is no resource available) at the period chosen. However, that check does not take into account the time off taken by the resources linked to that service rental product. This commit makes sure the time off of the resources linked to the product are correctly taken into account to know if the service rental product is available at a specific period. task-5075698 Forward-Port-Of: odoo/enterprise#98165
This update corrects a formatting error in invoices generated when using quotation templates in sales orders. Previously, the name and description were combined on the invoice PDF. Now, a necessary line break is added to ensure correct invoice presentation, improving clarity for customers.
Original PR description
### Issue: In this issue, when a quotation template is used in sale order, the end line is missing between name and description in the invoice pdf. #### Steps to reproduce: 1- Install a db with sale…
### Issue: In this issue, when a quotation template is used in sale order, the end line is missing between name and description in the invoice pdf. #### Steps to reproduce: 1- Install a db with sale and invoicing installed 2- Create a quotation template, and add a description in the line. 3- Create a quotation with the created template. 4- Confirm the order and create an invoice for the sale order. 5- Print the pdf, as seen the name and description are shown in the same line, while if the sale order was created without a template, we would have seen the description from product in the next line. `_get_journal_items_full_name` is used to enforce the product name in the description. However, in cases where product name doesn't exist in the description, e.g. our case here, the name and description will be shown in the same line in the invoice pdf. This can be fixed by adding a new line between the name and the description. opw-5130171 Forward-Port-Of: odoo/enterprise#102208 Forward-Port-Of: odoo/enterprise#100417
This update fixes an issue where the download button appeared prematurely in the eSigner wizard. It now correctly hides the button until a signature is completed, and adjusts text size for better readability when using Aadhaar signatures. This ensures a smoother and more professional user experience for e-document signing.
Original PR description
Version: - 19.0 Issue: - The wizard shows a download button even when using emsigner, but the file should only be downloaded after signing. - When users sign with Aadhaar and download the document, the text appears too small. Fixes: - Hide the download button in the wizard for emsigner requests. - Adjust page coordinates so the font size displays correctly. Impact: - Makes the text clear and readable in documents signed with Aadhaar. - Hides the download button until the user signs. After signing with eSigner, they can download the document with the certificate. task-5075596 Forward-Port-Of: odoo/enterprise#94279
This update fixes a previous issue where users couldn't select product variants when setting recurring prices. Now, users can accurately define recurring prices for each variant of a product, ensuring accurate subscription billing and improved flexibility in managing recurring revenue. This enhancement simplifies subscription management and reduces the risk of pricing errors.
Original PR description
Version: - 19.0 Before: - When creating a product with variants and setting recurring prices, users could not select product variants in the recurring price list. Issue: - The recurring price list appeared read-only for product variants, preventing users from defining variant-specific recurring prices. Cause: - The product variant field was missing from the recurring pricing view. Fix: - Added the product variant field to the recurring prices list view, allowing users to select and manage variants while setting recurring prices. Taskid-5361266 Forward-Port-Of: odoo/enterprise#101779
This update fixes a bug where the Partena export file incorrectly used the active company's code when generating exports for inactive companies. The change ensures the correct Partena code is included in the file, resolving potential reporting discrepancies. Tests have been added to verify this fix.
Original PR description
### Issue: In multicompany, when we generate the Partena export file of the 'not active' company, the partena code of the active company is inputted in the file. ### Steps to reproduce: - Install…
### Issue: In multicompany, when we generate the Partena export file of the 'not active' company, the partena code of the active company is inputted in the file. ### Steps to reproduce: - Install 'l10n_be_hr_payroll_partena' and switch to a Belgian company - Make sure the company has a "Partena Affiliation Number" - Create an employee for this company, with a "Partena code" - Create a contract for this employee, set it a running - Create a new Belgian company with a different "Partena Affiliation Number" - Activate both Belgian companies, but set the second one as active - Payroll > Reporting > Export work entries to Partena - Create a new one, populate it with the employee just created - Click "Generate Export File" ### Cause: When getting the data for the CSV file, we use `self.env.company` which is the active company. So when this company is not the one of the export record, we input the wrong code values. ### Solution: Use `self.company_id` instead of `self.env.company_id`. Also adds the test class with basic tests. opw-5345786 Forward-Port-Of: odoo/enterprise#102062 Forward-Port-Of: odoo/enterprise#101110
This update ensures that rental orders created from leads automatically include the tags associated with the original lead. Previously, rental orders lacked this functionality due to a slight difference in how context information was passed. This change streamlines the rental order process and maintains consistent tag management across sales and rental transactions.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a lead with tags; 2. convert lead to rental order. Issue ----- The new rental order has no tags. Cause ----- Tags are added to regular sales orders via the `_prepare_opportunity_quotation_context` method, but rental orders use `_get_action_rental_context` instead, which is virtually identical, but adds the `in_rental_app` context value, and doesn't include `default_tag_ids`. Solution -------- Rather than having duplicate code, make `_get_action_rental_context` retrieve the base context from `_prepare_opportunity_quotation_context`, then adding `in_rental_app=True`. opw-4549941 Forward-Port-Of: odoo/enterprise#102220
This update fixes an issue where invoice reports in the KE company setup were not displaying prices with commas. The fix removes a duplicate XPath and correctly formats the total and taxable amounts, ensuring accurate financial reporting. This improves clarity and compliance for KE-related invoices.
Original PR description
Steps to reproduce: 1. install `l10n_ke` 2. Switch to KE Company 3. Create a product with all KRA eTIMS details set on the Accounting page. 4. Create an invoice to KE Company with that product and set unitprice > 10000 5. Confirm the invoice and send it. Now, see the invoice report Issue: 1. xpath for `td_subtotal` was duplicated 2. The total amount and taxable amount were not formatted as prices (no commas). Before: <img width="771" height="397" alt="image" src="https://github.com/user-attachments/assets/492fe911-18d6-4e01-a16d-d7450c17373f" /> After: <img width="766" height="389" alt="image" src="https://github.com/user-attachments/assets/bbe5d4e2-b337-445c-833a-06492a8c827d" /> Solution: Updated the invoice report to: - Remove the duplicated `td_subtotal` xpath. - Properly format the total and taxable amounts with `t-options`. opw-5341578 Forward-Port-Of: odoo/enterprise#101794 Forward-Port-Of: odoo/enterprise#100279
This update fixes a technical issue that could cause website errors during event ticket payments when using rentable tickets. The change improves error handling to prevent these tracebacks from appearing to users, ensuring a smoother payment experience. While the rentable ticket feature itself is being addressed, this fix focuses on stabilizing the payment process.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have `website_event_sale` but not `stock` installed; 2. create an event with a ticket; 3. make the ticket's product rentable; 4. change ticket's product type to Goods; 5. publish the event to website; 6. register for the event via website; 7. go to payment. Issue ----- AttributeError: 'bool' object has no attribute 'tzinfo' Cause ----- Having odd configurations like rentable tickets creates rental orders without rental dates, leading to unhandled errors. Solution -------- While rentable event tickets doesn't make enough sense to make it work, we can still improve the error handling to prevent showing tracebacks to the client. opw-5207045 Forward-Port-Of: odoo/enterprise#101936 Forward-Port-Of: odoo/enterprise#99000
This update resolves a critical bug in the Report Editor that caused crashes due to incorrect data translation. By disabling translation specifically within the report's iframe, the system now reliably saves edited reports without errors. This ensures a stable and accurate report generation experience.
Original PR description
Before this commit, when google translate was active on the current ReportEditor, it produced wrong data to save, and ultimately crashes. After this commit, since we disable the translation on the whole HTML element inside the iframe (that is only for the edited report), there is no error any more opw-5122924 Forward-Port-Of: odoo/enterprise#97019
This update corrects a bug where invoice posting in Chilean tests resulted in incorrect date calculations due to timezone differences. The fix ensures invoices are processed correctly by freezing the test time and setting a fixed invoice date, preventing date rollbacks.
Original PR description
**Issue:** ```python File "/data/build/enterprise/l10n_cl_edi/models/account_move.py", line 744, in _l10n_cl_edi_post_validation raise UserError( odoo.exceptions.UserError: The stamp date and time…
**Issue:**
```python
File "/data/build/enterprise/l10n_cl_edi/models/account_move.py", line 744, in _l10n_cl_edi_post_validation
raise UserError(
odoo.exceptions.UserError: The stamp date and time cannot be prior to the invoice issue date and time. TIP: check in your user preferences if the timezone is "America/Santiago"
```
**Cause:**
Posting an invoice at early local hours (e.g., 2025-12-11 04:00) is converted by the [Chilean timezone (America/Santiago)](https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/l10n_cl_edi/models/l10n_cl_edi_util.py#L117-L120) to the previous day (e.g., 2025-12-10 19:30).
**Solution:**
- Freeze the test time at a stable CL-safe hour
- Add a fixed `invoice_date` aligned with the frozen timestamp
Reference : [timezone converter](https://dateful.com/time-zone-converter?t=730pm&d=2025-12-10&tz2=Santiago-Chile)
Runbot error: [234755](https://runbot.odoo.com/odoo/runbot.build.error/234755)
Related PR: https://github.com/odoo/enterprise/pull/99518
Forward-Port-Of: odoo/enterprise#102127
Forward-Port-Of: odoo/enterprise#101901This update streamlines the live chat closing process within the AI Website module. The change ensures a cleaner and more reliable way to close live chat sessions, reducing potential disruptions for users. This improves the overall user experience and efficiency of the AI-powered website.
This update fixes a usability issue in the Sign editor where the document dropdown didn't close properly after selection. The changes include improved hover behavior, consistent styling for actions, and a new mechanism to handle dropdown closures within the PDF iframe, ensuring a smoother user experience.
Original PR description
- Fix hover and pointer behavior on update document action - Apply consistent danger styling to delete action - Ensure dropdown closes correctly after interaction (PDF iframe has its own document so outside-click logic did not apply; add a click listener on the iframe document to close open dropdowns. ) task: 5384677
Features or functions removed from Odoo
This update removes a section related to GSTR reporting that is no longer required by Indonesian regulations. The change simplifies the report generation process and aligns with current tax requirements. This ensures Odoo Enterprise remains compliant.
Original PR description
Since the `purchase_b2c_regular` GSTR section is no longer required, this commit updates the related domain logic and removes the corresponding report lines.
Related PR: https://github.com/odoo/odoo/pull/236241
https://github.com/odoo/upgrade/pull/8933
Forward-Port-Of: odoo/enterprise#9977729 changes
New functionality added to Odoo
This update introduces new testing to ensure accurate calculation of maternity leave payments in the Belgian HR payroll module. The addition of PFA (Pay For All) test cases improves the reliability and compliance of the system when processing maternity leave benefits. This ensures accurate payroll reporting for employees on maternity leave.
Enhancements to existing features
This update enhances the delivery of Guatemalan electronic invoices to customers by automatically attaching the XML file alongside the PDF. Previously, only the PDF was sent, but now customers receive both files directly in their email, improving transparency and convenience. The XML file naming convention has also been standardized.
Original PR description
Purpose: In the Guatemalan localization, when an electronic invoice is created, the email template to the customer already contains the PDF version of the DTE. However, the XML file, generated and…
Purpose: In the Guatemalan localization, when an electronic invoice is created, the email template to the customer already contains the PDF version of the DTE. However, the XML file, generated and sent to the SAT through Infile, is not attached to that email. Even though the SAT and Infile deliver the XML to the customer, it is more convenient and transparent if Odoo includes it directly in the outgoing invoice template email, so the customer receives both files in one place. Before this commit:- - Only PDF version is attached by default in customer email for e-invoices. - Name of edi document is prefixed with `Demo` if company is in demo environment (check parent company's environment in case of child company) (e.g. DEMO_certificate_INV_2025_00001.xml) and prefixed with `SAT` if company is in testing or production environment(e.g. SAT_certificate_INV_2025_00001.xml). After this commit:- - XML version is also attached by default along with PDF in customer email for e-invoices. - Name of edi document is always prefixed with `SAT`. task-5224521 Forward-Port-Of: odoo/enterprise#98978
This update expands how SLAs are configured for helpdesk tickets, allowing other Odoo modules to adjust the criteria used to determine SLA deadlines. Previously, this was limited, but now it's enabled, providing greater flexibility and control over SLA management within the helpdesk system. This improves the accuracy and responsiveness of service level agreements.
Original PR description
Allow other modules to modify the _sla_find domain when adding SLAs to helpdesk tickets. This is already the case for extra and false domains, while the main domain is hardcoded up to this commit. Forward-Port-Of: odoo/enterprise#97501
Resolved issues and error corrections
This update ensures that exported PDF reports accurately reflect the filters applied in the web interface. Previously, reports like Trial Balance didn't display the selected Analytic Accounts, potentially leading to misinterpretations of the data. Now, the PDF header will clearly show the applied Analytic Accounts for accurate reporting.
Original PR description
Generally exported PDF reports should accurately reflect the filters applied in the web view. Currently, when a user filters a report (e.g., Trial Balance) by an Analytic Account, this context is…
Generally exported PDF reports should accurately reflect the filters applied in the web view. Currently, when a user filters a report (e.g., Trial Balance) by an Analytic Account, this context is missing from the exported PDF header. While the PDF correctly lists active Journals, Partners, and Dates, it omits the Analytic filter. This omission makes the report misleading, as a filtered report could easily be mistaken for a full company report when printed or shared. Impacts: - data/pdf_export_templates.xml Testing: 1. Open a report that supports analytic filtering (e.g., Profit & Loss). 2. Select some Analytic Account(s). 3. Export the report to PDF. 4. Verify that the PDF header explicitly lists "Analytic Accounts: [Acc1, Acc]" alongside the other options. <img width="1326" height="474" alt="image" src="https://github.com/user-attachments/assets/816a6343-3c7c-482c-a554-37e5bdf080e4" /> task-[5235995](https://odoo.com/odoo/all-tasks/5235995) --- In particular, we encountered this when making [`l10n_ph_reports`](https://www.odoo.com/odoo/all-tasks/5235995) cc- @ajml-odoo @vin-odoo
This update fixes an issue where custom report groupings with complex filters were incorrectly indented, causing formatting problems. The change improves the way Odoo calculates grouping levels, ensuring reports display correctly regardless of the complexity of the filters used. This ensures consistent and accurate report presentation.
Original PR description
When a custom groupby defined a domain with more than one element in it (typically, conditions on multiple fields, possibly with '|' or '&' operations), if groupby lines needed to be generated for subsequent groupby, the generated groupby lines had a too high level, and ended up being over-indented.
This was because the groupby expansion computed the number of higher-level groupby lines as the length of the domain needed to restrict their content. This was too naïve, and won't work well with custom groupbys, which can define longer (or even empty) domains.
This was spotted in master (19.1), with the refactored EC Sales list, which now uses a custom engine and a specific custom groupby map.This update allows accountants to archive reports, resolving an access issue that prevented them from doing so. The original problem stemmed from limited user permissions, specifically lacking the ability to update menu items. This change ensures accountants can properly manage and retain reports.
Original PR description
As a simple accountant without sysadmin rights, archive a report. A user access is raised because the user doesn't have access to update menuitems.
This update fixes a potential issue where users could accidentally pay sale orders linked to partners without addresses via the Point of Sale system. Following Fiskaly regulations, this change now prevents payment attempts and session closure if a partner lacks a required address, ensuring compliance and preventing errors. This improves the reliability of the PoS process.
Original PR description
### Description According to Fiskaly regulations, partners linked to PoS orders must have an address (street and zip code). A previous [commit] (https://github.com/odoo/enterprise/commit/af3a59ee8492693e20807ae30dc58038229f96cb) prevented adding such a client on a normal flow. However, before this commit it was still possible to pay a sale order linked to such a contact through PoS and this will raise a bad request error when closing the session and will prevent closing it. ### How to reproduce: * Setup a Fiskaly PoS config and open it. * Create a normal sale order linked to a partner with no address. * Select the sale order from pos and pay it. * Close the session Community PR: https://github.com/odoo/odoo/pull/235331 opw-5228944
This update fixes an issue where refreshing a new offer page after creation resulted in incorrect employee information. The fix ensures the correct employee context is maintained, preventing the system from defaulting to a blank employee field. This improves the user experience and data accuracy when creating new offers.
Original PR description
Steps to Reproduce ================== - Go to Employees - Choose an employee with no offers - Click on the "Offers - new" smart button (a form view will open with the correct employee name at the bottom) - Refresh the offer's page without saving (the employee field is emptied and the required Applicant field appears) Issue ================== The generate offer action that is triggered through the smart button returns a one-time action dictionary with the context. But that context is lost when we refresh the offer page as it's not saved anywhere. Fix ================== Replace the action dictionary with an action record for creating a new offer to ensure the context is maintained upon page refresh. Task-ID: 5059490
This update fixes a problem where users were receiving duplicate order receipts due to network delays. The fix ensures a unique identifier (UUID) is used for all print requests, preventing the IoT box from processing the same action multiple times. This eliminates the 'printing failed' error and ensures accurate receipt generation.
Original PR description
Currently multiple clients report double order receipts printing. This PR fixes the issue where due to slow network connection a request would be sent to the iot box but the iot box didn't reply in time to confirm the action finish. The user would then get an error showing 'printing failed' (due to a timout). If he cliks on retry the iot box would still print the previous receipt and then receive the new "retry" request with now a new action uuid which would also be printed because uuid is different from the 1st request. This PR adds a consistent uuid for both the initial and all the subsequent retry requests so that double actions would never be done by the iot box.
This update corrects a technical issue within the Enterprise edition's spreadsheet functionality. Specifically, a missing configuration setting was preventing proper sheet handling, which could have caused data inconsistencies. This fix ensures the spreadsheet feature operates reliably and accurately.
Original PR description
…SHEET command
This update resolves an error that prevented the creation of draft payslips for employees reporting through the BAS-W3 system in Australia. The fix corrects a coding issue that caused a data type error, ensuring that draft payslips can now be generated correctly for this specific employee configuration.
Original PR description
Currently, an error occurs when generating draft entries for the Australian payslips when the employee is configured to `report in BAS–W3`. **Steps to reproduce:** - Install the…
Currently, an error occurs when generating draft entries for the Australian payslips when the employee is configured to `report in BAS–W3`. **Steps to reproduce:** - Install the `l10n_au_hr_payroll_account` module and switch to `My Australian Company`. - Create an employee with all necessary payroll information and enable `Report in BAS – W3`. - Go to Payroll Settings and complete the `Payroll Onboarding`. - Navigate to Payroll > Payslips > Payslips and open any draft payslip. - Click `Create Draft Entry`. (Refer [1] for steps to produce.) **Error:** `TypeError: 'int' object is not iterable` **Root Cause:** At [2], the code tries to append an `integer`(`w3_tag.id`) to a `list`(`tag_ids`) using `+=`, which causes the `error`. **Fix:** This commit prevents an error when creating a draft entry by wrapping the integer in a list before adding it to `tag_ids`, similar to [3]. [1]: https://drive.google.com/file/d/1XGUUYCpmB3ocwXSWkxgFV7vjyAvRsHS6/view [2]: https://github.com/odoo/enterprise/blob/d9c864a5a55dd45f6fed794a809a5aefe26e7699/l10n_au_hr_payroll_account/models/hr_payslip_line.py#L23 [3]: https://github.com/odoo/enterprise/blob/d9c864a5a55dd45f6fed794a809a5aefe26e7699/l10n_au_hr_payroll_account/models/hr_payslip_line.py#L27 opw-5370293
This update adjusts the default demo data for the Belgian Intervat localization to disable Intervat calculations. This prevents Intervat from automatically being enabled during testing with Runbots, ensuring consistent and accurate demo results. This change improves the reliability of demo environments.
Original PR description
This commit set the `l10n_be_intervat_mode` to `disabled` in the l10n_be demo company. The reason why we are doing this it to avoid having intervat set by default on runbots. task-5404719
This update fixes a previous issue where tax warnings weren't displayed for certain sales lines flagged as 'out of scope.' The change ensures that all sales lines, including those marked as 'out of scope,' now trigger the appropriate tax configuration warnings, improving accuracy and compliance. This resolves a potential reporting discrepancy.
Original PR description
Previously, we excluded all lines with the `sale_out_of_scope` section from checks and warnings to improve performance. However, some tax-related warnings also apply to those lines. Due to the global exclusion, warnings for incorrect tax configuration were no longer shown when the line belonged to the `sale_out_of_scope` section. This commit removes the `sale_out_of_scope` condition from the shared (general) domain and instead applies it only to specific warnings where it is actually needed. task-5404258
This update resolves a formatting problem in invoices generated when using quotation templates in sales orders. Previously, the invoice PDF displayed product names and descriptions on the same line, creating an unreadable format. This fix ensures descriptions are correctly separated from product names in the invoice, improving clarity and professionalism.
Original PR description
### Issue: In this issue, when a quotation template is used in sale order, the end line is missing between name and description in the invoice pdf. #### Steps to reproduce: 1- Install a db with sale…
### Issue: In this issue, when a quotation template is used in sale order, the end line is missing between name and description in the invoice pdf. #### Steps to reproduce: 1- Install a db with sale and invoicing installed 2- Create a quotation template, and add a description in the line. 3- Create a quotation with the created template. 4- Confirm the order and create an invoice for the sale order. 5- Print the pdf, as seen the name and description are shown in the same line, while if the sale order was created without a template, we would have seen the description from product in the next line. `_get_journal_items_full_name` is used to enforce the product name in the description. However, in cases where product name doesn't exist in the description, e.g. our case here, the name and description will be shown in the same line in the invoice pdf. This can be fixed by adding a new line between the name and the description. opw-5130171 Forward-Port-Of: odoo/enterprise#102208 Forward-Port-Of: odoo/enterprise#100417
This update ensures that rental orders created from leads automatically include the tags associated with the original lead. Previously, rental orders lacked this functionality due to a minor difference in how context information was passed. This change streamlines the process of tagging rental orders, improving organization and reporting.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a lead with tags; 2. convert lead to rental order. Issue ----- The new rental order has no tags. Cause ----- Tags are added to regular sales orders via the `_prepare_opportunity_quotation_context` method, but rental orders use `_get_action_rental_context` instead, which is virtually identical, but adds the `in_rental_app` context value, and doesn't include `default_tag_ids`. Solution -------- Rather than having duplicate code, make `_get_action_rental_context` retrieve the base context from `_prepare_opportunity_quotation_context`, then adding `in_rental_app=True`. opw-4549941 Forward-Port-Of: odoo/enterprise#102220
This update resolves a bug where adding products to an invoice created from a project task was failing. The issue stemmed from differing context settings when navigating to the invoice from either a sales order or the task itself. This change ensures consistent domain settings, allowing users to correctly add products to invoices created from tasks.
Original PR description
On a fsm task, using the smart button to go to the invoice, will not give the same domain for the products, if you go from the sale order or directly from the task Steps to reproduce:…
On a fsm task, using the smart button to go to the invoice, will not give the same domain for the products, if you go from the sale order or directly from the task Steps to reproduce: ------------------- * Create a product - Purchase: False - Sale : True * Create a fsm task * Add products * Go to the sale order * Create the invoice (regular invoice) * Go back to the task * Go to the invoice using the invoices smart button * Try to add your product -> issue it's not possible. Observation: --------------- The domain of the search is not the same if we go from the sale order or from the task. This is because the domain depend on the context and the context is not the same : [Domain](https://github.com/odoo/odoo/blob/8258ddf12ed6c0495628f7a480d1e2424e756540/addons/account/views/account_move_views.xml#L1134-L1141) When using the smart button on the SO, some elements will be added to the context, the important one is: default_move_type : "out_invoice": [SO context](https://github.com/odoo/odoo/blob/18.0/addons/sale/models/sale_order.py#L1453) Instead when using it on the task, the context does not have that element: https://github.com/odoo/enterprise/blob/cb79d565031ee0e1bec9db82aa35deb2e1c03576/industry_fsm_sale/models/project_task.py#L325-L327 This will be calculate here in the js files: [evalContext](https://github.com/odoo/odoo/blob/c3367bd7c6900e42394b006ccf48c3b36a1b87e9/addons/web/static/src/views/fields/field.js#L400) opw-5135567 Forward-Port-Of: odoo/enterprise#101938 Forward-Port-Of: odoo/enterprise#98612
This update corrects an issue where subscription product cards incorrectly displayed both recurring and list prices. Now, subscription products only show the recurring price, ensuring accurate pricing information for customers. This improves clarity and simplifies product management.
Original PR description
Version - 18.0 Steps to Reproduce: Issue 1: Incorrect tooltip text 1. Go to Products → Products in subscription app. 2. Open a product page and select goods product type 3. observe product_tooltip…
Version
- 18.0
Steps to Reproduce:
Issue 1: Incorrect tooltip text
1. Go to Products → Products in subscription app.
2. Open a product page and select goods product type
3. observe product_tooltip show incorrect wording:
* "Based on order" showed end of the period.
* "Based on delivered" showed beginning of the period.
Issue 2: Product card shows both recurring and sales price
1. Go to Products → Products in subscription app.
2. Observe that the product card displays both recurring price and sales price
After this PR:
- Tooltip now correctly states:
* for "based on order" invoice_policy -> beginning of period
* for "based on delivery" invoice_policy -> end of period
- Product cards show only the recurring price when applicable.
task-5156390
<img width="1002" height="436" alt="image" src="https://github.com/user-attachments/assets/39f00555-e37a-44a5-8786-d7f8d6882de7" />
<img width="968" height="262" alt="image" src="https://github.com/user-attachments/assets/0d6d5c2d-d5ab-4376-bc03-dba243abce8b" />
Forward-Port-Of: odoo/enterprise#102147
Forward-Port-Of: odoo/enterprise#95010This update resolves an issue preventing HR Officers from generating offers due to changes in access permissions within the HR modules. The fix uses a temporary bypass to grant access to the necessary data, ensuring Officers can complete this critical task. This improves the efficiency of the recruitment process.
Original PR description
Steps to reproduce: ------------------------- 1. Install Salary Configurator module. 2. Create a new user and assign Officer rights in Employees and Recruitment. 3. Login with that user. 4. Create a new application and move it to 'Contract proposal' stage. 5. Click on the 'Generate Offer' button. Observation: ------------------------- An Access Error occurs, denying Read access to the `final_yearly_costs` field. Issue: ------------------------- In earlier versions, users had an additional access right that allowed them to access contract fields. After the HR modules were refactored, only HR Administrators and Payroll Users retained access to those fields. As a result users with only Officer rights in HR encountered an access error when generating an offer. Solution: ------------------------- Use `sudo()` to bypass access restrictions for the `final_yearly_costs` field when generating the offer. opw-5243280 Forward-Port-Of: odoo/enterprise#99478
This update fixes an issue where invoice reports for KE companies were not displaying prices with commas. The fix removes a duplicate XPath and correctly formats the total and taxable amounts, ensuring accurate financial reporting. This improves clarity and compliance for KE invoices.
Original PR description
Steps to reproduce: 1. install `l10n_ke` 2. Switch to KE Company 3. Create a product with all KRA eTIMS details set on the Accounting page. 4. Create an invoice to KE Company with that product and set unitprice > 10000 5. Confirm the invoice and send it. Now, see the invoice report Issue: 1. xpath for `td_subtotal` was duplicated 2. The total amount and taxable amount were not formatted as prices (no commas). Before: <img width="771" height="397" alt="image" src="https://github.com/user-attachments/assets/492fe911-18d6-4e01-a16d-d7450c17373f" /> After: <img width="766" height="389" alt="image" src="https://github.com/user-attachments/assets/bbe5d4e2-b337-445c-833a-06492a8c827d" /> Solution: Updated the invoice report to: - Remove the duplicated `td_subtotal` xpath. - Properly format the total and taxable amounts with `t-options`. opw-5341578 Forward-Port-Of: odoo/enterprise#101794 Forward-Port-Of: odoo/enterprise#100279
This update resolves an issue where archived employees were still appearing in timesheet entries. The fix ensures that timesheets only display entries for currently active employees, improving data accuracy and preventing confusion.
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 currency rates for companies outside of UYU were incorrectly generated with yesterday's date, leading to inaccurate tax calculations. The change ensures all currency rates are now synchronized with today's date, improving the accuracy of financial reporting for companies using other currencies.
Original PR description
When the company's currency is not UYU we will get an error when doing the convention of the rate return by (UY) BCU (Banco Central Uruguay). All the rates should be used the same date in order to…
When the company's currency is not UYU we will get an error when doing the convention of the rate return by (UY) BCU (Banco Central Uruguay). All the rates should be used the same date in order to properly do the conversions. ### Steps 1. Create a new Company with country Uruguay 2. Change current logged company to new Company 3. Change the currency to USD 4. Go to Settings, option Automatic Currency rate and configure provider yo [UY] Uruguayan Central Bank 5. Click manual synchronization 6. Check rates ### Current behavior before PR All currencies except UYU currency has created taxes with date today. Only one error in UYU currency that is created with yesterday rate  ### Desired behavior after PR is merged: All the currencies are created with the same date, the correct day that is today rate. References: LATAM 1341 / ADHOC Task 51716 Forward-Port-Of: odoo/enterprise#85065
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 version of the document, maintaining accurate product information. This improves data consistency and prevents users from seeing outdated document associations.
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 a bug where HR users were receiving unnecessary reminder emails. The system now filters out time-off and holiday entries, ensuring reminders are only sent for actual timesheets requiring user input. This improves efficiency and reduces email clutter for our users.
Original PR description
**Steps to reproduce:** - Install timesheet_grid_holidays - Create a user with no timesheet access - Create a leave and approve it as a manager - Set up employee reminders in timesheet settings - Run the timesheet reminder scheduled action **Issue:** HR users without timesheet app access or who haven’t submitted timesheets in the past 3 months were still receiving reminder emails. **Cause:** When a time-off is approved or a public holiday is recorded, it generates timesheet entries, which causes reminder emails to be sent incorrectly. **Fix:** Filter out time-off and public holiday entries when sending reminders. Now, reminders are only sent for actual timesheets that require user input. task-5085790 Forward-Port-Of: odoo/enterprise#102061 Forward-Port-Of: odoo/enterprise#95450
This update resolves an issue impacting Swiss payroll calculations, specifically related to overtime payments (ST-Overtime) and the LPP (Lohn- und Premodifizierungs-Pauschale) tax calculation. The fix ensures accurate and compliant payroll processing for Swiss businesses using the Odoo Enterprise module.
Original PR description
Forward-Port-Of: odoo/enterprise#102249 Forward-Port-Of: odoo/enterprise#102161
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 application failures and data inconsistencies. This improves the reliability of ECO processes.
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 fixes an issue where unnecessary slashes were being added to reports' XML formatting when there was no comment provided. The change ensures that the XML is correctly formatted, preventing potential errors in report generation and data processing. This improves the reliability of financial reports.
Original PR description
Since 17.0, we added a / when there was no comment in the comment section of the xml. This is wrong and should be left empty. opw-5242381 Forward-Port-Of: odoo/enterprise#101339 Forward-Port-Of: odoo/enterprise#100033
This update corrects a display issue in the Field Service 'All Tasks' view. Previously, task templates were incorrectly shown alongside real tasks. The fix ensures that only actual tasks are listed, improving the clarity and usability of this key reporting tool.
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 resolves an issue where employees designated as their own approvers couldn't modify their attendance records. The fix allows employees to directly update their attendance information, streamlining the process and improving accuracy. This change ensures employees have the necessary control over their attendance data.
Original PR description
Employees set as themselves as approvers couldn't modify their attendances due to permission issues with other models. task-5427553
This update resolves a problem where WhatsApp templates were incorrectly linked to the default company, preventing users from sending sign requests from other companies. The change filters templates based on user access rights, ensuring the correct templates are available for each company and eliminating access errors.
Original PR description
Currently, WhatsApp templates are linked to the default company, causing access errors when sending sign requests from other companies. This patch filters templates based on the user's access rights to avoid AccessErrors and clarify which templates are available per company. task-5424781
11 changes
Resolved issues and error corrections
This update resolves an error that occurred when sending quotations with a negative tax rate. The issue stemmed from a misconfiguration in how a key was being populated, leading to an attempt to access a missing key within the UBL export process. This fix ensures the system correctly handles negative tax scenarios, preventing the error and allowing quotations to be successfully sent.
Original PR description
Currently an error is generated when the user tries to send a quotations to the users. Steps to produce an error: - Create a new database with demo data and install `sale_management` - Go to…
Currently an error is generated when the user tries to send a quotations to the users.
Steps to produce an error:
- Create a new database with demo data and install `sale_management`
- Go to Invoicing > Configuration > Accounting >Taxes
- Create a new tax with a negative percentage, e.g., -10%
- Create a new `Quotation` and add a product line with the above-created negative tax.
- Error is generated when we try to `Send` this `Quotation`
Error: `KeyError: {'is_withholding': False, 'currency': res.currency(8,)}`
This issue occurs because the key `tax_total_grouping_key` is missing from `ubl_values[target_key]`. As we see at code line [1], there is already a condition intended to continue and avoid accessing the key when `tax_total_grouping_key` is empty. However, this condition is never triggered because `tax_total_grouping_key` is never empty.
The reason is that `tax_total_grouping_key` is populated from `ubl_default_tax_total_grouping_key` method. As shown in [2], this method always returns a value since it uses a static dictionary. Therefore, `tax_total_grouping_key` is guaranteed to have a value, making the empty check ineffective and allowing the code to attempt access to a key that may not exist in `ubl_values[target_key]`.
This commit fixes the issue by accessing `tax_total_grouping_key` from `ubl_values[target_key]` only when it is available.
[1]: https://github.com/odoo/odoo/blob/c620283459d802d06d07900652752d9f5ad3abef/addons/account_edi_ubl_cii/models/account_edi_ubl.py#L537
[2]: https://github.com/odoo/odoo/blob/c620283459d802d06d07900652752d9f5ad3abef/addons/account_edi_ubl_cii/models/account_edi_ubl.py#L99-L110
sentry-7113127232This update resolves an error that occurred when generating payslips for employees whose schedules didn't include Saturday public holidays. The fix ensures the system correctly verifies holiday presence in the employee's schedule before generating the payslip, preventing errors and ensuring accurate payroll processing. This improves the reliability of the HR payroll system.
Original PR description
## Short functional explanation of the error Let's say we have created a public holiday on a Saturday, which is out of an employee's schedule as they work from monday to friday. When trying to create…
## Short functional explanation of the error Let's say we have created a public holiday on a Saturday, which is out of an employee's schedule as they work from monday to friday. When trying to create a payslip for this employee for the month the public holiday occurs, it will show an error. ## Reproduction Steps 1. Create a public holiday on a Saturday. Set the Working Hours to a schedule not including Saturdays. Set the Work Entry Type as Generic Time Off. 2. Click on the Configuration tab > Time Off Types. 3. Create a Time Off type. Set the Requires Allocation field at No Limit, and the Work Entry Type field at Generic Time Off. 4. Click on the Management tab, then Time Off. 5. Click on New. Make sure to select an employee who has the same working schedule as the one you set for the public holiday, and that on their contract, their Work Entry Source is set to Working Schedule. Set the Time Off Type field to the one you just created. 6. Save and click Approve. 7. Go to Payroll. In Contracts, make sure that the employee's contract is running, and that their contract type is Full-Time. 8. Click on the Payslips tab > to pay. 9. Click on New and select the employee for which you just created a time off. ### Expected behavior The payslip is created. ### Unexpected behavior An Odoo Error Occurs. ## Origin of the issue In the code, we don't verify that the holiday is present in the employee schedule before computing the name of the payslip: https://github.com/odoo/enterprise/blob/a7e954dbe4a68b1770341e754101319a89e4de9e/hr_payroll/models/hr_payslip_worked_days.py#L87-L92 We simply check if one holiday exists, which is the case as a public holiday is applied to every employee. Therefore, we need one more check. __ opw-5269302 Forward-Port-Of: odoo/enterprise#100445
This update fixes inaccuracies in the Danish description for the Odoo module. The change ensures the module's details are accurate and clear for users in Denmark, improving the overall user experience. This is a minor correction to maintain accurate module information.
Original PR description
There were some mistakes in the Danish part of the module description. This commit corrects those mistakes. Forward-Port-Of: odoo/odoo#239180
This update fixes an issue where rental order scheduling wasn't updating correctly. The change mimics the rescheduling behavior of purchase orders, ensuring that rental transfer dates are adjusted when the rental order's period is extended. This improves the accuracy of rental tracking and management.
Original PR description
### Steps to reproduce: - In the settings enable "Rental Transfers" - Create a storable and rentable product P - Create and confirm a rental order for 1 unit of P - Change the rental period to 10 days in the future #### > The rental tranfers were not updated accordingly ### Cause of the issue: Nothing is currently implemented to reschedule the rental transfers. ### Fix: We somewhat mimic the reschedule purchase behavior: https://github.com/odoo/odoo/blob/6ca34a0f5347e0611cde95453119dda8b40fa589/addons/purchase_stock/models/purchase_order_line.py#L98-L101 But we rely on the order itself rather than its order lines since the `start_date` and the `return_date` are related fields so that no `write` is triggered when the order is rescheduled: https://github.com/odoo/enterprise/blob/96a80f583a0ca502ff06bc05d03775c76c6a7537/sale_renting/models/sale_order_line.py#L18-L19 opw-5158508
This update fixes an issue where items within Kanban card dropdown menus weren't easily navigable or highlighted on hover. By adding a specific styling class, the dropdown items are now fully functional and provide a better user experience for selecting options within Kanban views.
Original PR description
Issue:
Dropdown item-ish (such as `<a class="dropdown-item">` and ViewButton) inside kanban cards dropdown do not have the proper hover styling and are not navigable.
Steps to reproduce:
- Go to project -> open any card dropdown menu ("...") -> Items are not navigable
- Go to CRM -> open any card dropdown menu ("...") -> Items are not highlighted on hover
Fix:
This commit adds the "o-navigable" class to dropdown items and view buttons
which are inside a kanban card's dropdown menu, this makes them navigable
and adds proper hover and focus styling.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes a visual bug where the calendar wasn't displaying correctly on the My Dashboard. The issue stemmed from a missing CSS element, now resolved to ensure the calendar appears as expected when added to the dashboard. This improves the user experience for managing calendar events.
Original PR description
--- ## Short functional explanation of the error When adding a calendar to a personal dashboard, only the header shows. The calendar itself doesn't show. ## Reproduction Steps 1. Go to calendar and click on the cog next to it. 2. Click on Dashboard > add. 3. Go to the Dashboard app > My Dashboard. ### Expected behavior The calendar should show under the header. ### Unexpected behavior Only the header shows. ## Origin of the issue The calendar wrapper in the CSS style wasn't specified. --- opw-5242329 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug where forum post images set to specific sizes (50% or 25%) weren't being saved correctly. The issue stemmed from how Odoo handled inline styles, and the fix disables reliance on these styles for image sizing within forum posts. This ensures images are consistently displayed as intended.
Original PR description
Problem: When creating a new forum post with an image set to "50%" or "25%" size, the post is saved with the original image size instead of the selected one. Cause: The `Post.content` field has `strip_style=True`, which removes any inline `style` attributes before saving. Since image size ratios were applied using `style="width: 50%"`, the width information was lost. Solution: Disable image size options that depend on inline `style` attributes, as they cannot be preserved when saving forum posts. Steps to reproduce: 1. Go to Forum. 2. Create a new post. 3. Add an image and set its size to 50% or 25%. 4. Save the post — the image appears with its original size. opw-5173917 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234354
This update resolves an issue where custom snippet previews weren't appearing in the 'Insert a block' dialog when visibility options were saved. The fix ensures that snippet previews are consistently displayed, regardless of the configured visibility settings, improving the user experience.
Original PR description
When saving a snippet with visibility options (e.g. Hide on desktop), those options were also saved in the snippet template. As a result, the custom snippet preview was not displayed in the "Insert a block" dialog. This commit fixes the issue by explicitly forcing `display: block` on custom snippets in the dialog, ensuring they remain visible regardless of the saved visibility options.
This update removes a confusing warning message that appeared when users edited outdated website snippets. Now, users can directly access and modify these snippets without interruption. If an error occurs due to an outdated version, a clear alert message will be displayed to guide the user.
Original PR description
Currently when a user try to modify the options of an outdated snippet a warning block display on top of the options. The block present two options : 'try to update the snippet' or 'access options anyway'. This PR remove the warning on the options and suppose the 'access options anyway' is the default choice. If an error occur, the snippet version is verified and an alert message is display if the snippet is outdated. task-4297808
This update streamlines the planning process by automatically notifying users when employee work emails are missing. Instead of being blocked by a manual wizard, users receive a list of affected employees, allowing them to quickly resolve the issue by contacting HR or the employees themselves. This reduces delays and improves overall planning efficiency.
Original PR description
Before this commit, when the planning manager wants to send the planning and for some employees the work email is missing, the user is blocked on the wizard to fill the work email on those employees if he does not edit access to employee model. This commit makes sure the wizard to fill in the missing work email is not displayed if the user cannot edit the information of the employees. It also displays a notification listing the employees for which the work email is missing. By doing that, the user can easily remove those employees to continue his flow or ask to HR user or the employees concerned to complete the missing information. task-5090163
Documentation and clarification updates
This pull request updates the list of authorized members for the Adhoc Corporate Legal Agreement (CLA). This ensures compliance with Odoo's legal requirements and allows for continued contributions from key stakeholders. The change is purely administrative and does not impact Odoo's functionality.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
2 changes
Resolved issues and error corrections
This update corrects issues related to credit note processing for Kenyan businesses using the KRA (Kenya Revenue Authority) e-reporting system. Specifically, the system now prevents credit notes with mismatched customer PINs and ensures credit notes are not dated before the original invoice, ensuring accurate tax reporting and compliance.
Original PR description
* Prevent credit note with customer PIN different than the submitted invoice. * Prevent credit note to be dated before the original invoice date. task-5160113
This update resolves an issue with the Google Maps integration by modernizing the code to align with Google's latest guidelines. Specifically, it replaces outdated components and utilizes a more efficient loading method, ensuring ongoing compatibility and security.
Original PR description
Replaced the deprecated `google.maps.Marker` with `google.maps.marker.AdvancedMarkerElement`, as the former has been deprecated since February 2024. Additionally, updated the method for loading the Google Maps JS API to use the recommended dynamic library import for improved performance and compliance with the latest guidelines. References: - Migration to Advanced Marker: https://developers.google.com/maps/documentation/javascript/advanced-markers/migration - Dynamic library import: https://developers.google.com/maps/documentation/javascript/load-maps-js-api task-4441041