Tuesday, May 12, 2026
13 changes · saas-18.3
Resolved issues and error corrections
This update corrects a UI issue where the `l10n_co_edi_ubl` field on the Units of Measure form was missing its label, causing user confusion. The fix ensures the field is clearly labeled, improving form usability and data entry accuracy.
Original PR description
Currently, the field `l10n_co_edi_ubl` is displayed without a label in the UoM form, confusing users. **Steps to reproduce:** - Install the `l10n_co_edi` module and switch to the CO Company. -…
Currently, the field `l10n_co_edi_ubl` is displayed without a label in the UoM form, confusing users. **Steps to reproduce:** - Install the `l10n_co_edi` module and switch to the CO Company. - Navigate to Invoicing > Settings. - Enable `Units of Measure & Packagings`. - Open `Units & Packagings` and click `New`. **Observation:** The `l10n_co_edi_ubl` field appears between the `Quantity` label and its corresponding field, but its own label is not visible. <img width="1905" height="324" alt="6180769_before" src="https://github.com/user-attachments/assets/f35c345a-f449-46e4-ad15-6981109fca7a" /> **Root Cause:** The inherited view [1] inserts the field `l10n_co_edi_ubl` before `relative_factor` in the base view [2]. In the base view, `relative_factor` is wrapped inside a `<div>` with a shared label (`Quantity`). Since the new field is inserted inside this structure, it inherits the same layout without having its own label, resulting in the label being hidden. **Fix:** This commit updates the view to ensure that the field `l10n_co_edi_ubl` is properly displayed with its own label, avoiding UI confusion and improving form clarity. **After:** <img width="1907" height="376" alt="6180769_after" src="https://github.com/user-attachments/assets/f96470d3-8df2-4ca4-acf8-f6511a49d725" /> [1]: https://github.com/odoo/enterprise/blob/7b0d07bce92fb4b2cb588344fb0f6e3dd5d94f4a/l10n_co_edi/views/product_uom_views.xml#L4-L13 [2]: https://github.com/odoo/odoo/blob/bae4fa4e0dde2d2e2e4fcdbb968f630c080af818/addons/uom/views/uom_uom_views.xml#L15-L34 opw-6180769 Forward-Port-Of: odoo/enterprise#115933
This update resolves an issue preventing the sales team from opening project milestones. The fix bypasses access restrictions when calculating quantities, ensuring users in the 'sales_team' group can now successfully open and manage milestones within related sales orders. This improves workflow efficiency for sales operations.
Original PR description
Steps to reproduce: - Install the sale_project module - Create a sale order based on milestones - Create the project from the order - Open the project, click the three dots, and open a milestone Issue: Users are unable to open milestones and get an access error. Cause: Users in `sales_team.group_sale_salesman` lack read access to the related `sale.order.line`, causing an AccessError when `sale_line_id` is accessed during the computation of `product_uom_qty`. Fix: Compute `product_uom_qty` using `sudo()` to bypass record rule restrictions. task-5477304 Forward-Port-Of: odoo/odoo#263331 Forward-Port-Of: odoo/odoo#245392
This update resolves a problem where invoices using a specific tax category ('O-service out of tax scope') in Odoo failed Peppol validation. This was due to a misunderstanding of Peppol requirements regarding tax IDs. The fix ensures invoices with this category pass validation, improving compliance with Peppol standards.
Original PR description
**PROBLEM** In peppol, there is a tax category 'O-service out of tax scope'. This tax category is used when what is invoice can't be tax (out of the tax scope). This is different from tax exemption: when using tax category O, there can't be any vat id on the invoice. This also means you can't use tax category O with other taxes, since other taxes need the vat id. Invoices generated by odoo with tax category O failed peppol validation. **STEP TO REPRODUCE** 1. install account_edi_ubl_cii_tax_extension. 2. Create a tax with tax category O. 3. Create an invoice and try validating using the file validator. 4. You should have error BR-O-02 and BR-O-05. opw-6012669 Forward-Port-Of: odoo/odoo#254645
This update corrects a minor error in the account_edi_ubl_cii module that caused an unnecessary conditional check when determining tax exemption reasons for Belgium (BE). This fix ensures accurate tax processing and avoids potential issues with compliance. The change was a simple removal of a redundant condition.
Original PR description
When getting the tax exemption reason for BE, a redundant conditional was added by mistake related task-id-5905176 Forward-Port-Of: odoo/odoo#263753
This update fixes an issue where PDF Manager action names appeared awkwardly due to a styling class. The change removes this class, resulting in cleaner and more professional-looking action names within the PDF Manager interface. This improves the user experience.
Original PR description
Previously, pdf_manager actions used class "text-uppercase". Action names looked awkward. In this commit, we remove the class and properly display action names. task-6159317 Forward-Port-Of: odoo/enterprise#116382
This update resolves a visual glitch where the status bar appeared twice for sub-tasks. The fix ensures that the status bar accurately reflects the task's project association, preventing duplicate displays and improving the user experience. This change corrects a minor UI inconsistency.
Original PR description
Steps: - Create a task inside any project. - Create a sub-task under that parent task. - Open the sub-task and remove the project (clear the project field). - Look at the status bar at the top of the form view. Issue: - The status bar is displayed twice (both the Project stages and Personal stages - are visible simultaneously). Cause: - When the project field is cleared from a sub-task in the UI, conflicting visibility rules or residual stage data can cause the status bar widget to render twice. Fix: - To resolve this, an `onchange` event is added to the `project_id` field. If the user removes the project from a sub-task, the system now instantly falls back to the parent task's project and sets `display_in_project = False`. This syncs the frontend UI with the intended backend behavior, preventing the interface from entering the broken state and removing the duplicate status bars. task-6033970 Forward-Port-Of: odoo/odoo#255319
This update fixes an issue where the timesheet reporting incorrectly included public holidays from other companies, leading to inaccurate planned hour calculations. The fix ensures that only public holidays related to the employee's company are considered, improving the accuracy of the planning analysis report.
Original PR description
## Steps to reproduce: - Install project_timesheet_forecast module - Create a public holiday in one company - In another company create a planning slot for an employee that overlaps with the holiday - Go to Timesheets/Planning analysis report - Notice the report is not showing planned hours for the employee on the day of the public holiday ## Cause: When filtering the resource_calendar_leaves we don't check for the company so any public holiday in any company will be taken into account even if it doesn't affect the employee ## Fix: Exclude holidays that has different company than the planning slot opw-5027070 Forward-Port-Of: odoo/enterprise#116263
This update resolves an issue where a duplicate XML ID was present in the payroll configuration for Kenya (l10n_ke_he_payroll). This duplication caused potential errors and inconsistencies in payroll calculations. The fix ensures data integrity and accurate processing of employee salary contributions.
Original PR description
This commit avoids duplicated xml_id for `hr.salary.rule` model. In commit https://github.com/odoo/enterprise/commit/a7d51fa2ee8b1af0e807b3e9cb6e313d8885ff67, key `l10n_ke_employees_salary_pension_contribution` (sequence 72) was deleted and added key `l10n_ke_employees_salary_pension_contribution` (sequence 35). In commit https://github.com/odoo/enterprise/commit/c23243be9ca833acea7089defadbe0eaf869051d, key `l10n_ke_employees_salary_pension_contribution` (sequence 72) was added again. Forward-Port-Of: odoo/enterprise#115872 Forward-Port-Of: odoo/enterprise#85723
This update resolves an issue where pressing backspace in the HTML editor, specifically at the button's left edge, could cause a crash. It also corrected the behavior so that backspace accurately deletes characters when used at the edge of a button. This ensures a smoother and more reliable editing experience.
Original PR description
**Description of the problem** Pressing backspace when the cursor is positioned at the very left edge of a button could trigger a traceback. Additionally, even if the crash did not occur, the…
**Description of the problem** Pressing backspace when the cursor is positioned at the very left edge of a button could trigger a traceback. Additionally, even if the crash did not occur, the backspace behavior would be incorrect, because the cursor would move across a zero-width non-breaking space (Zwnbsp) without deleting the first character to the left. **How to reproduce** In the `html_editor`, create a button. Click on its very left edge, then press backspace. An error is thrown. **Why the problem happens** 1. Traceback when backspace is pressed `LinkPlugin.handleDeleteBackward` assumes that `previousSibling` is an element node, and calls the `matches` method. However, when clicking on the very left edge of a button, the cursor is positioned such that the left sibling (`previousSibling`) is a text node. Text nodes do not implement `.matches()`, leading to the crash. 2. No deletion of the character to the left of the cursor `DeletePlugin.isVisibleChar` handles the edge cases where backspace is pressed while the cursor is positioned to the side of a button, and defines the visibility of Zwnbsp to determine how much is deleted. The padding Zwnbsp to the left of a button are considered as visible, such that the user can delete an empty button without removing also the first character on its left. Anyway, the current code does not actually check if the button is empty, thus it applies to more cases than necessary. Probably this has never been observed before, because it takes a very precise click to the left edge to position the cursor between a button and its left Zwnbsp. **Fix** 1. Prevent the crash in `LinkPlugin` `LinkPlugin.handleDeleteBackward` now ensures that `previousSibling` is an element node before calling `matches`, otherwise it returns. 2. Fix backspace behavior in `DeletePlugin` `deletePlugin.isVisibleChar` now considers as visible only the Zwnbsp positioned to the left of an empty button. This way, if the user clicks on the very left edge of a button (which moves the cursor outside the button, to the left), pressing backspace actually deletes the character on the left. task-6102282 Forward-Port-Of: odoo/odoo#258858
This update eliminates redundant logging messages within the Account EDI UBL Cii module. Previously, similar log entries were repeated multiple times, which wasn't providing valuable insights. This change streamlines logging for better clarity and efficiency.
Original PR description
Before this commit, we had repeated logs (n-times if we had similar lines) but this doesn't help too much. To avoid this we decided to remove duplicated messages Task-None --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263779
This update fixes a minor discrepancy in the Norwegian tax settings. The tax code 32's rate was incorrectly set to 11.0. This change ensures accurate tax calculations for Norwegian businesses using Odoo, aligning with official tax regulations. This was coordinated with a related Enterprise PR.
Original PR description
The tax rate(`amount`) for code 32 was mistakenly set to '11.0'. To properly align with the official Norwegian tax rates, it needs to be updated to '11.11'. Related Enterprise PR: https://github.com/odoo/enterprise/pull/110792 task-6033027 Forward-Port-Of: odoo/odoo#263805 Forward-Port-Of: odoo/odoo#258390
This update fixes a display issue where fixed-price event tickets incorrectly showed a struck-through original price, appearing as a discount. The change ensures that fixed prices are displayed accurately, aligning with standard eCommerce behavior and providing a consistent user experience. This resolves a visual inconsistency that could mislead customers.
Original PR description
Event tickets show a struck-through original price even when a "Fixed Price" pricelist rule is applied, making it incorrectly appear as a discount. This is inconsistent with eCommerce shop behavior.…
Event tickets show a struck-through original price even when a "Fixed Price" pricelist rule is applied, making it incorrectly appear as a discount. This is inconsistent with eCommerce shop behavior. ### Steps to reproduce 1. Create an event with a paid ticket (e.g., 100 EUR). 2. Create a pricelist with a "Fixed Price" rule for that ticket (e.g., 80 EUR). 3. Open the event registration page. 4. The 100 EUR appears struck-through next to 80 EUR. ### Cause Odoo's website only shows a struck-through original price for discount rules, not fixed price rules. By design, a fixed price replaces the original rather than reducing it. However, the event registration page used a simplified check: it compared the final price to the original and assumed any difference was a discount. This ignored the rule type, incorrectly flagging fixed price rules as discounts. ### Fix Rationale A new helper method on the event ticket model now queries the applied pricelist rule to determine if it qualifies as a discount. opw-5993477
This update resolves a technical issue that could prevent the system from correctly processing stock valuation layers when they were linked to returned moves. Specifically, the system was incorrectly using a single UoM category, leading to errors. The fix ensures the correct UoM is used during quantity conversion, improving the reliability of stock valuation processes.
Original PR description
#### Issue: Consuming stock valuation layers linked to returned moves could raise an error when the SVL recordset contained products from different UoM categories. #### Cause: `_consume_specific_qty()` and `_consume_all()` used `self.uom_id` inside per-record loops. When self contained SVLs from different UoM categories, self.uom_id was multi-record, causing quantity conversion to fail with: `ValueError: Expected singleton: uom.category(2, 6)` #### Fix: Use the UoM of the current SVL record during returned quantity conversion: - `candidate.uom_id` in `_consume_specific_qty()` - `svl.uom_id` in `_consume_all()` opw-6119427 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263295 Forward-Port-Of: odoo/odoo#259736