Daily updates from Odoo
Navigate
Branch
Friday, June 13, 2025
76 changes
37 changes
Enhancements to existing features
A dedicated US tax report has been added so companies operating in multiple countries can view only their US tax data instead of mixing it with other countries. This also helps tax returns apply the correct country-specific settings, such as tax lock dates, and corrects the module dependency needed for US accounting reports.
Original PR description
Before this PR, the Generic Tax Report had always been considered as the only report necessary to handle the US taxes. The problem is that, if a company needs to submit tax reports in multiple countries (because it has a VAT number in them; what we call multivat in the Odoo jargon), the Generic Tax Report would then show the taxes from every company, not only the US ones, hence becoming a bit messy. This also causes issues with the tax returns, which need to know the country they belong to in order to properly set the tax lock date. We solve that by introducing a new US tax report. It does the same as the Generic Tax Report, but shows only the US taxes. We also fix the dependency of l10n_us_reports by changing l10n_us to l10n_us_account.
Spreadsheet date filters have been aligned with the latest shared behavior, making them more consistent and easier to maintain. This also updates related tests and removes an internal selector that is no longer needed, with no expected disruption for users.
This update adjusts Web Studio's automated tests to match recent changes in screen size handling. It helps keep quality checks reliable after the removal of an older breakpoint, with no direct change for end users.
Original PR description
Since the VSM breakpoint is removed the breakpoint entry > XS are -1 task-4806037 Community PR: https://github.com/odoo/odoo/pull/211605
The cart summary layout has been updated so rental details appear in the right place when customers review their order. This keeps the checkout experience consistent with recent website shop changes and helps avoid display issues for rental, subscription, and external tax flows.
Original PR description
*: website_sale_renting,website_sale_subscription Fix xpath due to template changes in community. Move rental input inside the cart_summary. task-4594964 Community PR: https://github.com/odoo/odoo/pull/204358
Payroll now shows a dedicated welcome screen when a company has no employees yet. This improves first-time onboarding by giving users a clearer starting point instead of an empty or confusing dashboard.
Original PR description
Add an empty payroll dashboard screen when the company has no employees. This helps the onboarding of the app. task-4568223
The time off request window now adapts better to the selected time off type, showing more helpful defaults and hiding unnecessary fields for half-day or hourly requests. This makes leave requests easier for employees to complete and helps reduce confusion or incorrect entries.
Original PR description
Improved the time off leave form UI according to the time off type to give more intuitive default value and declutter the form when the time off type is in half-days or hours task: 4765062 related: https://github.com/odoo/odoo/pull/213604
Payroll administrators can now translate payslip input type names, making payroll configuration clearer for teams working in multiple languages. This improves usability and consistency in multilingual payroll environments without changing payroll calculations or workflows.
Original PR description
In this PR, we enabled the translate setting for the name attribute within the hr_payslip_input_type model. Before:  After:    This work is related to the task: [4840358](https://www.odoo.com/odoo/project/1251/tasks/4840358).
Users can now undo the most recent drag-and-drop or resize change made to a Gantt item directly from a notification. This reduces accidental planning mistakes and makes schedule adjustments safer and faster.
Original PR description
When using drag & drop on a pill in the gantt view, we make a notification appear containing an "Undo" button. Clicking "Undo" will revert the last action made by the drag & drop (can be a rescheduling or a copy of the record). We also allow the user to be able to "Undo" the change after resizing a pill. task-4613127
This update fine-tunes the project dashboard and removes outdated styling that is no longer needed after responsive improvements in the Community edition. Users should see a cleaner, more consistent dashboard experience across devices, with reduced maintenance overhead behind the scenes.
Original PR description
* project_account_budget ### Clean scss files This PR removes `project_right_side_panel.dark.scss` and `project_update_view_mobile.scss` since the code in these files is no longer used. Since Community is now responsive, the code in `project_right_side_panel.scss` has been moved and adapted in Community. This code is no longer required here. ### Finetunes project dashboard This PR adds some changes related to the finetuning of the project dashboard made in https://github.com/odoo/odoo/pull/205511. task-4378105 Requires: - https://github.com/odoo/odoo/pull/205511
Resolved issues and error corrections
This update improves the reliability of Web Studio's internal test environment by ensuring cleanup happens properly between tests. It helps prevent false test failures when custom models or fields are created, supporting more stable future development.
This fixes an internal test setup issue in the India payroll module by removing or correcting unused demo data. It helps keep automated checks reliable without changing day-to-day payroll functionality for users.
Employees can now choose the work entry source when Attendance is installed, not only when Planning is installed. This fixes an inconsistency so businesses using either app can configure how work entries are generated from the employee form.
Original PR description
…e having multiple options Bug / current behavior: The field work_entry_source was added to the employee form view only when installing hr_work_entry_planning (a dependency of the Planning app). Required behavior: The field work_entry_source should be shown upon installing hr_work_entry_attendance (a dependency of the Attendance app) as well. Both modules add a new selection to the field. Thus, when either module is installed, the field should be added to the form view to allow the user to choose. Fix: Add the field work_entry_source as invisible to the form view in the base module hr_work_entry. Make it visible once you install any of the planning or attendance modules. task-4866002 Community PR: https://github.com/odoo/odoo/pull/213982
Updates internal spreadsheet test coverage to match recent changes in pivot table behavior and highlight coloring. This helps keep automated checks reliable so spreadsheet features continue to work as expected without affecting day-to-day users.
Original PR description
See https://github.com/odoo/o-spreadsheet/pull/6414 Task: 4793572
Code cleanup and technical improvements
This change reorganizes the invoice import logic used by invoice extraction and several country-specific electronic invoicing modules. It should make the import flow easier to maintain and more consistent across local requirements, with limited direct impact for day-to-day users.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/189979 task-4290875
Miscellaneous changes
An error was arising when making the following steps: 1. create a company contact with a proper name. 2. create an invoice address for that company through the company form view. 3. set a phone number for the invoice. 4. leave the `name` empty. 5. open the contacts tab on VoIP. This happened because the code was trying to access the first charachater of a falsy string which is `voipName` in this case. A solution to this was to guard falsy names of contacts and add a section for contacts
Original PR description
An error was arising when making the following steps: 1. create a company contact with a proper name. 2. create an invoice address for that company through the company form view. 3. set a phone number for the invoice. 4. leave the `name` empty. 5. open the contacts tab on VoIP. This happened because the code was trying to access the first charachater of a falsy string which is `voipName` in this case. A solution to this was to guard falsy names of contacts and add a section for contacts with empty string. This section will have a title of "#" and will appear at the end of the list. Forward-Port-Of: odoo/enterprise#87509
### Issue: Currently, non-system admin users are blocked from checking Envia rates. When initializing the `Envia` class, these users do not have access to the `carrier` fields, leading to an Access Error. ### Solution: Similar to `delivery_bpost` and `delivery_dhl`, we can use a `sudo` when grabbing the `api_key` value from the carrier record. opw-4761196 Forward-Port-Of: odoo/enterprise#85319
Original PR description
### Issue: Currently, non-system admin users are blocked from checking Envia rates. When initializing the `Envia` class, these users do not have access to the `carrier` fields, leading to an Access Error. ### Solution: Similar to `delivery_bpost` and `delivery_dhl`, we can use a `sudo` when grabbing the `api_key` value from the carrier record. opw-4761196 Forward-Port-Of: odoo/enterprise#85319
Forward-Port-Of: odoo/enterprise#86696
Original PR description
Forward-Port-Of: odoo/enterprise#86696
In uruguayan companies, if the field "Lock Posted Entries with Hash" is checked, the user can not validate electronic invoices in DGI. In this PR we are hiding the field in electronic uruguayan journals to prevent the user to check that field accidentally and generate inconsistencies with electronic invoicing. Forward-Port-Of: odoo/enterprise#85392
Original PR description
In uruguayan companies, if the field "Lock Posted Entries with Hash" is checked, the user can not validate electronic invoices in DGI. In this PR we are hiding the field in electronic uruguayan journals to prevent the user to check that field accidentally and generate inconsistencies with electronic invoicing. Forward-Port-Of: odoo/enterprise#85392
The dynamic payments domain for batch payments has been added in https://github.com/odoo/enterprise/pull/86217 Fix the override for domain payments in the SEPA module. Forward-Port-Of: odoo/enterprise#87481
Original PR description
The dynamic payments domain for batch payments has been added in https://github.com/odoo/enterprise/pull/86217 Fix the override for domain payments in the SEPA module. Forward-Port-Of: odoo/enterprise#87481
The name of the reconcile models displayed in the widget was sometimes empty due to a mismatch in user language. Specifically, if a reconcile model was created in one language (e.g., en_US) and the user switched to a different language, the model name would not be found and thus appear empty. This led to a props validation error in the widget. task-4863754 Forward-Port-Of: odoo/enterprise#87480
Original PR description
The name of the reconcile models displayed in the widget was sometimes empty due to a mismatch in user language. Specifically, if a reconcile model was created in one language (e.g., en_US) and the user switched to a different language, the model name would not be found and thus appear empty. This led to a props validation error in the widget. task-4863754 Forward-Port-Of: odoo/enterprise#87480
This adds tests to check that the UBL is correctly generated in the case of free invoices (feature introduced by c8abe0a7536a0bbe703730) and invoices involving both ISC and IGV (feature introduced by d598f338537b8f55771d7a). We take the opportunity to refactor the Peruvian tests and split the expected XMLs each into its own file. Community PR: https://github.com/odoo/odoo/pull/213402 task-4242065 Forward-Port-Of: odoo/enterprise#87585 Forward-Port-Of: odoo/enterprise#87222
Original PR description
This adds tests to check that the UBL is correctly generated in the case of free invoices (feature introduced by c8abe0a7536a0bbe703730) and invoices involving both ISC and IGV (feature introduced by d598f338537b8f55771d7a). We take the opportunity to refactor the Peruvian tests and split the expected XMLs each into its own file. Community PR: https://github.com/odoo/odoo/pull/213402 task-4242065 Forward-Port-Of: odoo/enterprise#87585 Forward-Port-Of: odoo/enterprise#87222
Before this commit when doing a write on a reco model, we checked that the modified reco model could be applied on the unreconciled statement lines. We didn't do the same for the create, this pr will do that no task id Forward-Port-Of: odoo/enterprise#87398
Original PR description
Before this commit when doing a write on a reco model, we checked that the modified reco model could be applied on the unreconciled statement lines. We didn't do the same for the create, this pr will do that no task id Forward-Port-Of: odoo/enterprise#87398
Currently, when validating deliveries, if multiples attachments are posted in the same chatter message, the printing jobs do not complete. Steps to reproduce: ------------------- * Install fedex * In operation types, select Delivery Orders then hardware * In print on validation, enable Carrier Labels and Export Documents * In the shipping methods, select fedex international * Change Label format to ZPL11 * Connect the database to an iot box * Set up the shipping labels to be send on z
Original PR description
Currently, when validating deliveries, if multiples attachments are posted in the same chatter message, the printing jobs do not complete. Steps to reproduce: ------------------- * Install fedex * In…
Currently, when validating deliveries, if multiples attachments are posted in the same chatter message, the printing jobs do not complete. Steps to reproduce: ------------------- * Install fedex * In operation types, select Delivery Orders then hardware * In print on validation, enable Carrier Labels and Export Documents * In the shipping methods, select fedex international * Change Label format to ZPL11 * Connect the database to an iot box * Set up the shipping labels to be send on zebra printer * Set up commercial invoice (/invoice) to be sent to another printer * Create a sale order, using fedex international as shipping * Confirm the SO * Select the delivery * Validate the delivery > Observation: Nothing prints, jobs are sent to CUPS bu not printing Why the fix: ------------ https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_fedex_rest/models/delivery_fedex.py#L192-L196 As show, when sending the shipping, if the invoice is generated, it gets added to the attachements. The function `message_post` will post all attachments in the same chatter message. In `delivery_iot` the `message_post` function is overridden to allow sending the printing jobs to the iot. https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_iot/models/stock_picking.py#L33-L46 Here, `attachments_names` will both contain `Label` and `ShippingDoc`. Since we enter the first if condition, the report is related to the shipping labels. Then we send the data related to all attachments to the device linked to the shipping labels, aka the zebra printer. Since the other attachment is of type PDF, the zebraprinter does not know what to do with it and ends up printing nothing. Since we can have multiple different attachment, the if/elseif condition does not make sense. By breaking it in two if, we can send both reports separately, while still keeping all attachments in the same chatter message. opw-4546715 Forward-Port-Of: odoo/enterprise#83481 Forward-Port-Of: odoo/enterprise#82094
When importing a coda statement, in case of globalisation, Odoo doesn't take into account the different levels of details. Instead of that, we keep every lines even if one is already the sum of each detailed lines. According to https://febelfin.be/media/pages/publicaties/2023/archief-bankstandaarden/0c9e6e5026-1694763197/standard-coda-2.4-fr.pdf Chapter 3.1 Transaction type are communicate like that: - 0 -> simple amount without detailed data - 1 -> amount as totalised by the cus
Original PR description
When importing a coda statement, in case of globalisation, Odoo doesn't take into account the different levels of details. Instead of that, we keep every lines even if one is already the sum of each…
When importing a coda statement, in case of globalisation, Odoo doesn't take into account the different levels of details. Instead of that, we keep every lines even if one is already the sum of each detailed lines. According to https://febelfin.be/media/pages/publicaties/2023/archief-bankstandaarden/0c9e6e5026-1694763197/standard-coda-2.4-fr.pdf Chapter 3.1 Transaction type are communicate like that: - 0 -> simple amount without detailed data - 1 -> amount as totalised by the customer - 5 -> detail of 1 - 2 -> amount as totalised by the bank - 6 -> detail of 2, simple amount without detailed data - 7 -> detail of 2, simple amount with detailed data - 9 -> detail of 7 Let's assume this case: - 1 line with transaction type == 2, amount == 3000 - 1 line with transaction type == 7, amount == 2000 - 1 line with transaction type == 9, amount == 2000 - 1 line with transaction type == 7, amount == 1000 - 1 line with transaction type == 9, amount == 1000 Currently, Odoo will display lines 1, 2 and 4 in case of split transactions instead of lines 3 and 5. In case of not split transactions, Odoo sums up the same lines. With this commit, we keep trace of last line's transaction type to: - be able to delete it if it has detailed data, in case of split transaction - to sum up only the relevant lines opw-4619660 opw-4795349 Forward-Port-Of: odoo/enterprise#87523 Forward-Port-Of: odoo/enterprise#85006
The test `test_computed_fields_without_dependencies` triggers all compute methods on new records (model.new()). In `_compute_company_vat`, we had: `re.sub(r'[^0-9]', '', wizard.company_id.vat or wizard.company_id.company_registry)` When running on a new record, both `vat` and `company_registry` are `False`, so: `re.sub(..., False)` This causes `TypeError: expected string or bytes-like object, got 'bool'`. We fix this by explicitly passing a string fallback. [runbot-1641
Original PR description
The test `test_computed_fields_without_dependencies` triggers all compute methods on new records (model.new()).
In `_compute_company_vat`, we had:
`re.sub(r'[^0-9]', '', wizard.company_id.vat or wizard.company_id.company_registry)`
When running on a new record, both `vat` and `company_registry` are `False`, so:
`re.sub(..., False)`
This causes `TypeError: expected string or bytes-like object, got 'bool'`.
We fix this by explicitly passing a string fallback.
[runbot-164199](https://runbot.odoo.com/odoo/error/164199)
Forward-Port-Of: odoo/enterprise#87323Currently, the VAT is split into two columns only if the VAT code consists solely of numeric values. However, in practice, VAT code may contain a combination of letters and numbers. **Steps to reproduce :** 1) Install `l10n_de_reports` and switch to the `DE` company 2) Create a partner with VAT as `NL000099998B57` from contacts 3) Now create a confirmed invoice for the above created partner 4) Go to "Accounting / Reporting / Audit Reports / General Ledger" 5) Download "DATEV DATA (Z
Original PR description
Currently, the VAT is split into two columns only if the VAT code consists solely of numeric values. However, in practice, VAT code may contain a combination of letters and numbers. **Steps to…
Currently, the VAT is split into two columns only if the VAT code consists solely of numeric values. However, in practice, VAT code may contain a combination of letters and numbers. **Steps to reproduce :** 1) Install `l10n_de_reports` and switch to the `DE` company 2) Create a partner with VAT as `NL000099998B57` from contacts 3) Now create a confirmed invoice for the above created partner 4) Go to "Accounting / Reporting / Audit Reports / General Ledger" 5) Download "DATEV DATA (ZIP)" and check "EXTF_customer_account.csv" **Issue:** Notice that the VAT was not split into country and VAT code for the above created partner. **Cause:** Previously, the code only split the VAT into country code and VAT code if the first two characters were alphabetic and the remainder was numeric. https://github.com/odoo/enterprise/blob/35944a38d306ea881e08e1d51ca77a3eab3a6e36/l10n_de_reports/models/datev_export_csv.py#L220-L227 This approach is insufficient because many countries have VAT codes that include both letters and numbers. For example vat formats for `NL` and `AT` https://business.gov.nl/finance-and-taxes/vat/numbers-for-vat/ https://ec.europa.eu/taxation_customs/vies/#/faq So by only checking whether the VAT code is numberic is not a valid thing. **Solution:** The code now uses the partner’s `_split_vat` method to separate the country code and VAT code whenever a VAT is provided and has more than two characters. It then validates the split VAT using the `simple_vat_check` helper method. If the VAT is valid, the country code (in uppercase) and the VAT code are output in separate columns; otherwise, the original VAT value is kept. This change ensures that VAT numbers with alphanumeric codes are correctly handled and split into their respective columns. opw-4820929 Forward-Port-Of: odoo/enterprise#87289 Forward-Port-Of: odoo/enterprise#86992
### Steps to reproduce: - In the settings: Enable `Units of Measure & Packagings` - Create a storable product with 100 units in stock and an associated packaging such as 'pack of 6' - Create and confirm a sale order for 5 pack of 6. > This creates and reserve a delivery for 30 units (5 pack of 6). - Process the delivery in the barcode app and scan a pack of 6 #### > A new line is created for 1 pack of 6 instead of updating the quantity of the line referring to these packs to 5/30. ###
Original PR description
### Steps to reproduce: - In the settings: Enable `Units of Measure & Packagings` - Create a storable product with 100 units in stock and an associated packaging such as 'pack of 6' - Create and…
### Steps to reproduce: - In the settings: Enable `Units of Measure & Packagings` - Create a storable product with 100 units in stock and an associated packaging such as 'pack of 6' - Create and confirm a sale order for 5 pack of 6. > This creates and reserve a delivery for 30 units (5 pack of 6). - Process the delivery in the barcode app and scan a pack of 6 #### > A new line is created for 1 pack of 6 instead of updating the quantity of the line referring to these packs to 5/30. ### Cause of the issue: Since the packaging/uom refactoring, packagings are just uoms. Now, scanning the packaging will launch a call of the `_processBarcode` method. During this call, the existing line will not be be found and considered as an appropriate candidate to be updated since the its prodcut_uom is in Unit and the packaging uom is not: https://github.com/odoo/enterprise/blob/bdb3f3d959d6fd56e96e2299823fba6edbb5428c/stock_barcode/static/src/models/barcode_model.js#L1710-L1711 As such, there will be no `currentLine` to update and a new line will be created: https://github.com/odoo/enterprise/blob/bdb3f3d959d6fd56e96e2299823fba6edbb5428c/stock_barcode/static/src/models/barcode_model.js#L1441-L1443 opw-4782296 Forward-Port-Of: odoo/enterprise#86659 Forward-Port-Of: odoo/enterprise#86180
### Steps to reproduce: - Create a storable product P with 10 units in stock. - Inventory > Configuration > Warehouse Management > Operation Types - Change the reservation Method of Delivery orders to Manual - Create confirm and manually assign a delivery order for 3 units of P - Process the DO in the barcode app, scan 1 unit of P > The line should be 1/3 - Leave and come back #### > The line is now at 1/1 ### Cause of the issue: Leaving the barcode app launch a call of the `spli
Original PR description
### Steps to reproduce: - Create a storable product P with 10 units in stock. - Inventory > Configuration > Warehouse Management > Operation Types - Change the reservation Method of Delivery orders…
### Steps to reproduce: - Create a storable product P with 10 units in stock. - Inventory > Configuration > Warehouse Management > Operation Types - Change the reservation Method of Delivery orders to Manual - Create confirm and manually assign a delivery order for 3 units of P - Process the DO in the barcode app, scan 1 unit of P > The line should be 1/3 - Leave and come back #### > The line is now at 1/1 ### Cause of the issue: Leaving the barcode app launch a call of the `split_uncompleted_moves` in order to keep track of the initial reservation in the barcode app: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L9-L11 However, one of the issue of the current system is that these new moves are expected to be assigned by the `_action_confirm`: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L37 But they are not in certain cases and we should therefore force re-assignation in that case: https://github.com/odoo/odoo/blob/bf0461552effe806fdaa8f85f088be3c3f3be09d/addons/stock/models/stock_move.py#L1427-L1432 Community: https://github.com/odoo/odoo/pull/211616 opw-4798349 Forward-Port-Of: odoo/enterprise#87461 Forward-Port-Of: odoo/enterprise#86394
**Before this PR:** - The `Validate` button was always visible, even if the OTP was empty or incorrect. - Users could attempt validation with an invalid or missing OTP. - The OTP delivery message was unclear. **After this PR:** - The `Validate` button proceed done when a valid 6-digit numeric OTP is entered. - A clear error notification is shown if users try to proceed without a valid OTP. - The OTP delivery message now clearly informs that the OTP is sent to the registered mobile n
Original PR description
**Before this PR:** - The `Validate` button was always visible, even if the OTP was empty or incorrect. - Users could attempt validation with an invalid or missing OTP. - The OTP delivery message was unclear. **After this PR:** - The `Validate` button proceed done when a valid 6-digit numeric OTP is entered. - A clear error notification is shown if users try to proceed without a valid OTP. - The OTP delivery message now clearly informs that the OTP is sent to the registered mobile number on the GST portal. These changes improve user guidance and prevent incorrect OTP submissions. Task ID: 4848729 Forward-Port-Of: odoo/enterprise#87199
When user clicks on Details in the commissions, A traceback will appear. Steps to reproduce the error: - Install ``sale_commission`` with demo data - Go to Sales > Commissions > My Commissions - Click on ``Details`` of any record Traceback: ``` UndefinedColumn: column "team_id" does not exist LINE 21: AND team_id in (1) ``` ``team_id`` field was removed in the commit: https://github.com/odoo/enterprise/commit/b1e41f9b23aa62bfd6f9be1feb1059b3507f2ce5 https://githu
Original PR description
When user clicks on Details in the commissions, A traceback will appear. Steps to reproduce the error: - Install ``sale_commission`` with demo data - Go to Sales > Commissions > My Commissions - Click on ``Details`` of any record Traceback: ``` UndefinedColumn: column "team_id" does not exist LINE 21: AND team_id in (1) ``` ``team_id`` field was removed in the commit: https://github.com/odoo/enterprise/commit/b1e41f9b23aa62bfd6f9be1feb1059b3507f2ce5 https://github.com/odoo/enterprise/blob/9d3a15d4d38fce8a2746778146c58123bc09178d/sale_commission/report/achievement_report.py#L341 Here, ``team_id`` field is still used. ``sale.commission.achievement`` model does not ``team_id`` field. So, It will lead to the above traceback. sentry-6378493886 Forward-Port-Of: odoo/enterprise#87268
Currently, an error occurs when a user tries to access `paid consultation` or `paid seats` if the booking fees are deleted by the user. **Steps to Reproduce:** - Install **appointment_account_payment** module without demo data. - Delete **Booking Fees** product`from `invoicing->customer->products` - Click on `Paid Seats` or `Paid Consultation` in the Appointment App. **Error:** `ValueError: No record found for unique ID appointment_account_payment.default_booking_product. It may have b
Original PR description
Currently, an error occurs when a user tries to access `paid consultation` or `paid seats` if the booking fees are deleted by the user. **Steps to Reproduce:** - Install…
Currently, an error occurs when a user tries to access `paid consultation` or `paid seats` if the booking fees are deleted by the user. **Steps to Reproduce:** - Install **appointment_account_payment** module without demo data. - Delete **Booking Fees** product`from `invoicing->customer->products` - Click on `Paid Seats` or `Paid Consultation` in the Appointment App. **Error:** `ValueError: No record found for unique ID appointment_account_payment.default_booking_product. It may have been deleted.` **Root Cause:** After deleting the **Booking Fees**, if user tries to open `Paid Seats` or `Paid Consultation` the system will try to access id of `appointment_account_payment.default_booking_product` at [1] or [2] causing an error. [1]- https://github.com/odoo/enterprise/blob/a4f68967a9826fac981c1141ece1791a0baf647a/appointment_account_payment/models/templates/appointment_type.py#L43 [2]- https://github.com/odoo/enterprise/blob/a4f68967a9826fac981c1141ece1791a0baf647a/appointment_account_payment/models/templates/appointment_type.py#L56 **Solution:** This commit prevents error by restricting user from deleting the `Booking Product`. Sentry-6013528364 Forward-Port-Of: odoo/enterprise#86159
In this commit: = - Closed the session of POS to settle the journal balance. runbot-error-181911 Forward-Port-Of: odoo/enterprise#86880
Original PR description
In this commit: = - Closed the session of POS to settle the journal balance. runbot-error-181911 Forward-Port-Of: odoo/enterprise#86880
Problem: Given that the fields for the salary rules has already been generated for the current country set on the salary structure, an error occurs when accessing the payroll reporting records after the user changes the country because the payroll reporting records will reference a different field name. The outdated fields will not properly unlink, new fields won't be generated based on the new country set, but the payroll report will reference the new field name. Purpose: When changing the c
Original PR description
Problem: Given that the fields for the salary rules has already been generated for the current country set on the salary structure, an error occurs when accessing the payroll reporting records after…
Problem: Given that the fields for the salary rules has already been generated for the current country set on the salary structure, an error occurs when accessing the payroll reporting records after the user changes the country because the payroll reporting records will reference a different field name. The outdated fields will not properly unlink, new fields won't be generated based on the new country set, but the payroll report will reference the new field name. Purpose: When changing the country on a salary structure, the rules that appears on the payroll reporting needs to unlink outdated fields and regenerate the fields based on the new country value. The salary rule fields are dependent on the country due to its naming convention. Steps to Reproduce on Runbot: 1. Install Payroll 2. Create a new salary structure with no country 3. Create a new salary rule and enable "View in Payroll reporting" 4. Check fields and observe that a field prefixed by 'x_l10n_xx' was created 5. Change the country set on the salary structure 6. Try to access a payroll report record and a traceback is thrown opw-4649030 Forward-Port-Of: odoo/enterprise#87464 Forward-Port-Of: odoo/enterprise#83749
Since [^1] VAT values are automatically compacted to the smallest form without any dots and dashes. For account creation in Avatax we must uncompress the VAT before sending to the API. Funny enough, Avatax requires compacted values for EDI api calls, as such the compression code will be removed in master. task-4817278 [^1]: https://github.com/odoo/odoo/pull/179078 Forward-Port-Of: odoo/enterprise#87291
Original PR description
Since [^1] VAT values are automatically compacted to the smallest form without any dots and dashes. For account creation in Avatax we must uncompress the VAT before sending to the API. Funny enough, Avatax requires compacted values for EDI api calls, as such the compression code will be removed in master. task-4817278 [^1]: https://github.com/odoo/odoo/pull/179078 Forward-Port-Of: odoo/enterprise#87291
Having a mandatory company on factors comes with multiple problems. The main one is that users rely on factors imported from huge databases, that would therefore have to be imported once per company. The current dabatase model is incidentally built around factors being available in all companies, which means one cannot actually import the factors multiple times. Another is that users could see sources (which are not company dependent) that are seemingly linked to no factors because they ar
Original PR description
Having a mandatory company on factors comes with multiple problems. The main one is that users rely on factors imported from huge databases, that would therefore have to be imported once per company. The current dabatase model is incidentally built around factors being available in all companies, which means one cannot actually import the factors multiple times. Another is that users could see sources (which are not company dependent) that are seemingly linked to no factors because they are in other companies, which can be confusing. To alleviate those problems, this PR makes the field non required. Note that this will only take effect for new databases or after an upgrade. Forward-Port-Of: odoo/enterprise#87500
This commit fixes a bug that happens when the partner name is a falsy value like a `" "`. This made the `t9_name` to be `false` and then to give an error when trying to access the `trim()` function. A solution for this was to guard it with a condition to check if the t9_name is falsy or not. Forward-Port-Of: odoo/enterprise#87328
Original PR description
This commit fixes a bug that happens when the partner name is a falsy value like a `" "`. This made the `t9_name` to be `false` and then to give an error when trying to access the `trim()` function. A solution for this was to guard it with a condition to check if the t9_name is falsy or not. Forward-Port-Of: odoo/enterprise#87328
### Issue: `helpdesk.ticket` ratings were converted to emojis in https://github.com/odoo/enterprise/pull/42972, but currently do not display the correct color or face. ### Solution: Correctly check the value of `rating_avg_text` to determine which face should be shown, and remove class decoration that was recently added that hides the proper color. opw-4703331 Forward-Port-Of: odoo/enterprise#86573
Original PR description
### Issue: `helpdesk.ticket` ratings were converted to emojis in https://github.com/odoo/enterprise/pull/42972, but currently do not display the correct color or face. ### Solution: Correctly check the value of `rating_avg_text` to determine which face should be shown, and remove class decoration that was recently added that hides the proper color. opw-4703331 Forward-Port-Of: odoo/enterprise#86573
39 changes
New functionality added to Odoo
Adds a shared withholding tax package for countries where taxes are withheld and recorded when payments are made. This gives businesses a reusable way to manage these tax workflows across localizations instead of relying on country-specific implementations.
Original PR description
Quite a lot of countries have systems in place where withholding taxes are used and only registered upon paying. This commit brings this functionality as a shared localization package so that users can decide to use this system if it fits their needs. Task [link](https://www.odoo.com/odoo/project/967/tasks/3614935) task-3614935
Enhancements to existing features
Analytic reporting now automatically adapts group-by options to the hierarchy levels defined in analytic plans. This makes it easier for users to analyze data by levels such as city, country, or continent across standard list, pivot, and graph views.
Original PR description
Help the users by creating filters automatically depending on the hierarchy of analytic plans. This allows to open any standard view (list/pivot/graph) by level of hierarchies. One usecase is, for a plan about localisation: * Main plan: City (i.e. Brussels, New York, Los Angeles) * Level 1 sub plan: Country (i.e. Belgium, USA) * Level 2 sub plan: Continent (i.e. Europe, America) This will generate (or delete) automatically new fields depending on the various levels in the hierarchy being created or deleted. When the feature is in use, the group by widget becomes a drop-down similar to the groupby selector of dates, allowing to select either the year/month/... task-4763892
The recruitment job positions page is being streamlined so hiring teams can see key actions and status information faster, including activity and configuration shortcuts, clearer application labels, in-progress status, and company names where available. The mobile view is also simplified to show only the most useful details, making day-to-day recruiting work quicker on smaller screens.
Original PR description
### Description of the issue/feature this PR addresses:
Making a cleaner recruitment job positions view:
- Adding activity and configure button directly in the view to avoid losing time clicking o_kanban_card_manage_settings -> Activities/Configuration
- Renaming
- open slots -> new applications
- open applications -> new applications
- Adding "in progress" (more convenient)
- Displaying company name when it's possible instead of the user_id (more convenient)
Cleaner recruitment job position for mobile:
- Displaying only usefull infos
- Displaying company name when it's possible instead of the user_id (more convenient)
On job position activities view:
- Adjusting spacing right to the assignee avatar
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe Journal Audit Excel export now includes an extra sheet listing the filters and options used when the report was generated. This makes exported reports easier to review, share, and audit because recipients can see the exact criteria behind the data.
Original PR description
In this commit: --- - Adds a new worksheet to the XLSX export of the Journal Audit report, summarizing all filters and options active at the time of export. - This feature was already available for other accounting reports but was missing in the Journal Audit report. --- task-4859786
Resolved issues and error corrections
Fixes an inventory issue where validating multiple partial receipts for subcontracted products could incorrectly add far more stock than was actually received. This keeps on-hand quantities accurate when purchase receipts are split across several backorders.
Original PR description
### Steps to reproduce: - Create a storable product P with a vendor and a subcontracting bom for that vendor. - Create a purchase order for 100 units with that vendor. - Validate the receipt R1 for 5…
### Steps to reproduce: - Create a storable product P with a vendor and a subcontracting bom for that vendor. - Create a purchase order for 100 units with that vendor. - Validate the receipt R1 for 5 units and backorder - Validate the backorder R2 for 3 units and backorder - Validate the backorder of the backorder R3 for 1 units and backorder #### > The on hand qty of the product is at 99 even thought you registered only 9 units. ### Cause of the issue: Currently, the above flow associate with the last receipt move with a qty of 1 both a move line for 1 unit and a move line for 90 units. As both will be picked at validation time, the receipt for 1 unit will effectively be treated as a receipt of 91 units. Here are the details: Updating the quantity of the move of R1 to 5 will in turn update the quantity of the move line to 5 and pick it by the "_set_quantity": https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/mrp_subcontracting/models/stock_move.py#L78-L82 https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/mrp_subcontracting/models/mrp_production.py#L139-L143 Then, the first validation (of R1) for 5 units instead of 100 is well processed: it creates a backorder with a receipt move for 95 units and assign it with a single move line of 95. Similarily, setting the quantity on R2 will set the move line to 3 picked units. However, at validation, the situation will be quite different when assigning its backorder since the move of R2 now has an `move_orig_ids`. This will result in R3 to be assigned by 2 move lines: - one for 2 units - one for 90 units instead of one for 92 units. Indeed, during the action_assign of R3 (triggered by the `_create_backorder` of R2), we try to determine the qty available from done move lines related to our move_orig_ids and its `move_dest_ids` in order to see if there is already an available quantity (bacause more was processed in than out for instance). We will then first create a move line for that available quantity: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/stock/models/stock_move.py#L1873-L1886 and finish the assignment with the `missing_reserved_quantity`: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/stock/models/stock_move.py#L1907 The issue is that in our case, we should not find any available quantity to assign and the method responsible for this computation `_get_available_move_lines` will still find a discrepency between the available_move_lines_in qty and the available_move_lines_out qty for 5 - 3 that is 2 units -> We will end up with one move line for 2 units and one for 90. The discrepency is due to the fact that the `_get_available_move_lines_in` finds one in move line **done** for 5 units of R1. But that the `_get_available_move_lines_out` first finds the move line **done** for 5 units related to R1: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/stock/models/stock_move.py#L1817-L1821 But then erase the values by the demand of 3 provided by the **partially_available** move line of R2 that we are currently validating and that we should not have considered in the present flow: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/stock/models/stock_move.py#L1822-L1823 In particular, we end with a picking R3 for 92 units and 2 move lines. Now, setting the quantity of R3 to 1 will update the quantity of the first move line to 1 and set it as picked without altering the second one as the update of the quantity can totally be handled by the first move line. We therefore end up with a move with a move with a quantity of 1 and 2 move lines: 1 picked unit and 90 unpicked unit: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/mrp_subcontracting/models/mrp_production.py#L124-L143 Now, this would be fine if the second move line was not automatically picked as it would be ignored by the action done. However, since the move it self was not picked since subcontracted moves are never automatically recomputed as picked from their move lines: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/mrp_subcontracting/models/stock_move.py#L61-L63 the _pre_action_done_hook of the picking validation will pick the entire move and hence set the other move line as picked: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/stock/models/stock_picking.py#L1486-L1487 In particular both move lines will be validated and update the related stock quants. ### Fix: Since in the case where there is no done move line we still find the outgoing partially reserved quantity that we are currently validating we should add the values of both **done** and **reserved** outgoing qties for the behavior on backorders to be the same as on the first picking validation. opw-4822646 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where image transformation controls could stay visible after a user deleted an image in the editor. This prevents confusing leftover controls and keeps the editing experience consistent, including in Chrome.
Original PR description
### Steps to reproduce: - Insert an image into the editor. - Open the Transformation controls for the image. - Press the `Backspace` key to delete the image. - The transformation overlay remains…
### Steps to reproduce: - Insert an image into the editor. - Open the Transformation controls for the image. - Press the `Backspace` key to delete the image. - The transformation overlay remains visible after the image is removed. ### Description of the issue/feature this PR addresses: - In commit [1](https://github.com/odoo/odoo/commit/85698bf4f591fc9280f054b9a255a7d5ff4d1fe2), the `image_transform_button` component unmounted before `selectionchange` event could fire. As a result, event listener was removed, and the transform container was not closed when the image was deleted. Desired behavior after PR is merged: - The `selectionchange` listener is now attached within the `image_transformation` component. - A `keydown` listener is also added to explicitly handle Backspace and Delete keys, addressing the case where Chrome does not trigger `selectionchange` on image deletion. task-4831728 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where videos and other embedded content could disappear when code view was enabled in the HTML editor. The editor now keeps the needed add-ons loaded, so users can switch modes without losing embedded content.
Original PR description
Problem: When the `codeview` option is enabled in the HTML editor, embedded components like videos no longer work and disappear from the content. Cause: The `html_field` overrides `config.resources` entirely when `codeview` is enabled, which prevents other required plugins (e.g., for embedded components) from being loaded. Solution: Move the code view logic into its own dedicated plugin, consistent with how other optional features are handled, to avoid overriding `config.resources`. Steps to reproduce: 1. Open an HTML field. 2. Add a video (embedded component). 3. Enable the `codeview` option. 4. Enter debug mode. → The video disappears from the content. opw-4837016 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Manufacturing orders for serial-tracked finished products now correctly set the produced quantity to 1 when production quantity is entered. This helps ensure related quality checks are processed with the right quantity and avoids errors in serial-based production workflows.
Original PR description
This commit update the finished move quantity of a production of a serial tracked product to 1 when set the quantity producing (always to 1 in case of a serial tracked product) This is mainly mandatory in case the production need to process quality checks. Task : 4575193 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
Italian EDI proxy users are now created only for branch companies that have a different VAT number or Codice Fiscale from their parent company. This prevents subsidiaries that share the same legal identity from getting separate proxy configurations, while still supporting branches that operate as independent legal entities.
Original PR description
Companies (typically branches) whose VAT or Codice Fiscale differs from their parent (root) company are now allowed to create their own EDI proxy user. This ensures that only independent legal entities are assigned individual proxy users, while subsidiaries sharing the same VAT/CF use the root company's proxy configuration. no-task
This update fixes inconsistencies between server-side and browser-side tax calculations, especially around rounding and inherited tax settings. It helps ensure invoices, sales orders, and related accounting totals are calculated more reliably and consistently.
Original PR description
- rounding_method is there on the python code but not js-side. - rounding_method is passed to the taxes computation but not used after to decide if the total_excluded has to be rounded or not. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes several issues affecting accounting, website editing, point of sale sample data, spreadsheets, email marketing, time off tests, and live chat internals. Business users should see fewer incorrect warnings, smoother website editing, more reliable demo/sample data loading, and corrected editor or dashboard behavior.
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
Manufacturing worksheets will no longer allow videos in the description area when those videos cannot be shown in the Shop Floor interface. This prevents users from adding content that would later disappear, keeping shop floor instructions consistent and reliable.
Original PR description
Problem: Videos added in the operation worksheet are not visible on the Shop Floor interface. Cause: `embedded_components`, such as video iframes, are only supported within the HTML editor context and cannot be rendered elsewhere. This results in the video being silently dropped. Solution: Introduce a `disableVideo` flag for the `note` field in worksheet views. This avoids embedding unsupported video content and ensures the interface remains consistent. Steps to reproduce: 1. Go to Manufacturing > Operations > Worksheet. 2. Add a video in the worksheet's description field. 3. Create a Manufacturing Order (MO) for a product using this operation. 4. Confirm the MO and open it in the Shop Floor interface. 5. Open the worksheet tab. → The video is missing (not rendered). opw-4783722 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents picking operation reports from crashing when a kit component has zero or missing packaging quantity. Business users can now print the report successfully even after manually removing kit components, avoiding a server error during warehouse operations.
Original PR description
Description of the issue/feature this PR addresses: When printing the Picking Operations report for kit-type BoMs, a `ZeroDivisionError` occurs if the packaging quantity (`product_packaging_id.qty`) becomes zero or is unset due to manual removal of a component. This happens in `_compute_product_packaging_qty`, where a division by zero is attempted when `product_packaging_id.qty == 0`. Current behavior before PR: - Users manually remove kit components (e.g., "Packing") - Print Picking Report → Server Error: `ZeroDivisionError: division by zero` Desired behavior after PR is merged: - The report prints correctly even if component quantities or packaging is zero - Division is safely guarded with a fallback of `1` to avoid crashes Fixes: #210594 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a vendor bill in a different currency is matched to a purchase order, the down payment amount is now converted correctly. This prevents purchase orders from recording incorrect down payment values and helps keep purchasing and billing totals accurate.
Original PR description
Users can create a downpayment bill directly from the purchase order or create a bill separately and then associate it with the original purchase order. However, in the latter case, the bill amount won't take into account the currency. Steps to reproduce: - Create a purchase order for a partner in company currency - Create a bill in foreign currency for the same partner - Click "Purchase Matching" smart button - Select PO and BILL > Add to PO > Add Down Payment Issue: Downpayment will be added into the PO without taking into account the different currency opw-4716949
This fixes an error where Bulgarian invoice totals written in words could show the wrong thousands value, such as describing 8,500 as 7,500. Businesses using Bulgarian invoices can now rely on the printed amount text matching the actual invoice total.
Original PR description
### Steps to reproduce: - Install l10n_bg - Install the Bulgarian language - In the Accounting Settings, tick the option "Total amount of invoice in letters" - Change a contact's language to Bulgarian - Create an invoice for this partner, select BGN as the currency - The total should be with a unit in thousands (for example 8500) - The text transcription of the number substracts 1000: Седем Хиляди И Петстотин = 7500 ### Cause: The class `NumberToWords_BG` is a copy of the library num2cyrillic except for the initialization of the variable `_digits` which specifies three arrays with variants of the numbers (1-9). We do it by copying the index 0, which is the default variant, for the non-different spellings. The issue comes from the line `_digits[-1] = [None, 'една', None] + _digits[0][2:]` which have an unneeded `None` which offsets the array by one. So when reading `_digits[-1][8]` we end up with "seven". ### Solution: Remove the `None`. opw-4753418
This update resolves several issues found during the 18.0 upgrade, including password reset errors, unnecessary vendor bill notifications, dashboard filtering inconsistencies, and repeated portal email verification messages. These fixes reduce confusion for users and improve reliability across accounting, purchasing, website profile, and signup workflows.
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
Studio exports no longer fail when a website uses a theme and the view has not been changed in Studio. This lets users complete exports reliably without needing to make unnecessary edits first.
Original PR description
**Before this commit:** - If the user had a website with a theme, then exporting from `Studio Export` would fail if no changes were made to the view via `web_studio`. **After this commit:** - The export now completes successfully, even when there are no changes made in the view through `web_studio`. task-4815179
This update corrects a test configuration problem in the Swedish point-of-sale localization that was causing automated validation to fail. It helps keep quality checks running reliably without changing business functionality for users.
Original PR description
In this commit: ------------ - We are fixing the unknown key "test" runbot error. runbot error-226611
Failed quality checks now correctly split stock movements when items are sent to a failure location, preventing location mismatches. This helps avoid downstream inventory routing and valuation problems, while keeping manufacturing quality checks safe during upgrades.
Original PR description
In case of 'quantity' control per quality point. If a complete stock move line is sent to a failure location. The stock move was not split. We could have a stock move line going to a location that is not child of the location of the corresponding move. This can lead issues in case of push_rules or stock valuation. Task: 4575193
This fix aligns the Italian point of sale tax calculation logic between the system backend and the browser interface. It helps avoid inconsistent tax rounding behavior during POS transactions, reducing the risk of incorrect totals or reporting differences.
Original PR description
rounding_method is there on the python code but not js-side.
Odoo now sends the full product catalog to UrbanPiper whenever connected delivery platforms such as JustEat, Grubhub, DoorDash, or UberEats require it. This prevents missing or inconsistent menu information on those partner platforms during synchronization.
Original PR description
Issue: --- - For providers like JustEat, Grubhub, DoorDash, and UberEats (US/UK regions), UrbanPiper expects the entire product catalog during sync. - However, Odoo was sending only updated products, causing issues on their end. Fix: --- - Updated the condition to ensure a full product sync is performed when any of the configured providers require it. task-4863894
The Italian Libro Giornale report now includes bank lines for payment entries, ensuring payments show both debit and credit sides. This prevents unbalanced report totals and supports more accurate statutory accounting output.
Original PR description
The Libro Giornale report was missing the bank (liquidity) line for payment entries, which caused the report to be unbalanced. This happened because the report is based on the standard journal report, which skips liquidity lines by default. To fix this, the `_get_export_lines_for_journal` method was updated to treat the bank line like a normal journal line, so it now appears in the report. This ensures that payment entries show both the credit and debit sides as required. Return to the default pdf and xml buttons name and remove _custom_options_initializer overwrite function task-4830113
This fixes an issue where scanning the same product after removing an inventory count line could create repeated duplicate sublines. Inventory counts in the Barcode app now stay clearer and more accurate, reducing confusion during stock checks.
Original PR description
### Steps to reproduce: - Create a storable product with 1 unit in stock and a barcode: XXX - Go to the barcode app > Inventory Count - Scan XXX > One line is created 1/1. - Diminish the quantity to…
### Steps to reproduce:
- Create a storable product with 1 unit in stock and a barcode: XXX
- Go to the barcode app > Inventory Count
- Scan XXX
> One line is created 1/1.
- Diminish the quantity to 0 > Remove the line
- Scan XXX
#### > The line appear with multiple sublines
#### > If you repeat the two last steps even more sublines will appear
### Cause of the issue:
Scaning XXX will create a line with a subline for each quant present in the lazyBarcodeCache:
https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_quant_model.js#L345 https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_quant_model.js#L359-L381 However, the quants present in the cache are currently stored in a list and they are pushed to the list by the `setCache` method even if they are already present:
https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/lazy_barcode_cache.js#L54-L62 This is problematic in the present flow since multiple actions set the cahche and hence add the "new" version of the already present quant rather than updating its current value.
To be more precise, in the present workflow, the `setCache` method is called once during the the first barcode scan:
https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/lazy_barcode_cache.js#L324-L325 And twice at each line deletion (once per `refreshCache` call, one during the save and one during the `trigger('refresh')`): https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_model.js#L823-L825 https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_model.js#L468-L471
opw-4787229The VIES summary report no longer crashes when integer rounding is enabled. This ensures users can open and review the report with rounded amounts as expected, improving reliability for tax reporting workflows.
Original PR description
When we enable the integer rounding option on this report, a traceback is raised at the report opening. It happens because integer rounding didn't support a groupby when a custom engine is used. opw-4688616
Non-administrator users can now retrieve Envia shipping rates without encountering an access error. This helps sales and operations teams quote shipping costs smoothly without needing elevated system permissions.
Original PR description
### Issue: Currently, non-system admin users are blocked from checking Envia rates. When initializing the `Envia` class, these users do not have access to the `carrier` fields, leading to an Access Error. ### Solution: Similar to `delivery_bpost` and `delivery_dhl`, we can use a `sudo` when grabbing the `api_key` value from the carrier record. opw-4761196
Miscellaneous changes
Currently, we prevent user to register payment for invoices belonging to different branches. With this commit, when trying to register payments for two invoices belonging to different branches, we register it as parent company. Steps: - Have a main company with 2 branch - Create and confirm one invoice for each branch - Select both branches in company selector - From the invoice list view, select the 2 invoices - Try to register payment -> Error: "You can't create payments for entries belongin
Original PR description
Currently, we prevent user to register payment for invoices belonging to different branches. With this commit, when trying to register payments for two invoices belonging to different branches, we register it as parent company. Steps: - Have a main company with 2 branch - Create and confirm one invoice for each branch - Select both branches in company selector - From the invoice list view, select the 2 invoices - Try to register payment -> Error: "You can't create payments for entries belonging to different branches." opw-4563936 Forward-Port-Of: odoo/odoo#212686
This commit introduces a hook filter method that allows to filter the amls taken into account in _get_invoiced_lot_values (verify the quantity of serial product previously delivered). PR enterprise: odoo/enterprise#81656 Ticket [link](https://www.odoo.com/odoo/project/49/tasks/4644031) opw-4644031 Forward-Port-Of: odoo/odoo#202262
Original PR description
This commit introduces a hook filter method that allows to filter the amls taken into account in _get_invoiced_lot_values (verify the quantity of serial product previously delivered). PR enterprise: odoo/enterprise#81656 Ticket [link](https://www.odoo.com/odoo/project/49/tasks/4644031) opw-4644031 Forward-Port-Of: odoo/odoo#202262
### Description: Adds a new computed `has_worksheet` field to avoid out of memory issues in Shop Floor. ### Reference: opw-4784076 Forward-Port-Of: odoo/odoo#211505
Original PR description
### Description: Adds a new computed `has_worksheet` field to avoid out of memory issues in Shop Floor. ### Reference: opw-4784076 Forward-Port-Of: odoo/odoo#211505
Description of the issue/feature this PR addresses: allowedFns is used to validate functions permitted for use in evaluate. However, it is not currently exported, so other modules cannot create new functions. Current behavior before PR: Other modules can inherit and add new functions. 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#214106
Original PR description
Description of the issue/feature this PR addresses: allowedFns is used to validate functions permitted for use in evaluate. However, it is not currently exported, so other modules cannot create new functions. Current behavior before PR: Other modules can inherit and add new functions. 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#214106
the tour was failing because the phone number was not set in the website configuration, which is required for the add to cart snippet tour to pass because it checks the phone number in the billing address form page which is required to be filled in order to proceed with the tour and confirm order is on the next page which is not reached so the tour was failing due to timeout build_error-160894 Forward-Port-Of: odoo/odoo#213178
Original PR description
the tour was failing because the phone number was not set in the website configuration, which is required for the add to cart snippet tour to pass because it checks the phone number in the billing address form page which is required to be filled in order to proceed with the tour and confirm order is on the next page which is not reached so the tour was failing due to timeout build_error-160894 Forward-Port-Of: odoo/odoo#213178
Setting the opacity to the empty string leads to max opacity but is seen as "/" in the builder because no options corresponds to this value. And the "None" option is not that, which is confusing. Setting a known value for the opacity shows the correct choice for the option Steps to reproduce: - In a database with demo data, go to `/event` - Go to "An unpublished event" - Open editor - Bug: "Filter Intensity" shows "/" Backport of 94cc1cbd2d8ed23fd243515ad215ea91bac46068 task-4367641
Original PR description
Setting the opacity to the empty string leads to max opacity but is seen as "/" in the builder because no options corresponds to this value. And the "None" option is not that, which is confusing. Setting a known value for the opacity shows the correct choice for the option Steps to reproduce: - In a database with demo data, go to `/event` - Go to "An unpublished event" - Open editor - Bug: "Filter Intensity" shows "/" Backport of 94cc1cbd2d8ed23fd243515ad215ea91bac46068 task-4367641 Forward-Port-Of: odoo/odoo#212836 Forward-Port-Of: odoo/odoo#212530
**Steps to reproduce:** - Install the modules `l10n_sg` and `l10n_sg_ubl_pint`. - Create an invoice. - On the form view of the partner you chose. Under the `Accounting` tab, set `eInvoice format` as PINT singapore. - On the invoice, for `currency_id`, use a currency other than SGD. - Download the invoice in the 'PINT Singapore' format. **Issue:** The invoice is not downloaded and it throws a traceback. **Cause:** The method '_get_additional_document_reference_list' returns a list of
Original PR description
**Steps to reproduce:** - Install the modules `l10n_sg` and `l10n_sg_ubl_pint`. - Create an invoice. - On the form view of the partner you chose. Under the `Accounting` tab, set `eInvoice format` as PINT singapore. - On the invoice, for `currency_id`, use a currency other than SGD. - Download the invoice in the 'PINT Singapore' format. **Issue:** The invoice is not downloaded and it throws a traceback. **Cause:** The method '_get_additional_document_reference_list' returns a list of dictionnaries within another list, while the XML is expecting a list of dictionnaries. **Solution:** Remove the append method. opw-4799363 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212754
If a currency not supported by AsiaPay is selected during payment, the system will crash, resulting in a KeyError. In the `const.py` file at [1], we have already defined the `CURRENCY_MAPPING`. Therefore, if a currency is chosen that is not included in the `CURRENCY_MAPPING`, it will cause a crash during the payment process. [1] https://github.com/odoo/odoo/blob/bcaafd941c1b4cae65a71900858894556805762e/addons/payment_asiapay/const.py#L19-L42 **Steps to produce:-** 1. Install `eCommerce`.
Original PR description
If a currency not supported by AsiaPay is selected during payment, the system will crash, resulting in a KeyError. In the `const.py` file at [1], we have already defined the `CURRENCY_MAPPING`.…
If a currency not supported by AsiaPay is selected during payment, the system will crash, resulting in a KeyError. In the `const.py` file at [1], we have already defined the `CURRENCY_MAPPING`. Therefore, if a currency is chosen that is not included in the `CURRENCY_MAPPING`, it will cause a crash during the payment process. [1] https://github.com/odoo/odoo/blob/bcaafd941c1b4cae65a71900858894556805762e/addons/payment_asiapay/const.py#L19-L42 **Steps to produce:-** 1. Install `eCommerce`. 2. Set up the `AsiaPay` payment provider, and in the configuration, set the Currencies as `EGP`. 3. Now, go to `Website > Shop` and add the product to the cart. 4. Try to make the `payment` for the cart using `AsiaPay`. **Error:-** `KeyError: 'EGP'` **Solution:-** - This commit adds a constraint that ensures only currencies defined in `CURRENCY_MAPPING` (from `const.py`) can be selected for the AsiaPay payment provider. If any unsupported currencies are selected, a ValidationError is raised listing the invalid entries. **Sentry - 6665716944** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213496
When scrapping a tracked product without a lot and without a picking_type_id, `stock.move.line._action_done` raises a UserError requiring a lot/serial number. This happens because the method checks for the absence of both `picking_type_id`, `is_inventory`, and `lot_id`, assuming a lot is always mandatory outside inventory and picking flows. However, scrap operations may occur outside these flows and should not necessarily require a lot, especially when triggered programmatically (e.g. via
Original PR description
When scrapping a tracked product without a lot and without a picking_type_id, `stock.move.line._action_done` raises a UserError requiring a lot/serial number. This happens because the method checks…
When scrapping a tracked product without a lot and without a picking_type_id, `stock.move.line._action_done` raises a UserError requiring a lot/serial number. This happens because the method checks for the absence of both `picking_type_id`, `is_inventory`, and `lot_id`, assuming a lot is always mandatory outside inventory and picking flows. However, scrap operations may occur outside these flows and should not necessarily require a lot, especially when triggered programmatically (e.g. via API or automation), bypassing the form view validation. This commit updates the condition in `_action_done()` to check the context key `is_scrap`, which is already passed in `do_scrap()` via `move.with_context(is_scrap=True)._action_done()`. This allows tracked products to be scrapped without a lot in valid scenarios, without misleadingly assigning a `picking_type_id` to the move. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212404 Forward-Port-Of: odoo/odoo#206900
Global purpose is to make mail/view controller more resilient by improving redirections when not having access to the record. Notably * correctly route internal users to discuss, portal users to /my and unlogged users to login; * keep original mail/view route when performing redirection after login so that we try the routing again; * fix various issues in redirect computation, such as lost access token parameter or partial reconstruction of URLs; Improve test coverage.
Original PR description
Global purpose is to make mail/view controller more resilient by improving redirections when not having access to the record. Notably * correctly route internal users to discuss, portal users to /my and unlogged users to login; * keep original mail/view route when performing redirection after login so that we try the routing again; * fix various issues in redirect computation, such as lost access token parameter or partial reconstruction of URLs; Improve test coverage. Task-4685166 Forward-Port-Of: odoo/odoo#213750 Forward-Port-Of: odoo/odoo#212545
In uruguayan companies, if the field "Lock Posted Entries with Hash" is checked, the user can not validate electronic invoices in DGI. In this PR we are hiding the field in electronic uruguayan journals to prevent the user to check that field accidentally and generate inconsistencies with electronic invoicing. Forward-Port-Of: odoo/enterprise#85392
Original PR description
In uruguayan companies, if the field "Lock Posted Entries with Hash" is checked, the user can not validate electronic invoices in DGI. In this PR we are hiding the field in electronic uruguayan journals to prevent the user to check that field accidentally and generate inconsistencies with electronic invoicing. Forward-Port-Of: odoo/enterprise#85392
### Description: When opening Shop Floor, the frontend will fetch all the worksheets linked to the displayed MOs. This causes the ORM to load all the attachments at the same time, which can create a Memory Error(OOM). ### Fix: The only reason why it is retrieved at the opening of the view is to check if the workorders have a worksheet. If it is, then the worksheet is loaded again when needed (i.e. when button is clicked to display it). This means that we can avoid unnecessarily preloadi
Original PR description
### Description: When opening Shop Floor, the frontend will fetch all the worksheets linked to the displayed MOs. This causes the ORM to load all the attachments at the same time, which can create a Memory Error(OOM). ### Fix: The only reason why it is retrieved at the opening of the view is to check if the workorders have a worksheet. If it is, then the worksheet is loaded again when needed (i.e. when button is clicked to display it). This means that we can avoid unnecessarily preloading all documents by adding a compute that will tell us if the workorders have one or not. ### Benchmark: | N° of worksheet | Before | After | |-----------------|--------|-------| | 29 | 3.36s | 1.2s | | 144 | OOM | 1.2s | ### Reference: opw-4784076 Forward-Port-Of: odoo/enterprise#86318
- Create a product with tracking by serial numbers then set a lot and serial number on the product - Activate the option Display Lots & Serial Numbers on Invoices in the Inventory settings - Create a sale order with the test product and confirm it - Create the invoice and send the cfdi report - Request a cancel and select the reason 01 Document issued with errors (with related document) . On the CFDI PDF report of the new invoice, there are no lines for lots and serial numbers—they are not
Original PR description
- Create a product with tracking by serial numbers then set a lot and serial number on the product - Activate the option Display Lots & Serial Numbers on Invoices in the Inventory settings - Create a…
- Create a product with tracking by serial numbers then set a lot and serial number on the product - Activate the option Display Lots & Serial Numbers on Invoices in the Inventory settings - Create a sale order with the test product and confirm it - Create the invoice and send the cfdi report - Request a cancel and select the reason 01 Document issued with errors (with related document) . On the CFDI PDF report of the new invoice, there are no lines for lots and serial numbers—they are not printed. The report uses the _get_invoiced_lot_values method from sale_stock to retrieve serial numbers. This method is first called when sending the CFDI for the parent invoice. However, when it is called for the child invoice, the method checks the quantity of the serial product, which is now depleted. This commit introduces a hook that allows to filter the amls taken into account in get_invoiced_lot_values. In l10n_mx_edi, we do not take the amls from the parent invoice after a cfdi cancellation. community PR: https://github.com/odoo/odoo/pull/202262 opw-4644031 Forward-Port-Of: odoo/enterprise#81656
**Current behavior:** A user who can otherwise use the entire mps can not add 'rows' to the view (i.e., write on `ResCompany` `mrp_mps` fields). **Expected behavior:** Can add rows to the MPS. **Steps to reproduce:** 1. Install `mrp_mps` with demo data 2. Edit "Demo" user access rights so they only have the mrp manager group 3. Open MPS -> click `Rows` dropdown (under search bar) and add/remove one -> access error **Cause of the issue:** Field is on `ResCompany` and the MPS us
Original PR description
**Current behavior:** A user who can otherwise use the entire mps can not add 'rows' to the view (i.e., write on `ResCompany` `mrp_mps` fields). **Expected behavior:** Can add rows to the MPS. **Steps to reproduce:** 1. Install `mrp_mps` with demo data 2. Edit "Demo" user access rights so they only have the mrp manager group 3. Open MPS -> click `Rows` dropdown (under search bar) and add/remove one -> access error **Cause of the issue:** Field is on `ResCompany` and the MPS user can't write to that model. **Fix:** Permit writes on `ResCompany` `mrp_mps` fields if they are on an mps field and the user has the mrp manager group. opw-4591655 Forward-Port-Of: odoo/enterprise#80881