Daily updates from Odoo
Monday, November 10, 2025
128 changes
8 changes
Resolved issues and error corrections
Point of Sale now sends orders to the server one at a time instead of in large batches. This reduces the risk of timeouts and missing orders, especially when some orders take longer to process, such as those that need invoicing. Loyalty coupon confirmation was also adjusted so it happens correctly for each order during this process.
Original PR description
`syncAllOrders` method is now splitting the list of orders to synchronize them one by one. This allows to have better control over each order synchronization and error handling. Some customer were experiencing issues when synchronizing too many orders at once, leading to lost orders or orders not being synchronized properly. For example, synchronizing orders that needs to be invoiced takes too long and can lead to timeout issues. By synchronizing orders one by one, we ensure that each order is properly synchronized before moving to the next one. --- Modification in `pos_loyalty` module to adapt to this change: The `confirm_coupon_programs` method is now called for each order individually, instead of being called once for all orders in the `payment_screen`. This ensures that coupon programs are confirmed correctly for each order even when orders synchronization is delayed Forward-Port-Of: odoo/odoo#233870 Forward-Port-Of: odoo/odoo#232073
This fix ensures that when a delivery is split into two, the original delivery’s availability status is recalculated correctly. It prevents the system from showing outdated stock information, which helps users trust the quantities shown during warehouse operations.
Original PR description
Steps to reproduce: - Create a storable product “P1” - Update its quantity to 10 - Create a delivery picking with 10 units of P1 - Confirm → The picking is in “Ready” state and the move is “Available” - Update the “Quantity” of P1 to 6 units in the picking → The move state is recomputed to “Partially Available”, since the demanded quantity exceeds the quantity done. https://github.com/odoo/odoo/blob/18.0/addons/stock/models/stock_move.py#L2207-L2208 - Split the picking Problem: A new picking is created with 4 units in quantity and its move is “Available”, but the original move with 6 units does not have its state recomputed. opw-5173374 Forward-Port-Of: odoo/odoo#232516
This change fixes an issue where saving a default value could fail if duplicate default records already existed. The system now selects only one matching record, which avoids an error and lets the save complete normally.
Original PR description
There’s no constraint preventing duplicate `ir.default` records. When setting a default using `self.env['ir.default'].set()`, it searches for an existing one, but if more than one match is found,…
There’s no constraint preventing duplicate `ir.default` records. When setting a default using `self.env['ir.default'].set()`, it searches for an existing one, but if more than one match is found, accessing `default.json_value` raises a singleton error.
This fix makes sure the search only picks one record, avoiding that crash.
Before fix:
```py
self: res.users(1,)
>>> company = self.company_id
>>> company
res.company(1,)
>>> self.env['ir.default'].create({'field_id': 4540, 'company_id': company.id, 'json_value': 7})
ir.default(9,)
>>> self.env['ir.default'].set('res.partner', 'property_account_receivable_id', 7, company_id=company.id)
Traceback (most recent call last):
File "/home/odoo/odoo/odoo/odoo/orm/models.py", line 5630, in ensure_one
_id, = self._ids
^^^^
ValueError: too many values to unpack (expected 1)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/home/odoo/odoo/odoo/odoo/addons/base/models/ir_default.py", line 107, in set
if default.json_value != json_value:
^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/odoo/odoo/orm/fields.py", line 1670, in __get__
record.ensure_one()
File "/home/odoo/odoo/odoo/odoo/orm/models.py", line 5633, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: ir.default(4, 9)
```
After fix:
```py
self: res.users(1,)
>>> company = self.company_id
>>> company
res.company(1,)
>>> self.env['ir.default'].create({'field_id': 4540, 'company_id': company.id, 'json_value': 7})
ir.default(10,)
>>> self.env['ir.default'].set('res.partner', 'property_account_receivable_id', 7, company_id=company.id)
True
```
opw-5228419
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#234944
Forward-Port-Of: odoo/odoo#234893This change makes the Belgian blackbox point of sale more resilient when the internet connection drops during order synchronization. If an order cannot be signed because the connection is lost, it is now returned to a draft state so the cashier can try again later instead of the order getting stuck.
Original PR description
When trying to sync orders while being offline, a `ConnectionLostError` is raised. This error was not handled in the pos_blackbox_be module. Now, if an order was not signed correctly by the blackbox, we put its state back to "draft", allowing the cashier to retry later (when the connection to bbox is re-established). Forward-Port-Of: odoo/enterprise#98778
When users click a channel in the Discuss Kanban view, Odoo now opens the channel form instead of doing nothing. This makes channel navigation work as expected and improves the experience for users managing discussions.
Original PR description
**Steps to reproduce:** Open 'Discuss' Click on 'Channel' in the menu to display channels in kanban view Click on any channel **Cause**: The action 'mail.discuss_channel_action' did not include form view in view_mode. **Effect**: Clicking on a kanban card does not display the form view. **Fix**: Open the form view of a channel when clicking on a kanban card. Task-5076555 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227668
This change fixes an issue where installing the Argentina withholding demo data could create duplicate taxes with the same name. It keeps the demo setup clean and avoids confusion when users review or configure taxes.
Original PR description
**Description of the issue/feature this PR addresses**: This pr is to avoid duplicated taxes when the demo data is installed. **Steps to reproduce**: 1. Install l10n_ar_withholding module with demo…
**Description of the issue/feature this PR addresses**: This pr is to avoid duplicated taxes when the demo data is installed. **Steps to reproduce**: 1. Install l10n_ar_withholding module with demo data. 2. Take position in "(AR) Responsable Inscripto" company. 3. Check the taxes created on "Invoicing > Configuration > Accounting > Taxes". 4. Delete the filter "Sale or Purchase". 5. Add custom filter: Argentina Withholding Payment Tax type (l10n_ar_withholding_payment_type) is in ["supplier", "customer"]. 6. You will see that there are duplicated taxes (duplicated names) with suffix (Copy). **Current behavior before PR**: Duplicated taxes are created when demo data is installed. <img width="1597" height="795" alt="image" src="https://github.com/user-attachments/assets/51b65037-bb89-4ec7-8adf-21636b68e405" /> **Desired behavior after PR is merged**: No duplicated taxes are created when demo data is installed. _Task latam side_: 1360. _Task Adhoc side_: 57627. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226992
This change prevents upgrade failures when creating analytical entries from helpdesk tickets. It ensures the correct analytic account is kept so the system no longer raises a validation error during processing.
Original PR description
When creating an analytic line from a helpdesk ticket, we assigned the account_id from the project's account_id during the upgrade. However, in the standard code, the account_id is later overridden and updated from ticket.analytic_account_id, which is null. As a result, the constraint "At least one analytic account must be set" is triggered. see: https://github.com/odoo/enterprise/blob/dcfef2cc462631f376a596a7c85ae483826835ad/helpdesk_timesheet/models/account_analytic_line.py#L119 Multiple upgrade request failed due to this.
This change turns off IndexedDB during Hoot test runs for Point of Sale. It helps prevent test environments from filling up with too many databases, making the full test suite more reliable and easier to run.
Original PR description
Disable IndexedDB in Hoot tests to avoid creating to much IndexedDB databases when running the full test suite. IndexedDB is still tested in dedicated tours. Forward-Port-Of: odoo/odoo#234701
1 change
Resolved issues and error corrections
This update prevents the Mail module from failing during uninstallation when related database fields have already been removed. It helps ensure the module can be cleanly removed and later reinstalled without database errors.
Original PR description
When uninstalling module mail, an override of `unlink()` deletes the activities of the records being deleted. However, this override crashes whenever columns of `mail.activity` have been dropped already. As a consequence, it may prevent the deletion of the field `mail_message_id` of model `mail.tracking.value`, and its table, too. And this causes the reinstallation of module mail to log error: ``` column "mail_message_id" of relation "mail_tracking_value" contains null values ``` See https://runbot.odoo.com/odoo/runbot.build.error/233618 for the cases where it failed. The fix consists in checking whether the columns of `mail.activity` still exist before searching for activities.
12 changes
Enhancements to existing features
When a website uses the cookie bar, new Google Fonts will now default to not loading directly from Google. This helps websites stay more aligned with GDPR expectations, and the updated help text makes the privacy impact clearer for users setting up fonts.
Original PR description
__Current behavior before commit:__ When the cookies bar is installed, Google fonts are still loaded from Google servers by default, which may violate GDPR requirements. See the PR adding the "Serve from Google"[1] option for more details. __Description of the change:__ If the cookies bar is enabled, it likely means that the website needs to be GDPR compliant. In this case the "Serve from Google" option is disabled by default when adding a new Google Font, preventing it from being served from Google servers. The tooltip and setting help text are also updated to clarify GDPR implications. [1]: https://github.com/odoo/odoo/pull/101129 task-5111612
Discuss now includes a dedicated live chat category for conversations marked as "Looking for Help." Agents also see a star indicator on chats that match their expertise, helping them spot and respond to the most relevant conversations faster.
Original PR description
Add a live chat category in the Discuss app that allows live chat agents to easily identify conversations marked as "Looking for Help." A star icon is added next to conversations that match the agent's expertise, making it easier to assist with conversations related to their area of expertise. part of task-5190237.
Resolved issues and error corrections
Branch companies can now see and use payment providers set up for their parent company when customers pay online. This fixes a problem that previously blocked checkout with a “No compatible payment providers found” message.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a published payment provider; 2. create a branch company; 3. create a sales order in branch company; 4. enable online payment for sales order; 5. open sales order in portal view; 6. attempt to pay. Issue ----- No compatible payment providers found. Cause ----- The `payment.provider._check_company_domain` is set to the default exact match, so when it's used in `_get_compatible_payment_providers`, it's unable to find any providers for the branch company. Solution -------- Set `_check_company_domain` to `check_company_domain_parent_of`. opw-5214269 Forward-Port-Of: odoo/odoo#234821 Forward-Port-Of: odoo/odoo#234763
This update prevents a website access error when a product variant has a ribbon assigned. It ensures visitors can view product pages normally, avoiding a broken shopping experience for public users.
Original PR description
### Issue: An access error is shown on the website if ribbon is added to a product variant. #### To reproduce: 1- Create a db with `website_sale` installed. 2- Activate product variant. 3- Create a product variant and publish it. 4- Add a ribbon to the variant. 5- Using public user, navigate to the website product page. #### Cause: This is caused due to not having proper access rights. On stable we can use both the csv modification and adding sudo env to have an easier view update without need to upgrade the module. In master, we can keep the fix only in the csv file. opw-5224552
The Discuss command palette now uses smaller avatars on desktop so it matches the rest of the Discuss interface. This makes the list look more consistent and allows more results to be visible at once, while keeping the larger mobile layout unchanged.
Original PR description
Discuss command avatar were much bigger than rest of discuss UI, such as discuss sidebar. Discuss sidebar avatar size was reduced in 19.0, but discuss command palette still had big size like before this change. This commit fixes the issue with reduced size. To compensate with reduced size, more items are shown at once. This change only applies to desktop: in mobile the avatar need to be bigger, so this commit doesn't affect small UI. Part of Task-5227387 Before <img width="1280" height="946" alt="Screenshot 2025-11-10 at 12 59 56" src="https://github.com/user-attachments/assets/532c7d7f-a381-43f4-8a65-b0e3db7d6809" /> After <img width="1281" height="946" alt="Screenshot 2025-11-10 at 12 59 43" src="https://github.com/user-attachments/assets/9e018c92-a862-4aee-a2ad-dadd880b21f3" />
This change updates a manufacturing accounting test so it matches the latest way production duration is calculated. It ensures the test reflects the current logic and prevents false failures in automated checks.
Original PR description
### Issue: This is caused by changing the duration inverse in #233777. ### Cause: Before #233777, in duration inverse, only sum of `time_ids` was taken into account to calculate the `duration`. After that PR, `time_ids` with `get_working_duration` are also taken into account which cause this test fail. runbot-233742 Forward-Port-Of: odoo/odoo#234305
This change adds a regression test to make sure work entry generation still succeeds when an employee has overlapping leave periods, such as sick leave and a public holiday. It helps prevent a specific runtime error for fully flexible employees using attendance-based work entries, improving reliability in payroll-related processing.
Original PR description
**Purpose:** Add regression test to verify that overlapping leave scenarios (sick leave + public holiday) do not cause singleton errors for fully flexible employees using attendance-based work entries. **Test Coverage:** - Fully flexible employee with no calendar assignment - Attendance-based work entry source configuration - Overlapping sick leave and public holiday scenario - Work entry generation and validation without singleton errors Related : [PR](https://github.com/odoo/odoo/pull/223448) opw-4979974 Forward-Port-Of: odoo/enterprise#96664 Forward-Port-Of: odoo/enterprise#93902
This change prevents payroll from failing when an employee with fully flexible working hours has overlapping leave records, such as sick leave and a public holiday. It makes work entry processing more reliable and avoids blocking payroll runs for affected employees.
Original PR description
**Issue:** Multiple errors occur when processing payroll for "Fully Flexible" employees and overlapping leave scenarios: 1. ValueError "Expected singleton: hr.work.entry.type(7, 8)" during work entry…
**Issue:** Multiple errors occur when processing payroll for "Fully Flexible" employees and overlapping leave scenarios: 1. ValueError "Expected singleton: hr.work.entry.type(7, 8)" during work entry generation when sick leave overlaps with public holiday **Steps to Reproduce:** 1. Go to the **Employees** app and create a new employee. * Set the working hours to **empty (fully flexible)**. 2. Go to **Contracts** and create a new contract. * Set the **Work Entry Source** to *Attendance*. * Save and make the contract **Running**. 3. Go to **Time Off** → **New**, and create a sick time off for the employee. * Example: from **25th to 29th**. * Approve the time off. 4. Go to **Configuration** → **Public Holidays**, and create a new public holiday. * Example: **27th**, which overlaps with the sick time off. * Work Entry Type = **Paid Time Off**. 5. Go to **Payroll** → **Work Entries**. * A **traceback** occurs. **Root Causes:** - In `_get_interval_leave_work_entry_type()`: Direct access to `interval[2].work_entry_type_id.code` causes singleton violation when overlapping leaves create intervals containing multiple work entry types. **Fix:** - Replace direct access to `interval[2].work_entry_type_id.code` with safe recordset slicing `interval[2].work_entry_type_id[:1].code` to prevent singleton violation when interval contains multiple work entry types This resolves payroll blocking issue for deployments using the Fully Flexible employee feature, where employees may have overlapping leave types and no assigned working calendar. Test : [PR](https://github.com/odoo/enterprise/pull/93902) opw-4979974 Forward-Port-Of: odoo/odoo#230659 Forward-Port-Of: odoo/odoo#223448
When users click a channel from the Kanban view in Discuss, the channel now opens in the form view as expected. This makes it easier to review and manage channel details without extra steps.
Original PR description
**Steps to reproduce:** Open 'Discuss' Click on 'Channel' in the menu to display channels in kanban view Click on any channel **Cause**: The action 'mail.discuss_channel_action' did not include form view in view_mode. **Effect**: Clicking on a kanban card does not display the form view. **Fix**: Open the form view of a channel when clicking on a kanban card. Task-5076555 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227668
This change prevents the employee version timeline from trying to use payroll-related data when a user does not have access to it. As a result, HR users can open employee forms reliably, and the timeline simply omits the extra contract grouping line when the needed information is unavailable.
Original PR description
Before this commit, the version timeline component needs to read contract_type_id and contract dates fields to be able to add an extra line below the versions to mention the versions inside the same contract. The problem is `contract_type_id` and the contract dates fields are not available when the user cannot see the payroll tab in the employee form. This commit makes sure the fields needed to display the extra line inside the version timeline are only used if the user has access to them otherwise no extra line will be displayed since some information is missing to be able to display it. task-5253864 X-original-commit: 0b1d4b006908b1ad993177f024d65a484d477078
This update fixes when Avatax-related fields and address validation appear on customer and product screens. It ensures the system reads fiscal country codes correctly, so users see the right options at the right time and Avatax data is handled more reliably.
Original PR description
**Changes:** - Updated the logic for showing address validation in `res_partner.py` to handle fiscal country codes more robustly. - Modified visibility conditions for `is_avatax`, `avatax_category_id`, `avatax_unique_code`, `avalara_partner_code`, and `avalara_exemption_id` fields in XML views to correctly parse and check fiscal country codes. **Purpose:** These changes ensure that the application correctly identifies when to display certain fields based on the fiscal country codes, enhancing the accuracy of the Avatax integration. This is made necessary because of changes to the _compute_fiscal_country_codes method introduced in commit https://github.com/odoo/odoo/commit/c518589716ebde6fb418d907ee01799dd7b889e9.
This change makes uploaded videos compatible with Odoo’s content protection rules, so a page edited by an admin can still be updated later by restricted users. It prevents video embeds from being stored in a way that causes the page to look uneditable, improving collaboration on website content.
Original PR description
Steps to reproduce the current behaviour: - Update the DEMO user to be a website "restricted editor" and sales "admin" who cannot bypass HTML field sanitization. - As ADMIN, add a YouTube video to a…
Steps to reproduce the current behaviour: - Update the DEMO user to be a website "restricted editor" and sales "admin" who cannot bypass HTML field sanitization. - As ADMIN, add a YouTube video to a product page > Save. - As DEMO, try to update the content on the product page > You cannot (a dialog informs you that you cannot edit the content because an admin edited it previously). Explanation: Starting from [1], an HTML field can be flagged as `sanitize_overridable` which allowed users with the `base.group_sanitize_override` group to skip the HTML field sanitize process. If such users added some content that is not considered "sanitize friendly" (e.g. YouTube iframe), a restricted user won't be allowed to add content in the fields, since the sanitizer will remove the original content from the DOM. For this case, the code from [2] added an implementation to consider the field as none editable and warn the user once he tries to update it. Implementation: The goal of this commit it to fix the current limitation for video upload that currently prevents non admin users to edit a website record once an admin adds a video on it... The idea of the fix is the following: - We already have a technical fallback when uploading a video to save the iframe `src` to an attribute: `data-oe-expression`. - The public widget is now destroying the video iframes so they are never saved in the DOM. - A non-lazy code will build the iframes immediately on page load. - The public widget can always create the iframes if they are not already created (for compatibility). [1]: https://github.com/odoo/odoo/commit/cf844e34dd0ce4830eb99fd0fa5b6b9cb58c867c [2]: https://github.com/odoo/odoo/commit/cb80c15d3db49ede3c93171abcaa9064b88822c6 task-3757205 Forward-Port-Of: odoo/odoo#233792 Forward-Port-Of: odoo/odoo#175717
4 changes
Resolved issues and error corrections
This update adjusts an automated purchase test so it works correctly with PostgreSQL 18. It keeps the test focused on the real business behavior while avoiding a database-specific error name change that caused unnecessary test failures.
Original PR description
Apparently in pg18 a standard-compliance
fix (postgres/postgres@086c84b23d99c2ad268f97508cd840efc1fdfd79) has led to `RESTRICT_VIOLATION` being emitted in cases which formerly emitted `FOREIGN_KEY_VIOLATION`. One such case is specifically being tested for by `test_purchase_order_line_without_uom`, leading to this test failing systematically when running pg18:
psycopg2.errors.RestrictViolation: update or delete on table "uom_uom" violates RESTRICT setting of foreign key constraint "purchase_order_line_product_uom_id_fkey" on table "purchase_order_line"
DETAIL: Key (id)=(29) is referenced from table "purchase_order_line".
Update the test to use the more generic `IntegrityError` as it's probably more than sufficient for our purposes. Technically we could pass a tuple of `(ForeignKeyViolation, RestrictViolation)` but it doesn't really seem necessary. And it would require fixing the `_raisesContext` override as currently it is very much *not* compatible with that.This fix makes drag-and-drop work more reliably on touch devices in the Documents app. It helps users move files or items on mobile devices, where the browser was previously losing the needed drag information before the drop action completed.
Original PR description
For now, touch devices do not work with native drag and drop in browsers. When a datatransfer is set on a dragstart event, it is lost before reaching the drop event, but only when using a touch device. Unfortunately, I still haven't found any sources that clearly explain whether this is a known bug or a limitation. The fact that on mobile (really mobile, not devtools, you need a touch device) drag fails on Chrome but succeeds on Firefox. To fix this issue, this commit manages datatransfers in an external variable, without using the method in the Event. I keep the original behavior as default, I just add a fallback to my global datatransfer variable. opw-5139435
This change makes interval calculations consistently normalize their data before combining results. It helps prevent incorrect overlaps and errors when different interval types are used together, especially in planning-related operations.
Original PR description
## The issue Prior to this commit, the `other` parameter in the `_merge` method could belong to a different class, not necessarily an instance of `Intervals`.…
## The issue Prior to this commit, the `other` parameter in the `_merge` method could belong to a different class, not necessarily an instance of `Intervals`. https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L158-L165 The comment indicates that normalization should be enforced; however, there is no corresponding reference to it within the `_boundaries` method. https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L48-L53 That normalization just happens in the `__init__`. https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L117-L132 ## Example For example, in Planning module, we perform operations between `Intervals` and `WorkIntervals`. The `WorkIntervals` class behaves differently from `Intervals`: while `Intervals` uses disjoint closed intervals, `WorkIntervals` uses disjoint semi-closed intervals. ## Side effects During these operations, the `_merge` method was not normalizing the `_items`, which caused inconsistencies and errors (when we are merging two unormalized intervals `([0, 10], [10, 20])` with an empty `others`). ## The fix This commit ensures that the `other` parameter is normalized before processing the `_merge` operation. The fix ensures that normalized intervals are always produced after `_merge`, even when unnormalized intervals are provided as input. ## Real case That issue has been found in that ticket: 5184291 Forward-Port-Of: odoo/odoo#234352
Live chat visitors on mobile devices will no longer see the message input automatically zoom in when they tap it. This keeps the send button visible and makes chatting smoother on external websites.
Original PR description
Before this commit, when using livechat for visitors on mobile devices, click on input would zoom on input of about 115%. This zoom would hide send button at the very end of composer input, and would…
Before this commit, when using livechat for visitors on mobile devices, click on input would zoom on input of about 115%. This zoom would hide send button at the very end of composer input, and would force users to pinch-to-unzoom, making the UX quite poor. This problem happens because mobile devices have an auto-zoom feature that is triggered when font-size is below 16px. The discuss UI is designed with 14px font size (web client font size), and since 14px < 16px, it zooms on input focus to about 115%. This commit fixes the issue by using a font-size of 16px specifically for livechat visitor on mobile devices, so that this doesn't auto-zoom. Note that this problem doesn't happen on the web client even though this uses a font-size of 14px because it specifically disable the autozoom feature: https://github.com/odoo/odoo/blob/17.0/addons/web/views/webclient_templates.xml#L250 This solution is not practical for livechat, for which it has to work on any external website. opw-5229076 Before <img width="199" height="431" alt="after" src="https://github.com/user-attachments/assets/cc2f8e04-bde7-4eeb-84d5-b2efa2763490" /> After <img width="199" height="431" alt="before" src="https://github.com/user-attachments/assets/6c6679fc-9c16-40e7-ab6f-21540d20d59d" /> Forward-Port-Of: odoo/odoo#234967
3 changes
Enhancements to existing features
This change speeds up the calculation of accounting move amounts by preparing required data in advance instead of repeatedly loading it on demand. It significantly reduces processing time, memory use, and database queries when handling very large reconciliations, making large accounting operations much faster and more efficient.
Original PR description
Currently performance on `_compute_amount()` is bottlenecked by `__get__()` calls on fields on `line_ids`. We tackle this bottleneck by warming the cache with `fetch()` Benchmark on reconciling 2 account moves with ~70k lines each | |Total Time|Allocated Memory|Queries| |----------|----------|----------------|-------| |Before |43.23s |2GB |993 | |After |18.60s |1GB |693 | opw-5098543
Resolved issues and error corrections
Mobile visitors using live chat will no longer see the message field auto-zoom when they tap to type. This keeps the send button visible and makes the chat experience smoother on phones and tablets.
Original PR description
Before this commit, when using livechat for visitors on mobile devices, click on input would zoom on input of about 115%. This zoom would hide send button at the very end of composer input, and would…
Before this commit, when using livechat for visitors on mobile devices, click on input would zoom on input of about 115%. This zoom would hide send button at the very end of composer input, and would force users to pinch-to-unzoom, making the UX quite poor. This problem happens because mobile devices have an auto-zoom feature that is triggered when font-size is below 16px. The discuss UI is designed with 14px font size (web client font size), and since 14px < 16px, it zooms on input focus to about 115%. This commit fixes the issue by using a font-size of 16px specifically for livechat visitor on mobile devices, so that this doesn't auto-zoom. Note that this problem doesn't happen on the web client even though this uses a font-size of 14px because it specifically disable the autozoom feature: https://github.com/odoo/odoo/blob/17.0/addons/web/views/webclient_templates.xml#L250 This solution is not practical for livechat, for which it has to work on any external website. opw-5229076 Before <img width="199" height="431" alt="after" src="https://github.com/user-attachments/assets/cc2f8e04-bde7-4eeb-84d5-b2efa2763490" /> After <img width="199" height="431" alt="before" src="https://github.com/user-attachments/assets/6c6679fc-9c16-40e7-ab6f-21540d20d59d" />
This fix ensures that when a transfer in a batch is only partly completed, it is correctly removed from the batch afterward. This helps keep batch lists accurate and avoids confusion for warehouse users managing ongoing operations.
Original PR description
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