Daily updates from Odoo
Monday, November 17, 2025
57 changes · 19.0
Security fixes and vulnerability patches
The live chat transcript email option is now limited to internal users only. This helps prevent sensitive conversation records from being sent outside the company and improves control over customer communication data.
Original PR description
This commit restricts the possibility of emailing a transcript of the live chat conversation to internal users. task-5262277
Enhancements to existing features
Employees can now view and select a VoIP provider themselves instead of relying on an administrator for every change. This makes provider switching simpler while still keeping the information they can access limited to what they need.
Original PR description
We now allow base.group_user to have read access to voip.provider so that user can change provider by themselves. Note that the visible fields to base.group_user are still limited. Task-5262635
This update adds a button to create a CFDI for all payslips in a payroll run at once, instead of handling them one by one. It helps payroll teams complete Mexican payroll reporting faster and with less manual work.
Original PR description
This adds a button to generate a CFDI for the whole payrun when ready. Task: 5224206
This update refreshes the automatic database backup module and its supporting files to align with the latest v19 codebase. It helps keep backup scheduling, notifications, and related documentation current so system backups remain reliable and easier to maintain.
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
The Maintenance app is being updated so equipment opens in a table-style list by default instead of separate cards. This makes it easier for teams to scan, compare, and manage equipment details at a glance while keeping the same underlying features.
Original PR description
Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress. <!-- START COPILOT CODING AGENT SUFFIX --> <details>…
Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress. <!-- START COPILOT CODING AGENT SUFFIX --> <details> <summary>Original prompt</summary> > In the maintenance module (addons/maintenance) for Odoo 18, change the equipment view from individual blocks (kanban view) to a table format (list/tree view) as the default view. > > The changes should: > 1. Modify the equipment action in addons/maintenance to set the tree/list view as the default view instead of kanban > 2. Update the view mode order to prioritize list/tree view over kanban view > 3. The tree view should display equipment in a table format with columns including: equipment name, category, equipment location, serial number, model, effective date, cost, and responsible person > 4. Keep all existing functionality intact - just change the default display format from kanban blocks to a table > > Files that likely need modification: > - addons/maintenance/views/maintenance_views.xml (to set default view mode) > - Any action definitions for equipment that currently default to kanban view > > The goal is to show all equipment in a table/grid format for better overview and management instead of individual card blocks. </details> *This pull request was created as a result of the following prompt from Copilot chat.* > In the maintenance module (addons/maintenance) for Odoo 18, change the equipment view from individual blocks (kanban view) to a table format (list/tree view) as the default view. > > The changes should: > 1. Modify the equipment action in addons/maintenance to set the tree/list view as the default view instead of kanban > 2. Update the view mode order to prioritize list/tree view over kanban view > 3. The tree view should display equipment in a table format with columns including: equipment name, category, equipment location, serial number, model, effective date, cost, and responsible person > 4. Keep all existing functionality intact - just change the default display format from kanban blocks to a table > > Files that likely need modification: > - addons/maintenance/views/maintenance_views.xml (to set default view mode) > - Any action definitions for equipment that currently default to kanban view > > The goal is to show all equipment in a table/grid format for better overview and management instead of individual card blocks. <!-- START COPILOT CODING AGENT TIPS --> --- 💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more [Copilot coding agent tips](https://gh.io/copilot-coding-agent-tips) in the docs.
This update makes sure that links from payroll and contract screens open the correct employee or contract forms. It improves navigation for users by sending them to the intended record view instead of an incorrect or outdated one.
Original PR description
The contract template form view is now written on the formview_action directly. This is a backport of https://github.com/odoo/enterprise/pull/97463 task-5082709 Forward-Port-Of: odoo/enterprise#99486
When users open a version record in HR, they are now sent to the most relevant screen: contract templates open in the contract template view, while employee-related versions open in the employee form with the correct version already selected. This makes navigation more accurate and reduces confusion when reviewing or editing HR version data.
Original PR description
If the version record is a contract template, redirect to the version contract template view. Otherwise, redirect to the employee form view with the version_id in the context. This is a backport of https://github.com/odoo/enterprise/pull/97463 task-5082709 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#235691
This update brings the Spanish tax return feature into version 19.0, aligning it with the newer product version. It keeps the existing BOE reporting options working, so businesses gain the new return process without losing current compliance workflows.
Original PR description
The tax return functionality was added in master in https://github.com/odoo/enterprise/pull/90615. This PR backports the functionality in 19.0 while preserving the previous BOE functionalities as per stable policy. An upgrade PR allows for a fallback to master behavor : https://github.com/odoo/upgrade/pull/8602. task-5113840
Resolved issues and error corrections
Users on mobile can now add emoji reactions in chat without the picker being hidden behind the conversation window. The update also adjusts the discuss app so chat bubbles are no longer shown there, improving the mobile chat experience and preventing a confusing blocked action.
Original PR description
[FIX] mail: can add message reaction in mobile Before this commit, mobile uses could not practically add reactions. Steps to reproduce: - open a discuss conversation on mobile device - post a message…
[FIX] mail: can add message reaction in mobile Before this commit, mobile uses could not practically add reactions. Steps to reproduce: - open a discuss conversation on mobile device - post a message - click on "..." - click on "Add a reaction" => No emoji picker is shown. This happens because the emoji picker opens in a modal in mobile. The modal has a z-index lower than chat window, and because of this it is actually shown below the chat window. The chat window being above modal is sometimes desirable, like for AI chat windows triggered from a modal in desktop, but sometimes the opposite is desirable, like in mobile. Chat window had z-index for desktop use of above modal, but in mobile the opposite is desirable. This commit fixes the issue by reducing the chat window z-index in mobile, so that modals are above chat windows. Note that current desktop style for chat window being necessarily above modals is not exactly correct, but this is a tricker part to fix therefore this PR focuses on the immediate usability issue in mobile that makes using any modal in chat window unusable. Task-5208322 Task-5261880 This PR also disables the showing of chat bubbles in discuss app similarly to the desktop counter-part. Task-4607436 https://github.com/odoo/enterprise/pull/99588
This fix restores the ability to add emoji reactions to messages on mobile devices in Discuss. It improves the mobile messaging experience so users can respond to conversations the same way they do on desktop.
Original PR description
Task-4607436 Task-5261880 https://github.com/odoo/odoo/pull/235852
This fix makes the QRIS configuration fields visible again in the Indonesian bank form. It corrects where the fields are inserted so they no longer end up inside a hidden section, improving the setup experience for users who need to configure QRIS payments.
Original PR description
**Description of the issue/feature this PR addresses:** This issue occurs because the XPath targeting the `currency_id` field is placed inside a `<div>` that becomes invisible under certain conditions. The `view_partner_bank_form_inherit_hr` view is loaded first due to its sequence, and the `l10n_id` view is applied afterward, causing the QRIS fields to be inserted into that hidden `<div>` from `view_partner_bank_form_inherit_hr`. **Current behavior before PR:** The fields l10n_id_qris_api_key and l10n_id_qris_mid are not visible. **Desired behavior after PR is merged:** The fields l10n_id_qris_api_key and l10n_id_qris_mid are visible by changing XPath target Task: [5247678](https://www.odoo.com/odoo/project.task/5247678) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an error that could occur when users enter certain barcodes in the barcode app. It ensures the barcode data is interpreted correctly so scanning and applying barcodes works without crashing in both standard stock and manufacturing flows.
Original PR description
This error occurs while entering the barcode number. Steps to reproduce: --- - Install `stock_barcode` module(without demo) - Setting > Barcode > Set Barcode Nomenclature = `Default GS1 Nomenclature`…
This error occurs while entering the barcode number. Steps to reproduce: --- - Install `stock_barcode` module(without demo) - Setting > Barcode > Set Barcode Nomenclature = `Default GS1 Nomenclature` - Barcode > click on `Scan or tap` > Enter a barcode(barcode number should startwith `urn` (eg: "urn:epc:tag:sgtin-96 : 3.0614141.038656.0")) > Apply Traceback: --- `KeyError: 'rule'` (with GS1 Nomenclature) `AttributeError: 'list' object has no attribute 'get'` (without GS1 Nomenclature) At [1], we expect the key `rule` to be present in the result, but this key is never set in the return statement at [2]. Since [1] also relies on the result’s type, a new key value `type` has been added in this [commit] to address that. This commit ensures that the correct keys are passed in the result dictionary. [1]- https://github.com/odoo/enterprise/blob/b001e9cc2af0f800e2a7965b61aa9b9c5bd4e89e/stock_barcode/controllers/stock_barcode.py#L29-L31 [2]- https://github.com/odoo/odoo/blob/f8f72b15598576f5870e49879e96fc5c127a6100/addons/barcodes/models/barcode_nomenclature.py#L174-L189 [commit]: https://github.com/odoo/odoo/commit/1394fa161a6fcf77b4443cbf784ad7dd635e7f9e#diff-be2a58d0591614180295c070396ff487f4bc04bf33aad2829d7bfab4671a792cR60 sentry-6992944243 Forward-Port-Of: odoo/enterprise#98761
This change prevents AI chats from breaking when a user closes the conversation before the answer arrives. It also avoids sending the reply to a new, unrelated chat, ensuring the response is either handled correctly or safely ignored if the chat is gone.
Original PR description
If a user sends a message to an ai agent and then closes the chat channel before receving the response, - For AI composer channels (channels opened through AI chatter button) an error occurs. - For…
If a user sends a message to an ai agent and then closes the chat channel before receving the response, - For AI composer channels (channels opened through AI chatter button) an error occurs. - For other AI channels, A new ai chat channel gets created and the response is posted to that channel instead of the deleted one. Cause of the Issue : When the channel is deleted, a serialization error occurs because one transaction is trying to delete the channel while the other is trying to post the ai response to the channel. The delete transaction finishes execution and the response generation transaction is retried. - For AI composer channels some fields of the deleted channel are accessed inside `_ai_add_message_to_context` and `_ai_create_response` which raises an error. - For other AI channels, when generate_response is retried,_get_or_create_ai_chat is called and given that the old channel has already been deleted, a new one is created and the response is posted to that channel. Note: No issue will happen if the response generation transaction is executed and the deletion transaction is retried, because it will delete the channel after the response was posted which is a normal behavior. task-5063221 Forward-Port-Of: odoo/enterprise#93877
This change removes leftover database sequences created for Point of Sale sessions after those sessions are closed. It helps keep the system tidier and avoids unnecessary buildup of database objects over time.
Original PR description
to avoid having too many postgres sequences, this make sure the sequence used by the pos session is cleaned up after being closed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235875 Forward-Port-Of: odoo/odoo#235500
Work orders now correctly include their time-based cost when they are marked as done directly from the status control. This ensures project profitability and margin calculations reflect the real manufacturing cost, even when the work order is not started first.
Original PR description
Backport of: 223ec6ac83ba2ec94f7ea394458aee0972bb8b44 **Original msg commit:** This commit fixes the problem of adding the hourly cost of the work center when marking an operation as done from the status widget. To reproduce the bug: 1- Create a work center with an hourly cost > 0. 2- Create an MO with 1 operation in that work center, expected time > 0. 3- Create and set a project on the MO. 4- Make sure that project has an analytic account. 5- Mark the operation as done from the status widget. (click on it and choose done, don't use the start button) 6- Go to the analytic account of the project and check the gross margin. = No cost of the workorder was added. Now, this commit takes into account the duration of the WO first when marking it as done directly from the status widget. opw-5170664 Forward-Port-Of: odoo/enterprise#99439
This fix corrects how Point of Sale order totals are displayed in the backend. The Tax Excl amount now shows the full subtotal before tax, instead of incorrectly showing the unit price, which improves the accuracy of order review and reporting.
Original PR description
**Steps to reproduce:** * Install the **Point of Sale** module with demo data. * Open the POS interface and create a new order. * Add a product that has **taxes applied** and set its quantity to more…
**Steps to reproduce:** * Install the **Point of Sale** module with demo data. * Open the POS interface and create a new order. * Add a product that has **taxes applied** and set its quantity to more than one. * Confirm the order by proceeding to payment and Validate payment. * Go to the backend: **Point of Sale → Orders → Orders**. * Open the created order and check the value displayed under **Tax Excl**. **Issue:** * The **Tax Excl** field shows the *unit price* of the product instead of the *subtotal without tax*. - *Example -* *Unit Price*: 10 *Quantity*: 3 *Tax*: 10% **Expected Value -** **Tax Excl**(price_subtotal) : 30 **Tax Incl**(price_subtotal_incl): 33 **Current Value -** **Tax Excl**(price_subtotal) : 3 **Tax Incl**(price_subtotal_incl): 33 **Cause:** * The POS code incorrectly assigns `price_subtotal` using the displayed unit price instead of the actual tax-excluded subtotal. **Fix:** * Assign `price_subtotal` using the correct **PriceExcl** value so the subtotal without tax is accurately reflected. --- opw-5252340 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the normal record limit when returning to a Kanban view after removing a grouping. It helps avoid the page slowing down or crashing when too many records would otherwise be loaded at once.
Original PR description
Steps to reproduce ================== - Add a group by in the kanban product view - Switch to the list view - Remove the group by - Switch back to the kanban view -> No limit is applied, and the webclient can crash if too many records are returned. Cause of the issue ================== The groupsLimit is set as MAX_SAFE_INTEGER in the kanban view https://github.com/odoo/odoo/blob/df959e05ac9cf3136d1724bc80b7597a70932225/addons/web/static/src/views/kanban/kanban_controller.js#L168 Which is then reused as the limit https://github.com/odoo/odoo/blob/df959e05ac9cf3136d1724bc80b7597a70932225/addons/web/static/src/model/relational_model/relational_model.js#L368 Solution ======== There is already a code path to reset the limit when switching from grouped to ungrouped, but is wasn't called on the first load (when this.root isn't set yet) opw-5167769 Forward-Port-Of: odoo/odoo#235794 Forward-Port-Of: odoo/odoo#235232
This change makes the purchase catalog suggestion test more reliable by moving it to a test setup that better handles timing delays. It prevents random failures in automated builds without changing the user-facing purchasing flow.
Original PR description
Description of the issue/feature this PR addresses: Fixes non deterministic runbot error in the purchase catalog suggestion JS tour: https://runbot.odoo.com/odoo/runbot.build.error/233744 Current behavior before PR: We test the adding product quantity behavior of the kanban product record with the suggestion feature ON **in a JS tour.** which has a non deterministic behavior on the runbot due to a debounce on an RPC. Desired behavior after PR is merged: Perform the same functionality test but in Hoot testing (which allows for parallel testing) and can better handle awaiting the debounce on the AddProduct RPC call. Use this PR as reference for the Hoot test odoo/enterprise#63041 (see the discussion on runAllTimersin the above mentionned PR if unclear --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes an error that appeared when users grouped the Chart of Accounts by Status. The view now works correctly instead of showing a traceback, making it easier to review accounts by status without interruption.
Original PR description
When grouping by the ``Status (audit_status)`` field in the Chart of Accounts view, A traceback will appear. Steps to reproduce the error: - Install ``Accounting`` module - Go to Accounting > Configuration > Chart of Accounts - Group By: ``Status (audit_status)`` field Traceback: ```py SyntaxError: syntax error at or near "," LINE 1: SELECT , COUNT(*) FROM "account_account" WHERE "account_acco... ``` https://github.com/odoo/enterprise/blob/9ebe781f2abd399ad4610114a75993b784f71921/account_reports/models/account.py#L319-L321 In the main view of ``acount.account``, ``working_file_id`` is not available in the context, So, ``working_file`` becomes ``False`` and ``_field_to_sql`` returns an empty SQL(). This results in the above traceback when grouping by the Status field. sentry-6944233306
This update makes payroll PDF generation more resilient when a record cannot be rendered. Instead of letting the whole scheduled process fail and eventually disable itself, the error is now saved on the record and the remaining files continue to be processed.
Original PR description
When rendering PDF files, `_get_rendering_data` is expected to return a dict with the key `error` when needed. Some localizations respect this correctly, but others will raise an UserError instead. In particular, the `Payroll: Generate pdfs` cron will keep trying to generate the file and the `UserError` will never be caught, so the scheduled action will eventually be deactivated. With this fix, the exception is caught, the message is recorded on the sheet, and the PDF is skipped. The cron will then keep processing the other records. Source: investigation after the cron got disabled on our server
This update prevents product quantities in the online shop from becoming decimal values when packaging rules are applied. It rounds quantities down so customers only see valid whole-number quantities, avoiding confusing or incorrect stock displays.
Original PR description
### Issue: In ecommerce quantity can become decimal. #### To reproduce: 1- Add a packaging `Pack of 6` to the product 2- Uncheck `continue selling` 3- Update in-stock quantity of the product to 9 4- In product shop page and increase the qty to 9 5- Change the packaging option to `Pack of 6` Talked with PO about this issue. There are no use cases in ecommerce where the quantity needs to be a decimal number. We should round the quantity down, as in this instance where: - In-stock quantity: 9 - Packaging: Pack of 6 The `free_qty` should be 1. opw-5237233
This update prevents list views from crashing when they use sample data together with grouped results. It makes list behavior consistent with kanban so empty real groups are handled safely and users can continue browsing without errors.
Original PR description
This commit reverts PR [1] which attempted to fix an issue with grouped list views with sample data. The issue occured when the web_read_group returned real groups that are all empty. When this…
This commit reverts PR [1] which attempted to fix an issue with grouped list views with sample data. The issue occured when the web_read_group returned real groups that are all empty. When this happened, the model kept and relied on the real groups information, in particular which groups are open ("folded" flag).
In kanban, this works fine because we use those real groups in the sample server, and populate them with sample records. However, we didn't do that for the list view, for an obscure reason. As a consequence, in list, we sometimes received sample groups that matched the real ones (same id, when grouped by many2one), so we re-used the real group information (i.e. the folded flag). We were then manipulating groups that we believed to be open, i.e. to have a `records` key, whereas the fake read group done by the sample server returned groups without that `records` key, leading to a crash.
PR [1] tried to fix web_read_group in the SampleServer, to take into account the `opening_info` and return a `__records` key for opened groups. However, the fix crashed if there were more open real groups than sample groups (i.e. 5).
This commit fixes the issue by generalizing the kanban logic to the list, i.e. by moving it to the RelationalModel. From now on, both kanban and list will use the real groups, and fill them with sample data if necessary.
In master, we'll go even further by allowing to manipulate those groups (e.g. edit, create new...) like we do in kanban.
[1] https://github.com/odoo/odoo/pull/226253
Issue reported on the feedback pad after migrating odoo.com to v19
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-prThis update corrects how grouped list views calculate the width of the group header. As a result, grouped lists should now display columns more accurately and avoid layout issues when optional fields are shown.
Original PR description
This commit removes the colspan incrementation for optional fields in the group name. The incrementation was redundant, as the group configuration cog menu <th> is always present in the column for optional fields when the list is grouped. This ensures the colspan value now correctly reflects the actual number of visible columns. task-5261958
Regular users can now create Global Invoices in the Mexican localization without getting an access error. This fixes a permissions issue that previously blocked non-admin users from completing the process and ensures the CFDI document is created successfully.
Original PR description
## Issue: When creating a Global Invoice with a non-admin user (e.g., demo), an Access Error was raised: `Sorry, you are not allowed to access this document` ## Cause: This commit change the…
## Issue: When creating a Global Invoice with a non-admin user (e.g., demo), an Access Error was raised: `Sorry, you are not allowed to access this document` ## Cause: This commit change the attachment creation to use the SUPERUSER: https://github.com/odoo/enterprise/pull/95197 However, updating `attachment.res_id` then required `base.group_system` access rights, preventing regular users from modifying the attachment As a result, non-admin users (like demo) triggered an access error during Global Invoice creation ## Steps to reproduce: - Switch to the MX company - Create a product with an UNSPSC Category (Accounting Tab) - Create and Confirm an Invoice for the product (enable CFDI to public) - Connect as Demo - Go in Accounting > Customers > Invoices - Toggle the last created invoice checkbox - Actions > Create Global Invoice - Before the fix, the Access Error is displayed - Check in the invoice Chatter for the Global CFDI document creation success opw-5181925 Forward-Port-Of: odoo/enterprise#98218
This update fixes an error that could cause a crash when creating a group time off request that overlaps with an existing one. It also corrects the wording of the message shown to users, so they now get a clear notification instead of a traceback.
Original PR description
Issue: When generating a new group time off, if the leave type uses "hour" as the request unit (e.g., unpaid or extra hours), and there is a conflicting leave request for the same time period, a traceback occurs. Steps to Reproduce: - Generate a group time off using this leave type. - Ensure there is an existing leave request that overlaps with the requested time. - Observe the traceback error. Root Cause: The translation function _ is invoked incorrectly in the error message, and there are typos in the message text. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product descriptions in the online shop now adapt better to the available space, making long text easier to read in showcase and card list layouts. Editing descriptions in showcase mode also works more smoothly because the overlay no longer blocks access to the text.
Original PR description
On showcase and card list design, the description can be very long making the paragraphs hard to read. The readability standard for comfortable reading is ~66 characters. The responsive font-size on these designs were not properly following the container width. On showcase, in edit mode the description couldn't be edited because the overlay was displayed over it. task-5150655 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The system now avoids using the mobile phone search feature until the user has typed at least three characters. This prevents an error from appearing as soon as someone starts typing and makes contact search feel smoother.
Original PR description
`phone_mobile_search` doesn't allow you to search for less than 3 characters. This commit excludes `phone_mobile_search` from the search domain when there are less than 3 characters. This avoids triggering an UserError on the first characters typed. Forward-Port-Of: odoo/enterprise#99548
The FEC import process has been adjusted to load only the partner details it actually needs, instead of pulling in every available field for all partners. This reduces memory usage and helps prevent import failures on large databases.
Original PR description
### Description: When importing an FEC, Odoo will fetch all the partners to link the new imported records to the existing partners. The issue is that it triggers the prefetching of all the fields of the partners (304k partners in their case), causing a memory error. To avoid that, we can just fetch the field that we need (e.g. "name" and "ref"). ### Reference: opw-5153555 Forward-Port-Of: odoo/enterprise#98483
This update corrects how fixed local taxes are written into Mexican electronic invoices. It prevents the tax amount from being multiplied by 100 in the XML, so the generated CFDI shows the right value and avoids reporting errors.
Original PR description
Steps to reproduce: 1. With an MX Company setup configure a new tax as follows - Tax Computation: Fixed - SAT Tax Type: Local - Factor Type: Cuota - Amount: 5 2. Create a customer invoice with the tax 3. Generate CFDI Issue: In the XML the ImpuestosLocales node contains `<implocal:TrasladosLocales ImpLocTrasladado="VAT 0%" Importe="20.00" TasadeTraslado="500.00"/>` The tax fixed amount was multiplied by 100 This occurs because we don't check if the tax is fixed when normalizing the amount opw-5132807 Forward-Port-Of: odoo/enterprise#99431 Forward-Port-Of: odoo/enterprise#98988
When a delivery is split into two pickings, the availability status of the original move is now recalculated correctly. This prevents the system from showing outdated stock availability information and helps users rely on accurate delivery statuses.
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#232914 Forward-Port-Of: odoo/odoo#232516
When a shape is applied to a background or image, it is now clearly highlighted in the shape selector. This makes it easier for users to see the current setting and improves the overall usability of the editor, including better keyboard support and panel behavior.
Original PR description
Before this commit, when a shape was applied to a background or an image, that shape was not highlighted in the shape selector. After this commit, active shapes are highlighted with a border in the shape selector. task-5187272 Forward-Port-Of: odoo/odoo#233035
This fix prevents an error that could happen when a stock move line has no quantity. It helps ensure inventory valuation calculations continue smoothly instead of failing in these edge cases.
Original PR description
The method, _get_valued_qty introduced in this commit: https://github.com/odoo/odoo/commit/08b62a4bbcc6f9a391b2cc00a621ef4c76100229#diff-ad6229e976ce0bd1592e805b88e9813ac4e3f6fb989d3dfb8dfb8b70af03cd58 because move_lines can have quantity as zero. This is where the value of in_qty comes from. 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
This change improves automated tests by making unfinished drag-and-drop actions safely cancel themselves at the end of a test. It prevents delayed errors from appearing after tests have already finished, which makes test runs more stable and easier to trust.
Original PR description
Before this commit, when initiating an unfinished drag sequence (i.e. calling `drag` without `drop` or `cancel`), the drag sequence was ended by destroying the component, which could throw asynchronous errors after the test finished. One possible fix would be to wait for these errors upon ending a test, but this process is handled by Owl and through a possible chain of promises, which would have to be accounted for by an arbitrary amount of 'animationFrame' or 'advanceTime' calls. Instead, the `contains...drag` and `contains...dragAndDrop` now handle a single drag sequence at a time, with a systematic cleanup after each test in case a drag sequence has been left pending. In such cases, the sequence is canceled. Enterprise: https://github.com/odoo/enterprise/pull/99369 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235826 Forward-Port-Of: odoo/odoo#235359
This fix removes an access issue that could block Recruitment Administrators from sending referral campaigns when they do not have Employees access. It ensures the campaign action works for the intended recruitment users, improving the workflow for hiring teams.
Original PR description
STEP TO REPRODUCE:
------------------
1- Give to Marc Demo the right : Recruitment / Administrator (be sure he doesn't have any right on Employees)
2- Log as Marc Demo
3- Go to Recruitment
4- Click on the three dots in kanban card
5- Click on Referral Campaign
6- Click on Send
You will have an access error
This user (with these groups) should be able to send a referral campaign
task-5082344
Forward-Port-Of: odoo/enterprise#98773
Forward-Port-Of: odoo/enterprise#96746This update ensures changes to Belgian Dimona payroll fields are properly tracked in the version history. It resolves a failing automated test and helps keep change logs complete and reliable for payroll-related updates.
Original PR description
The test_hr_version_fields_tracking was failing because the Belgian Dimona fields in hr.version model were missing tracking=True. task-5122440 Forward-Port-Of: odoo/enterprise#95735
This change restores the correct default document type when creating debit notes. It prevents the system from accidentally replacing that default with an invoice document type, which helps avoid confusion and ensures debit notes start with the right settings.
Original PR description
Restores code from v16 to define a default document type for debit notes on records with debit_origin_id. Previously, when using the wizard to generate a debit note, the default document type (related to debit notes) was being overwritten by the first document type associated with invoices. Although this behavior will be removed in v17, this fix is necessary to prevent overwriting the default value for now. Note: It's still possible to use the document type for invoices. Therefore, the change only affects the computation of the default value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181106
This fix prevents Studio from crashing when editing JSON-based fields such as analytic distribution. It adds the missing placeholder support so dynamic widget settings work correctly and the editor stays usable.
Original PR description
When trying to edit the `analytic_distribution` field using Studio, the following traceback occurred: `Caused by: TypeError: Cannot read properties of undefined (reading 'subOptions')` This happened because the new option `placeholder_field` was [introduced](https://github.com/odoo/odoo/commit/6620ebbd184de6f106fceb4427a081b61d97296a) for dynamic placeholders in widget. However, there was no support declared for `placeholder` inside the `FIELD_TYPE_ATTRIBUTES` definition for the `json` field type. This commit adds `EDITABLE_FIELD_ATTRIBUTES.placeholder` to the `json` field type, allowing widgets on JSON fields to correctly handle `placeholder_field` options without causing a Studio crash. opw - 5180896 upg - 3249816
This update makes sure drag-and-drop actions used in automated tests are fully completed before the test ends. It helps prevent unfinished test steps from being canceled too early, improving the reliability of web and Gantt-related test results.
Original PR description
Since drag sequences are automatically canceled at the end of tests, 'cancel' or 'drop' calls should be properly awaited before the end of a test. This commit ensures that these actions are properly finished before a test ends. Community: https://github.com/odoo/odoo/pull/235359 Forward-Port-Of: odoo/enterprise#99559 Forward-Port-Of: odoo/enterprise#99369
This fixes an issue where adding a shape to certain Unsplash images could fail after selecting images from a multi-word search. The image path is now handled correctly, so users can edit these images without encountering an error.
Original PR description
Steps to reproduce: =================== - Connect Unsplash to your database - Add a snippet on your website page like "Feature wall" for example - Double click on an existing image - type at least…
Steps to reproduce: =================== - Connect Unsplash to your database - Add a snippet on your website page like "Feature wall" for example - Double click on an existing image - type at least two words separated by a space like "Sleeping cat" - select any image from the list. - Add a shape to this image -> Traceback Cause: ====== When an image is chosen from Unsplash using a multi-word search, its URL contains encoded characters (e.g., `%20` for a space). The image processing utility was extracting the `pathname` directly from the image's URL. This path, however, remained URL-encoded. This encoded path was then used in a subsequent RPC call to fetch the original image data before applying the shape. https://github.com/odoo/odoo/blob/b9435baa1948f54e19f2dd5702a39d073e8eb57d/addons/html_editor/static/src/utils/image_processing.js#L204 This caused the fetch operation to fail, returning an `undefined` value. The attempt to apply a shape to this `undefined` result is what triggered the traceback. Solution: ========= The `srcUrl.pathname` is now wrapped in `decodeURIComponent()`. This function correctly decodes URL-encoded sequences (like `%20`) back into their original characters before the path is sent to the server. The backend now receives a clean, valid path, resolving the traceback. opw-5241317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235263
This update fixes an issue in report editing where inserting a new table or element could move the cursor to the wrong place. The editor now keeps the user’s position intact, so they can continue typing or interacting with the inserted content smoothly.
Original PR description
On a new report, add a X2Many table in a new Report. In many cases there will be some issues with the selection as, when inserting the Element via the command of the report Editor we explicitly focus the editable of the html_editor. We need the document inside the iframe to get the focus, because our flow implied to click on some popover bound to the main window. But focusing the editable element changed the selection. So, instead, we focus the iframe's inner window, and the selection stays at the right place, and the user can immediately interact with it (by continuing typing after the insertion) task-5159482 Forward-Port-Of: odoo/enterprise#97642
The sales order product search now works with supplier-specific product names and codes again. This restores a useful lookup option that was accidentally removed, helping users find the right product faster when matching supplier information.
Original PR description
Commit 6e69b1d4a357bf236695a2ed5b09fd62de911872 cleaned up SO views and removed some context fields from the product_id and product_template_id fields which were in fact used in the `_search_display_name` override of the related models. This commit brings back those values to allow finding products by their seller product name or code. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235591
This update fixes how employee version records are duplicated, ensuring all relevant details are copied when creating a new version. It also adjusts a payroll validation rule so it checks uniqueness per employee instead of per version, which better matches how the information is now stored.
Original PR description
## [FIX] hr*: make sure copy of a version copy all version fields This commit makes sure all the information of a version is completely duplicated when the user creates a new version from an existing version of an employee. ## [FIX] l10n_be_hr_payroll_group_s: move group S unicity constraint per employee Before this commit, the group S unicity constraint were per versions since before it was per contract. Now, since we no longer any contract model and more than version could represent the same contract, that constraint is a bit too restrictive. Moreover, the group S is more stored on the employee, so it would surely make more sense to trigger an error if 2 different employees have the same group S code. This commit moves the group S unicity constraint in hr.employee model to make sure we check per employee instead of per version. Forward-Port-Of: odoo/enterprise#95559
This change prevents an error that could happen when users click "Create and Enrich Partner". It ensures the system saves the correct company reference, so partner creation and enrichment complete successfully without interruption.
Original PR description
Currently, an error occurs when the user clicks the `Create and Enrich Partner` button. **Error:** `ProgrammingError: can't adapt type 'res.partner'` This error occurs when the user clicks the…
Currently, an error occurs when the user clicks the `Create and Enrich Partner` button.
**Error:**
`ProgrammingError: can't adapt type 'res.partner'`
This error occurs when the user clicks the `Create and Enrich Partner` button. Then it tries to find or
create the company using IAP. From here [1], it returns the record as company, and here [2], it writes
this record into the partner as the parent_id. However, since the parent_id is a record instead of an ID,
when the system tries to browse the partner by this record [3], the error is raised.
This commit ensures that when writing the parent_id of the partner, the actual ID is used instead
of the record.
[1]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/mail_plugin/controllers/mail_plugin.py#L386
[2]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/mail_plugin/controllers/mail_plugin.py#L52-L53
[3]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/account/models/partner.py#L801
sentry-6831922000
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#235198This update fixes several issues in employee versioning so that new versions preserve all the right information and any edits made during creation are tracked properly. It helps prevent missing data or unintended changes when updating employee records, making version management more reliable for HR teams.
Original PR description
## [FIX] hr: track the fields updated when creating new version Before this commit, when the user alters an employee form view and then create a new version, if a version exists on that employee…
## [FIX] hr: track the fields updated when creating new version Before this commit, when the user alters an employee form view and then create a new version, if a version exists on that employee altered, it will copy the version with the changes made by the user at the same time and so no tracking values on the values changed by the user are created. This commit makes sure the changes made by the user are correctly tracked when a new version is created with some values given in parameter. ## [FIX] hr: add explanation how to change group on version fields in employee model ## [FIX] hr*: make sure copy of a version copy all version fields This commit makes sure all the information of a version is completely duplicated when the user creates a new version from an existing version of an employee. ## [FIX] hr: protect fields copied in create_version to avoid recomputing Before this commit, since now we do a write after the copy of a new version to be able to track the changes made by the user. We cannot guarantee the vals given to the write will trigger a compute method from a field copied. This commit makes sure the version fields copied will never be invalidated and only the fields inside the write (that is, the fields altered by the user) will be altered. Forward-Port-Of: odoo/odoo#222744
Financial reports on mobile devices can be scrolled again after a styling issue was fixed. This restores access to report content that could previously be cut off on smaller screens.
Original PR description
make the financial reports scrollable again, as the overflow-hidden inadvertently removed it. task-5251154
This fix ensures leave records are created under the employee’s own company instead of the company of the person validating the leave. As a result, resetting work entries keeps the correct leave type and avoids turning leave time into regular attendance by mistake.
Original PR description
When validating a leave for an employee from another company, if the employee’s working hours had no company set, the created resource.calendar.leaves used the validator’s company instead of the employee’s. This caused the reset of work entries to replace leave entries by attendance. We now compute the resource calendar leave’s company using calendar_id.company_id or its existing company before falling back to the current validator company. task-5240785 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
Attendance officers can now update attendance records even when related work entries already exist. The system no longer blocks the edit because of payroll permissions, making routine attendance corrections smoother and reducing access issues for non-payroll users.
Original PR description
Steps to reproduce: 1. Log in as an Attendance Officer without payroll rights. 2. Attempt to edit any attendance record. Cause: If work entries already exist for the attendance, Odoo tries to regenerate them an action requiring payroll permissions. Solution: Execute the work entry regeneration wizard with sudo to bypass the payroll access restriction. Task: 5265141
This fix removes an unwanted border that appeared on the background blur toggle in the call video settings. It makes the video call interface look cleaner and more consistent when users click the option.
Original PR description
**Current behavior before PR:** The background blur toggle button in the call video settings dropdown shows an unintended border when clicked. **Desired behavior after PR is merged:** The background blur toggle button in the call video settings dropdown no longer shows border when clicked. Before: <img width="463" height="203" alt="image" src="https://github.com/user-attachments/assets/ffc42a8d-3d07-480d-84ba-5959e7bf723d" /> After: <img width="398" height="205" alt="image" src="https://github.com/user-attachments/assets/01cc4883-b6e0-4e23-b400-45c4373ef77e" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change makes live chat agent assignment depend only on whether an agent is truly available, not on their custom chat status. As a result, agents who are actually online will no longer be incorrectly left out of chat routing.
Original PR description
Since 19.0, users can set their im status (online/away/busy/offline). Because of this, some agents are considered unavailable while they actually are online. The intent is to prevent assignation when an agent is *really* unavailable. Custom IM status shouldn't interfere with assignation. This commit ensures we only consider *real* IM status to determine if an agent is available. 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
When an appointment cannot be saved because there are not enough available seats, the error message now clearly includes the appointment type name. This makes the message easier to understand and helps users quickly identify which appointment is affected.
Original PR description
Currently, when creating a new appointment with a specified number of people but no resources, saving the record triggers a UserError that does not display the appointment type name. Issue: 2 seats are missing to be able to book the appointment.type(1,): Table (30) <img width="1813" height="776" alt="image" src="https://github.com/user-attachments/assets/f87f45de-3552-47bb-b34c-fcc06cea425f" /> Solution: 2 seats are missing to be able to book the Table: Table (30) <img width="1769" height="905" alt="image" src="https://github.com/user-attachments/assets/04188071-be67-4500-b720-039ee7a27c2e" />
This update corrects how certain icons and buttons appear in company-specific settings screens, so the interface is more consistent and easier to understand. It improves the presentation of inventory-related configuration pages without changing the underlying business behavior.
This update prevents the documentation page from crashing when a custom field was renamed in Studio but an old duplicate field record still exists in the system. It restores access to /doc while the underlying data issue is addressed separately.
Original PR description
Steps to reproduce: 1. Install studio and contact (the bug is in the ORM, but studio/contact make it easy to reproduce). 2. Add a field (regular one, text/checkbox/...) on a partner form view with…
Steps to reproduce:
1. Install studio and contact (the bug is in the ORM, but studio/contact make it easy to reproduce).
2. Add a field (regular one, text/checkbox/...) on a partner form view with studio. Note its auto generated "old" name.
3. Rename the field via studio Note its new name.
4. Go to /doc, traceback `Key error: "old name" not in Model._fields`.
5. Go to "technical/database structure/fields" in ?debug=1 mode.
6. Search for "x_studio" `[("x_studio", "in", "name")]`
On "partner" you only see a single field, with the new name. On "user" you see two fields, one with the old name and another with the new name.
The problem is that when renaming the field, the ORM renamed (replaced) the old field by the new one on partner, reflected the change by adding a new field on res.users (inherits) but failed to remove the old field on res.users.
The traceback in /doc is only a symptom of the above problem. In this work we are adding a band-aid to skip badly renamed fields. It doesn't solve the root problem but it makes it possible to use /doc again until the actual bug is solved.
task-5172546This update improves inventory valuation closing so Odoo only considers the relevant stock movements since the last closing. It also lets users generate closing entries using the selected date, while preventing dates that would make later closings inconsistent. The result is fewer misleading suggestions and more reliable accounting records.
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
This change fixes a payment failure that could occur when customers paid subscriptions in IDR using a card that required 3D Secure verification through Xendit. It ensures the payment amount is sent in the format Xendit expects, preventing checkout errors and improving payment success rates.
Original PR description
When trying to pay a subscription (tokenization enforced) in IDR with a card that require the 3DS flow in Xendit, the following error is raised: `"amount" must be an integer.` So following 46166e25f049, when creating then token authentication we must use the rounded amount (introduced by b3f4e08cea6c) to meet Xendit specific currencies requirements. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235759
This change prevents a validation error that could occur when multiple inactive companies each have a "Current Year Earnings" account. It ensures these accounts are checked in their own company instead of being incorrectly grouped together, improving reliability during setup and data updates.
Original PR description
# Description of the issue/feature this PR addresses: Currently, the constraint `account.account._check_account_type_unique_current_year_earning` raises a validation error when there are more than…
# Description of the issue/feature this PR addresses:
Currently, the constraint `account.account._check_account_type_unique_current_year_earning` raises a validation error when there are more than one accounts of type "Current Year Earnings" in the same company. This is expected behaviour.
However, the ORM will throw an exception if it finds two or more accounts of this type across multiple inactive companies. Example:
```sql
lare_3183476=>
SELECT COUNT(account.id), account.company_id, company.active
FROM account_account account
JOIN res_company company
ON account.company_id = company.id
WHERE account.account_type = 'equity_unaffected'
GROUP BY account.company_id, company.active;
count | company_id | active
-------+------------+--------
1 | 1 | t
1 | 2 | f --
1 | 3 | t
1 | 4 | f --
1 | 5 | t
1 | 6 | t
(6 rows)
```
# Current behavior before PR:
When the above constraint retrieves accounts of type "Current Year Earnings" grouped by their companies, those records belonging to inactive companies are grouped together into an "empty" company, res.company(). This raises an exception due to the definition of the constraint even though the accounts belong to a different company, and therefore, don't break the condition.
# Desired behavior after PR is merged:
To address this issue, we will modify the context of the environment to consider inactive records in the search by disabling the flag `active_test`. Since only two models are involved in the query, and account.account doesn't have a field for active records, this addition will correctly group the accounts in their correct company.
---
upg-3185680
upg-3143424
Thanks to @jlom-odoo for providing initial insights on the problems as well as additional examples.
---
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/18.0/odoo/service/server.py", line 1361, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-13>", line 2, in new
File "/home/odoo/src/odoo/18.0/odoo/tools/func.py", line 97, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 129, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 523, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/src/odoo/18.0/odoo/modules/migration.py", line 222, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
File "/home/odoo/src/odoo/18.0/odoo/modules/migration.py", line 259, in exec_script
mod.migrate(cr, installed_version)
File "/home/odoo/src/odoo/18.0/addons/l10n_mx/migrations/2.2/end-migrate.py", line 7, in migrate
env['account.chart.template'].try_loading('mx', company, force_create=False)
File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 160, in try_loading
return self._load(template_code, company, install_demo, force_create)
File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 228, in _load
self._post_load_data(template_code, company, template_data)
File "/home/odoo/src/enterprise/18.0/account_reports/models/chart_template.py", line 10, in _post_load_data
super()._post_load_data(template_code, company, template_data)
File "/home/odoo/src/odoo/18.0/addons/stock_account/models/account_chart_template.py", line 12, in _post_load_data
super()._post_load_data(template_code, company, template_data)
File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 681, in _post_load_data
self._setup_utility_bank_accounts(template_code, company, template_data)
File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 874, in _setup_utility_bank_accounts
self.env['account.account']._load_records([
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5503, in _load_records
data['record']._load_records_write(data['values'])
File "/home/odoo/src/odoo/18.0/addons/account/models/account_account.py", line 1103, in _load_records_write
super()._load_records_write(values)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5421, in _load_records_write
self.write(values)
File "/home/odoo/src/odoo/18.0/addons/account/models/account_account.py", line 1036, in write
res = super(AccountAccount, self.with_context(defer_account_code_checks=True, prefetch_fields=not any(field in vals for field in ['code', 'account_type']))).write(vals)
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 343, in write
return super(MailThread, self).write(values)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4830, in write
real_recs._validate_fields(vals, inverse_fields)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 1631, in _validate_fields
check(self)
File "/home/odoo/src/odoo/18.0/addons/account/models/account_account.py", line 42, in _check_account_type_unique_current_year_earning
raise ValidationError(_('You cannot have more than one account with "Current Year Earnings" as type. (accounts: %s)', [a.code for a in account_unaffected_earnings]))
odoo.exceptions.ValidationError: You cannot have more than one account with "Current Year Earnings" as type. (accounts: [False, False])
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#231708Documentation and clarification updates
This change adds Raj Gohel’s individual contributor license agreement to Odoo’s records. It is an administrative update that helps confirm the legal permissions needed for contributions, with no effect on product features or users.
Original PR description
I am signing the Odoo Individual Contributor License Agreement. This PR adds my CLA entry to the list of individual contributors. Signed, Raj Gohel rajgohel2018@gmail.com GitHub: https://github.com/Rajgohel0312
This change updates Vauxoo’s contributor agreement record to include Jonathan Osorio Alcala as an approved contributor. It is an administrative/legal update that helps keep contributor records current and compliant.
Original PR description
Incorporate Jonathan Osorio Alcala (jonathanosalc) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235181