Tuesday, February 24, 2026
28 changes · 19.0
Enhancements to existing features
In French, replace 'toutes taxes comprises' with 'ttc' for better UI alignment. task-5712223
Original PR description
In French, replace 'toutes taxes comprises' with 'ttc' for better UI alignment. task-5712223
This update adds tests to ensure accurate calculation of wage types on payslips, considering various employee contract details like monthly wage types and multiple leave requests across different months. These tests strengthen the reliability of the Swiss payroll system by verifying correct wage type assignments.
Original PR description
This commit adds tests to the `_compute_l10n_ch_swiss_wage_ids` function to verify **Wage Types** in payslips across multiple months and with different **Monthly Wage Types** defined in an employee’s contract, as well as multiple leave requests occurring in different months. task-5906677 Forward-Port-Of: odoo/enterprise#107802
Resolved issues and error corrections
When a POS order paid through an online payment QR code is completed, the customer display now closes the QR popup automatically. This removes an unnecessary manual step for cashiers and keeps the customer display in sync with the finalized order.
Original PR description
Steps: --- - Configure online payment on the POS configuration. - Open a POS session and the customer display. - Add a product and an online payment line. - Validate the order and complete the payment via QR code. Issue: --- - The order is finalized, but the payment QR code remains visible on the customer display. - The QR popup must be closed manually every time. Cause: --- - The customer display popup lifecycle depends on `onlinePaymentData`. - This data was not cleared when the order was finalized. Fix: --- - Clear `onlinePaymentData` when the order is completed. task-5502344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249932 Forward-Port-Of: odoo/odoo#244991
Code cleanup and technical improvements
This update replaces an older component with a newer one for handling website URLs in the live chat feature. The change improves the system's architecture and ensures consistent URL display. This update doesn't impact user functionality but is a routine maintenance update.
Original PR description
This commit replaces the use of `WebsiteUrlPicker with `BuilderUrlPicker` community PR: [226324](https://github.com/odoo/odoo/pull/226324) task-5260613
Documentation and clarification updates
This pull request adds a signed Contributor License Agreement record for the contributor mega-ramo. This is a legal and administrative update that confirms contribution rights and does not change product behavior.
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
Romanian electronic stock delivery slips no longer crash when printed for partners using non-English languages. The report now relies on stable shipment data fields instead of translated label text, making delivery documentation more reliable for multilingual operations.
Original PR description
Steps to reproduce: 1. Switch the partner language to Spanish. 2. Print the Delivery Slip. 3. The report crashes due to translated XPath anchors. Cause: XPath targeted hardcoded English strings 'Tracking Number' and 'Total Weight'. Solution: Target technical fields o.carrier_tracking_ref and o.shipping_weight instead of text labels. opw-5493498 Forward-Port-Of: odoo/odoo#248679
The Point of Sale product and payment screens now use matching padding for their main action buttons. This creates a more consistent layout and improves the visual polish of the checkout experience.
Original PR description
For the main buttons of the product screen and the payment screen, we put the same padding so that the layout is more consistent. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Vendor payments in the Argentine withholding module now ignore withholding taxes that have been disabled. This prevents inactive taxes from being incorrectly calculated on vendor bill payments, reducing payment errors and manual corrections.
Original PR description
# How to reproduce - Install the l10n_ar_withholding module - Pick a Vendor and add a Purchase Withholding tax in the accounting tab - Go into configuration and disable that tax - Create a Vendor Bill with that Vendor - Confirm the bill and create a payment # The problem The deactivated tax is still computed in the payment # Why The function that fetches the withholding taxes does not check if the taxes are active or not # The fix I though of 2 solution : - Add an override to remove the taxes from the Vendor when they are deactivated - Add a filter to the fetch function to check if the taxes are active I chose the 2nd solution as it is the least invasive one. opw-5917257 Forward-Port-Of: odoo/odoo#247831
The Recruitment app now hides the option to edit talent properties when a talent record is not linked to a job. This prevents users from encountering a confusing error and keeps the interface clearer in cases where editing would not work.
Original PR description
# How to reproduce - Go to the Talen Pool sub-menu of the recuitment app - Create a new Talent - Click on the cog button, then on "Edit Properties" # The problem A not very descriptive error message…
# How to reproduce - Go to the Talen Pool sub-menu of the recuitment app - Create a new Talent - Click on the cog button, then on "Edit Properties" # The problem A not very descriptive error message is displayed # Why The hr.applicant model has a Properties field that allows the edition of its properties directly in the UI. This field needs to be linked to a PropertiesDefintion field in another model. In our case, that definition is in the hr.job model linked to the hr.applicant model via the field job_id. To be able to edit the properties of the hr.applicant model, it needs to be linked to a job, which is not always the case. A fix was made in master to allow the edition of properties even when there is no job_id (https://github.com/odoo/odoo/commit/99aa75bc64ee8898a0815163603e5861c35b0b94) but that fix is not applicable to a stable version. The fix I implemented instead hides the button when editing the properties would fail. opw-5932666 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue that could block users when moving an already won CRM lead to another won stage after the year changed. The update prevents an unexpected error in the celebration message logic, keeping sales workflows smooth for older opportunities.
Original PR description
Currently, a traceback occurs when a lead won in a previous year is moved to another won stage in the current year. ### **Steps to Reproduce:** 1) Install CRM without demo data. 2) From the…
Currently, a traceback occurs when a lead won in a previous year is moved to another won stage in the current year.
### **Steps to Reproduce:**
1) Install CRM without demo data.
2) From the `CRM>Configuration>Stages` make `new` stage as **'won'** stage.
3) Create a lead with dated in the past (e.g., 30-12-2025 by changing system date)
and with some expected_revenue.
4) Change the system date to today and move the lead to the Won stage.
Ref Video: https://drive.google.com/file/d/18OCQ4Tl6Co_oh28XNag3qjxMkXJNSMOh/view?usp=sharing
### **Error:**
`TypeError: '<' not supported between instances of 'NoneType' and 'float'`
### **Root Cause:**
When a lead is moved to a won stage, `_get_rainbowman_message` is called and computes the values for `max_{team,user}_{31,7}`. However, when the lead spans different years, the condition of SQL query at [1] fails(because 2025 != 2026) due to which SQL query return null from the MAX() Function. As a result, subsequent comparisons at [2] fail, raising an Error.
### **FIX:**
Introduce small helper method(`_is_lower_than_expected_revenue`) to ensure comparisons
across different years only happen when we have meaningful numeric values.
[1]- https://github.com/odoo/odoo/blob/fb4e08fe46c0e1865e30b0ce1eb5f4436438ea03/addons/crm/models/crm_lead.py#L1218
[2]- https://github.com/odoo/odoo/blob/fb4e08fe46c0e1865e30b0ce1eb5f4436438ea03/addons/crm/models/crm_lead.py#L1232
**opw-5484887**
**sentry-7026119584**This fix makes website page checks more reliable by avoiding a request context that may not always be valid. It helps prevent potential errors when the system checks whether a website page already exists.
Original PR description
The `request` global object should not be used from models, as it may be invalid. This commit remove its uses from the method `check_exsiting_page` that was introduced in commit 45e15673a70cf770d8e343a0a3b805eccdbed0d1. task-5888297
This fixes a display issue in the Discuss app where users could see an unwanted horizontal scrollbar when using a narrower desktop browser window. The chat area now resizes properly, making conversations easier to read without sideways scrolling.
Original PR description
Before this commit, when Odoo browser had a relatively small width but still desktop width, the Discuss app had sometimes an horizontal scrollbar. Steps to reproduce: - Open General with Demo data on…
Before this commit, when Odoo browser had a relatively small width but still desktop width, the Discuss app had sometimes an horizontal scrollbar. Steps to reproduce: - Open General with Demo data on 1080p monitor - have window take slightly below half of screen width => The Discuss app has horizontal scrollbar, from sidebar non-compact, message list, and the member panel all open at once. This horizontal scrollbar comes from the General demo data that has a sub-thread preview from the 1st message. A sub-thread preview has a max-width of 400px, which shouldn't be an issue on itself. However due to parented container not having `min-width: 0`, it didn't want to shrink lower than this max-width. This commit fixes the issue with `o-min-width-0` on the parented container to make sure this can shrink lower than the sub-thread preview's max width of 400px. Task-5956698 Before / After <img width="882" height="635" alt="Screenshot 2026-02-20 at 16 36 14" src="https://github.com/user-attachments/assets/516b66a1-f8d2-4ee9-b62f-6d94dfe98d11" /> <img width="884" height="637" alt="Screenshot 2026-02-20 at 16 37 07" src="https://github.com/user-attachments/assets/987f418c-f7e2-477b-ae9c-6c68d6a21ec5" />
Fiscal position tax mappings now show inactive taxes consistently, matching what users see when opening taxes from the tax configuration menu. This helps accounting teams review and maintain tax replacement rules without missing archived tax records.
Original PR description
Observed issue: inactive taxes are shown in "Replaces" `original_tax_ids` field if the form view of a tax is opened through "Configuration"->"Taxes", but not shown under "Replaces" in a fiscal position tree view, nor are they shown in the same "Replaces" field of the tax form view when opened from the fiscal position tree view. Cause: the fiscal position link calls `action_open_related_taxes` on partner (path `/account.tax/[id]`), while the "Configuration"->"Taxes" calls `action_tax_form` on tax (path `/taxes/[id]`), which has additional context element `'active_test': False` among others. Solution: adding the context to the fiscal position action produces the desired behavior, but it might break something else as it affects the whole view. task-5917667 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247787
This fixes the website editor’s “More options” behavior so the editing area keeps focus after the menu opens. It also ensures typing in that menu correctly narrows the available commands, making content editing smoother and less confusing.
Original PR description
**Issue 1:** Steps to Reproduce - Click on the More options button in the power buttons. - The powerbox opens, but the editor loses focus and the button receives focus. Description of the issue: -…
**Issue 1:** Steps to Reproduce - Click on the More options button in the power buttons. - The powerbox opens, but the editor loses focus and the button receives focus. Description of the issue: - After clicking the power button, the button becomes focused and the editor loses focus. Solution - When clicking the power button, after the command is executed in the click event, explicitly restore focus to the editable area so the editor remains focused. **Issue 2:** Steps to reproduce - Click More options in the Power Buttons to open the powerbox. - Start typing `heading`. Description of the issue: - The powerbox does not filter commands and continues to show all commands. Cause: - In `search_powerbox_plugin`, commands are filtered only when `shouldUpdate` is true. - `shouldUpdate` is set only when the powerbox is opened through `search_powerbox_plugin`. - Power Buttons open the powerbox via `powerbox_plugin`, so `shouldUpdate` remains false and filtering is not triggered. Solution: - Introduced `openSearchPowerbox` in `searchPowerboxPlugin`. - Updated the implementation to use this method instead of `openPowerbox` in `search_powerbox_plugin`. - Instead of opening the powerbox via `powerbox_plugin`, it is now opened via `search_powerbox_plugin`, ensuring `shouldUpdate` is set correctly and commands are filtered on keypress. task-5485088 Forward-Port-Of: odoo/odoo#249352 Forward-Port-Of: odoo/odoo#244454
The chat window now shows the Call Settings panel header with the correct background color. This prevents the title from visually overlapping content while scrolling, making the panel easier to read and use.
Original PR description
Before this commit, when opening the "Call Settings" in a chat window, the header of the action panel was missing a background color. Because of this, when scrolling down, the Action panel title was floating above the content and the text was overlapping, making it hard to read. This comes from `.bg-inherit` that requires the parented chain to rigorously have `.bg-inherit` too until reaching an actual bg color. In this case, one parent container lacked it, which is what this commit fixes. Task-5867464 (point 84) Before / After <img width="382" height="465" alt="Screenshot 2026-02-24 at 16 06 32" src="https://github.com/user-attachments/assets/f5c4a309-c60a-4e9b-bef0-06ee7ba731b8" /> <img width="386" height="468" alt="Screenshot 2026-02-24 at 16 06 18" src="https://github.com/user-attachments/assets/fea35f8f-2a76-4c40-b51e-28dbfce3a281" />
This fixes a rounding mismatch in tax calculations when prices include tax. It helps prevent small one-cent differences in accounting totals, improving invoice and tax amount accuracy.
Original PR description
The included method calculates with the to_price_excluded_factor during computation and thus gets the entire float value. However, the exclude function gets a rounded raw_base, which in certain scenarios can cause the amount to be off by a point. eval_tax_amount_price_included (raw_base * to_price_excluded_factor * tax.amount) / 100.0 (33.33 * 0.8474576271186441 * 18) / 100.0 => -5.0842372881355935 (5.08) eval_tax_amount_price_excluded (raw_base * tax.amount) / 100.0; (28.25 * 18) / 100.0 => 5.085 (5.09) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the payroll sheet calculation would fail if there were minor warnings during processing. The change allows the payroll sheet to be generated even with warnings, ensuring consistent payroll reporting. This improves the reliability of payroll data and reduces potential disruptions.
Original PR description
Revert https://github.com/odoo/enterprise/pull/104137
This update corrects a discrepancy in payslip calculations for employees using the private car daily allowance. The daily amount is now rounded to two decimal places, ensuring it precisely matches the 'Quantity × Amount' displayed on payslips. This improves payroll accuracy and reporting.
Original PR description
Round the computed daily private-car salary rule amount to 2 decimals so the displayed per-day value matches Quantity × Amount on payslips. References task-5917569 Forward-Port-Of: odoo/enterprise#107986 Forward-Port-Of: odoo/enterprise#106753
This update resolves a testing issue that prevented users from validating Arabic VAT invoices. The change uses elevated permissions to write necessary files, ensuring the testing environment functions correctly. This improves the reliability of the Arabic VAT module during development and testing.
Original PR description
This pull request makes a minor update to the `_dummy_afip_validation` method in `account_move.py`, improving its reliability for testing environments. * Testing reliability: The method now uses `sudo()` when writing dummy AFIP fields, ensuring that the operation succeeds even if the current user lacks write permissions. Without this fix, if the user doesn't belong to group "base system", it won't be able to validate invoices in testing environment. <img width="1258" height="454" alt="image" src="https://github.com/user-attachments/assets/522bfd9d-33be-4bcd-a60b-ef4c09a8e0d6" /> Forward-Port-Of: odoo/enterprise#107937
This update fixes an issue where the order of selection options in sign templates was being lost. The change ensures that users consistently see their selected options in the order they entered them, improving data accuracy and usability. This was achieved by modifying a core process to preserve the original sequence of selections.
Original PR description
Steps to reproduce: 1. Open a Sign template. 2. Drag a 'Selection' field onto the document. 3. In the popover, type options in a specific order (e.g., Delta, Alpha, Beta). 4. Click save. 5. Re-open or inspect the data 6. observe the order is scrambled based on Database ID. Cause: The Python method used `list(set())` which is an unordered collection, losing the user's input sequence. Furthermore, the final `search().ids` call returned records sorted by primary key (ID) rather than the provided list order. Solution: Replace `set()` with `dict.fromkeys()` to deduplicate while preserving input order. opw-5896373 Forward-Port-Of: odoo/enterprise#107175
This update fixes a validation issue in the self-order point system by aligning its data checks with the standard point-of-sale system. This ensures greater data accuracy and reliability for self-order transactions, reducing potential errors and improving the overall customer experience.
Original PR description
This commit improves the data validation of pos self order by using the same validation as the one used for regular pos order.
This update resolves a previous limitation in offer creation, allowing users to now select both the PDF template and designated signatories when generating offers. Previously, certain offer types couldn't utilize these features, restricting customization options. This enhancement improves the flexibility and professionalism of offer generation within the system.
Original PR description
Before if you created an offer for an employee version and not a contract template or a contract template without a sign template, it was impossible to choose a pdf template or signatories. This commit fixes this issue. Backport of https://github.com/odoo/enterprise/pull/101081 Task-5485397
This update resolves an issue where the holiday attest calculation in the payroll module would fail when employees had multiple leave types allocated. The fix ensures all leave types are correctly accounted for during the calculation, preventing errors and providing accurate holiday attest reports. This improves payroll accuracy and reporting.
Original PR description
Bug : - allocate multiple leave types to an employee - lay off the employee -access the holiday attest wizard and try to compute holiday attest and you'll see a traceback Reason : - time_off_allocated and time_off_taken were expecting to find exactly one line of "Legal Time Off". Receiving multiple caused an Error. Fix : FIxing the logic by taking all the available lines and summing there values. task - 5461268
This update resolves a minor issue where the stock barcode scanning process was occasionally rounding off stock quantities, leading to discrepancies in delivery orders. The fix ensures more accurate stock updates when scanning barcodes, improving order fulfillment precision. This impacts the accuracy of stock levels reported in the system.
Original PR description
To reproduce the issue: - Create a stock quantity of product1 for example of 275.84 kg in PACK1 - Create a delivery order of 3.6 kg - Go to the delivery order on stock barcode - Scan PACK1 - The new line is created as 272.2399999999 Forward-Port-Of: odoo/enterprise#108198 Forward-Port-Of: odoo/enterprise#89300
This update resolves an issue where users with limited accounting access (read-only) were encountering errors when viewing invoices or partner details. The change ensures that the 'addenda_ids' field is only displayed to users who have the necessary permissions, improving stability and usability for all users.
Original PR description
User with "read-only" access to accounting will trigger an error if they try to open an invoice or partner due to field addenda_ids. This commit aims to render this field only if the have the right to fetch it. opw-5931178 opw-5954244
Portal and internal users were previously unable to upload documents to requested documents. This fix addresses a technical error where sending both an access token and a user folder ID to the upload controller resulted in a 400 error. The solution is to simply omit the user folder ID when an access token is provided, allowing successful document uploads.
Original PR description
Portal users and internal users cannot upload a document in a requested document Steps to reproduce: 1. Install Documents 2. Go to Documents and create a new request for user Joel Willis 3. Connect as portal user and go to Documents 4. Try to upload the requested document 5. An error occurs The same problem occurs for user Marc Demo Problem: Sending both an access_token and a user_folder_id to the controller raises an error 400 https://github.com/odoo/enterprise/blob/519862bf9b708d756478d4d81787f8a1999bc574/documents/controllers/documents.py#L608-L609 Solution: Do not send a user_folder_id when we have an access_token opw-5439104
This update fixes an issue where the names of Ecuadorian localization regimes didn't comply with government requirements for electronic invoices. The names have been updated to meet these standards, and a mapping field has been added to ensure consistent naming in government-submitted XML invoices, always in Spanish. This ensures accurate and compliant invoice generation for Ecuadorian businesses.
Original PR description
[FIX] l10n_ec_edi: fiscal localizations name The name of the regimes for the Ecuadorian localization does not respect the government requirements Steps to reproduce: 1. Install l10n_ec_edi module 2. Go to Settings > Invoicing > Ecuadorian Localization 3. In Electronic Invoicing > Regime, the names of the regimes do not respect government requirements Solution: Change the name of the fiscal localizations to respect the requirements Add a computed field used to map the name of the regime to the technical name of the regime used in SRI documents We write them in Spanish because we always want the name of the regime to be in Spanish in the XML invoice sent to the government, even if the user didn't install any other language. opw-5221871 Forward-Port-Of: odoo/enterprise#105914
This update corrects a display issue in the Timesheet grid view where the total overtime was incorrectly labeled as 'Weekly Overtime'. The change renames the display to 'Total Overtime', ensuring accurate reporting across different time periods (day, week, month).
Original PR description
### Issue: When displaying the month in the grid view and hovering the bottom right cell, where the total overtime is displayed, it shows "Weekly overtime". ### Steps to reproduce: - Open Timesheet app - In "My Timesheet", display the grid in day or month - Hover the bottom right cell - It displays "Weekly Overtime" ### Solution: Rename it to "Total overtime" to handle all periods (day, week, month). opw-5502864 Forward-Port-Of: odoo/enterprise#107642