Friday, October 10, 2025
24 changes · saas-18.4
Resolved issues and error corrections
The time off request summary card has been adjusted so leave measured in hours displays clearly without overly long text. This improves readability for employees and managers reviewing time off requests.
Original PR description
On a time off request, there is a summary on the side. Problem: if we have time off in hours, the display is not adapted and the text is too long. This commit fixes the issue to display the hours correctly. task-5092855 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#227631
This fixes how tables copied into the HTML editor are handled so they automatically receive the standard Odoo table styling. Users get more consistent, properly bordered tables after pasting content, reducing manual formatting work.
Original PR description
### Purpose of this PR: - Ensure that pasted table elements get the standard classes: `table, table-bordered, and o_table.` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230517 Forward-Port-Of: odoo/odoo#230208
The Attendance app now correctly groups records by department after correcting a typo. This helps users get accurate department-based attendance views and reports without workarounds.
Original PR description
- Fixed typo in groupby for 'department' task-id - 5109185 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228334
Creating a goal from an employee appraisal now assigns the goal to the employee being appraised, rather than the current user. Creating a goal directly from the Goals menu no longer pre-fills employee or manager fields, reducing incorrect goal assignments.
Original PR description
If you go on _appraisals -> any employee -> goals smart button -> new_, it will populate the employee field with the current user. Instead, the field should be filled by the appraisal's user. If the goal is created from the "Goals" menu item directly, then no user / manager should be put by default in the goal's fields. I changed the field's default value to use the employee already passed in the context. I also added some tests to make sure the bug doesn't happen again. task-5048292 Forward-Port-Of: odoo/enterprise#93522
This fix prevents Odoo from recreating the default employee administrator record during updates when companies have already replaced it with their own setup. This helps avoid unwanted sample-like employee records reappearing in HR data after upgrades.
Original PR description
The `employee_admin` is a default admin option. Later when clients set up their work flow they set up their own admin employee. This record is not present, and it doesn't make sense recreate it with every update. 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#230250 Forward-Port-Of: odoo/odoo#228117
This update corrects how table cells are selected in the HTML editor. A single cell is now selected only when all of its content is selected, preventing confusing or accidental selections while editing text in tables.
Original PR description
Current behavior before PR: - Create an m x n table. - Write some text in a cell. - Put cursor at the end of text. - Try to select cell by moving mouse rightwards. Notice that the cell is selected although the cell content is not fully selected. Desired behavior after PR: This PR backports commit [1] to ensure that single cell is selected only if the cell content is fully selected. [1]: https://github.com/odoo/odoo/commit/09d369e118f622f30149f46702f58c656a3cee04 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230133 Forward-Port-Of: odoo/odoo#230071
Videos added inside certain website layout blocks now expand to the full width available instead of appearing unexpectedly small. This improves the editing and viewing experience for website pages using Masonry or Quadrant-style sections.
Original PR description
To reproduce: ============= 1- In Website edit mode, drop the "Masonry" snippet. 2- Add a video in one of the text blocks. -> It will appear smaller than expected, with no way to make it larger Why: ==== The child iframe already had width: 100%, but it can only stretch to 100% of its parent container. If the parent container (.media_iframe_video) doesn't have an explicit width, it defaults to its minimum content size. This issue happens specifically in blocks where the columns are display: flex. As a result, the iframe ends up being too narrow despite having width: 100%. Solution: ========= By adding width: 100% to the container itself, it now fills the grid cell, and the iframe inside fills the container. opw-5104640 Forward-Port-Of: odoo/odoo#229001
Time off warning messages now appear in the right place with consistent spacing. This prevents the India-specific sandwich leave alert from appearing collapsed when creating a new time off request, making important guidance easier to notice.
Original PR description
Issue: The sandwich leave alert for l10n India was incorrectly shown folded when creating a new time off entry for Indian companies. Additionally, the leave_type_increases_duration alert lacked proper top margin, causing inconsistent spacing. Steps to Reproduce: - For the sandwich alert: When shown, it appears folded automatically when creating a new time off entry (only for Indian companies). - For leave_type_increases_duration: When displayed, it lacks top margin. Fixes: - Moved the sandwich leave alert to the header alongside other alerts for consistency. - Adapted margins for all alerts. Task ID: 5071899 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226229
This fix prevents the HTML editor from creating invalid page structure when users change the style of text inside certain inline elements displayed as blocks. It helps preserve the intended content layout and avoids unexpected browser rendering issues.
Original PR description
Before this commit we would insert a block inside of a phrasing content if it's displayed as a block and we change its font style. For example, if we tried to modify text inside of a `<small>` that has `display: block` style, it would insert a new block inside of it. Steps to see the issue: - Have an open editor with `<small>Text</small>` content, that has `display: block` style - Select "Text" and change the font style to paragraph => It will be `<small><p>Text</p></small>` which is not valid HTML, and it will be parsed by a browser as `<small></small><p>Text</p>`, which is not the expected behavior. task-5123274 Forward-Port-Of: odoo/odoo#229043
This fix restores Indian accounting localization updates that were missed during a previous forward-port. It corrects tax naming and chart of accounts data so businesses using the India localization see the intended accounting configuration.
Original PR description
During the following [fw-port](https://github.com/odoo/odoo/pull/229757/) and resolving conflicts few changes such as Renaming of taxes and change of CoA was missed out in this commit we resolve the issue and add the missing changes that were unintentially missout during fw-port --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230787
This fix prevents an error page when someone opens a course embed link that points to a course category instead of an individual lesson. Users are now redirected to the course homepage, keeping the learning experience stable and avoiding a confusing crash.
Original PR description
When users try to access a `slide ID` that is not included in `channel_slides_ids`, a traceback occurs. Steps to reproduce: --- - Install `website_slides` module - Go to the Website and click on the…
When users try to access a `slide ID` that is not included in `channel_slides_ids`, a traceback occurs. Steps to reproduce: --- - Install `website_slides` module - Go to the Website and click on the `Courses` menu. - Then go to `/slides/embed/<int:slide_id>` route. (http://localhost:8069/slides/embed/7) - The error will occur. Traceback: --- `ValueError: 7 is not in list` At [1], `slide_content_ids` contains the IDs of `channel content`. However, we are trying to access a slide from the `channel category` in URL. As a result, at [2], when attempting to find the index of the slide in `slide_content_ids`, an error occurs because the slide ID actually belongs to `slide_category_ids` and is not present in `slide_content_ids`. Solution: --- Added a special case for category slides — if the slide is a category, redirect to the channel homepage. [1]- https://github.com/odoo/odoo/blob/482bb19e103de9ddbe1b1942b94b33d3da38889b/addons/website_slides/controllers/main.py#L120 [2]- https://github.com/odoo/odoo/blob/482bb19e103de9ddbe1b1942b94b33d3da38889b/addons/website_slides/controllers/main.py#L121 sentry-6572999628 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225374
This fix makes an automated barcode workflow test wait for the right screen state before validating an operation. It reduces random test failures, helping keep inventory barcode updates more stable and predictable for future releases.
Original PR description
Sometime, the test `test_scrap_change_source_location` could fail randomly. The issue happens in last few steps of the tour. What we do is: - We edit a move line lot in the form view; - We save it; -…
Sometime, the test `test_scrap_change_source_location` could fail randomly. The issue happens in last few steps of the tour. What we do is: - We edit a move line lot in the form view; - We save it; - We validate the operation. The validation is done by a barcode scan (`OBTVALI`) but since [1](https://github.com/odoo-dev/enterprise/commit/b3a855a870d1861515abaff8683081a39f95558f), barcodes scanned when the user is somewhere else than in the barcode lines view are skipped. With a little bit of bad luck, the tour scans `OBTVALI` while the save from the form view is not finished yet and thus, the scanned barcode is ignored. To reproduce that, run the test `test_scrap_change_source_location` locally in debug mode and add a throttling (eg.: Fast 4G) before to run the tour. To solve the issue, finetune the `validateBarcodeOperation` default trigger, so the error won't happen in this tour and other similar contexts. Runbot build error: [232331](https://runbot.odoo.com/odoo/runbot.build.error/232331) Forward-Port-Of: odoo/enterprise#96542
The Documents app no longer shows an unused tooltip field on document tags, reducing confusion for users managing tag settings. The field remains safely in the system for compatibility but is marked as deprecated until it can be fully removed in a future version.
Original PR description
The 'tooltip' field was introduced on document tags categories, but after couple of refactors it ended up unused on document tag. As we cannot remove fields from the data model in stable, this commit removes tooltip from the view and marks it as deprecated in the code. opw-4567814 ## Stems from https://github.com/odoo/odoo/pull/210147 https://github.com/odoo/enterprise/pull/79496 # Merge plan - hide `tooltip` in stable - remove `tooltip` in master Forward-Port-Of: odoo/enterprise#86504
This fix prevents sales orders and invoices from crashing when they use a contact that has no name. Sale warning messages now handle unnamed partners safely, allowing users to continue creating documents without interruption.
Original PR description
When creating a Sale Order or Invoice for a partner without a name, a traceback occurs. Steps to reproduce the error: - Install ``sale_management`` with demo data - Enable ``Sale Warnings`` from…
When creating a Sale Order or Invoice for a partner without a name, a traceback occurs. Steps to reproduce the error: - Install ``sale_management`` with demo data - Enable ``Sale Warnings`` from settings - Open ``Azure Interior`` Contact > In Contact, Add Contact > Type: invoice > Save & close - Create a sale order with the newly created partner AND - Create an invoice with the newly created partner Traceback: ``TypeError: unsupported operand type(s) for +: 'bool' and 'str'`` https://github.com/odoo/odoo/blob/7a1b27e5985b3b16768bea450c51226ae3659c76/addons/sale/models/sale_order.py#L822 https://github.com/odoo/odoo/blob/7a1b27e5985b3b16768bea450c51226ae3659c76/addons/sale/models/account_move.py#L59 Here, ``partner_id.name`` is ``False``, which leads to string concatenation with a boolean in sale warning messages and results in the above traceback. sentry-6912482256 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229529
This fixes an editor issue where pasted plain text could lose an active style, such as bold, when inserted into an empty formatted area. Users can now rely on selected formatting being preserved while writing descriptions or other rich text content.
Original PR description
Problem: When text is inserted inside an empty format, the format is lost. Cause: After https://github.com/odoo/odoo/commit/ae33ca3d38d4a5adaad3015f036321d473713638, any empty format gets removed if content is inserted inside. Solution: Only remove the empty format if a media element is added. This preserves styling when inserting plain text inside an empty format. Steps to reproduce: 1. Copy some text from somewhere. 2. In an empty task description, press CTRL+B. 3. Press CTRL+SHIFT+V. 4. Notice that the text is not bold, even though the format was active. task-5136314 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230051
A problem in the Expenses app could cause an error message to be incorrectly defined, potentially preventing users from seeing the intended guidance. This fix ensures the message is raised properly so users get clearer feedback when an expense action cannot be completed.
Original PR description
in 953fac5, the new error was not given the proper arguments Forward-Port-Of: odoo/odoo#229488
An unstable automated test for the online shop was removed from version 18 releases because it was causing random failures in the validation system. This does not change customer-facing behavior, but it helps make release checks more reliable.
Original PR description
Versions -------- - 18.0 - saas-18.2 - saas-18.3 - saas-18.4 Issue ----- The `test_toggle_contact_us_button_visibility` causes random errors in runbot. Cause ----- Unsure, but with commit 26d22fc975e3f removing jQuery from `VariantMixin`, the random error no longer seems to pop up. Solution -------- Remove the test for versions before 19.0. runbot-145473 Forward-Port-Of: odoo/odoo#230728
Restaurant point-of-sale bill splitting now closes correctly once the last split item has been paid. This prevents staff from being left on a zero-balance split screen, reducing confusion and keeping checkout flow smooth.
Original PR description
When splitting a bill, a specific flow would leave the bill splitting screen open event when everything was paid. Steps to reproduce: ------------------- * In pos restaurant add 2 product to the order * Select Action > Split * Select a product * Click Pay(ment) and validate the payment * Continue * Select the last product * Click Pay(ment) and validate the payment * Continue > Observation: The Bill splitting screen is still open at 0$ Why the fix: ------------ When one or more products are selected a new order is created with those products. If the quantities match, it's the last payement for that bill, we can directly pay. The original order will then be closed. opw-5006042 Forward-Port-Of: odoo/odoo#230536 Forward-Port-Of: odoo/odoo#228991
Demo chat messages from Alex now display Alex as the sender instead of Odoobot. This makes the sample Discuss data clearer and avoids confusion when evaluating or demonstrating chat conversations.
Original PR description
Before this commit, Alex's messages in discuss demo data were displayed as "Odoobot" rather than Alex. This happens because message had proper author_guest_id but no author_id defined, thus it had default value Odoobot and since [1] the author_id has precedence over `author_guest_id`. Before [1] there was no bug because the server returned formatted data of a single author as a persona, and guest_author_id had precedence over author_id. [1]: https://github.com/odoo/odoo/pull/211868 Before <img width="811" height="279" alt="Screenshot 2025-10-10 at 16 18 53" src="https://github.com/user-attachments/assets/862cfd18-24a0-485f-89b6-77277b9098ad" /> After <img width="815" height="280" alt="Screenshot 2025-10-10 at 16 17 45" src="https://github.com/user-attachments/assets/f83b98dd-ffb1-4419-851c-f34f3261792d" />
This update adjusts an internal mail test related to link previews so it is formatted more reliably. It helps maintain product quality by making automated checks easier to understand and less prone to false failures, with no direct change for end users.
Original PR description
Forward-Port-Of: odoo/odoo#230833
This change prevents pricelist rules based on another pricelist from being saved unless the referenced pricelist is provided. This avoids incorrect price calculations when rules are created outside the standard user interface, such as through custom screens or integrations.
Original PR description
Before this commit, only a view-level required attribute ensured that pricelist items with `base=='pricelist'` have a `base_pricelist_id` set. Creating pricelist items from a custom view or the API or the shell could result in missing values for this field, causing `_compute_base_price` to incorrectly assume that `base=='list_price'`` This commit introduces a new constraint ensuring any pricelist whose price is `base`d on an "Other Pricelist" has a value for `base_pricelist_id`. Note: in the views, `base_pricelist_id` is required if `compute_price == 'formula' and base == 'pricelist'` but the first condition is not neeeded because `_onchange_compute_price` sets `base` to `'list_price'` when `compute_price!='formula'` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230438
Links added to Social Marketing posts are now recognized correctly when their parameters include commas or similar special characters. This prevents previews from cutting the link too early, helping users share accurate URLs in social posts.
Original PR description
**Steps to reproduce:** - Go to `Social Marketing` app. - Click on `New Post`. - Select Facebook for preview (should not matter). - Write a message with an URL which have comma-separated parameters. (e.g 'TEST URL https://example.be:8080/path/res-123/ext/?param1=v1,v2,v3') - URL is cut on the first comma in the preview. **Issue:** URL regex did not match URLs containing comma-separated query parameters, causing them to be truncated. **Fix:** Updated the regex to include commas. opw-5042131 Forward-Port-Of: odoo/enterprise#94220
This fixes demo chat data so messages from Alex are displayed as coming from Alex instead of Odoobot. It improves the accuracy of demo conversations and avoids confusion when users review or present the Discuss app.
Original PR description
Before this commit, Alex's messages in discuss demo data were displayed as "Odoobot" rather than Alex. This happens because message had proper author_guest_id but no author_id defined, thus it had default value Odoobot and since [1] the author_id has precedence over `author_guest_id`. Before [1] there was no bug because the server returned formatted data of a single author as a persona, and guest_author_id had precedence over author_id. [1]: https://github.com/odoo/odoo/pull/211868 Before <img width="811" height="279" alt="Screenshot 2025-10-10 at 16 18 53" src="https://github.com/user-attachments/assets/862cfd18-24a0-485f-89b6-77277b9098ad" /> After <img width="815" height="280" alt="Screenshot 2025-10-10 at 16 17 45" src="https://github.com/user-attachments/assets/f83b98dd-ffb1-4419-851c-f34f3261792d" />
Cashiers can now enter numeric passwords using a physical keyboard when the password popup is open. This fixes a point of sale usability issue where staff had to rely only on the on-screen number buttons, making login and cashier switching faster and more convenient.
Original PR description
Before this commit, when the NumberPopup was open (for example, when entering the cashier password), the keyboard input was ignored because the overlay manager blocked all keyboard events while any popup was active. As a result, it was only possible to use the on-screen number buttons. After this commit, the keyboard input is allowed when a NumberPopup is open, enabling users to type the password directly using the keyboard. opw-5152235 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230626