Monday, May 18, 2026
8 changes · 17.0
New functionality added to Odoo
This update adds the ability to display JSON content with syntax highlighting within Odoo's Ace editor. Previously, custom modules using JSON data couldn't be formatted, but now users can view and interact with JSON data like configuration snapshots and API responses with proper code coloring and folding capabilities. This improves readability and usability for working with JSON data within Odoo.
Original PR description
## Summary - Vendors the canonical [ace-builds](https://github.com/ajaxorg/ace-builds) `mode-json.js` into the `web.ace_lib` bundle, so the Ace editor can syntax-highlight JSON content. - Registers…
## Summary
- Vendors the canonical [ace-builds](https://github.com/ajaxorg/ace-builds) `mode-json.js` into the `web.ace_lib` bundle, so the Ace editor can syntax-highlight JSON content.
- Registers `"json"` in `CodeEditor.MODES` so `widget="ace" options="{'mode': 'json'}"` passes the prop validator.
- For readonly editors only, re-enables `showGutter` and `showFoldWidgets` when `mode === "json"` — this is what makes the fold triangles in the gutter clickable for users viewing read-only JSON (config snapshots, API response logs, audit fields, etc.). Other modes keep their existing behavior of hiding the gutter when readonly.
## Why
Odoo ships the Ace editor with modes for `js`, `xml`, `qweb`, `python`, and `scss`, but not `json`. Custom modules that surface JSON payloads (third-party API responses, structured logs, configuration blobs) have no native way to render them with syntax highlighting; today they either fall back to a plain `<field>` or vendor their own `mode-json.js`, which is fragile.
This is the smallest change that solves the gap consistently for everyone:
- The mode lives next to the other vendored ace modes.
- The `CodeEditor` API surface is unchanged (just one more allowed value for `props.mode`).
- The readonly gutter override is narrowly scoped — no behavior change for any other mode.
The vendored `mode-json.js` is the standard ace-builds file, adapted minimally to match the existing files in `addons/web/static/lib/ace/`:
## Test plan
- [ ] In a development DB, open a view that renders an ace JSON field — e.g.
```xml
<field name="some_text_field" widget="ace" options="{'mode': 'json'}"/>
```
and confirm: syntax colors are applied; brace matching highlights pairs; `Ctrl+/` line-comments; typing JSON behaves the same as in `python` / `js` modes.
- [ ] On the same field with `readonly="1"`, confirm the gutter is visible and fold triangles appear next to every `{` and `[`. Clicking a triangle collapses the block; clicking it again expands. Keyboard shortcuts (`F2`, `Alt+L` / `Cmd+Option+L`) also fold/unfold.Resolved issues and error corrections
This update resolves an issue where the Timesheet Kanban header and dropdown menus were overlapping. The fix removed a problematic CSS setting (`position-sticky`) that created separate stacking contexts, allowing the header and Kanban view to display correctly. This ensures a cleaner and more functional user experience.
Original PR description
Steps to reproduce: - Open Timesheets. - Switch to kanban view. - Groupby any field. - Start timer and click on task/project field. Issue: - Kanban Header and Dropdown menu of selection overlap. Reason: - It is due to the usage of `postion-sticky` on the header thus creating it's own stacking context, so header and Kanban Renderer body work in different stacking context, thus overlapping each other where they shouldn't have. For more info refer: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/position#sticky Fix: - Remove `postion-sticky` as it doesnt serve any purpose as header can now work being a static postioned node. task-4714235
This update corrects a technical issue where an approval rule was being applied incorrectly due to a duplicate XML ID. By renaming one of the duplicate IDs, the system now correctly distinguishes between user-level and manager-level approval access, ensuring accurate and reliable approval workflows. This resolves a potential inconsistency in how approvals were handled.
Original PR description
The XMLID `approval_approver_manager` was defined twice, causing the rule to be applied with the last evaluated access configuration for both `group_approval_user` and `group_approval_manager`. This commit renames the first occurrence of the duplicated XMLID to `approval_approver_user` to restore the intended separation between user-level and manager-level approval access rules. task-6095010
This update ensures that the price comparison strikethrough only appears when the compare price is higher than the sales price. Previously, it incorrectly displayed a strikethrough even when the prices were identical, creating a confusing user experience. This change improves the accuracy and clarity of product pricing on the website.
Original PR description
Steps to produce: --- - Install website_sale module. - Enable `Comparison Price` from settings. - Create a product with sales price = 25 and compare price = 25. - Go to the shop page and search for…
Steps to produce: --- - Install website_sale module. - Enable `Comparison Price` from settings. - Create a product with sales price = 25 and compare price = 25. - Go to the shop page and search for the product. Issue: --- - The strikethrough appears on the compare price (25) even when the compare price equals the sales price. - The strikethrough should only appear when the compare price is strictly greater than the sales price. Root cause: --- - In `_search_render_results_prices` [1], the condition only checks for the presence of `compare_list_price` in `combination_info`, without verifying that it is actually greater than the sales price. This causes the strikethrough to render even when both prices are equal. Solution: --- - Added a strict greater-than check on compare price against the sales price, aligning with the existing behavior already implemented for the product page [2]. Before: --- <img width="537" height="98" alt="image" src="https://github.com/user-attachments/assets/a1524f0f-4a59-4daf-ac7d-834604710492" /> After: --- <img width="538" height="95" alt="image" src="https://github.com/user-attachments/assets/1e32269b-13c0-469b-9d1f-e6d6ced97fdd" /> [1]https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/models/product_template.py#L831-L834 [2]https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/views/templates.xml#L1340-L1346 opw-6178129 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures all date displays in the Point of Sale module (including cash receipts and sales reports) use Odoo's standard date format, regardless of the user's device. Previously, dates were displayed based on local device settings, leading to inconsistencies. This change improves clarity and accuracy for users.
Original PR description
Why this commit: --- There are two instances in version 17.0 where dates use toLocaleString(), which relies on the device's local format instead of the Odoo-configured format. Since Odoo already…
Why this commit: --- There are two instances in version 17.0 where dates use toLocaleString(), which relies on the device's local format instead of the Odoo-configured format. Since Odoo already defines a standard date format, all toLocaleString() usages in pos should be replaced to ensure consistency. Starting from version 17.0, cash in/out receipts and the sales report use the local device time format. This commit updates those references and aligns them with the Odoo-configured date format. During forwardporting the fix in version 19.0 needs to be added to [base.js](https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/point_of_sale/static/src/app/models/related_models/base.js#L64-L69). As formatDateOrTime function is used in the [reciept header](https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml#L13) printing date on all reciepts. After this commit: --- <img width="947" height="982" alt="image" src="https://github.com/user-attachments/assets/2d9e4199-75dd-40ea-aeb1-27401c9022f3" /> All date references consistently use the Odoo-configured date format. OPW: 6087341 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the UBL XML generated by our system was sending the delivery date with a time component, causing external validation services to reject it. Now, the delivery date is formatted as a date-only value, ensuring compliance with UBL standards and successful validation. This prevents errors in the invoicing process.
Original PR description
Behavior before: The UBL XML generation was sending the delivery date as a datetime value (e.g. 2026-05-12 14:00:00) instead of a date-only value. This caused the external validation service to reject the XML because the ActualDeliveryDate field expects a date-only format. Behavior after: The delivery date is now converted to a date-only value before being included in the UBL XML payload, ensuring compliance with the expected schema format. Fix: 1. Convert invoice.delivery_date to invoice.delivery_date.date() before serializing the XML payload. 2. Added safe handling for empty delivery dates to avoid runtime errors. opw-6183723 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a technical issue related to how Odoo handles JSON responses from external services. The change ensures that error handling works consistently regardless of whether a specific library (simplejson) is installed, preventing unexpected errors and improving stability. This resolves a potential disruption to data processing.
Original PR description
The requests library uses different libraries to parse json objects depending on whether or not the simplejson library is installed (https://github.com/psf/requests/blob/dc9dbdfb3434c6e58d48fd102f93e5342308817e/src/requests/compat.py#L74). This in turn causes our try/excepts to fail if the simplejson library is installed in the env we simply re-raise the json error in case the simplejson library is installed so our try/excepts flows are not broken by the existence of a random package opw-6150349
This change resolves a test failure related to user group permissions within the Odoo account module. The fix ensures the test works correctly when only the core 'account' module is installed, preventing disruptions to development. This improves test reliability and streamlines the development process.
Original PR description
**Problem:** In PR #263425, the test uses the user group `group_account_manager` to grant write access to `bank.statement.line`. However, this write access is available through `group_account_user` which is only inherited in `account_accountant`. **Solution:** Instead, use the user group `group_account_user` directly so the test works with only `account` installed.