Thursday, April 16, 2026
18 changes · saas-19.1
Resolved issues and error corrections
This update corrects a flaw in how Odoo calculates the available capacity for appointments booked through Google Reserve. Previously, the system reserved the entire party size, leading to potential overbooking. The fix ensures accurate capacity allocation, preventing scheduling conflicts and improving the booking experience for users.
Original PR description
The current logic inside the appointment google reserve controller to compute reserved and used capacity per resource was incorrect. It was reserving the full party size for each resource instead of properly computing how much spots we are reserving for each. The code was fixed and a test was adapted for proper coverage. Task-6120016 Forward-Port-Of: odoo/enterprise#113908 Forward-Port-Of: odoo/enterprise#113805
This update ensures that transaction dates pulled from iap are always within the correct 'lock date' range. Previously, transactions could be retrieved with dates before the lock date, which was an error. Now, the system uses the maximum of the lock date and the last statement date to guarantee accurate data retrieval.
Original PR description
To fetch transactions from iap, we have to give a date from. Before this commit, it was possible to have a date from prior the lock date which is not supposed to happen. This commit will do the max between the lock date the last date of either the statement or the statement line. task-6019584 Forward-Port-Of: odoo/enterprise#110010
This update corrects a visual issue where clickable scorecards in the spreadsheet module were displaying a default arrow cursor instead of a pointer on hover. Now, scorecards that function as buttons in the dashboard view correctly show a pointer cursor when hovered over, improving user experience and clarity. This resolves a minor usability problem.
Original PR description
## Description of the issue/feature this PR addresses: Current behavior before PR: - The scorecard case was missed when replacing hasOdooMenu with hasOdooLink. - Clickable scorecards were showing the default arrow cursor instead of a pointer on hover. Desired behavior after PR is merged: - Scorecards now correctly use hasOdooLink to determine if they are clickable. - The pointer cursor is displayed on hover when the scorecard acts as a button in dashboard view. Task: [6116584](https://www.odoo.com/odoo/2328/tasks/6116584) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug where the state of a date field in forms was incorrectly being reset after saving. Specifically, closing the date picker would sometimes revert the date back to an older value. This issue has been fixed to ensure accurate date tracking and prevent data inconsistencies.
Original PR description
Step to reproduce: - Go on view form with a date field - Set the date with the input by typing the date with day and month (mm/dd or dd/mm), then press enter - Save the record - Redo the second step by with a different date - Save the record The assignation of the state.value done when closing the datepicker is useless and can put old a value in the state. The datepicker hasn't finished to update of the record that the assignation put back the old value of the record back in the state. The reason why it happens only after a save is still unknown. task-6095467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258111
This update fixes an issue where Arabic text on invoices was incorrectly formatted in the generated PDF. The change ensures parentheses surrounding Arabic characters are positioned correctly, improving readability for invoices in English. This resolves a display problem for international invoices.
Original PR description
**Problem:** When printing an invoice in English (LTR report) with a product whose name contains Arabic text and parentheses (e.g., لوحة توزيع كهربائية 100 أمبير (شنايدر )), the brackets appear in…
**Problem:** When printing an invoice in English (LTR report) with a product whose name contains Arabic text and parentheses (e.g., لوحة توزيع كهربائية 100 أمبير (شنايدر )), the brackets appear in the wrong position in the generated PDF. **Steps to reproduce:** 1. Create a product named: لوحة توزيع كهربائية 100 أمبير (شنايدر ) 2. Create an invoice with that product 3. Print the invoice PDF in English 4. Observe the brackets are misplaced in the description column **Current behavior:** Parentheses appear detached from the Arabic word they enclose, floating at the wrong end of the text. **Expected behavior:** Parentheses correctly wrap the enclosed Arabic text. **Cause of the issue:** Odoo's report CSS sets `direction: ltr` on elements that are ancestors of the line description span. When CSS `direction: ltr` targets the same element as `dir="auto"`, wkhtmltopdf's WebKit engine lets the CSS rule win, keeping the paragraph base direction as LTR. The Unicode BiDi algorithm then resolves parentheses (neutral characters) using LTR as the base direction, misplacing them. **Fix:** Placing `dir="auto"` directly on the `<span>` that renders the line description — rather than the parent `<td>` — avoids the CSS override. wkhtmltopdf then detects the first strong character (Arabic) and uses RTL as the base direction for that span, allowing the BiDi algorithm to correctly position the brackets. opw-5884712 Forward-Port-Of: odoo/odoo#258521 Forward-Port-Of: odoo/odoo#251190
This update resolves an issue where published course cards with buttons in their descriptions were displaying a grey overlay. The fix accurately targets only unpublished courses, ensuring a consistent and correct visual presentation of all course cards on the website. This improves the user experience and visual consistency.
Original PR description
Steps to reproduce: ================= 1. Go to eLearning > Courses and create a published course 2. In the Description tab, add a button with a link and save 3. Go to /slides on the website 4. The…
Steps to reproduce: ================= 1. Go to eLearning > Courses and create a published course 2. In the Description tab, add a button with a link and save 3. Go to /slides on the website 4. The course card appears with a grey overlay (0.5 opacity) => Published course cards with a button in the description show a grey overlay => Only unpublished course cards should have the grey overlay Cause: ====== In [1], the opacity for unpublished courses was moved from `.o_wslides_course_unpublished` to its container using a `:has()` selector. However, the selector `div:has(> .card + .card-body, ...)` was too broad: it matched any container whose `.card` child had a sibling `.card-body`, regardless of whether the course was unpublished. When a course description contains a button (or any block-level element), the browser renders the button outside the `.card` element. This creates the structure `div > .card + .card-body` that the selector matches, applying a 0.5 opacity grey overlay to fully published courses. Solution: ======== The fix restricts the first selector arm to only match when `.o_wslides_course_unpublished` is the sibling, ensuring published courses with buttons in their descriptions are not affected. [1]: https://github.com/odoo/odoo/pull/249969 opw-5900287 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258700
This update resolves an issue where double-clicking on a message action menu in Odoo kept displaying the same menu. Now, a second right-click on the message will trigger the browser's standard context menu, providing users with more flexibility and control over actions. This improves usability and caters to user workflows.
Original PR description
Before this commit, when message actions are displayed from right-click, triggering a right-click on the message again would keep displaying the message actions. Right-click on message to show the actions is useful in many cases, but sometimes the user wants to trigger the browser context menu. Currently browser context menu is shown on links and when there are some text selection, but there might be some other potential cases where seeing the browser context menu is desirable. In practice users could trigger it through SHIFT + right-click but they are not necessarily aware of it. This commit let double right-click on same message open the browser context menu, so that if users really want to have the browser context menu then doing it twice will show it. Before  After 
This update ensures the Peppol sending option in the account system is only available for companies that are actually registered on the Peppol network. Previously, it automatically enabled this option, which was misleading and inaccurate. This change improves data accuracy and ensures compliance.
Original PR description
Previously, the send wizard would automatically enable the send "by Peppol" option whenever Peppol was available for the company's country. This behavior was misleading, as it didn't check whether the company was actually registered on Peppol. This commit ensures the option is only enabled for companies that are registered on Peppol. task-6044073 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258731 Forward-Port-Of: odoo/odoo#254671
This update fixes an issue where users couldn't sort sale orders by delivery date. A recent change made the delivery date field un-sortable. This change adds the 'promised delivery' date back to the list view, allowing users to sort sale orders by delivery date as before.
Original PR description
Version: --- 19.1+ Issue: --- it's not possible to sort sale order list using `delivery date` anymore. After 30b895e3bd93ab3f0c0a86c3fcfd0fc0c3b6fb89, a `delivery_field` field is introduced, and `commitment_date`'s string is renamed to `promised delivery`. The new `delivery_date` is a compute field, hence it isn't sortable. The propostion here is to add `commitment_date` to the list view, in case users want to sort the list using `Promised delivery date`. opw-6112037
This update fixes an issue where web pages could incorrectly access data due to cached records. Specifically, when users edit relationships between records, the system now ensures that only accessible data is used, preventing errors and improving data reliability. This enhances the overall stability and accuracy of the Odoo platform.
Original PR description
**Description of the issue/feature this PR addresses**: web_read on x2many fields can reuse cached ids after write/web_save. Some of these cached ids may be inaccessible with the current record…
**Description of the issue/feature this PR addresses**:
web_read on x2many fields can reuse cached ids after write/web_save. Some of these cached ids may be inaccessible with the current record rules/context (cache pollution).
**Example**:
- **Context**:
- Two companies exist: Company A and Company B.
- Two users exist: User A and User B.
- User A can only access Company A (company_ids=[A], company_id=A).
- User B is linked to both companies (company_ids=[A, B], company_id=A).
- The "res.company" record rule is the standard one: [('id', 'in', company_ids)] (company_ids comes from allowed_company_ids).
- User A edits User B and saves the form.
- **Steps**:
- User A performs a web_read to load User B: company_ids contains only Company A.
- User A performs web_save (write + internal web_read in the same request): cached ids [A, B] are reused and the code attempts to read Company B.
**Current behavior before PR (without fix)**:
After saving a form with an x2many field, web_save calls write and then web_read. In this flow, web_read can include inaccessible x2many ids from cache and raise an AccessError.
**Desired behavior after PR is merged**:
x2many records are re-filtered with current read rules before formatting, and inaccessible ids are removed from values_list.
Forward-Port-Of: odoo/odoo#257517
Forward-Port-Of: odoo/odoo#250904This update fixes a minor issue where images on the website weren't loading correctly when accessed from deeper pages within the application. The fix adds missing forward slashes to image source URLs, ensuring the browser correctly interprets the image locations. This improves the overall user experience and ensures all website content displays properly.
Original PR description
This commit fixes two missing leading slashes in the "src" attribute of two "img" tags in `s_cta_mockups`. The browser resolves links differently based on leading slashes. Before this commit, the lack of leading slahses caused the snippet to not display properly on deeper pages (for example, "/shop/product-name"). task-6103616 Forward-Port-Of: odoo/odoo#259138 Forward-Port-Of: odoo/odoo#258879
This update resolves a technical issue that caused payroll processing to crash when employee bank account information was incomplete. The change safely handles missing data, ensuring payroll calculations continue without errors and preventing invalid data from being sent to tax authorities.
Original PR description
Accessing the employee bank accounts using index [0] raised an IndexError when no accounts were defined. Additionally, computing the CLABE flag using len() caused a TypeError when the account number was missing. This change uses a safe recordset slice to avoid accessing empty records and guards the length check to only evaluate when a value is present. It prevents crashes while keeping the original behavior unchanged and avoids sending invalid empty values in the CFDI. Forward-Port-Of: odoo/enterprise#113987
This update fixes a discrepancy in the 'To Pay' dashboard by including receipts in the calculations. Previously, the dashboard only considered invoices and refunds, leading to an inaccurate count and amount. Now, the dashboard metrics align with the records visible when viewing receipts, ensuring a more reliable view of outstanding payments.
Original PR description
- The "To Pay" section in the purchase/sales dashboard was only considering invoices(`in_invoice` and out_invoice) and refunds(`in_refund` and `out_refund`) when computing the number and amounts to pay. - However, the corresponding action view includes receipts (`in_receipt` and `out_receipt`), leading to an inconsistency where the dashboard count and amount did not match the records shown after clicking. - This commit updates the dashboard query to also include receipts, ensuring consistency between the displayed metrics of the coreesponding purchase/sales dashboard and the action view. Related PR: https://github.com/odoo/enterprise/pull/111142 taskID-6040828 Forward-Port-Of: odoo/odoo#259245 Forward-Port-Of: odoo/odoo#254295
This update resolves an issue that prevented users from assigning recruiters to job positions when the HR payroll module wasn't active. The fix ensures the system correctly identifies the company context, allowing for proper recruiter assignment functionality. This improves the user experience and prevents a frustrating error.
Original PR description
**Steps to Reproduce:** 1. Ensure hr_payroll module is NOT installed 2. Open a Job Position in hr_recruitment app 3. Click on "Assign Recruiter" button for a position without a recruiter 4. Observe error: "Name 'company_id' is not defined" **Bug Cause:** The interviewer_ids field used a string-based domain that referenced 'company_id' as a variable which is evaluation in client-side lacking access to Python record context, causing it to fail when hr_payroll module is not installed. **Solution:** Replace the string domain with a lambda function that evaluates server-side, providing access to self.company_id context. **Task:** 6106143 --- 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 font size in the toolbar didn't correctly reflect the font size of sub-items within nested lists. The fix ensures that the default font size is consistently displayed, regardless of the parent list item's custom font size setting. This improves the user experience when working with complex lists.
Original PR description
Problem: When using nested lists where a parent list item has a custom font size, the child list does not display the default font size in the toolbar. Cause: `getFontSizeDisplayValue` does not treat `.o_default_font_size` as a boundary element. It continues searching up the DOM and may retrieve a font size from a parent element outside the intended default font size scope. Solution: Stop the font-size lookup when reaching `.o_default_font_size`, since this class defines the default font size boundary. Steps to reproduce: - Go to a "To do" note. - Insert a bullet list with sub-items. - Select the top list item and set its font size to 72. - Select a sub-item. - Observe the toolbar does not show the default font size. task-6105581 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258027
This update resolves a visual glitch on the Odoo shop page where product images would overlap with popup content when popups were positioned with 'sticky' styling. The fix prevents popups from being placed within elements with 'sticky' positioning, ensuring proper popup display and a consistent user experience.
Original PR description
If an popup is dropped within an element with the property "position" set to "sticky", there would visual issues with the modal. For example, if the user drop a popup below the filters in the /shop page, the images of the product would appear over the popup content when the popup is opened. Since there shouldn't be cases where "position" is setted to sticky without having the specific class, this commit fixes the issue by adding the selector ".position-sticky" as a forbidden ancestor for popups. task-5411329 Forward-Port-Of: odoo/odoo#240545
This update prevents issues caused by updating tax groups when associated accounts are modified. Specifically, it avoids constraint errors related to account types, ensuring smoother operation during chart updates. This improves the stability and reliability of tax group management.
Original PR description
Upon chart reload, accounts will not be updated (except for tax_ids), but tax groups are. If a tax group was changed to relate to a different account and this account was re-purposed (e.g.…
Upon chart reload, accounts will not be updated (except for tax_ids), but tax groups are. If a tax group was changed to relate to a different account and this account was re-purposed (e.g. account_type changed from an incompatible to a compatible type, the fact that the account is not updated will trigger constraints in the tax group when it is written. IOW, if the purpose of an account is not changed, its use should not be changed either. E.g.: 1f4710deb206736cd71580d8fd95552d9b7c8014 changed the value of `tax_payable_account_id` on tax group `tax_group_cofins_incl_goods` to `account_template_202011005` and the same commit changed the value of `account_type` on `account_template_202011005` from `liability_non_current` to `liability_payable`, triggering `_constrains_payable_receivable_account` (in 19.2: https://github.com/odoo/odoo/blob/e00dd21880c3c4e5c22d65567c700e02541f7259/addons/account/models/account_tax.py#L68). So here, we skip the update of relations to accounts on tax groups, if the account already exists. Forward-Port-Of: odoo/odoo#259160
This update resolves a technical issue that prevented demo flows from working correctly after the addition of Peppol and Nemhandel response data. The fix ensures demo mode functions as expected, providing a reliable demonstration of the new features. This improves the quality and usability of our demo environment.
Original PR description
With the recent addition of responses in Peppol and Nemhandel, we forgot to adapt the mocking data for demo flows, which resulted in tracebacks in demo mode. Forward-Port-Of: odoo/odoo#258655