Monday, August 24, 2026
24 changes · saas-19.4
Enhancements to existing features
Administrators can now see and adjust whether each time off type creates a Calendar entry when employees submit leave requests. This makes the existing option easier to manage and helps companies control how absences appear in shared calendars.
Original PR description
The `create_calendar_meeting` field on `hr.leave.type` allows users to choose if leave requests created with a given time off type generate a corresponding entry in the Calendar app. However, this field was not displayed on the form view. This commit adds `create_calendar_meeting` to the `hr.leave.type` form view inside the configuration section, along with dedicated help text explaining its behavior. Task: 6445794 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283450
The website configurator now clearly names the color palette selected by the AI recommendation. This helps users understand the suggested branding choice and why it fits their business context.
Original PR description
Steps to reproduce: - Start website creation with the configurator. - Reach the color palette selection step. => The AI recommendation does not name the selected palette. Before this commit, the recommendation described suitable colors without identifying the corresponding palette. After this commit, the recommendation names the selected palette and explains why it fits the business context. task-6484260
This update adds automated checks to catch outdated code patterns that could silently break parts of the interface after a framework upgrade. It also updates the mail chatter composer to use the current pattern, reducing the risk of users encountering unexpected behavior.
Original PR description
Owl 3's useEffect takes a single callback and calls it with no arguments, but Owl 2 code still parses and runs. `useEffect(fn, () => [deps])` silently drops the dependencies, and `useEffect((el) => ...)` gets undefined parameters - nothing fails until a user walks the path. Add two no-restricted-syntax selectors so eslint catches both on the lint build. They are wrong by construction, so no exceptions are needed, and the useLayoutEffect shim keeps its two arguments under a different callee name. The rules go in test_lint/tests/eslintrc and, for point_of_sale, iot and obox, in web/tooling/_eslintrc.json. The chatter composer patch is the last community call site of that shape. Its body already reads both recipient lists, so dropping the dependency argument is enough; it matches master, so the forward-port is a no-op. Enterprise: https://github.com/odoo/enterprise/pull/128751
Stock quantity updates now avoid repeating the same warehouse lookup when processing several products at once. This reduces unnecessary database work during batch operations and can make inventory updates run more efficiently.
Original PR description
When `_inverse_qty_available` processes multiple products, it performs the same warehouse search for every eligible product, resulting in redundant queries during batch operations. Look up the warehouse lazily once and reuse it for all products in the recordset. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283564
Canceled point-of-sale orders using the Belgian black box no longer hold up the checkout flow while waiting for receipt printing. This helps staff move on faster when an order is canceled, reducing unnecessary delays at the register.
Original PR description
Stop awaiting the receipt print in the POS for canceled orders task-id: 6425204 Forward-Port-Of: odoo/enterprise#128593
Resolved issues and error corrections
The HTML editor now places the drag-and-drop move handle on the correct side when editing right-to-left content. This makes block editing more intuitive and consistent for users working in RTL languages.
Original PR description
Problem: In MoveNodePlugin, `setMovableElement` sets the position of the drag-and-drop handler without considering `this.config.direction === "rtl"`. The handler is placed on the left side regardless of text direction. Solution: - In RTL mode, calculate the handle position from the right edge of the element so it is placed on the right side with the same distance as in LTR. - Update hover hooks, editable bounds, and dropzone rectangles for RTL mode. Steps to reproduce: 1. Open the editor in RTL mode. 2. Hover over a movable block element (e.g. `<p>`). => The move handle appears on the left side of the element instead of the right. task-6442717 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283662 Forward-Port-Of: odoo/odoo#281249
Documentation and clarification updates
A contributor has submitted their Individual Contributor License Agreement for Odoo. This is a legal documentation update that helps ensure future contributions can be accepted under the project’s licensing requirements.
Original PR description
This pull request submits my Odoo Individual Contributor License Agreement signature. Forward-Port-Of: odoo/odoo#282045
This fix ensures Odoo correctly recognizes when the email queue process is running as a scheduled job, so progress tracking works as intended. It also adds clearer logging of the email sending limit to help support teams investigate silent email queue failures linked to memory limits.
Original PR description
The changes introduced by https://github.com/odoo/odoo/commit/19d5367862528979abdcd411095f18d36bdbe7b8 aimed at aligning the mailing cron job logic with the new `_commit_progress` system. While doing…
The changes introduced by https://github.com/odoo/odoo/commit/19d5367862528979abdcd411095f18d36bdbe7b8 aimed at aligning the mailing cron job logic with the new `_commit_progress` system.
While doing so, it accidentally added an if condition based on `self.env.get('ir_cron')`, which will always return False and never run the progress commit as intended.
To address this, in this PR:
- we change the condition to `if self.env.context.get('cron_id'):`, the cron_id context variable being set when the method was called from a scheduled action
- additionally we take the occassion to add an info log that outputs the computed send limit at the time the method was triggered. This will make it easier to investigate the logs ad-hoc in situations where the "Mail: Email Queue Manager" cron job fails silently because of a memory limit error. A high send limit (batch_size) increases the chances of memory errors proportionally. Knowing what the exact sending limit was at a given point in time makes investigation easier when trying to build a sequence of past events that could explain issues related to email sending.
OPW-6396087
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#283402
Forward-Port-Of: odoo/odoo#282892This update removes unused invoice customization code for Gulf localization. It reduces maintenance complexity while keeping existing invoice behavior handled by the standard system.
Original PR description
Remove create() and _compute_narration() method overrides from l10n_gcc_invoice as they only existed to call _load_narration_translation(), which has already been disabled. The parent class implementations handle all required functionality. Keeps the codebase clean by removing unnecessary method overrides. Forward-Port-Of: odoo/odoo#281565 Forward-Port-Of: odoo/odoo#281395
Fixed an issue where planning shifts without a linked sales order line could cause an error when determining the customer. This makes shift handling more reliable and prevents interruptions for users working with sales planning.
Original PR description
Before this commit, when the shift has no SOL set, the `_compute_partner_id` crashes because the value for partner_id field is not set for that shift. This commit fixes the compute method of partner_id to make sure the value is correctly set for all shifts. Forward-Port-Of: odoo/enterprise#128965
The mail compose process now uses the current progress-tracking method instead of an outdated one. This prevents unnecessary warning tracebacks in server logs during automated mail processing, helping keep operations monitoring cleaner without changing user-facing behavior.
Original PR description
Since 19.0 `_notify_progress`` is deprecated in favor of `_commit_progress``. See: https://github.com/odoo/odoo/commit/ee337934f9885834d95592946f435c6e1c8ef970 Currently, the mail compose wizard still calls an explicit _notify_progress followed by an explicit commit. This leads to warning tracebacks being dumped into the server logs (for example everytime the "Mail Marketing: Process queue" cron runs). We replace it with an equivalent `_commit_progress` call, which should log the progress and implicitly take care of the cursor commit. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282926
This fix prevents highlighted text from losing its background color when users turn paragraphs into lists or convert list items back to regular text. It also ensures clearing formatting removes background colors from list items as expected, making document editing more consistent.
Original PR description
Problem: Background color was lost both when converting text with a background color into a list item and when converting a list item with a background color back into a paragraph. Cause: - `insertListAfter` only copied `color` from the font wrapper to `li.style.color`, ignoring `background-color`. - Unwrapping a list item (`ListPlugin`) extracted `color`, `font-size`, and `text-align`, but ignored `backgroundColor`. Solution: - Preserve `background-color` from font wrapper onto `li.style.backgroundColor` when creating a list. - Restore `li.style.backgroundColor` onto a `<font>` wrapper when unwrapping a list item. Steps to reproduce: - Apply background color to a paragraph and toggle list -> background color is lost. - Apply background color to a list item and toggle list off -> background color is lost. opw-6481665 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283158
This fixes an issue where temporary wizard screens could incorrectly appear as selectable records for marketing campaign references. The change keeps those reference lists cleaner and prevents users from choosing items that should not be used there.
Original PR description
Various places mistakenly used `model.is_transient()` to filter the transient models, where the model is `ir.model` record itself, which always returns False since `ir.model` is a regular persistent model. As a result, transient models (wizards) were never filtered out and allowed into the `utm_reference` Reference field selection. This commit fixes it by using `self.env[model.model].is_transient()` to call `is_transient` on the actual model. Task-6458883 Forward-Port-Of: odoo/odoo#283599 Forward-Port-Of: odoo/odoo#282711
Closing the product configurator in Point of Sale no longer leaves optional products visible for an item that was not added. This prevents cashiers from seeing or selecting add-ons tied to a discarded product, reducing confusion during checkout.
Original PR description
When discarding the product configurator, we still showed the optional product. We no longer do that as no one wants to add optional products to a not-added product. task-6442422 Forward-Port-Of: odoo/odoo#283378 Forward-Port-Of: odoo/odoo#282916
The web search now ignores a default filter when its linked record no longer exists, instead of blocking the page with an error. This improves reliability for users opening saved actions or menus that reference outdated records.
Original PR description
…'t exist Have a search view with a m2o field Have an action that sets search_default_m2o: [/BAD ID/] Before this commit there was a crash After this commit, we simply ignore the filter. task-6469841 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 Forward-Port-Of: odoo/odoo#282738
This fixes an issue where pressing Shift+Enter in Safari created a new paragraph instead of a soft line break in the HTML editor. Users editing Knowledge articles on Mac Safari can now format text consistently with other browsers.
Original PR description
**Steps to reproduce:** - Use a Mac with Safari - Install Knowledge app - Go to any article - Press Shift+Enter to try to enter a soft line break - Hard split is done instead **Issue:** Shift+Enter causes a `insertParagraph` event instead of `insertLineBreak` in Safari, which triggers the `SplitPlugin` instead of the `LineBreakPlugin`. **Fix:** Check if the browser is Safari and call `insertLineBreak` from the `SplitPlugin` (when needed) by listening to the "keydown" events. (note: I was not able to find any other key combination to properly trigger the `insertLineBreak` event in Safari) opw-6413507 Forward-Port-Of: odoo/odoo#281458
Argentine delivery operations using class X document types no longer require CAI authorization code and expiration date fields. This aligns the workflow with government rules, which only require those details for class R delivery notes, reducing unnecessary blocking errors for users.
Original PR description
Currently, when the user attempts to create a delivery operation for a class X document type, the system prompts the user to provide values for the CAI and CAI Expiration Date fields. ## Steps to…
Currently, when the user attempts to create a delivery operation for a class X document type, the system prompts the user to provide values for the CAI and CAI Expiration Date fields. ## Steps to produce: - Install `l10n_ar_stock` with demo data - Switch Company to `(AR) Exento` - Create a warehouse - Configuration > Operation Types > Delivery Orders - Set Document Type to `'(94) MAILING X' `and try to save ## Observed Behavior: The fields 'CAI' and 'CAI Expiration Date', which represent the authorization code and expiration date issued by the government, are currently configured as required fields. **Expected Behavior:** As specified on the [government site](https://www.argentina.gob.ar/normativa/nacional/resoluci%C3%B3n-1415-2003-81316/actualizacion#:~:text=Los%20datos%20indicados%20en%20el%20inciso%20a%29%2C%20puntos%207%2C%2010%2C%2011%2C%2012%20y%2013%2C%20s%C3%B3lo%20ser%C3%A1n%20para%20los%20remitos%20clase%20%27R%27%2E): > > 12. Printing authorization code, preceded by the acronym 'CAI No. ...'. > 13. Expiration date of the receipt, preceded by the legend 'Expiration Date ...' > > 'The data indicated in section a), points 7, 10, 11, 12 and 13, will only be for 'R' class delivery notes.' These statements indicate that the information mentioned in points 12 and 13, including the **CAI** and **CAI Expiration Date** fields, is applicable only to **'R'** class delivery notes. Therefore, for class X delivery notes, these fields should be optional rather than required. ## Root Cause: According to [1], the field is configured as a required field when a Document Type ID is selected. This configuration causes the **CAI** and **CAI Expiration Date** fields to become mandatory, regardless of the document type requirements defined by the government specification. [1]- https://github.com/odoo/odoo/blob/62b05c4ea61942072b6b1fb420fe3efedb11ed14/addons/l10n_ar_stock/views/stock_picking_type_views.xml#L11-L16 ## Solution: Apply constraints that align with the government specifications, allowing the CAI and CAI Expiration Date fields to remain optional for document types where they are not required. opw-6359503 Forward-Port-Of: odoo/odoo#283288 Forward-Port-Of: odoo/odoo#275533
Fixes an issue in the HTML editor where selected link text using a gradient style could become invisible. Users can now clearly see and edit selected gradient-styled links, reducing confusion while creating or updating website content.
Original PR description
Problem: When text formatted with `.text-gradient` is inside a link with `.o_link_in_selection`, the selected text becomes invisible. `.text-gradient` sets `-webkit-text-fill-color: transparent`, which prevents `color: black !important` on `.o_link_in_selection` from taking effect. Cause: `-webkit-text-fill-color: transparent` from `.text-gradient` overrides standard text `color` rendering, causing the text to stay transparent against the selection highlight background. Solution: Set `-webkit-text-fill-color: black` on `.o_link_in_selection` to ensure text inside gradient links is rendered in black and remains clearly visible when selected. Steps to reproduce: - Add text "ABCD". - Apply gradient color to all text. - Create a link on "BC". - Place cursor/selection inside the new link. - Observe that the text is not visible. opw-6479350 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282952
This fixes a point of sale issue where the order details popup stayed on screen after choosing to edit a payment. Cashiers are now taken cleanly to the payment screen without an overlapping popup, reducing confusion during order corrections.
Original PR description
Steps to reproduce: ----------- - Validate an order, then open it from the ticket screen - Open the order details popup, click "Edit Payment" - Redirected to PaymentScreen, but the order details popup stays open on top of it Cause: --------- OrderDetailsDialog (opened via the dialog service) and PaymentScreen (opened via pos.navigate) are two separate stacks. Navigating to PaymentScreen does not close the dialog. Fix: -------------- Call dialog.closeAll() before pos.editPayment(order) in the editPayment callback passed to OrderDetailsDialog, so the dialog closes before navigating to PaymentScreen. task-6463084 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#281960
The quick create fields in the bank reconciliation workflow were not displaying correctly after a recent interface framework update. This fix restores the expected full-width layout, making the form easier to use and reducing visual confusion for accounting users.
Original PR description
There was a change in the css since owl3, the quick create was impacted. By adding w-100 to the two fields, the problem is solved. no task id
Documents created by splitting a multi-page PDF now appear in a predictable order instead of being randomly arranged. This makes it easier for users to review and manage split pages in the Documents kanban view.
Original PR description
steps: - upload a multi-page pdf - split all the pages -> they now show in a random order The issue is that the current documents are sorted by create_date desc, but the split creates all the different documents at the same time so they are sorted in the order they happen to be on the disk. We now add a sort by id to act as a tie-breaker. opw-6176840 Forward-Port-Of: odoo/enterprise#128410 Forward-Port-Of: odoo/enterprise#117255
The LinkedIn social account refresh now handles cases where LinkedIn returns no statistics for an account. This prevents an unexpected crash and keeps social media data refreshes running reliably.
Original PR description
Bug === When the LinkedIn API returns no statistics for the account, the refresh crashes. Task-6425391 Forward-Port-Of: odoo/enterprise#126326
This fix prevents errors in Sales Planning reports when planning slots are grouped by customer. The system now uses the correct customer reference depending on the installed features, keeping reporting stable across configurations.
Original PR description
Before this commit, #122034 converted the related non-stored `partner_id` field in `planning.slot` into a compute non-stored field with a search method, the problem is that field was used as groupby inside a read_group which causes a traceback since the field is no longer reachable in SQL. This commit alters the groupby in problematic _read_group methods to use partner_id field when it is stored (when field service is installed) otherwise the groupby should be `sale_order_id.partner_id`. Forward-Port-Of: odoo/enterprise#128540
The pull request records that GitHub user kshitij-nariya has signed Odoo's Individual Contributor License Agreement. This administrative update helps ensure their future contributions can be reviewed and merged without CLA-related blockers.
Original PR description
Description of the issue/feature this PR addresses: Signed the Odoo Individual Contributor License Agreement to contribute to the Odoo repository. Current behaviour before PR: The CLA signature is missing for GitHub user `kshitij-nariya`, which will prevent future contributions from being accepted and merged. Desired behaviour after PR is merged: The CLA signature for `kshitij-nariya` is recorded in the repository, allowing future pull requests and contributions to be successfully merged. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282808