Daily updates from Odoo
Tuesday, July 22, 2025
71 changes
25 changes
Resolved issues and error corrections
Sales orders with multiple make-to-order purchased products now continue processing even if one product has no vendor configured. The product without a vendor falls back to stock fulfillment and responsible users are notified, while purchase orders for correctly configured products are still created.
Original PR description
Bug introduced in: https://github.com/odoo/odoo/commit/eb26262f17cf0c828e8fdf03a8e2f916e3619d81
Steps to reproduce the bug:
- Create two storable products:
- P1:
- Routes: Make To Order (MTO) + Buy - Vendor: Azure Interior
- P2:
- Routes: Make To Order (MTO) + Buy
- No vendor defined
- Create a sales order with one unit of P1 and one unit of P2
- Confirm the SO
Problem:
The stock move for P2 is created with the procurement method Make To
Stock (MTS), while P1 uses Make To Order. but the purchase order for P1
is not created, because When processing P2 the `run_buy`, a return
occurs and function is stopped instead of continuing to process
the other moves/flow.
Solution:
Ensure that the absence of a vendor for MTO+Buy products only causes a fallback to MTS and notify responsible, without breaking the processing of other moves.
opw-4945468
Forward-Port-Of: odoo/odoo#219302Italian electronic invoices will no longer include references to related documents dated after the current document. This prevents SDI rejections caused by invalid future-dated invoice links, improving reliability for Italian invoicing workflows.
Original PR description
In a FatturaElettronica xml document <DatiFattureCollegate> allow us to specify any references to other previously sent documents. However, it is currently possible that the system populate this element with moves dated after the current document, causing the SDI to reject the document. Steps to reproduce: - Create an invoice A and register a full payment via the button - Create a credit note for the invoice, unreconcile the credit note if necessary - Create a new invoice B and add the credit note as payment - Create the XML of the credit note Issue: The XML includes info about invoice B, created after the credit note. If invoice B is dated after the credit note, the SDI will reject the xml Solution: Avoid including reconciled elements with date later than the current document date opw-4795664 Forward-Port-Of: odoo/odoo#219646 Forward-Port-Of: odoo/odoo#219106
This fixes an issue in Point of Sale where searching while a product category was selected could make the screen go blank. Cashiers can now filter by category and search products without interrupting sales operations.
Original PR description
This commit https://github.com/odoo/odoo/pull/217898/commits/9b1477f2693fb0678ca073d36ad6630c3034df00 introduced a bug where, when the user had a category selected and he would type a word in the search bar, he would have a white screen. This is fixed by reverting the change that was doing it and was not necessary. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219311
Messages received while the Discuss app is open no longer create chat bubbles that appear later after leaving Discuss. Users still receive notifications, while live chat conversations continue to show bubbles as expected.
Original PR description
**Current behavior before PR:** Receiving a new message while the Discuss app is open creates a chat bubble in the background. These bubbles become visible after leaving the Discuss app. **Desired behavior after PR is merged:** Chat bubbles are no longer created while the Discuss app is open, except for livechat messages. Messages still trigger notifications, but no background bubbles are inserted. task-[4752392](https://www.odoo.com/odoo/project/1519/tasks/4752392) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219806 Forward-Port-Of: odoo/odoo#215125
This fix makes an automated test for the messaging connection warning more reliable by shortening simulated reconnection timing during the test. It helps prevent false test failures in busy environments without changing the user-facing behavior of the product.
Original PR description
The "show warning when bus connection encounters issues" test simulates a disconnected WebSocket that fails to reconnect. In this scenario, an alert is shown to warn the user that some features may…
The "show warning when bus connection encounters issues" test simulates a disconnected WebSocket that fails to reconnect. In this scenario, an alert is shown to warn the user that some features may be unavailable or slow. However, the websocket worker’s initial reconnect delay is 1.5s, with an added random jitter up to 1 second which means the first reconnect attempt can take up to 2.5s. The test waits up to 2.5s for the alert to show, which is not always enough. The reconnect attempt alone may be that long, and under high CPU load, processing the resulting event can take even longer. This commit reduces the initial reconnect delay and the jitter during this test, ensuring that the reconnect attempt fails and the alert is shown within the expected time. fixes runbot-226443 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#219649
This fix ensures purchase orders that were manually locked can be unlocked even when the automatic 'Lock Confirmed Orders' setting is not enabled. It prevents users from getting stuck with locked purchase orders after customizing the interface or using Studio.
Original PR description
Steps to reproduce the bug: - Do not enable the “Lock Confirmed Orders” setting. - Create a Purchase Order: - Add any product. - Confirm the PO. Problem: The `Lock` button is not visible. Starting from version 18.3, users must enable the setting, and all POs are locked automatically: [Commit reference](https://github.com/odoo/odoo/commit/63bfd81dfdec9ef2d928aed439bb7b97841e76d7) However, a user can edit the view or use Studio to manually display the Lock button and lock the PO. But when attempting to unlock it, an error is triggered: > “Unlocking the order is not allowed as 'Lock Confirmed Orders' is enabled.” **opw-4948226** Forward-Port-Of: odoo/odoo#219463
The task dependency list now shows task priority correctly in the Blocked by tab. The priority column is hidden by default to keep the view focused on key details like status, task name, and assignees.
Original PR description
Before this commit, the priority field of project.task was not correctly rendered inside the sub-list view of task dependencies (in "Blocked by" tab in task form view). This commit makes sure the priority field of project.task is correctly in that sub-list view. Also, it also hides by default the column to let more spaces for the most relevant fields (state, name and assignees). Forward-Port-Of: odoo/odoo#219706
French electronic invoices sent through Peppol now use the correct identifier field in BIS Billing 3.0 XML. This helps prevent invoice rejection due to invalid XML formatting when using Chorus Pro/Factur-X with French SIRET identifiers.
Original PR description
### Issue: BIS3 XML is not valid for Peppol ### Steps to reproduce: - Install l10n_fr_facturx_chorus_pro and switch to french company - Activate peppol - Create a French customer - Under Sales and…
### Issue: BIS3 XML is not valid for Peppol ### Steps to reproduce: - Install l10n_fr_facturx_chorus_pro and switch to french company - Activate peppol - Create a French customer - Under Sales and Purchase tab, set SIRET to "11000201100044" - Under Accounting tab, set the following: - Invoice sending = Peppol - Einvoice format = BIS Billing 3.0 - peppol_eas = France SIRET - peppol endpoint = 11000201100044 - Use Invoice/Invoiced smart button, then select New to create an invoice for this french customer - Add any non-zero invoice line, then confirm - Send and print, send to peppol - Download the XML. The /PartyIdentification/ID element will have the schemeName attribute set. ### Cause: Previous [commit](https://github.com/odoo/odoo/commit/0f3a9dee5cf15fa978a1857c184413003147c4a6#diff-10c62c279423109c43458eab15a3177ff5592d6570451f890fead74389bc3740) added `schemeName`. But Peppol doesn't want any `schemeName`, see the [doc](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/UBL-DT-08/). ### Solution: The correct attribute here seems to be `schemeID`. See an [example from the docs of Peppol](https://docs.peppol.eu/poacc/billing/3.0/bis/#_parties_2). Change `schemeName` to `schemeID`. opw-4934436 Forward-Port-Of: odoo/odoo#219586 Forward-Port-Of: odoo/odoo#219012
Reinstalling the Amazon sales connector on databases with many past Amazon sale lines could run out of memory. This change limits the data loaded during setup, reducing peak memory use and making reinstalls more reliable for affected customers.
Original PR description
Description ----------- On databases that had `sale_amazon` installed in the past, were used for sales for a certain period, then had the module uninstalled, and later attempted to re-install it, a…
Description ----------- On databases that had `sale_amazon` installed in the past, were used for sales for a certain period, then had the module uninstalled, and later attempted to re-install it, a memory error will occur. The peak memory usage stems from `sale.order.line._compute_is_service`. The reason the compute is triggered is because of the "re-creation" of the master data products `default_product` & `shipping_product`, which writes `type`, which the compute depends on. So the compute will be triggered for all `sale.order.line` records that had those products. This commit avoids the excessive memory usage by explicitly fetching the fields that are needed for the compute, which avoids fetching large fields like the different products' HTML descriptions. Benchmark --------- On a database with 400k+ `sale.order.line` with an amazon related product, installing `sale_amazon` peak memory usage was: | | Peak Mem. | |--------|-----------| | Before | 3.8 GiB | | After | 580 MiB | Reference --------- opw-4915892 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219599
Vendor bills using the Saudi 15% reverse charge tax now create the expected reverse charge accounting entry. This ensures the tax amount is reflected in the correct account and appears properly on VAT filing reports.
Original PR description
Steps to reproduce: - With a SA Company setup - Create a Vendor Bill - Add a Service product and apply 15% R C tax - Confirm Issue: The reverse charge account is not hit by the tax amount, no reverse charge entry is created and it does not show on the VAT filling report opw-4755993 Forward-Port-Of: odoo/odoo#219135 Forward-Port-Of: odoo/odoo#217384
Fixes an issue in the HTML editor where pressing backspace after an emptied file attachment box could delete both the box and the preceding character. This helps users edit content with attached files more safely and prevents unintended text loss.
Original PR description
Problem: When pressing backspace after text followed by an `o_file_box`, both the last character and the file box are deleted at once. Cause: An empty `o_file_box` is skipped in `findPosition` because it's treated like a zero-width space (`.textContent === "\ufeef"`), causing incorrect position resolution. Solution: `o_file_box` elements should not be skipped during position checks, even when empty. Steps to reproduce: - Go to Quality ---> Quality Control --> Control Points - Create New. - Add text - Add a file just after the text - Delete all content of the file box - Place the cursor after the file box and press backspace -> The character before the file box is also deleted opw-4903841 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219358 Forward-Port-Of: odoo/odoo#216559
This update fixes an intermittent failure in an automated website editor test by making the test wait for background requests to finish before continuing. It helps keep validation runs stable and reduces false failures during quality checks.
Original PR description
This commit fix the tour `test_restricted_editor_only` which was failing on runbot. runbot-226535
This fix ensures message updates in Discuss, Mail, and Live Chat are applied in the right order even when background notifications are delayed. Users are less likely to see old message content return after editing, improving reliability in busy or slow environments.
Original PR description
Before this commit, discuss RPCs like update_content were prone to race-condition that can lead to UI showing outdated content of a message that was just edited. This happens because some store data…
Before this commit, discuss RPCs like update_content were prone to race-condition that can lead to UI showing outdated content of a message that was just edited. This happens because some store data are exclusively feed from return data of RPC whereas some store data are feed from bus notifications. Ordering of data are essentially sound among RPC returns and bus notifications, but not between the 2 groups. Therefore RPC return or bus notifications can come before or after the other one, and the ordering may be wrong and result in wrong store data. In practice bus notifications usually before return of RPCs. Most of discuss code is robust against this ordering, even though there's likely many potential of race conditions that may happen and are genuine bugs. When bus notifications come after returned RPCs, however, problems are more apparent. This may happen when the bus notification queue is slow, but also in tests this is likely to happen because RPCs are simulated with single micro-tick whereas handling of bus notification is usually more than 1 micro-tick. The test "Can edit message comment in chatter" is showing this problem: it's a relatively long test that interacts a lot with message edition, which has the message content being obtained from both bus notifications and RPC returns. When the CPU load is high, test takes much more time to run, e.g. 400ms becomes 2500ms. This CPU load affects barely RPC returns but bus notifications are heavily throttled and therefore causes bus notifications to come much later than expected. Test edits message twice with different content and then once without any change. The high CPU load can make test fail after 3rd edit step because the content of message is the 1st edited content instead of the last. The last edition is coming later in the bus notification, but due to timing constraints of 3 seconds assertion can lead to timeout of test because the message is not showing the most recent edited content. Roughly: 1. message is "original message" 2. message is edited to "edited message" 3. message shows "edited message (edited)" 4. message is edited to "edited again" 5. message shows "edited again (edited)" 6. message editing is started => message content in composer is "edited message" instead of "edited again", so crash after 3 seconds Step 6 fails because message content between 5 and 6 is changed to "edited message" from the bus notification. All previous steps had the message edited relatively quickly (500ms each) by returned RPC. The bus notifications are throttled to about 3 seconds, thus the "edited message" bus notification arrived very late when starting edition in step 5. The composer content is wrong and the contains wait for at least 3 seconds, but due to heavy throttle of bus notifications from CPU load, the test fails. This commit fixes the issue by introducing a `busRpc()` function on bus_service and have message edition flow use this busRpc() rather than `rpc()`. This `busRpc()` function is a special flavour of `rpc()` that awaits until the RPC and related notifications have been received. `busRPC()` works by forging a UUID bus_rpc_uuid that the RPC sends back at end of RPC. The `busRPC()` function waits until this notification is received.s This commit ensures ordering of store data received from server is good, because RPC properly awaits bus notification. Store data of RPC return makes sense after these bus notifications, but ideally it should also be sent to bus notification and business code should ignore returned data from RPC, so that ordering of store data is always good even with interleaving if discuss actions. This also solves the race condition in the test "Can edit message comment in chatter", because each assertion of message content ensures we are in the window of data feed by related bus notifications. When a message is being edited the composer is not affected by new message content from store data of bus notifications, but the save of the message edition should necessarily have to await related bus notifications, ensuring no previous bus notifications can be feed after this store data state. Fixes runbot 227618 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 reverts a previous accounting update that caused problems when validating transactions using mandatory analytic information. It restores the prior behavior to prevent errors for users working with expense accounts and analytic plans.
Original PR description
This reverts commit 8194c6e2bfedc9437964090b1a498c3e8cff225c. opw-4936028 opw-4933629 opw-4935236 opw-4933456 opw-4933652 opw-4935789 opw-4938570 opw-4938388 opw-4935709 opw-4940233 opw-4938849 Forward-Port-Of: odoo/odoo#218833
Expense approval activities are now assigned to the manager chosen on the expense, rather than automatically going to the employee's default manager. This helps ensure the right person is notified and can act on expense submissions without delays or misrouting.
Original PR description
When an expense is submited and you've selected a different manager than the default one, this is not the right person that gets the activity linked to the expense. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213162
The automatic invoice sending scheduled job now reports how many invoices it has processed and how many remain. This avoids misleading status messages that previously suggested no records were processed, making monitoring more reliable for administrators.
Original PR description
The scheduled action for the automatic sending of invoices currently does not explictly use the `_notify_progress` method introduced since Odoo 18 to track the progress of CRON jobs. This means that implicitly, by default the CRON will log `processed 0 records, 0 records remaining` at each run. This can be confusing, as the automatic invoice sending CRON is batched, and might run multiple times in sucession, reporting each time that it processed 0 records (which might not be true). ## Proposed fix: We correctly count the total account moves that need to be processed (using a `search_count`) and calculate the number of processed records and the remaining ones. opw-4926541 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218763
The live chat test now uses a dedicated user instead of the demo user, preventing other demo data from changing the expected email address. This keeps nightly demo builds stable and reduces false test failures without changing customer-facing behavior.
Original PR description
This commit fixes a failing test in the nightly "With Demo" build. The test fails because it checks the email of the demo user, which is overridden by the demo data from another module. This commit fixes the issue by making the test run with a different user than the demo user, so that the email remains predictable. fixes runbot-229925 Forward-Port-Of: odoo/odoo#219421
This fix makes automated website tours more reliable when they move to a different page. It helps prevent inconsistent test behavior caused by page unload events, reducing false failures during quality checks.
Original PR description
In this commit, we add expectUloadPage to goToUrl util. This util redirect to another page an involves a unload event so we need to add this key to this util to avoid undeterministic behaviors in tours that use it. 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#219672
Fixed an issue where shops using an UrbanPiper payment method could become unable to close their point-of-sale session after completing an order. The closing screen now avoids duplicate payment method entries, preventing the session from getting stuck and helping staff finish end-of-day operations normally.
Original PR description
Currently if setting a urban piper payment method on a shop and using it at checkout will not allow you to close the session. Steps to reproduce: ------------------- * Go in the setting and set up…
Currently if setting a urban piper payment method on a shop and using it at checkout will not allow you to close the session. Steps to reproduce: ------------------- * Go in the setting and set up urban piper (no need for credentials) testing with random keys will do * Go into the payment methods and take one of the urban piper one and assign it to a shop * Open that shop * Place an order and use the urban piper payment method * Validate * Try closing the session > Observation: Nothing happen, we're now unable to select the menu. If doing the same steps but in debug mode, a traceback is shown indicating a duplicate key in a t-foreach Why the fix: ------------ The duplicate key is happening when rendering the closing popup because the function `get_closing_control_data()` was returning twice the information related to the urban piper payment method. Even though urban piper wasn't build with the use case in mind we want to keep it possible. We avoid sending twice the urban piper methods if they were already computed in the super method. opw-4874699 Forward-Port-Of: odoo/enterprise#90427 Forward-Port-Of: odoo/enterprise#88156
This fixes an issue where Belgian POS settings did not correctly limit IoT device choices to blackbox devices. The change helps businesses configure compliant fiscal devices more reliably and avoids showing irrelevant hardware options.
Original PR description
The domain to display only blackboxes in the IoT devices configuration on pos.config was a string, so not correctly passed to res.config.settings in the related field. This commit fixes this issue by computing the domain with a lambda method.
Fixes an error that occurred when website editors chose specific appointment types for an Appointment Button. Selected appointment types now display their names correctly, making the setup flow reliable and easier to understand.
Original PR description
Since [1], the conversion of actions to classes introduced a forgotten shared function, leading to a traceback when specifying appointment types under the "Appointments" option. Additionally, this commit corrects the missing `display_name` in `SetAppTypesAction`. Previously, this omission caused the selected appointment types to appear empty without a name in the UI. Steps to reproduce: - Drop "Appointment Button" - Change "Appointments" option to "Specific Types" - Click on "Specify" option and choose any record from the list - Traceback occurs [1]: https://github.com/odoo/enterprise/commit/1f8b599a23330b03bffd898d85fe74a0f0eeda1f
Project profitability now includes budget lines even when their analytic account belongs to a different analytic plan than the project's main plan. This prevents valid budget information from being hidden after analytic account setup changes or upgrades, giving users a more accurate profitability view.
Original PR description
In version 17.3, the analytic mixin was introduced in budget.line model to allow to link a budget line to multiple analytic accounts belonging to different analytic plans. The issue is that we have…
In version 17.3, the analytic mixin was introduced in budget.line model to allow to link a budget line to multiple analytic accounts belonging to different analytic plans. The issue is that we have not adapted the code in project profitability, to take those changes into account. A problematic situation could be the following: 1. We have a project where the account "X" is set to the main project plan (the first one) "Projects" BUT the account "X" actually belongs to the analytic plan "Departments" (yes, it's possible that there is a mismatch between the project plan and the analytic plan, especially after the 18.0 upgrade where "analytic_account_id" just became "account_id", no matter in which plan it was). 2. We have a budget line linked to the account "X" for the plan "Departments". 3. We want to display the budget lines in project profitability, but this line does not appear. That's because we currently only look for the budget lines belonging to the analytic plan "Projects" aka the main/first plan, that match the account "X" of the project. But as account "X" actually belongs to the analytic plan "Departments", no budget lines are found. task-4901400 version-18.0 Forward-Port-Of: odoo/enterprise#88658
Users who process invoices can now use the Reload AI Data button without needing administrator settings access. This prevents an error during invoice AI data refreshes and keeps the workflow available to functional accounting users.
Original PR description
When clicking on the "Reload AI Data" button (`account.move::action_reload_ai_data`), a user not in `base.group_system` group encounters an access rights error when searching on `ir.module.module` model in `account.move::is_indian_taxes()`:
```python
def is_indian_taxes(self):
l10n_in = self.env['ir.module.module'].search([('name', '=', 'l10n_in')])
return self.company_id.country_id.code == "IN" and l10n_in and l10n_in.state == 'installed'
```
This commit adds `sudo()` to the `search` call to ensure that the check for the 'l10n_in' module does not fail for users not belonging to "Administration/Settings" group.
This prevents a traceback and ensures that functional users can reload AI data.
Forward-Port-Of: odoo/enterprise#90021Fixed an issue that could cause spreadsheets to crash when users autofilled pivot columns that were themselves created through autofill, especially with dates beyond the original range. This makes spreadsheet pivot editing more reliable and helps users continue their analysis without interruption.
Original PR description
Fix crash when autofilling columns which where created by autofill. Task: 4719884 Forward-Port-Of: odoo/enterprise#90462 Forward-Port-Of: odoo/enterprise#83314
The Brazil AvaTax integration now handles tax provider error responses gracefully instead of failing unexpectedly. This reduces disruption when external tax calculations return errors and removes leftover debugging output.
Original PR description
Oversight of odoo/enterprise#82623. There won't be a 'lines' key in the response if the API returned errors. This also removes a logger meant for debugging. Noticed by VBE during review of odoo/enterprise#90156.
12 changes
Resolved issues and error corrections
Users without administration settings access can now use the Reload AI Data action on invoices without hitting an access error. This keeps invoice AI data refresh available to functional users and avoids an unexpected failure during their workflow.
Original PR description
When clicking on the "Reload AI Data" button (`account.move::action_reload_ai_data`), a user not in `base.group_system` group encounters an access rights error when searching on `ir.module.module` model in `account.move::is_indian_taxes()`:
```python
def is_indian_taxes(self):
l10n_in = self.env['ir.module.module'].search([('name', '=', 'l10n_in')])
return self.company_id.country_id.code == "IN" and l10n_in and l10n_in.state == 'installed'
```
This commit adds `sudo()` to the `search` call to ensure that the check for the 'l10n_in' module does not fail for users not belonging to "Administration/Settings" group.
This prevents a traceback and ensures that functional users can reload AI data.
Forward-Port-Of: odoo/enterprise#90021This fix ensures products already scanned from different locations keep their original source locations when an empty destination package is scanned. It helps warehouse teams avoid inaccurate picking records while still assigning all relevant items to the correct package.
Original PR description
Issue ===== When a package is scanned as the destination package, if a source location was previously scanned, the source location will be updated for every product who will be packed. How to…
Issue ===== When a package is scanned as the destination package, if a source location was previously scanned, the source location will be updated for every product who will be packed. How to reproduce ================ - Enable multi-locations and package; - Create an empty package, two locations and two products; - Create a delivery in the Barcode app; - Scan the first location then the first product; - Scan the second location then the second product; - Scan the empty package -> The package is rightly assigned as the result package for both lines, but the source location of the first product was update for the last scanned source location. Cause of the issue ================== When a source location was previously scanned, when a line is updated (`updateLine`), we update the line's source location. Usually, that's the wanted behavior but in this case, we don't want to the source location of already processed lines when we scan a destination package. Solution ======== When calling `updateLine` from `_assignEmptyPackage`, give a key in the parameters to not update the source location. [opw-4859851](https://www.odoo.com/odoo/project.task/4859851) Forward-Port-Of: odoo/enterprise#90091 Forward-Port-Of: odoo/enterprise#89142
This update adds missing internal labels to automated tests so they are recognized correctly by the test system. It helps keep quality checks reliable without changing customer-facing helpdesk or subscription behavior.
Original PR description
With the new test-tags features that allows to add additional test tags at runtime, the tests that starts a tour or that are using a query_count and that are not detected as such must be tagged respectively `is_tour` or `is_query_count`. Forward-Port-Of: odoo/enterprise#90152 Forward-Port-Of: odoo/enterprise#89934
This fixes a point of sale restaurant booking issue where the date filter stayed active after users switched away from the kanban view. The filter is now properly removed or updated, preventing stale booking results and reducing confusion for staff.
Original PR description
Steps to reproduce: - Open booking in a pos restaurant - Switch from kanban view to any other view - The filter on the date is not removed Issue: The onRemove method in the kanban_controller is never called. Fix: It is not possible to call the code an onWillUmount since onWillUmount is called after the onMount of the desired view. The deletion of the filter needs to be handled in the control_panel. Also each time createStartFilter was called, a new filter was added and never removed. In this commit if a filter already exists it is simply updated. Task-4916512
Fixes an issue where loans could fail when being cancelled, reset to draft, and confirmed again while Accounting Audit Trail is enabled. This helps accounting teams manage loan records reliably without encountering an unexpected error from previously posted entries.
Original PR description
Steps: - Activate Audit Trail in Accounting configuration - Create and confirm a loan, having some moves posted in the past - Cancel it, reset it to draft the re-confirm it again -> ValueError: Expected singleton This is because posted moves can not be unlinked when canceling/closing the loan if audit trail is activated. Therefore we try to access the `state` field from a recordset instead of a singleton. With this commit, we filter the generated move to get the newly created one. opw-4834361 Forward-Port-Of: odoo/enterprise#88286
This fix ensures asset setup only updates accounts that already exist. It prevents the system from accidentally creating incomplete account records during installation or setup, keeping accounting data cleaner and more reliable.
Original PR description
In the post init hook for account_asset we are updating the chart accounts to add the asset models, and then we load those assets. The update should only be performed on accounts that already exist, otherwise the load will create empty account records with all values null except the assets, which is not the intention here. This fix filters the update to existing accounts only, and filters the asset that use those accounts. [ci error](https://runbot.odoo.com/odoo/runbot.build.error/229788)
Project profitability now includes budget lines even when a project's analytic account belongs to a different analytic plan than expected. This prevents valid budget information from being hidden after analytic account migrations or plan mismatches, giving users a more complete profitability view.
Original PR description
In version 17.3, the analytic mixin was introduced in budget.line model to allow to link a budget line to multiple analytic accounts belonging to different analytic plans. The issue is that we have…
In version 17.3, the analytic mixin was introduced in budget.line model to allow to link a budget line to multiple analytic accounts belonging to different analytic plans. The issue is that we have not adapted the code in project profitability, to take those changes into account. A problematic situation could be the following: 1. We have a project where the account "X" is set to the main project plan (the first one) "Projects" BUT the account "X" actually belongs to the analytic plan "Departments" (yes, it's possible that there is a mismatch between the project plan and the analytic plan, especially after the 18.0 upgrade where "analytic_account_id" just became "account_id", no matter in which plan it was). 2. We have a budget line linked to the account "X" for the plan "Departments". 3. We want to display the budget lines in project profitability, but this line does not appear. That's because we currently only look for the budget lines belonging to the analytic plan "Projects" aka the main/first plan, that match the account "X" of the project. But as account "X" actually belongs to the analytic plan "Departments", no budget lines are found. task-4901400 version-18.0 Forward-Port-Of: odoo/enterprise#88658
Bank statement reconciliation has been optimized to run much faster on very large accounting databases, reducing the risk of slow imports or timeouts. This improves day-to-day accounting workflows, especially when importing statement files with many lines.
Original PR description
[FIX] account_accountant: refactor and optimize _try_auto_reconcile_statement_lines() In big databases, this method called on large recordsets of statement lines would take too much time, or worse:…
[FIX] account_accountant: refactor and optimize _try_auto_reconcile_statement_lines() In big databases, this method called on large recordsets of statement lines would take too much time, or worse: timeout. This is mainly because the 2 SQL queries are doing too complex searches and hence are badly optimized by the query planner. To solve that, * We search for reconciliable accounts outside the queries to avoid a join * We add a trigram index on statement_line.payment_ref and only use ILIKE operations for reference matching so that it can be used * Instead of using complex and costly regexp_split, we search for matches by splitting account_move_line.ref on ' - ' * We move some logic in python, amount matching, rather than in sql * We don't try anymore to match on amounts found in the payment_ref Additionnally, * The algorithm now treats the statement lines with and without partner the same for reference matching, but lines without partner are just ignored for the amount matching, as it's way too dangerous * Bug of with_prefetch, pre-loading the ids of a wrong object, has been fixed * We revert the patch https://github.com/odoo-dev/enterprise/commit/da52bc70cd745f3e9f7a0539528c84aa47b98cc5 because it was only a temporary measure while the time was back to acceptable * The test_matching_rules_with_empty_aml_ref, irrelevant, was removed Benchmark --------- Importing a csv file of 200 statement lines, on a database of 21M account.move.line, and thus triggering the culprit function, takes (hot timings): | Before | After | Speed-up | |--------|-------|----------| | 185 s | 52 s | ~3.5x | see https://github.com/odoo/odoo/pull/218642
Manufacturing orders created from Barcode now generate all required stock transfers when multi-step manufacturing is enabled, including picking components and storing finished products. This prevents missing warehouse movements and ensures by-products are correctly linked to the manufacturing order.
Original PR description
Task: 4558792 If 3-step manufacturing is enabled, the creation of an MO should also create 2 stock transfers: "Pick Components" and "Store Finished Product". Currently, when an MO is created via Barcode, only SFP is created. The problem boils down to the newly created stock move not having a `warehouse_id` field set, which causes Odoo to miss the required stock rules. This PR fixes the issue by fetching the `warehouse_id` field in XML, from where it is later passed to JS and back to Python's `create` method. Additionally, by-product moves for MOs created via Barcode were not correctly associated with the MO. This issue was solved by passing the missing fields from XML to Python. Forward-Port-Of: odoo/enterprise#90370 Forward-Port-Of: odoo/enterprise#83895
The AI assistant now avoids sending the same user question twice when preparing a response. This helps produce cleaner, more accurate replies and reduces unnecessary AI processing.
Original PR description
Prior to this commit, we send messages to the llm like the following:
```
[
{'content': Markup('<p>first question</p>'), 'role': 'user'},
{'content': Markup("<p>Sure, I'm here to help. What's your first question?</p>"), 'role': 'assistant'},
{'content': Markup('<p>second question</p>'), 'role': 'user'},
{'role': 'system', 'content': "You are a RAG assistant.\n\nToday's date to be used: 2025-07-18"},
{'role': 'user', 'content': 'second question'}
]
```
We're actually duplicating the user's prompt and this is because of the retrieval of the chat history. Before calling generate_response, we post the user's message. Therefore, he's message is already recorded in the db. We should then skip the most recent message to assemble the chat history since its just the same to the prompt.Fixed an issue that could prevent a point-of-sale session from closing after an Urban Piper payment method was used. The closing screen now avoids duplicate payment method entries, so staff can complete end-of-day closing normally.
Original PR description
Currently if setting a urban piper payment method on a shop and using it at checkout will not allow you to close the session. Steps to reproduce: ------------------- * Go in the setting and set up…
Currently if setting a urban piper payment method on a shop and using it at checkout will not allow you to close the session. Steps to reproduce: ------------------- * Go in the setting and set up urban piper (no need for credentials) testing with random keys will do * Go into the payment methods and take one of the urban piper one and assign it to a shop * Open that shop * Place an order and use the urban piper payment method * Validate * Try closing the session > Observation: Nothing happen, we're now unable to select the menu. If doing the same steps but in debug mode, a traceback is shown indicating a duplicate key in a t-foreach Why the fix: ------------ The duplicate key is happening when rendering the closing popup because the function `get_closing_control_data()` was returning twice the information related to the urban piper payment method. Even though urban piper wasn't build with the use case in mind we want to keep it possible. We avoid sending twice the urban piper methods if they were already computed in the super method. opw-4874699 Forward-Port-Of: odoo/enterprise#90427 Forward-Port-Of: odoo/enterprise#88156
This update simplifies an automated check for signing documents through the customer portal by removing a fragile step tied to another app. It helps reduce false test failures, supporting more reliable releases without changing the signing experience for users.
Original PR description
We remove the last step, which depends on the mail module and is too complex. The reason for this step was to avoid a failed to fetch received after termination. This problem must be solved in another way. runbot-error-id~163605 Forward-Port-Of: odoo/enterprise#84480
8 changes
Resolved issues and error corrections
Fixed an issue that could prevent project task overlap checks from correctly handling filters based on related task information. This helps ensure planning conflicts are detected accurately and reduces the risk of missed scheduling issues.
Original PR description
The query that determines overlapping tasks is making two different Query objects: the first one for the main task and the second one for overlapping tasks. The second query is joined into the first one, injecting the second one's where clause as join condition, but that composition does not work if the second query has extra joins. Those extra joins come from related fields that may occur from the domain. The fix consists in recomposing the query with a join condition that does not depend on a dynamic domain, and injecting the domain in the where clause of the main query. With this strategy, the joins that appear because of the related fields in the domain are part of the main query, and are no longer lost by the composition. Note also that the test test_same_user_overlap_with_allocated_hours_less_than_workable_hours was actually broken, because the field allocated_hours wasn't flushed when doing the SQL query. The new query flushes the field, and the test has been fixed.
This fix makes Odoo more stable when working with newly created records before they are saved. It prevents errors during automatic field updates and display-name calculations, reducing interruptions in workflows such as field service reporting and Belgian tax reporting.
AI-generated values for HTML fields now keep the same formatting regardless of optional conversion tools installed on the system. This prevents inconsistent output and resolves related automated test failures, improving reliability for teams using AI fields.
Original PR description
Purpose: ------- After the changes introduced in commit e6438de, depending on if markdown2 is installed or not, ai values for html fields did not have the same format (a trailing "\n" was added with markdown2). This commit removes the unnecessary "\n" added by markdown2. Fixes runbot errors 230097 and 230098
Users with view-only access to shared PDF documents no longer see the split PDF option. This prevents them from running an action they are not allowed to complete, avoiding a confusing error and improving the document sharing experience.
Original PR description
When a user with only view permissions attempts to split a PDF, an error occurs: Unexpected token '<', "<!doctype "... is not valid JSON **Steps to Reproduce:** - Go to Documents. - Choose a PDF file. - Click on Share and select Internal Users with Viewer permission. - Copy the generated link. - Open the link in another window as a non-manager user. - Click on split PDF then split The fix consists in hiding the pdf split functionality for users without edit permission. opw-4354451 Forward-Port-Of: odoo/enterprise#89764 Forward-Port-Of: odoo/enterprise#75803
This change fixes an access problem that could prevent users from using the salary configurator correctly. It removes an unnecessary company-related recalculation that was causing permissions issues, while keeping company filtering already handled elsewhere.
Original PR description
Since this commit: https://github.com/odoo/enterprise/commit/b68569868c00765bca910b5630a72db75347c03d, the salary configurator had an access issue on hr.job model. This is due to the compute method on company_id introduced in the previous commit. As the properties definition field of the hr_job is defined on the company, it was recomputed every time the company commute is triggered. Additionnaly, this compute on the company_id is useless as the domain on the contract_template_id is already filetered based on the company. A test for this is added in this PR: https://github.com/odoo/enterprise/pull/90412 task-4951648
This fixes a configuration issue in Swiss payroll ELM transmission by removing an inappropriate default value from a linked setting. It helps ensure payroll transmission settings reflect the company configuration correctly and avoids misleading preset values.
Original PR description
…lated field Forward-Port-Of: odoo/enterprise#90490 Forward-Port-Of: odoo/enterprise#90425
When a report is opened in Studio without an existing template, the system now automatically creates the standard views it needs. This prevents crashes and lets users continue editing reports created from the technical menu.
Users without administrator settings access can now use the Reload AI Data button on invoices without hitting an access error. This keeps AI-powered invoice processing available to functional users while preserving the existing tax localization check.
Original PR description
When clicking on the "Reload AI Data" button (`account.move::action_reload_ai_data`), a user not in `base.group_system` group encounters an access rights error when searching on `ir.module.module` model in `account.move::is_indian_taxes()`:
```python
def is_indian_taxes(self):
l10n_in = self.env['ir.module.module'].search([('name', '=', 'l10n_in')])
return self.company_id.country_id.code == "IN" and l10n_in and l10n_in.state == 'installed'
```
This commit adds `sudo()` to the `search` call to ensure that the check for the 'l10n_in' module does not fail for users not belonging to "Administration/Settings" group.
This prevents a traceback and ensures that functional users can reload AI data.
Forward-Port-Of: odoo/enterprise#9002126 changes
Resolved issues and error corrections
The Today filter in Timesheets and the Attendance report now correctly limits results to records from the current day. This helps users rely on daily time and attendance views without seeing records from other dates.
Original PR description
In this bug, the today filter in timesheet is not written correctly. To reproduce the bug: 1- Create a db with timehseet installed 2- In timesheet app, and add records with different dates 3- Add Today filter 4- The filtered records are not only from today 5- The bug is also reproducible in attendance report In the fix, the filters which are used both in timesheet and report, are fixed. opw-4936780
Paid online self-ordering orders now appear correctly in the POS ticket list with the proper paid status. This prevents staff from seeing the wrong action and helps them refund paid orders instead of trying to load them again.
Original PR description
**Steps:** - Configure POS with self-ordering via QR code and online payment. - Open a session and place a paid order through self-ordering. - In the POS UI, open the TicketScreen and apply the "Paid Orders" filter. **Issues:** - The paid order does not show the "Paid" tag. - The "Load Order" button appears instead of the "Refund" button. **Cause:** - The paid order retains an outdated uiState, with `uiState.locked` incorrectly set to false. **Fix:** - Use `finalized` instead of `uiState.locked` to determine order state on TicketScreen. - Remove the unused `locked` property from `uiState` in posOrder. Task: 4745869 Related: odoo/enterprise#86684
This fix updates an automated website test so it correctly recognizes when a scroll animation has finished. It helps keep quality checks reliable and prevents false failures during website-related validation.
Original PR description
## Version 18.0+ ## Issue The tour `snippet_popup_and_animations` times out when trying to wait for the last column to become "not animated and hidden". This happens because the element never…
## Version 18.0+ ## Issue The tour `snippet_popup_and_animations` times out when trying to wait for the last column to become "not animated and hidden". This happens because the element never actually becomes `hidden` after the scroll-triggered animation ends — it remains in the DOM and visible. ## Cause Commit 7e85f88214b6b57db87a6c1964286f0b7813f6ff attempted to fix a selector that was always true by adding `:hidden`, assuming the element would be hidden once the scroll animation completed. But since the element’s visibility is never changed via `display: none` or `visibility: hidden`, the `:hidden` condition never matches, blocking the tour. ## Fix Remove the `:hidden` pseudo-class from the trigger. Instead, wait for the `.o_animating` class to be removed (indicating the end of the animation), then: - Add a short delay to ensure animation processing is complete. - Check that the element is outside of the viewport (scrolled out). - Verify that `animation-delay` is approximately 0. runbot-227077
A redundant step was removed from an automated restaurant point-of-sale test. This helps keep the validation process reliable and reduces the chance of false failures in quality checks.
Original PR description
Following this commit: ==== - Extra step was removed. runbot Error: 114352
This change restores proper scrolling on mobile screens when editing a record, such as changing a contact's country. It prevents users from getting stuck because two parts of the page were competing for scrolling, making forms easier to use on phones.
Original PR description
Steps to reproduce ================== - Use a mobile viewport - Go to contact - Open a record - Edit the contry - Try to scroll => Nothing happens Cause of the issue ================== Both the `.o_content` and the `.modal-body` are scrollable, so we need to scroll twice to go to the bottom. Solution ======== We revert https://github.com/odoo/odoo/commit/7d7aedc6149a170db2c73b1f62872bd35786c5ca opw-4851373
Tax totals are now rounded more consistently before being displayed. This prevents confusing values such as negative zero and ensures small amounts round to the expected cent, improving clarity on accounting screens.
Original PR description
The tax totals view component rounds the value we got from python (in the javascript `formatFloat` function). However, it has a few weird quirks because of how the function we're currently using (`toFixed`): - When rounding value like `-0.00000001` to 2 decimal precision, it resulted in `-0.00`, while a more sensical result would be `0.00`. - Some value are rounded incorrectly: for ex: `0.015` -> `0.01`. (it should be `0.02`) Solution- we use the appropriate rounding function separately before converting the value to string with `toFixed`. This way, `-0.001` will become just `0.00`, and `0.015` is rounded correctly to `0.02`. task-4685953
This change keeps a job application and its linked candidate assigned to the same company, reducing access errors for recruiters in multi-company setups. It also assigns website-created candidates to the job posting's company when appropriate and prevents a form warning from crashing when a page element is missing.
Original PR description
The problem: With the introduction candidate/applicant models in 18.0 a subtle bug got introduced. The core of the bug is that most of the field on an application are related/inherited from the…
The problem: With the introduction candidate/applicant models in 18.0 a subtle bug got introduced. The core of the bug is that most of the field on an application are related/inherited from the candidate of that application except company_id. This means that both models have a company_id and those are not synced. This can become an issue in a multi company issue where a candidate is assigned to company A while their application is in company B. The recruiter in company B will then get constant access errors because they don't have write permission on a record(candidate) in a different company. The fix: This PR aims to fix this by doing 2 things. 1. Every time the company on a application gets changed the company of the candidate is also updated. This still means that if the company of the candidate is manually changed we will have this issue again but there's no way around that (that can be implemented in stable). 2. Makes sure that candidates created through the website are assigned to the company of the job posting or no company, preventing a mismatch from happening. There was also trace-back happening on the job application form on odoo.com as a warning message div is missing there for some reason so I added a simple condition to check if that div exists to prevent the trace-back. task-4350838 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update keeps the company assigned to a job applicant and the related candidate aligned, reducing access errors for recruiters working across multiple companies. It also ensures candidates created from website job applications use the job posting's company when appropriate and prevents a website form warning from causing a crash.
Original PR description
The problem: With the introduction candidate/applicant models in 18.0 a subtle bug got introduced. The core of the bug is that most of the field on an application are related/inherited from the…
The problem: With the introduction candidate/applicant models in 18.0 a subtle bug got introduced. The core of the bug is that most of the field on an application are related/inherited from the candidate of that application except company_id. This means that both models have a company_id and those are not synced. This can become an issue in a multi company issue where a candidate is assigned to company A while their application is in company B. The recruiter in company B will then get constant access errors because they don't have write permission on a record(candidate) in a different company. The fix: This PR aims to fix this by doing 2 things. 1. Every time the company on a application gets changed the company of the candidate is also updated. This still means that if the company of the candidate is manually changed we will have this issue again but there's no way around that (that can be implemented in stable). 2. Makes sure that candidates created through the website are assigned to the company of the job posting or no company, preventing a mismatch from happening. There was also trace-back happening on the job application form on odoo.com as a warning message div is missing there for some reason so I added a simple condition to check if that div exists to prevent the trace-back. task-4350838 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Italian electronic credit notes now show tax amounts as negative values in the generated XML, matching refund behavior and Italian EDI requirements. This helps prevent incorrect electronic invoicing data and potential compliance issues when sending tax integrations.
Original PR description
**Issue** When generating the XML for a credit note, the <Imposta> field (tax amount) appears as a positive value, whereas it should be negative in compliance with Italian EDI standards. **Steps to…
**Issue** When generating the XML for a credit note, the <Imposta> field (tax amount) appears as a positive value, whereas it should be negative in compliance with Italian EDI standards. **Steps to Reproduce** 1. Install the Accounting module and Italian localization. 2. Create and confirm a vendor bill using a service-type product. 3. Reverse the bill into a credit note. 4. On the credit note, go to the Journal Items tab. 5. Assign tax 22% S RC and confirm. 6. Click Send Tax Integration. 7. Inspect the generated XML: <Imposta> appears as positive. **Root Cause** The XML generation logic for tax lines does not consider the type of the accounting move. As a result, for credit notes (in_refund or out_refund), the tax amount (<Imposta>) remains positive, even though it should be negative to reflect the refund nature of the document. **Fix** The tax amount is inverted for credit notes to ensure the XML reflects the correct financial direction. This distinction prevents misreporting, as positive values in a refund context would contradict e-invoicing standards. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4831091) opw-4831091
Odoo now completes all pending internal field updates even when those updates create additional records that also need processing. Property field updates are also handled with the right permissions, reducing unexpected access errors during routine system operations.
Original PR description
The existing implementation was incomplete when some recomputation creates a new record that has fields to recompute. The latter fields were not taken into account when recomputing "all fields". We also adapt the flushing loop in the same way. This fix revealed a related issue. Properties fields have a compute method, which is a technical artifact to update their default values when the many2one to their definition record is modified. For some weird reason, this method re-triggers its computation on the record. And in some of those cases (when the record becomes inaccessible) the second recomputation crashes (`AccessError`). The fix consists in computing the field in sudo mode.
Customer records can no longer be saved with clearly invalid phone numbers, email addresses, or website links. This helps keep contact data accurate and reduces follow-up issues caused by unusable customer information.
Original PR description
Purpose :
Prevent saving invalid contact data when creating or updating partners.
Fixes: #217386
Changes
1. Server-side validation in res.partner:
Phone/Mobile must match: ^[+\d][\d\s().-]{5,}$
Email must match: ^[^@\s]+@[^@\s]+\.[^@\s]+$
Website must:
Start with http:// or https://
Contain a valid domain and top-level domain (TLD)
2. Unit tests:
Added test_partner_validation.py
Validates:
Invalid/valid phone numbers
Invalid/valid email addresses
Invalid/valid website URLs
3. CLA:
Signed the Individual Contributor License Agreement
Added doc/cla/individual/hamzaahmedhussein.mdCredit notes sent using BIS Billing 3.0 now place discount information in the correct XML order. This prevents validation errors when issuing electronic credit notes with early payment discounts, helping ensure smoother e-invoicing processing.
Original PR description
### Issue: The structure of the bis3 XML for a credit note with an early discount is invalid. ### Steps to reproduce: - On a partner set the E-Invoicing format to "BIS Billing 3.0" - Create an…
### Issue: The structure of the bis3 XML for a credit note with an early discount is invalid. ### Steps to reproduce: - On a partner set the E-Invoicing format to "BIS Billing 3.0" - Create an invoice for this partner, confirm, send - Create a credit note from this invoice - Add a payment term with early discount to the credit note - Confirm and send to BIS Billing - The generated XML has a bad structure: https://peppol-tools.ademico-software.com/ui/document-validator ### Cause: The field `AllowanceCharge` should be after `Delivery`, `PaymentMeans` and `PaymentTerms` ([doc](https://docs.oasis-open.org/ubl/os-UBL-2.1/xsd/maindoc/UBL-CreditNote-2.1.xsd)). UBL_20 template adds `AllowanceCharge` before `TaxTotal` ([code](https://github.com/odoo/odoo/blob/ffd9c0f96bda1bad1ad2059d9be2fae54b60eace/addons/account_edi_ubl_cii/data/ubl_20_templates.xml#L570)). UBL_21 template adds `Delivery`, `PaymentMeans` and `PaymentTerms` before `TaxTotal` again ([code](https://github.com/odoo/odoo/blob/ffd9c0f96bda1bad1ad2059d9be2fae54b60eace/addons/account_edi_ubl_cii/data/ubl_21_templates.xml#L67)) As the UBL_21 template inherits frome the UBL_20 template it gets triggered after so `AllowanceCharge` ends up before `Delivery`, `PaymentMeans` and `PaymentTerms`. ### Solution: UBL_21 template now adds `Delivery`, `PaymentMeans` and `PaymentTerms` before `AllowanceCharge`. opw-4812408 Forward-Port-Of: odoo/odoo#218316
Point of Sale now calculates prices correctly when products have selectable variants with extra charges. This prevents customers from being charged duplicated or incorrect variant surcharges, especially when mixing dynamic and configurable product options.
Original PR description
When you have product with dynamic variants using extra price, the price added to the cart is not correctly computed. Steps to reproduce: ------------------- * Create a product with a dynamic variant…
When you have product with dynamic variants using extra price, the price added to the cart is not correctly computed. Steps to reproduce: ------------------- * Create a product with a dynamic variant (2 values), price 1 * Add an extra price for each value, ex 10, 20, 100 * Make a sale order with the first two variant value * Open shop * Add the product to the order 3 times, 1 for each value > Observation: Prices are respectively: 21, 41, 111 Why the fix: ------------ In the shop only `product.product` are shown. When selecting the product with variant, the product has a `lst_price` of 11 which corresponds to the price of the `product_template` plus the extra price. This value is normal but cannot be used in the computation of `get_price` as we also provide the value for `extra_price`. We can use `list_price` instead of `lst_price` as it does not include the information related to variants. Why do we see 2 different behaviors before this fix? When selecting a variant option, if the product with this variant already exist, the lst_price already contains the information about the selected variant. Which explains why, in the end, the price has twice the extra price of the variant selected. When the product with the variant does not exist, the price has one time the price of the selected variant plus one time the price of the first product with variant the is created. Configurable products were also having issues when mixing multiple variants, especially when one of them had creation mode set to "always". When exiting the configuration popup the payload does not include the extra price coming from "always" attributes. depending on what the other choices were we would have an extra price, meaning we would compute the price with `list_price` but the extra price did not include the information about the "always" variant if it had one. Using `list_price` is enough for the initial problem but only when the selected DYNAMIC variant has an extra price otherwise the code does not pass through the condition asking for extra price. In such case there is no extra price from the payload and it's still computing the price with `lst_price`, which includes information about the extra price of the variant that was already sold previously. Thus we make sure that we compute with `list_price` whenever a configurable product is added. opw-4815555
This update corrects a failing automated test related to project profitability when stock valuation accounts are missing. It helps keep the sales, project, and inventory test suite reliable so future changes can be validated without false build failures.
Original PR description
This problem was introduced with [203936](https://github.com/odoo/odoo/pull/203936/commits/a6bde40096da2e16d58b9dcc300c607b40633038) The test `test_report_invoice_items_anglo_saxon_automatic_valuation` throws an error because a stock input account cannot be found for the product avco product. This breaks the class `TestSaleProjectStockProfitability`in the 17.0 No demo build. Runbot - [229892](https://runbot.odoo.com/odoo/runbot.build.error/229892) Forward-Port-Of: odoo/odoo#219643
Automated actions now use the same evaluation rules as the browser interface. This reduces inconsistencies between what users see in the interface and how automated rules run in the background, helping avoid unexpected behavior.
Original PR description
Before this commit, the eval context for base_automation was not aligned with the browser side py_builtin.js eval context. After this commit, the eval context for base_automation is aligned with the browser side py_builtin.js eval context. Task id: opw-4737292
Odoo now avoids a crash when an accounting localization template code is missing during company setup or localization installation. Instead, users receive a clear message prompting them to check that the correct localization module is installed, making setup failures easier to understand and resolve.
Original PR description
The system would crash with a KeyError when attempting to load a chart of accounts using a template code that does not exist in the chart template mapping. This happened during the setup of a new company or while installing localization modules. **Steps to Produce:-** 1. Install the `Accounting` module. 2. Navigate to `Settings > Users & Companies > Companies`. 3. Create a new company, but do not select a country for it. 4. Switch to the newly created company. 5. Go to `Accounting > Configuration > Settings and set Iraq as the Fiscal Localization`. 6. Attempt to save the changes. **Error:-** `KeyError: 'iq'` **Solution:-** - Check if `template_code` exists in the chart template mapping. - Raise a proper `UserError` with a clear message if it doesn't, guiding the user to verify the correct localization module is installed. **Sentry - 6613287121, 6613283263, 6712436024** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where users could encounter an error when opening the On Hand stock view from a product added to an approval request. This ensures inventory quantities can be viewed normally from approvals without disrupting the workflow.
Original PR description
<b>Steps to reproduce:</b> 1. Install the `approval`,`stock` module. 2. settings Inventory> Warehouse > check storage Loaction 3. Go to approval > Manager> All Approvals 4. Select an Approval > add storable product with on hand quantity > 0. 5. Go through the product > stat button On Hand <b>Issue:</b> - A traceback for unknown name field occurs when opening the On hand (stock.quant list view) <b>Cause:</b> - The context `search_view_ref` is passed from the `approval_product_line_view_tree` via the `product_id` field, which interferes with the Quant list view rendering. As a result, the On Hand button fails to display the expected stock information. <b>Solution:</b> - Removed `search_view_ref` from the `product_id` field context in the approval product line tree view. This prevents the context from unintentionally affecting unrelated views i.e. stock.quant list, ensuring On Hand smart button works as expected. <b>opw-4916178</b>
Users without administrator settings access can now use the Reload AI Data button without hitting an access error. This prevents interruptions when processing invoices with AI extraction and keeps the workflow available to regular accounting users.
Original PR description
When clicking on the "Reload AI Data" button (`account.move::action_reload_ai_data`), a user not in `base.group_system` group encounters an access rights error when searching on `ir.module.module` model in `account.move::is_indian_taxes()`:
```python
def is_indian_taxes(self):
l10n_in = self.env['ir.module.module'].search([('name', '=', 'l10n_in')])
return self.company_id.country_id.code == "IN" and l10n_in and l10n_in.state == 'installed'
```
This commit adds `sudo()` to the `search` call to ensure that the check for the 'l10n_in' module does not fail for users not belonging to "Administration/Settings" group.
This prevents a traceback and ensures that functional users can reload AI data.
Forward-Port-Of: odoo/enterprise#90021The Project Documents app can now be installed even if a default Documents tag, such as Draft, was deleted beforehand. This prevents an installation error and makes the setup process more resilient for databases where document tags have been customized.
Original PR description
**Steps to reproduce** On a fresh database: - Install Documents - Delete the "Draft" tag - Try to install `documents_project` Installation fails: `ValueError: External ID not found in the system: documents.documents_tag_draft` **Cause** Documents tags can be deleted, innstallation of `documents_project` will fail if `ir_actions_server_data.xml` references a deleted tag https://github.com/odoo/enterprise/blob/99d7d43abf17877f6cf2e0ad88bb64fdd85b4579/documents_project/data/ir_actions_server_data.xml#L14 **Solution** Partially backport the part of the fix related to `documents_project` in https://github.com/odoo/enterprise/commit/0be3fb2661b14690f090776a2da4eb767e489ef2 , the part related to `documents_account` is only necessary for 18.2 and later after https://github.com/odoo/enterprise/commit/30968e831a92d4317025a2c312a273a0bd51f9a2. opw-4554976
The Urban Piper POS integration now checks the finalized order status directly instead of relying on an unused internal flag. This helps keep ticket screen behavior consistent and removes redundant state tracking that could cause confusion in future maintenance.
Original PR description
In this commit: ==== - Use `finalized` instead of `uiState.locked` to determine order state on TicketScreen. - Remove the unused `locked` property from `uiState` in posOrder. Task-4745869 Related: odoo/odoo#207406
The product description shown for subscription goods billed on delivered quantity has been corrected. This prevents users from seeing misleading information when configuring subscription products, reducing confusion during setup.
Original PR description
To reproduce: ============== 1- go to subscription 2- go to product 3- select product type : goods and invoicing_policy : Delivered Quantity Problem: ========= wrong description. Solution: ========== update description. opw-4929735
This fix prevents an error when viewing technical product data for products using the POS Pricer module. It ensures the product price display field always has a safe default value, improving reliability for users managing product variants.
Original PR description
**Step to reproduce:** 1. Install pos_pricer module: 2. Open the Point of Sale app and create a product. 3. Go to the Product Variants menu. 4. Open that product. 5. Activate developer mode. 6. Click…
**Step to reproduce:** 1. Install pos_pricer module: 2. Open the Point of Sale app and create a product. 3. Go to the Product Variants menu. 4. Open that product. 5. Activate developer mode. 6. Click on the Bug icon (top-right corner). 7. Click on Data. **Issue:** A traceback is raised with the error: `Compute method failed to assign product.product(191,).pricer_display_price` The method `_compute_pricer_display_price` was removed in this commit https://github.com/odoo/enterprise/commit/87b1672ac7c1d27cd9eab05138b78f6a9439fea7 , and was reintroduced in a later commit https://github.com/odoo/enterprise/commit/4575d3dfdbd0ccd9bf57bddbd35a89bd47c48798 to avoid the AttributeError. **Cause:** The computed field `pricer_display_price` is a type Char and and is non-stored was not being assigned a value inside the compute method. So ORM requires that records to be assigned a value in a compute method. **Solution:** To fix this, assign a default value to `pricer_display_price` inside the compute method to prevent the error. opw-4887318
Mexican POS global invoices now use the journal's configured issuing address when available, instead of defaulting to the company address. This ensures the official XML shows the correct place of issue for cash sales invoiced globally.
Original PR description
Steps to reproduce: [l10n_edi_extended] - setup up a mexican company - create a journal in which you define an issued address (different from your company) - setup your pos with newly created journal - Open a pos session - add a product - pay in cash with no customer - in the backend go into the orders - select the newly created order in the list view and click on the action "create global invoice" - in the order > cfdi: download the created xml Issue: The "Lugar de expedicion" will have the zip code of the company and not from the issued address one Cause: We only check for issue adress in account_move but not from orders. Global invoice is not only for invoices but also to account for sale (orders) made with petty cash Solution: We don't want to create a bridge module only for that. We check if the field is defined on `account.journal` opw-4802389
This change removes an unstable automated test related to the website rental period interface. The affected customer-facing behavior was non-critical, and removing the unreliable test helps keep the overall release validation process stable.
Original PR description
## Version 18.0 saas-18.1 Non existing test from saas-18.2 ## Issue Commit 2ee876f9409b0ea4bc859d9629362e390c25f6e3 tried to fix a16a25b6023d2d48ad5c00853728c1498509b5a5 but did not solve indeterminism in the newly created test. Since the test validates a non-critical UI fix and introduces complex indeterminism, we choose to remove it to preserve stability in OE’s global test suite. runbot-229884
This fixes an issue where non-admin employees saw an access denied message when entering a Colombian NIT on a contact. The certificate check now runs with the needed permissions, so contact creation works smoothly while keeping the process unchanged for users.
Original PR description
When entering a Colombian Tax ID (NIT), the onchange checks `company.l10n_co_dian_certificate_ids`, which reads `certificate.certificate` records , resulting in an “Access Denied” popup. This changes Wrap the certificate lookup in `company.sudo()` so that the NIT VAT‐onchange can fetch the DIAN certificate records. Steps to Reproduce: 1. Install the l10n_co_dian module and switch to CO company 2. Create a user with only the “Internal User” (base.group_user) group—do not grant Administration/Settings. 3. Log in as that non-admin user. 4. Go to Contacts -> Create. 5. Set Country = Colombia and Identification Type = NIT. 6. Enter any VAT (NIT) number and leave the field. 7. “Access Denied” error for certificate.certificate. opw-4936604
This fixes an error that could occur when two users tried to confirm the same loan at the same time. The loan confirmation process now handles overlapping actions more safely, reducing interruptions for accounting users.
Original PR description
This error occurs when multiple users attempt to `Confirm` the same account loan simultaneously from different browsers. Steps to reproduce: --- - Install `account_loans` module - Give 'Demo' user the rights of `Administrator` for accounting - Login with Demo in another browser - Open the same record in two separate browsers and attempt to `Confirm` it in both Traceback: --- ValueError: Expected singleton: account.move(4421, 3033) At [1], filtered(...) can return multiple records. Accessing `.state` directly on a multi-record set raises a ValueError because Odoo expects a singleton (only one record) when accessing a field directly. [1]- https://github.com/odoo/enterprise/blob/1474a85084a860e307302387bcb24015aa486663/account_loans/models/account_loan_line.py#L72-L75 sentry-6316959067