Thursday, December 18, 2025
17 changes · 19.0
Enhancements to existing features
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
This pull request enhances the visual appearance and usability of the account reports module. Specifically, it updates the selection badges, improves the styling of review states, and adds functionality to redirect users to relevant check views based on return status. These changes aim to provide a clearer and more intuitive reporting experience.
Original PR description
task-5155703
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 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 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 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 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 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 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 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
This update resolves an issue where MRR commission calculations were inaccurate due to incorrect currency conversions. The fix ensures that all amounts are consistently converted to the company's main currency, leading to more reliable commission reporting and accurate financial data. This improves the reliability of subscription revenue reporting.
Original PR description
Before this commit, the log amount_signed was converted to the currency of the company of the log before being converted to the currency of the current company. There were issues as sometimes we did not any value in sub_rate_query. The join would fail to find a row and therefore the achievement would not be displayed. Moreover, the conversion rate were not always correct. This commit reuse the logic of the sale_order_log_report. We convert the amount_signed of the log into the currency of the main company and we convert that amount into the currency of the current company.
This update corrects an issue in the Belgian payroll calculations (l10n_be_hr_payroll) related to the calculation of Paid Family Allowance (PFA). Specifically, it now accurately handles the deferral of leaves to the following month and addresses discrepancies that could arise from version updates during the payroll period. This ensures more precise and reliable payroll reporting.
Original PR description
Fix the PFA computations: - Fix number of leaves to defer to next months - Deal with change of version in middle of the month