Daily updates from Odoo
Tuesday, October 21, 2025
32 changes · saas-18.4
Resolved issues and error corrections
This update allows files, such as images, to be processed before they are uploaded. This helps reduce oversized image storage and can keep the database leaner without changing the user's upload flow.
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 Forward-Port-Of: odoo/odoo#231899 Forward-Port-Of: odoo/odoo#226611
App icons created in Studio are now automatically resized before being saved. This prevents oversized images from increasing database size, cache usage, and request payloads, helping keep the system more efficient without changing the user workflow.
Original PR description
Before this commit, the IconCreator images were sent as is in their full size. Downstream it was problematic because apps' icons were bigger than necessary, bloating the different caches, the database, and the request. After this commit, icon are resized to a max of 64x64 pixels. Forward-Port-Of: odoo/enterprise#97626 Forward-Port-Of: odoo/enterprise#94480
Fixes a checkout issue where quickly navigating back and changing the delivery address could show an error instead of continuing smoothly. Customers are now safely redirected to the shop when the cart is no longer available, reducing failed checkout experiences and support incidents.
Original PR description
Currently, an error occurs when the user changing the delivery address in the website. **Steps to reproduce:** - Install the `website_sale` module and enable the `Demo` payment provider. - Go to `Website` > `Shop` > `Add a product to Cart` > `View cart` > `Checkout`. - Ensure there are at least two different delivery addresses > `Confirm` > `Pay now`. - Quickly press the browser’s `back button` twice. - Select a different `delivery address`. **Error:** `ValueError: Expected singleton: sale.order()` **Root Cause:** At [1], the code calls `order.ensure_one()`. When the cart (`sale.order`) is empty, leads to an `error`. **Fix:** This commit prevents a traceback on the frontend when a user attempts to change the delivery address and safely redirects them to the shop page. [1]: https://github.com/odoo/odoo/blob/88c9a45ee1ff8dde871865723c3387c059af8289/addons/delivery/models/delivery_carrier.py#L157 sentry-6869972801 Forward-Port-Of: odoo/odoo#226781
This fixes an issue in Italian Point of Sale where enabling the cash drawer could prevent the fiscal receipt from printing correctly during a sale. Businesses using Italian fiscal printers can now complete sales with the cash drawer option enabled and still receive the required printed receipt.
Original PR description
Pull request https://github.com/odoo/enterprise/pull/91412 attempted to fix an issue related to printing the receipt with the italian fiscal printer. That PR forgot to handle the cash drawer correctly. This Pr fixes that. It is essentially a backport of commit 32b5651. Steps to reproduce: 1. clean DB 2. setup an italian POS 3. configure the printer 4. in the POS settings, tick the box "cash drawer" 5. attmept to make a sale After this commit, the receipt is correctly printed. opw-4882480 Forward-Port-Of: odoo/enterprise#97379
Mobile self-order customers now see the correct order after placing a new order, instead of being shown a previous paid order. Receipts also remain accurate after refreshing the page, including the correct payment details, reducing confusion for customers and staff.
Original PR description
This PR contains 2 small fixes for mobile self order: - **[FIX] pos_self_order: wrong order on confirmation screen** Steps to reproduce: 1. Configure a Self Order POS to use QR menu + ordering 2. In…
This PR contains 2 small fixes for mobile self order:
- **[FIX] pos_self_order: wrong order on confirmation screen**
Steps to reproduce:
1. Configure a Self Order POS to use QR menu + ordering
2. In the mobile menu, make an order and confirm
3. The confirmation screen shows order S001, pay at the counter
4. In the POS, pay and validate the order
5. In the mobile menu, make another order and confirm
Expected behaviour:
- The confirmation screen shows order S002, pay at the counter
Actual behaviour:
- The confirmation screen shows order S001, already paid
The cause of this is that `selectedOrderUuid` is cleared whenever the
`getUserDataFromServer` method is called, even if the server doesn't
return an order to replace it with. The self order service then tries
to find the current order and takes the previously paid order instead of
the new order.
To fix this, we simply don't clear `selectedOrderUuid`. It will still be
overwritten if the server does return new order data.
- **[FIX] pos_self_order: incorrect receipt after refresh**
Steps to reproduce:
1. Configure a Self Order POS to use QR menu + ordering
2. Make an order in the mobile menu
3. Pay and validate the order in the POS using the 'Card' payment method
4. Go to 'My Orders' in the mobile menu, and download the receipt
5. Observe the correct 'Card' payment line is shown on the receipt
6. Refresh the page
7. Download the receipt again
Expected behaviour:
- The downloaded receipt is the same as the first one, with the 'Card'
payment line.
Actual behaviour:
- The downloaded receipt has no payment lines, so it just shows a
negative 'Change' line at the end.
The cause of this issue is that the payment lines and payment methods
used to render the receipt were not being persisted in the indexed DB.
The fix is simply to add these models to the data service options so
that they also get saved locally.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#232314
Forward-Port-Of: odoo/odoo#231910Payment registration now looks at the customer linked to the invoice instead of the company partner on the accounting line. This ensures saved payment methods are offered correctly when creating later invoices for the same customer, reducing failed or manual payment handling.
Original PR description
Currently, when user A from company AA records a payment method, a payment token is stored for that user. However, when an invoice is issued for that user, the payment token cannot be used because the payment registration form uses the partner AA instead of the user linked to the move, partner A. Step to reproduce: 1. Create a user A in company AA 2. Create an invoice for user A 3. Register a payment on the invoice and save the payment method (token) 4. Create another invoice for user A 5. Try to register a payment on the invoice: the payment token is not proposed This fix updates the logic to use the user linked to the move instead of the partner on the line, allowing proper selection of a payment token. opw-5036106 Forward-Port-Of: odoo/odoo#232134 Forward-Port-Of: odoo/odoo#230105
Invoices paid with a partial payment within tolerance will no longer be automatically closed as fully paid. This keeps the invoice marked as partially paid so users can decide how to handle the remaining balance.
Original PR description
Prevents the system from creating a write-off and marking an invoice as 'Fully Paid' when a partial payment (within tolerance) is reconciled from the invoice form. The invoice status will now correctly remain 'Partially Paid', giving the user control over the remaining balance. task-5114658 Forward-Port-Of: odoo/enterprise#95899
Point of Sale now correctly applies quantity-based pricelist rules when the same lot-tracked product is split across multiple lots. This ensures customers receive the intended price once the combined quantity reaches the discount threshold, improving pricing accuracy at checkout.
Original PR description
**PROBLEM** Pricelist rules based on a minimum quantity does not work well with lot tracked product, when the quantity is splitted between multiples lots. For example, if you take 2 product from lot…
**PROBLEM** Pricelist rules based on a minimum quantity does not work well with lot tracked product, when the quantity is splitted between multiples lots. For example, if you take 2 product from lot A, and 3 product from lot B, a rule defining the price for a minimum quantity of 5 will not trigger (it should). **STEP TO REPRODUCE** 1. install pos 2. create a lot tracked product 3. create a pricelist rule for the product, with a price based on min qty 4. from the pos, order the min qty but split it accross multiple lots 5. price will not takethe rule into account **CAUSE** Order line of lot tracked products are never merged. The quantity used to compute if a pricelist trigger is the quantity of each line individually. **FIX** For lot tracked product, to determine the price of a line, we parse find all corresponding lines and add their quantities together. Then we update all of their prices. To know if we should take into account a line, we verify if they would have been merged, if their product wasn't lot tracked. **REMARK** Ideally, their would be a way to merged order line of lot tracked product, while being able to edit the quantity taken from each lot directly from the pos. From now, order line doesn't work well with multiple lots, and it would require unstable change on the db. opw-4751920 Forward-Port-Of: odoo/odoo#232276 Forward-Port-Of: odoo/odoo#219110
This update improves the spacing of menu-related settings shown in debug mode for event website pages. The clearer layout makes it easier for administrators to match each label with its field when configuring event page menu tabs.
Original PR description
The PR fixes the display of the fields displayed when the debug mode is activated and used to show buttons in the menu of event website pages. Previously, it was difficult to determine what were the labels of the fields. To make it clearer, the spaces between the label-field couples have been increased. Task-4750239 Forward-Port-Of: odoo/odoo#214135
Changing the shape of a GIF image in the editor no longer causes an error. This improves reliability for users editing website or HTML content with animated images.
Original PR description
Steps to reproduce: =================== 1- Add an image of type GIF. 2- Try to change its shape. → Traceback occurs. Cause: ====== The `process` image function can return a callback function when GIF…
Steps to reproduce:
===================
1- Add an image of type GIF.
2- Try to change its shape.
→ Traceback occurs.
Cause:
======
The `process` image function can return a callback function when GIF transformation must be skipped:
https://github.com/odoo/odoo/blob/7f95cc6094b914c57b6e36ad072ebb2c9c3b324b/addons/html_editor/static/src/main/media/image_post_process_plugin.js#L78
It can also return an object `{ url, newDataset }`: https://github.com/odoo/odoo/blob/7f95cc6094b914c57b6e36ad072ebb2c9c3b324b/addons/html_editor/static/src/main/media/image_post_process_plugin.js#L224
Only the object case was handled:
https://github.com/odoo/odoo/blob/7f95cc6094b914c57b6e36ad072ebb2c9c3b324b/addons/html_editor/static/src/main/media/image_post_process_plugin.js#L231
As a result, when a function was returned, the image source was set to `null`, because `processed` was a function and didn't have a `url` or `newDataset`, causing a crash here:
https://github.com/odoo/odoo/blob/22c83301337e40699b11621053af627f5bfd505b/addons/html_builder/static/src/plugins/image/image_shape_option_plugin.js#L412
Solution:
=========
Ensure that only the `url` and `dataset` are returned, since the same
function is called elsewhere expecting those values.
opw-5137667
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe Planning and Timesheet Analysis report now calculates planned and remaining hours using each employee's actual working schedule, rather than assuming a standard Monday-to-Friday week. This makes reports more accurate for employees with part-time or non-standard calendars.
Original PR description
To reproduce: ============= - set the company calendar to 40h/week (Mon to Fri) - create an employee with a 32h/week working schedule (doesn't work on Fri) - on planning app, create a shift for this employee for ex from 01/09 to 15/09 with 2h allocated - go to Planning / Timesheet Analysis report and check report for this employee on september -> planned hours and remaining hours are wrong Problem: ======== when querying the data for the desired period, we divide the allocated hours by the number of weekdays (Mon to Fri) in the period, but we should divide by the number of working days according to the employee's working schedule Solution: ========= we compute the number of working days based on the resource calendar of the employee and use this number to compute the planned hours and remaining hours opw-5008066 Forward-Port-Of: odoo/enterprise#95115
This fixes an issue where IoT event updates could fail because required timing information was missing. Businesses using IoT-connected devices should see more reliable event delivery and fewer interruptions when the system checks for new device activity.
Original PR description
In odoo/odoo#232282, `time` was removed from registered events, leading to `KeyError` when trying to fetch longpolling events.
Undoing an auto-reschedule in the work order planning view no longer triggers an error. This helps manufacturing planners safely adjust schedules and reverse changes without interruption.
Original PR description
When rescheduling workorders in mrp's Planning by Workcenter using Auto-Reschedule mode and then Undo-ing, a bad query error occurs, due to
WHERE "mrp_workcenter"."id" IN ('m', 'r', ...
This comes from web_gantt_reschedule returning something like
{'3': {'date_finished': '2025-10-20 11:43:51',
'date_start': '2025-10-20 09:43:51',
'workcenter_id': 'mrp.workcenter(1,)'}}Automatic printing during delivery validation now includes shipping labels and related shipping documents in the normal validation flow. This prevents missed print actions after the page reloads, especially when only one IoT-connected printer client is available.
Original PR description
The `button_validate` method called clicking "Validate" returns a list of client actions to call. After these clients actions are executed, the page reloads. This reload makes our broadcasted action not to be caught by the client if there is only one connected. Anyway, this flow was overcomplicated and has been simplified overriding the method returning the client actions, adding the "shipping labels" and "shipping documents" to it. Forward-Port-Of: odoo/enterprise#97627 Forward-Port-Of: odoo/enterprise#97462
Fixed an issue where required matrix questions in surveys could fail if their description also included a table. This ensures respondents can complete affected surveys without errors, improving reliability for survey creators and participants.
Original PR description
A conflict occurs if a matrix question is set to "Mandatory answer" (questionRequired = True) and a table is also added to its description. The issue is that when the system evaluates a required matrix, it gets the subQuestionsIds by looking for the first table within the question's wrapper. If a table exists in the description, the system incorrectly tries to retrieve the IDs from that table. This action throws a traceback because the descriptive table does not contain any sub-question data. This commit fixes the issue by being more specific when looking for the table containing the subQuestionsIds. It adds a specific class to this table and uses it in the selector. An attribute selector, like 'table[data-sub-questions]', could also have been used as an alternative. opw-4931881 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229909
This fix improves Swiss payroll employee views so they work correctly in setups with multiple companies or countries. It helps businesses using Swiss payroll avoid incorrect visibility or configuration issues when managing employees across different company contexts.
Original PR description
task-5159023 Forward-Port-Of: odoo/enterprise#97636 Forward-Port-Of: odoo/enterprise#96733
This update fixes an automated website test related to hiding the sidebar header. It helps ensure the website editing experience remains reliable in the saas-18.4 version without changing functionality for end users.
Original PR description
Tour added in that [commit], was previously failing. This commit aims to fix it. Original commit hasn't been merged in `19.0` yet, so this fix applies only to `saas-18.4` . [commit]: https://github.com/odoo/odoo/commit/a5455bf27cb21762d79636cb7dd133c88441bccb runbot-233438
OdooBot's predefined canned responses are now shared with the appropriate user group in standard and demo data. This ensures users can actually see and use these ready-made replies, improving consistency and saving time in conversations.
Original PR description
**Description of the issue this PR addresses:** Modify Canned Response master and demo data **Current behavior before PR:** Before this PR, canned responses created by OdooBot in master and demo data were not shared effectively, so they were not visible to anyone. **Desired behavior after PR is merged:** This PR ensures canned responses created by OdooBot are shared properly, by assigning a user group, ensuring that everyone can see them. task-[5069111](https://www.odoo.com/odoo/project/1519/tasks/5069111) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231976 Forward-Port-Of: odoo/odoo#228006
The Documents app now correctly switches debug mode when users use the command palette shortcut. This prevents confusion where the shortcut appeared not to work, while keeping shared document links accurate.
Original PR description
Issue: In the documents app toggling debug mode through the command palette (ctrl-k) does not work. Manually editing the URL works as expected. Cause: A patch on `router.stateToUrl` for the documents app rebuilds the URL to create clean, shareable links. When doing so, it attempted to preserve the debug status by referencing the global `odoo.debug`. This global object did not reflect client-side state changes. The command palette correctly provides the intended future state to the router. The patch was ignoring this incoming state and using the outdated global value, causing the generated URL to be incorrect. Solution: Modify the patch to use the `state` argument provided to `stateToUrl`, which contains the correct, up-to-date information for the navigation. Task-5095056 Forward-Port-Of: odoo/enterprise#96275
This change removes a browser option that was causing point of sale connections to IoT devices to fail in some older Chrome versions. The option was unnecessary for Odoo's secure device communication, so removing it improves compatibility without changing the user workflow.
Original PR description
This reverts commit 1a934ae which added the `"targetAddressSpace": local` option to IoT fetch requests. This is because of two reasons: 1. It caused errors on older versions of Chrome that implemented the obsoleted 'Private Network Access' standard. 2. It was not actually required in the first place, it is only needed in situations where a HTTP resource is accessed from HTTPS using a domain that resolves to a local IP. In Odoo we only ever do this for HTTPS -> HTTPS requests, where it works automatically. task-5157145 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232378 Forward-Port-Of: odoo/odoo#232110
This change removes a browser request option that caused errors in some older Chrome versions when connecting to IoT devices. IoT and point-of-sale hardware connections should continue to work as before, with fewer compatibility issues for affected users.
Original PR description
This reverts commit 6d09dc6 which added the `"targetAddressSpace": local` option to IoT fetch requests. This is because of two reasons: 1. It caused errors on older versions of Chrome that implemented the obsoleted 'Private Network Access' standard. 2. It was not actually required in the first place, it is only needed in situations where a HTTP resource is accessed from HTTPS using a domain that resolves to a local IP. In Odoo we only ever do this for HTTPS -> HTTPS requests, where it works automatically. task-5157145 Forward-Port-Of: odoo/enterprise#97679 Forward-Port-Of: odoo/enterprise#97500
Website editors can now change or select shaped images without encountering an error. The fix keeps older image shapes working after the editor migration, preventing disruption for pages created in previous versions.
Original PR description
Steps to reproduce: =================== 1. Drop a snippet having an image with a shape (e.g. "Intro Pill", "Images Mosaic", ...). 2. Try to change the image shape. → Traceback occurs. This issue also happens when clicking on images with shapes that were added in previous versions. Cause: ====== Before the refactoring, shape URLs started with `web_editor`, but now `html_builder` is expected. This mismatch causes the shape to be considered invalid when parsed, leading to a traceback. The issue was introduced by this PR: https://github.com/odoo/odoo/pull/222471 Solution: ========= Ensure backward compatibility by allowing shapes using the old `web_editor` path to remain functional after the migration to `html_builder`.
Inventory transfers now list each source document only once, even when several items come from the same receipt or origin. This prevents duplicated references in transfer records, making warehouse documents clearer and easier to review.
Original PR description
### Behavior: #### Current: During the assignment of a picking, if several of its moves have the same origin, it will repeat that origin in its own origin. #### Expected: Only have one time each…
### Behavior: #### Current: During the assignment of a picking, if several of its moves have the same origin, it will repeat that origin in its own origin. #### Expected: Only have one time each origin. ### Steps to reproduce: From Inventory * Enable two step transfer for the warehouse From Barcode * create and validate new receipts with "Product A" * create and validate a second new receipts with "Product A" and other products From Inventory/Operations/Transfers/Receipts * Open the corresponding receipts * In "source Document" (Field: origin, Model : stock.picking) we can see that the reference from second receipts is repeated. ### Observation: In the case of already existing origins it will not duplicate them but it's missing if several item comes from the same origin. https://github.com/odoo/odoo/commit/0caa44ca97d9d197811a03ad2ff227df68d4437a#diff-55c6314416a6a400da6acd5018d161a55eeeb0e3008fec8828121e3dd12be0ebR1410 opw-4970159 Forward-Port-Of: odoo/odoo#223251
This fix makes product image fetching more reliable by replacing a fragile scheduling check with a safer cleanup step before creating a new scheduled task. It also reduces unnecessary processing when scheduled tasks are created, helping keep background operations efficient across the system.
Original PR description
Remove `_check_image_cron_is_not_already_triggered` because: - It doesn't work in batch mode due to `self.cron_id.id`. - It increases the cost of creating a cron trigger because the reference lookup (`ref`) makes at least one extra query. (We want to keep cron trigger creation efficient since it is used everywhere.) - Because of this constraint, there is an extra commit in `_trigger_fetch_images_cron` that is inefficient and error-prone, serving no purpose. Keep the intended effect of the constraint by removing the existing cron trigger before the new one is created, ensuring the time offset is respected. Forward-Port-Of: odoo/enterprise#97411
This fix removes an outdated requirement that an eCommerce website must be publicly accessible for Google Merchant Center product feeds. Feeds now use access tokens instead, reducing unnecessary setup restrictions while keeping authorized access in place.
Original PR description
Initially, a constraint was added to ensure the eCommerce site was publicly accessible, allowing Google to access the feed without requiring authentication. However, the updated version of GMC no longer relies on this constraint. Instead, it uses an access token to authorize feed access. A previous attempt ([^1]) to remove this constraint targeted the wrong model. This commit corrects that mistake. [^1]: https://github.com/odoo/odoo/pull/225536 Forward-Port-Of: odoo/odoo#232477
This fixes an issue where reconciling certain journal items could fail when a customized default journal entry type was in use. The reconciliation wizard now consistently creates the required write-off as a standard journal entry, reducing interruptions for accounting users.
Original PR description
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account…
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account type. Root cause: The wizard used the default `move_type`. While this is usually `entry`, a customisation can change it. Since types other than `entry` have more robust requirements in terms of necessary fields (ie. `partner_id`) and account type limitations, this results in an exception being raised. Fix: Added a line in `write_off_vals` that explicitly assigns `move_type` as `entry`. Steps to reproduce: 1. Have unreconciled Journal Items. 2. Define a new User-defined default for the Journal Entry model, setting its default type to a value other than "Journal Entry". 3. Select an unreconciled Journal Item in the list view and attempt to reconcile it through the wizard. 4. Observe the exception pointing to a missing `partner_id` or incorrect account type. opw-5107155 Forward-Port-Of: odoo/enterprise#97130 Forward-Port-Of: odoo/enterprise#97028
Shipping notification emails for Gelato orders now include the correct tracking link when an order ships in a single parcel. This prevents customers from being sent to a broken tracking page and helps them follow deliveries more reliably.
Original PR description
After receiving the shipping webhook from Gelato, we send a shipping notification with the tracking information to the customer. This commit fix the tracking url for single parcel, which was pointing to an inexistant url. opw-4637331 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232468 Forward-Port-Of: odoo/odoo#232071
UPS shipment requests now include the sender and customer VAT information, so commercial invoices generated for international deliveries show the correct tax details. This helps businesses avoid incomplete customs paperwork and reduces manual follow-up for missing VAT numbers.
Original PR description
**Current behavior:** There is currently no tax information supplied in the UPS shipment request. So, for example, the VAT number section on a commercial invoice generated from a shipment will always be blank. **Steps to reproduce:** - Create a quotation, chose a customer that is not is the same country as your company. - Add a delivery and chose UPS. - Validate the delivery. - Check the invoice generated in the chatter. - The VAT is not in the invoice **Cause of the issue:** The VAT of the company and the VAT of the customer were never given to UPS. **Fix:** The VATs are now added to the UPSRequest class before making the call to the API. As the TaxIdentificationNumber field is depricated, we have to use the new GlobalTaxInformation container, which allows us to specify the tax information about the sender and the shipper. opw-4591744 Forward-Port-Of: odoo/enterprise#82356
This fixes an automated Payroll test that was failing because newer Chrome versions report text styling slightly differently. The change keeps payroll testing reliable without changing business features or user workflows.
Original PR description
Since either 140 or 141[^0] Chrome uses compact serialization rules for text-decoration, as a result of w3c/csswg-drafts#12486. This was merged [on August 12th][CL-6824265] and Chrome 139 was cut on August 5 so couldn't have had this change. The new serialization rule means values which can be ommitted from a shorthand (default or fallback) should be, so the default `text-decoration-line` and a `text-decoration-color` matching the `color` won't be serialized in `text-decoration` anymore. Instead of matching the shorthand, match the actual stored properties. [^0]: 140 was not deployed on chrome next so it may or may not have been broken then [CL-6824265]: https://chromium-review.googlesource.com/c/chromium/src/+/6824265 Note: this commit is a backport of odoo/enterprise@eddbdb2d9593b331c5ef641b7747ec61c736d84d Forward-Port-Of: odoo/enterprise#97719
A web interface test was adjusted to account for a minor Chrome browser behavior change that can shift a resizable panel measurement by one pixel. This keeps automated checks reliable without changing how users experience the product.
Original PR description
In Chrome 140, a fix [^0] has been applied regarding the `offsetParent` property with a fixed position element. Due to this fix, a resizable panel's test failed by 1px. As this difference doesn't have a real functional impact, we adapted the test to accept both the pre/post fix values. Note: that it is also related to a clarification [^1] in the CSS spec [^2]. [^0]: https://chromium-review.googlesource.com/c/chromium/src/+/6774502 [^1]: https://github.com/w3c/csswg-drafts/issues/12352 [^2]: https://drafts.csswg.org/cssom-view/#dom-htmlelement-offsetparent Forward-Port-Of: odoo/odoo#232458
Code cleanup and technical improvements
This update applies automated linting cleanup to the VoIP codebase, improving consistency and maintainability without changing business functionality. It helps reduce future development risk in calling, softphone, and related test areas.
Documentation and clarification updates
The contributor agreement records were updated to include Acsone and Tobias Zehntner. This keeps Odoo's legal contributor documentation current and confirms contribution rights for future work.
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232278