Daily updates from Odoo
Tuesday, February 18, 2025
52 changes · 18.0
Enhancements to existing features
When creating a new journal entry, the cursor now starts in the next editable field instead of the entry name. This helps prevent users from accidentally changing the automatically generated sequence number.
Original PR description
…layed name to the next editable field(Reference) 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 update simplifies the invoice Print & Send flow by removing unnecessary warnings, improving Peppol guidance, and avoiding automatic e-invoicing format choices that caused confusion. It also improves reliability for invoices without bank account details and prevents Peppol sending when recipient details are not verified.
Original PR description
## Commit 1: [IMP] account{,_edi_ubl_cii,_peppol}: Misc imps of the Print & Send - "What is Peppol" warning no longer appear on already sent invoices. - Remove the warning related to already existing…
## Commit 1: [IMP] account{,_edi_ubl_cii,_peppol}: Misc imps of the Print & Send
- "What is Peppol" warning no longer appear on already sent invoices.
- Remove the warning related to already existing PDF. This will be improved
by the following task [1].
- Remove the warning related to bank accounts, this will be improved
in the next commit of this PR.
- Align warnings related to absence of EAS/Endpoint.
- Move the "Test/Demo mode" warning next to the "by Peppol" label.
- Remove the new "Print" button from draft invoices.
[1]: https://www.odoo.com/odoo/project/967/tasks/4498564
task-4478365
-----------------------------
## Commit 2: [FIX] account: Add translation for invoice pdf report field in form
task-no
-----------------------------
## Commit 3: [IMP] account_{edi_ubl_cii,peppol}: Stop setting automatically an invoice edi format
In previous refactor[1], we set automatically an invoice EDI format.
This decision was too zealous considering the overall state of e-invoicing
and now cause more frictions than necessary.
We therefore decided to remove the automatic computation of EDI format on
partners.
[1]: https://github.com/odoo/odoo/commit/9e769e1b11f22890e5245859053bc8dd31e42634
task-4478365
-----------------------------
## Commit 4: [FIX] account: remove partner_bank_id from readonly field of posted moves
In previous PR [1], we made the partner_bank_id field editable on
the invoice form as long as the move is not sent.
There was still a security check in place, let's remove it for this
field.
[1]: https://github.com/odoo/odoo/pull/195069
task-4478365
-----------------------------
## Commit 5: [IMP] account_edi_ubl_cii: use code ZZZ instead of 30 if no bank account is set
To generate a valid BIS3 format, if we put 30 - credit transfer as payment means,
we need to have a bank account set. If it's not the case, it will raise an error.
We improve the usability by changing that code to ZZZ - mutually defined if no
bank account is provided to the invoice.
This should improve the onboarding flow when no bank account is set yet.
task-4478365
-----------------------------
## Commit 6: [IMP] account_peppol: expand the countries where we display WhatIsPeppol banner
This list is based on recent usage statistics from OpenPeppol.
task-4478365This update helps accounting users spot when asset depreciation schedules no longer match the balance sheet. It adds a report warning with a direct link to the affected assets, making it easier to review and correct account settings in bulk.
Original PR description
…depreciation schedule and the balance sheet using an sql querie [imp] a warning message that has a button to take you to the assets so that you can change the accounts making the discrepancy(manually) Allwed mass edition on the assets list view
Quality checks now show product variant details instead of only the general product name. This makes it easier for staff to distinguish similar products during transfers and reduces handling confusion.
Original PR description
Before Commit: ---------------------------- - Quality checks only displayed the product name, making it difficult to distinguish between variants in the same transfer. After Commit: ----------------------------- - Quality checks now display variant details, ensuring clarity and reducing confusion when handling multiple variants of the same product. task-4478249
Adds a warning in accounting reports when asset depreciation schedules do not match the balance sheet. Users can jump directly to the affected assets and edit them in bulk, helping teams correct account setup issues more efficiently.
Original PR description
…depreciation schedule and the balance sheet using an sql querie [imp] a warning message that has a button to take you to the assets so that you can change the accounts making the discrepancy(manually) Allwed mass edition on the assets list view
Restaurant booking forms now show the answers guests provided to appointment questions. This gives staff the context they need directly in the booking view, helping them prepare for customer visits without checking elsewhere.
Original PR description
This commit allows the calendar_event_view_form_gantt_booking_inherit form view to display the answers to the questions linked to an appointment. https://github.com/odoo/odoo/pull/196426
Resolved issues and error corrections
This fixes a restaurant point of sale issue where adding a kitchen note and sending it still left the order button visible and the line marked as changed. Staff now get clearer order status after notes are sent to preparation screens, reducing confusion and duplicate actions.
Original PR description
Steps to Reproduce: - Open POS restaurant. - Select a table. - Order some food. - Return to the floor plan. - Select the same table again. - Add a kitchen note to a line. - Click Order. - The note update is correctly sent to the preparation display. The "order" button is still displayed and the line with the note is still marked as “changed”.
The point of sale customer display now automatically scrolls as new order items are added, so customers can see the latest products even when the list is longer than the screen. This fixes a restaurant POS display issue when using a separate customer-facing device.
Original PR description
Steps to reproduce: - Install pos_restaurant - In restaurant's configs, set 'Customer Display' to 'Another device' - Open the customer display in another tab, and start adding products from the main display -> The list of products on the customer display doesn't auto scroll when the products overlow the view. Explanation: The last `OrderLine` is supposed to be pass a `selected` prop, so it can be targeted from JavaScript and scrolled into the view [1]. However, this prop was removed in 1bc90a18807c43206c4620d7faad2579a3a61fc9. Now we add it back. [1]: https://github.com/odoo/odoo/blob/18.0/addons/point_of_sale/static/src/app/generic_components/order_widget/order_widget.js#L28-L30 opw-4458215
This fix allows non-administrator users to open the stock replenishment view without encountering an access error. It corrects a permission issue introduced by a prior change, helping inventory teams continue replenishment work normally.
Original PR description
odoo/odoo#192897 introduced a new bug when trying to access the replenishment view without administrator rights due to a call to `ir.config.parameter` method `get_param` without sudo rights. opw-4583651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes several automated website, point-of-sale, barcode, and eLearning test journeys more stable by improving how they wait for pages, animations, and interface elements. It reduces false test failures, helping teams validate changes with more confidence without changing normal customer-facing behavior.
Original PR description
Here is description of modifications for each tour: modified: addons/barcodes/static/src/barcode_handlers.js Use hoot event instead of custom event defined in macro.js to uniform code and behaviors.…
Here is description of modifications for each tour:
modified: addons/barcodes/static/src/barcode_handlers.js
Use hoot event instead of custom event defined in macro.js to
uniform code and behaviors.
modified: addons/l10n_br_website_sale/static/tests/tours/brazilian_address.js
Add a delay to wait the form is loaded to avoid problem with
_selectState(id) function.
modified: addons/point_of_sale/static/tests/tours/utils/chrome_util.js
Use waitFor in run of step because .fa-circle-o-notch should not
appears ... then of course body:not(:has(.fa-circle-o-notch)) also
not and then tour crashes.
modified: addons/pos_self_order/static/tests/tours/self_order_kiosk_tour.js
Because of the background animation, clicking on order now
may not do anything... so we'll click until we get to take out.
modified: addons/pos_self_order/tests/test_self_order_kiosk.py
Let's see comment of previous file ... We could need more time
for the tours.
modified: addons/test_website/static/tests/tours/restricted_editor.js
:contains(text) => Check that textContent.test(regex)
:has(class) => Check the element classList contains the class
modified: addons/website/static/tests/tours/html_editor.js
Additionnal steps to ensure tour take the good way.
modified: addons/website_slides/static/tests/tours/slides_tour_tools.js
Uniformize the behavior for two tours with clickOnAddTagDropdown
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-prFixes two issues in the HTML editor: deleting selected content no longer creates unwanted empty blocks, and the ChatGPT alternatives dialog no longer disrupts the user's text selection. This makes editing content more predictable and prevents accidental changes while the dialog is open.
Original PR description
In the following HTML: ```html <h1>[test</h1><p>content]</p>\n ``` The "\n" text node is invisible whitespace. When deleting the selection, failing to account for that, the content of the heading was…
In the following HTML: ```html <h1>[test</h1><p>content]</p>\n ``` The "\n" text node is invisible whitespace. When deleting the selection, failing to account for that, the content of the heading was "joined" with the invisible text node so that the heading's first child was that text node. This enventually snowballed when inserting new content as the start container was now a text node at offset 0, signalling to `insert` to do its insertion before its parent, and we ended up with an empty block after our insertion. This fixes it by correcting `getJoinableFragment` so it doesn't join with an invisible text node. ----- This prevents the default behavior of a mousedown event on the ChatGPT alternatives dialog so it doesn't cancel the user's text selection in the editor. This way, like with every other dialog, whenever it's open nothing can happen in the background. task-4258167 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale product searches now treat accented and unaccented text consistently. This helps cashiers find products with accented names more reliably, reducing checkout delays and missed search results.
Original PR description
Currently, if you have a product named "clémentines" and input "clémentine" in the search bar it will not be found. Steps to reproduce: ------------------- * Create a product sold in POS named clémentine * Open a shop which does not restrict categories * Input in the search bar "clémentine" > Observation: No product for "clémentine" Why the fix: ------------ The product `searchString` is `unaccent` and `toLowerCase` while the searchWord is only `toLowerCase`. https://github.com/odoo/odoo/blob/f82f768729d897fa54b04789f4e0637ed1bb27f4/addons/point_of_sale/static/src/app/screens/product_screen/product_screen.js#L397-L397 opw-4558898
This fixes an automated website setup check that could fail depending on which website apps were installed. The tour now only opens the link editor when needed, making website testing more reliable without changing customer-facing behavior.
Original PR description
The following PR: https://github.com/odoo/odoo/pull/190321 introduced a new website tour. However, one of the step make the tour consistently fail with a single app website install. The reason for the fail is that the "edit link" sub-window is opened by default if the link is not open through the "extra menu". Clicking the button (what currently do the test) do close the sub-window making the input not clickable in the following step.  *single-app website build screenshot* the URL input is open by default *multi-app build screenshot* the URL input is not shown by default as the mega-menu menu-item is shown in the "extra menu" due to the amount of menu added by other website related app After this PR: The "edit link" button is pressed only if the input is not visible rb-111286
The manufacturing BoM overview no longer crashes when viewing products that use dynamically created variants. If a specific product variant does not yet exist, variant-specific operation details are safely skipped so users can still access the overview.
Original PR description
Steps to reproduce the bug: - Ceate a product - add a new attribute with "variant creation mode" = "Dynamic" - create a BoM for this product - make sure to add an operation in the operational lines…
Steps to reproduce the bug: - Ceate a product - add a new attribute with "variant creation mode" = "Dynamic" - create a BoM for this product - make sure to add an operation in the operational lines of the bom - Click on the BoM smart button then BoM overview smart button Problem: Traceback is raise, because in the BoM overview it creates a BoM report, and it adds the operational lines(operations) to the report, some operations are skipped based on the function `_match_all_variant_values` that checks if the product has all the variant values. This function expects a product to run on, but in case of dynamic attribute a product will only be created if it is included in a sales order, hence the product is empty and the function raise the exception. Since the BoM report is for the product variants, then we can skip the operational line if no product is used in the BoM, and hence the `_match_all_variant_values` won't be called over empty product. opw-4518723 **Possible approaches for the Issue**: 1- Change the product variable in the bom object in the _get_bom_data function to be the product.template instead of the concrete product, this will affect many other functions in the generating of the bom report as **_get_resupply_route_info** function that calls **_get_rules_from_location** which is not a function on the 'product.template' model. Considering that approach requires anticipating the case of having the product.template in the bom in all the sections in the bom report. 2- Keep the porduct in the bom object empty one since we don't have with dynamic attributes. And we just skip operational lines if the porduct is empty so the **_match_all_variant_values** is not called. [**IMPLEMENTED**] (This change doesn't require more changes as everything will be still working with the expected model type 'product.product' but the operations and other data will be empty in the report which make sense because they are variant related ) Current behavior before PR: the app show error whenever a BoM overview smart button is clicked for a BoM of a product with dynamic attribute variants Desired behavior after PR is merged: The BoM overview report should be shown normally with no problems. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes the mobile call screen so the push-to-talk button keeps the correct size instead of expanding over the call view. Mobile users can now access call controls without the interface being blocked by an oversized button.
Original PR description
Before this commit, since https://github.com/odoo/odoo/pull/189657, the mobile push-to-talk button was also affected by the aspect ratio affecting all buttons of the call action list. This was making the button too big and covering the whole call view. This commit fixes this issue by introducing a dedicated selector for the bar part of the call action list. before:  after: 
Chat bubbles in spreadsheets now stay fully visible when the filters panel is hidden. This prevents conversations from being partially covered by the spreadsheet scrollbar, making chat easier to use while working in spreadsheets.
Original PR description
Before this commit, when using spreadsheet with some chat bubbles, the chat bubbles were cut with horizontal scrollbar of spreadsheet. Steps to reproduce: - make a spreadsheet - put a chat in chat…
Before this commit, when using spreadsheet with some chat bubbles, the chat bubbles were cut with horizontal scrollbar of spreadsheet. Steps to reproduce: - make a spreadsheet - put a chat in chat bubble (e.g. from click on messaging menu) - remove the "filters" panel of the spreadsheet This happens because the horizontal scrollbar of spreadsheet uses a `z-index: 15` while chat bubble uses `z-index: 10`. The `z-index` of chat bubble is relative to navigable list, and since the value was exactly slightly offset from navigable list, this commit fixes by shifting the `$o-mail-NavigableList-zIndex`. It was `11`, now it's `21`. As a result, the chat bubble `z-index` is being changed from `10` to `20`, which is greater to `15` from spreadsheet horizontal scrollbar. Task-4547672 Before / After <img width="106" alt="Screenshot 2025-02-17 at 17 10 28" src="https://github.com/user-attachments/assets/caf3d9f8-59d4-4b2b-9981-d2e5ed68a510" /> <img width="97" alt="Screenshot 2025-02-17 at 17 11 14" src="https://github.com/user-attachments/assets/1c9376bc-ca24-42dd-8864-eee0878fc1c7" />
This fix ensures portal chatter components wait until all required background services are ready, including when parts of the page are loaded later. It reduces the chance of unpredictable loading behavior or broken chatter interactions for portal users.
Original PR description
When loading portal chatter, because the chatter bundle is lazy loading, it could happen that some components are added to the main_components registry while the services are not fully updated. In non-lazy loading scenarios, this doesn't happen because before lunching the main components, the code waits for all services to start, but with lazy loading, the services update happens again with the lazily loaded bundle, and if there are some main components in that bundle, they will be added to the MainComponentsContainer regardless of the updating services. As a result, this could lead to a main component being added randomly before or after the services are loaded. This commit, by postponing the lunching of the MainComponentsContainer until after the lazy loading is complete, ensures that if there are other lazily loaded services, the main components will wait for them to be updated.
Simplified invoices sent to TicketBAI now leave out recipient details when the customer does not have a VAT/NIF number. This prevents validation failures and helps Spanish companies submit these invoices successfully.
Original PR description
Since Odoo 18.0, the recipient is always included when sending a simplified invoice. While this is allowed by TicketBAI, it is only valid if the partner has a VAT number (NIF). Steps to reproduce: Install the l10n_es_edi_tbai module and setup an ES company Create a simplified invoice with the partner "Simplified Invoice Partner (ES)" Send the invoice to TicketBAI The following error will be returned: "B4_1000002: Todos los registros incluidos en la petición son incorrectos." The Fix: For simplified invoices, this fix ensures that the recipient is only included in the XML if the partner has a VAT/NIF. If not, the recipient is omitted to avoid TicketBAI validation errors. Ticket [link 1](https://www.odoo.com/odoo/project/967/tasks/4525875), [link 2](https://www.odoo.com/odoo/project/967/tasks/4522938), [link 3](https://www.odoo.com/odoo/project/967/tasks/4553030) opw-4525875 opw-4522938 opw-4553030
Accounting settings now block invalid fiscal year dates, such as February 29 in non-leap years. This prevents invoice creation from failing later with a confusing system error and gives users clear feedback when configuring fiscal periods.
Original PR description
Currently, An error occurs when attempting to create an invoice, and the user entered an invalid date in the `Fiscal Periods` of the accounting settings. Step to produce: - Install the `accountant`…
Currently, An error occurs when attempting to create an invoice, and the user entered an invalid date in the `Fiscal Periods` of the accounting settings. Step to produce: - Install the `accountant` module (without demo data). - Go to Settings / Technical / Sequences & Identifiers / Sequences, And delete all records. - Go to Accounting settings, Set the month to February and the day to 29 in the `Fiscal Periods` section, - Go to Invoicing / Customers / Invoices, Try to create a new invoice. `ValueError: day is out of range for month` The issue occurs because the system attempts to get a 29th February at [1], But 29th February is not available in all years(e.g '2025'). Link [1]: https://github.com/odoo/odoo/blob/0f507a8982a29bf1c35aaf9f8f97fc3d5381226c/addons/account/models/account_move.py#L3487 To resolve this, raise a validation error if the user enters an invalid date in the `Fiscal Year` of the accounting settings. Sentry-6190026432 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale product search has been updated to match the newer search behavior after fuzzy search was removed. Users should now see all relevant product results instead of being limited to only exact matches, making it easier to find items during checkout.
Original PR description
Since the fuzzy search has been removed, it is no longer necessary to exclusively display only exact match results. This commit updates the search functionality to adopt and return all relevant search results, ensuring consistency with the new behavior. opw-4535250 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a French accounting setup issue caused by a module split in Odoo 18. The change ensures existing tax tags are preserved using the correct French accounting module, helping avoid configuration inconsistencies during updates.
Original PR description
I found this bug while reading the code of l10n_fr_account. In v18, the module l10n_fr was split between l10n_fr and l10n_fr_account. When calling preserve_existing_tags_on_taxes(), we need to pass the module name l10n_fr_account because account.account.tag are now defined in l10n_fr_account, cf https://github.com/odoo/odoo/blob/18.0/addons/l10n_fr_account/data/account_chart_template_data.xml#L3 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
In https://github.com/odoo/odoo/commit/b42c99abd362c15e86f6a745399979dd3236b75a, we changed the xml_id but we forgot to change that in the pot --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
In https://github.com/odoo/odoo/commit/b42c99abd362c15e86f6a745399979dd3236b75a, we changed the xml_id but we forgot to change that in the pot --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where exporting selected records could fail after using the “select all” option in list views. This makes export actions more reliable, including inventory stock reporting exports.
Original PR description
The domain was incorrectly initialized in the `getExportedFields` method after this commit https://github.com/odoo/odoo/pull/174366/files#diff-a3a01eded3e54743e243ef83e4c7dc682ddc91630015fa1f986e20346e7b84caR521-R530. The domain now defaults to an empty array (`[]`) when `parentParams` is undefined, preventing unexpected errors during export operations. This ensures consistent handling of record selection and domain construction. Steps to reproduce Go to Inventory / Reporting / Stock Change the number of records displayed to be less than the total When you try to select all in the list view it shows the select all button. Click it. Actions / Export / Stock Quant Open this there is a video that explain in the [ticket](https://www.odoo.com/odoo/project.task/4333244) opw-4333244 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures formatted comments in restaurant booking views display as intended in Point of Sale. It adds the required editor support so staff can read rich text notes properly during booking workflows.
Original PR description
Before this commit comment field in calendar_event_view_form_gantt_booking used in pos restaurant does not display properly html field. Fixed by importing the html editor to the point_of_sale manifest. task-4547369 https://github.com/odoo/enterprise/pull/78536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes several issues in the WinBooks import process so accounting data imports more accurately and with fewer manual corrections. It improves handling of draft entries, missing accounts, and analytic accounting details, including using the correct analytic plan names and enabling analytic features when needed.
Original PR description
Details in various commits
The version history panel no longer offers a redundant rename menu action that could trigger an error. Users can still rename a spreadsheet version directly by clicking the editable name, making the experience simpler and more reliable.
Original PR description
Clicking 'Name this version' in the version history panel causes a traceback because the `el` of TextInput is not found. We have two possible solutions: 1. Forward the refs of TextInput and VersionHistoryItem explicitly using `useChildRef` and `useForwardRefToParent`, or use a callback to retrieve the ref for focusing the input. 2. Remove the menu item, as the cursor already changes to a text pointer on hover, indicating the name is editable. I think the second approach is better since it is simpler and more intuitive. Task: 4563422
Accounting settings now reject invalid fiscal year dates, such as February 29 when it would cause errors in non-leap years. This prevents users from encountering an invoice creation failure caused by an unsupported fiscal period configuration.
Original PR description
Currently, An error occurs when attempting to create an invoice, and the user entered an invalid date in the 'Fiscal Periods' of the accounting settings. Step to produce: - Install the `accountant` module (without demo data). - Go to Accounting settings, Set the month to February and the day to 29 in the Fiscal Periods section, - Go to Invoicing / Customers / Invoices, Try to create a new invoice. `ValueError: day is out of range for month` The issue occurs because the system attempts to get a 29th February at [1], But 29th February is not available in all years(e.g '2025'). Link [1]: https://github.com/odoo/odoo/blob/0f507a8982a29bf1c35aaf9f8f97fc3d5381226c/addons/account/models/account_move.py#L3487 To resolve this, raise a validation error if the user enters an invalid date in 'Fiscal Year' to ensure that users cannot enter an invalid date. Sentry-6190026432
Creating a share link from an appointment type no longer clears the user’s current filters. This keeps users in their existing view and avoids unnecessary reloading while managing appointment sharing.
Original PR description
Steps to reproduce ================== - Got to appointment type; - Apply some filter. - Now create a share link. - Filter is lost. Technical =========== https://github.com/odoo/enterprise/pull/63046/commits/492296e91e9c0b1106a7bc6852010be426d2abe8 Here we are loading the action while creating or updating the share link to reflect the changes without refreshing. It is not required when we create a share link from other places instead of a Share link menu. After this commit ================== This commit addresses the issue and now the filter will not lost when we create a share link from appointment_type. Task-4138356
When a Mexican electronic payment document is canceled, Odoo now also cancels the linked payment record. This prevents payments from incorrectly remaining posted after the official CFDI cancellation process.
Original PR description
Since Odoo 18.0, account.payment no longer inherits from account.move. As a result, canceling a payment with `_l10n_mx_edi_cfdi_move_post_cancel` does not automatically cancel the associated payment record. Steps to reproduce: 1. Ensure the Mexican localization is installed and properly configured. 2. Generate an invoice and sign it with the government (CFDI). 3. Create and sign a payment for the invoice. 4. Cancel the payment from the CFDI table. Current behavior: - Odoo cancels the move, but the related payment remains posted. Expected behavior: - The payment should also be canceled when the move is canceled. This fix ensures that the associated payment is canceled correctly. opw-4528910
Batch picking screens now show tracked product lines grouped correctly, making warehouse operations easier to review and process. This fixes a display issue that could make batch picking confusing when lot or serial tracked items were involved.
Original PR description
opw-4291149
Documentation and clarification updates
This pull request adds an individual Contributor License Agreement record for the contributor minhlc1108. It is an administrative legal update that helps confirm contribution eligibility and does not change Odoo product 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
This pull request adds an individual contributor license agreement record for Alystrasa898. It supports Odoo's legal contribution process and does not change product features or user 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
Miscellaneous changes
In 50c62eab72678d51fb88c88fbeb81da2decca6f2, an override was done to attachments to disable deleting them, detaching them instead. As this is only required for German companies, a check can be added in the override to allow non-German companies to be able to delete their attachments. Also, another restriction was added for changing the fiscal country to make sure the flow for deleting German attachments cannot be bypassed. task-4500319 Forward-Port-Of: odoo/odoo#197006
Original PR description
In 50c62eab72678d51fb88c88fbeb81da2decca6f2, an override was done to attachments to disable deleting them, detaching them instead. As this is only required for German companies, a check can be added in the override to allow non-German companies to be able to delete their attachments. Also, another restriction was added for changing the fiscal country to make sure the flow for deleting German attachments cannot be bypassed. task-4500319 Forward-Port-Of: odoo/odoo#197006
Previously, if a request in the Nilvera Client failed due to connectivity issues, a traceback was thrown. This behavior caused upgrade CI failures because the internet is blocked and check_nilvera_customer would be triggered for newly created partners. This commit enhances the exception handling for all requests and fixes the upgrade CI issue by silently exiting the function when a connectivity problem is detected. no task ID. Forward-Port-Of: odoo/odoo#197797
Original PR description
Previously, if a request in the Nilvera Client failed due to connectivity issues, a traceback was thrown. This behavior caused upgrade CI failures because the internet is blocked and check_nilvera_customer would be triggered for newly created partners. This commit enhances the exception handling for all requests and fixes the upgrade CI issue by silently exiting the function when a connectivity problem is detected. no task ID. Forward-Port-Of: odoo/odoo#197797
Continuation of https://github.com/odoo/odoo/pull/185073 Forward-Port-Of: odoo/odoo#196811 Forward-Port-Of: odoo/odoo#190196
Original PR description
Continuation of https://github.com/odoo/odoo/pull/185073 Forward-Port-Of: odoo/odoo#196811 Forward-Port-Of: odoo/odoo#190196
This commit comes as an apology for the horrible code I wrote in PR #166043 in order for the installation of `l10n_hu_edi` to not fail if some of the default Hungarian taxes (defined in `l10n_hu`) had been deleted. Instead of rolling back the loading of the EDI-specific fields if some taxes don't exist, we can just load those fields on the taxes that do exist. Which is a lot cleaner and simpler. Sorry again! task-none Forward-Port-Of: odoo/odoo#196471
Original PR description
This commit comes as an apology for the horrible code I wrote in PR #166043 in order for the installation of `l10n_hu_edi` to not fail if some of the default Hungarian taxes (defined in `l10n_hu`) had been deleted. Instead of rolling back the loading of the EDI-specific fields if some taxes don't exist, we can just load those fields on the taxes that do exist. Which is a lot cleaner and simpler. Sorry again! task-none Forward-Port-Of: odoo/odoo#196471
We should only show the FACe/Factura-e section on invoice when the related company is located in Spain. opw-4397651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197117
Original PR description
We should only show the FACe/Factura-e section on invoice when the related company is located in Spain. opw-4397651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197117
There is an inconsistency in the product description during 3-step incoming shipments. How to reproduce the issue: - Enable three-step incoming shipments. - Create a product with a description for receipts (e.g., 'receipt') and a different description for internal transfers (e.g., 'transfer'). - Create a receipt with the product, validate it, and open the corresponding picking for the internal transfer. The move_line description_picking is taken from the receipt description instea
Original PR description
There is an inconsistency in the product description during 3-step incoming shipments. How to reproduce the issue: - Enable three-step incoming shipments. - Create a product with a description for receipts (e.g., 'receipt') and a different description for internal transfers (e.g., 'transfer'). - Create a receipt with the product, validate it, and open the corresponding picking for the internal transfer. The move_line description_picking is taken from the receipt description instead of the internal transfer description (it shows 'receipt' instead of 'transfer'). opw-4406582 PR with very similar issue: https://github.com/odoo/enterprise/pull/77283 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193996
Before this commit, when archiving an inheriting view from a main one (via the list and the form), the main record was not savable. This is due to 6f06420e4a9443c52dc0cb427f8f55eb4aecabce which automatically adds missing but useful fields in a view in readonly mode. This commit adds that field manually to be able to save the active field. opw-4534225 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---
Original PR description
Before this commit, when archiving an inheriting view from a main one (via the list and the form), the main record was not savable. This is due to 6f06420e4a9443c52dc0cb427f8f55eb4aecabce which automatically adds missing but useful fields in a view in readonly mode. This commit adds that field manually to be able to save the active field. opw-4534225 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#197137
In the context of grouping records on a Many2Many field (e.g. tags of tasks) in the list view, it's possible to select the same record multiple times. In such case, when modifying the selected records, there could be duplicated ids in the arguments of the different RPCs (write, unlink, call). Processing the same record multiple times in backend could cause unexpected issues. So in this PR, we filter out the duplicated records ids before each call, to work with a clean recordset in backend.
Original PR description
In the context of grouping records on a Many2Many field (e.g. tags of tasks) in the list view, it's possible to select the same record multiple times. In such case, when modifying the selected records, there could be duplicated ids in the arguments of the different RPCs (write, unlink, call). Processing the same record multiple times in backend could cause unexpected issues. So in this PR, we filter out the duplicated records ids before each call, to work with a clean recordset in backend. version-17.4 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195224
The `require_partner_bank_account` flag on the payment shouldn't require the `allow_out_payment` flag on it when the payment type is `inbound` as it leads to confusion. This generates an issue with the `l10n_it_riba` Ri.Ba. payment method. It requires the bank account, but the money is incoming, not outgoing. Old PR for saas-17.2: odoo/odoo#195312 Enterprise PR: odoo/enterprise#78959 Task [link](https://www.odoo.com/odoo/project/967/tasks/4497749) task-4497749 Forward-Port-Of: odoo/o
Original PR description
The `require_partner_bank_account` flag on the payment shouldn't require the `allow_out_payment` flag on it when the payment type is `inbound` as it leads to confusion. This generates an issue with the `l10n_it_riba` Ri.Ba. payment method. It requires the bank account, but the money is incoming, not outgoing. Old PR for saas-17.2: odoo/odoo#195312 Enterprise PR: odoo/enterprise#78959 Task [link](https://www.odoo.com/odoo/project/967/tasks/4497749) task-4497749 Forward-Port-Of: odoo/odoo#197141
When the modifier is empty we don't get any error in the fronted. It's just assumed as `False`. Since 6f06420e we have a new mechanism that adds fields to views as long as they are used in an modifier's expression. This unfortunately fails with a syntax error if the expression is empty. OTOH having an empty expression could be useful for development as a placeholder for further changes. The presence of empty expressions causes issues during the upgrade from <17.4 to higher versions. --- I
Original PR description
When the modifier is empty we don't get any error in the fronted. It's just assumed as `False`. Since 6f06420e we have a new mechanism that adds fields to views as long as they are used in an modifier's expression. This unfortunately fails with a syntax error if the expression is empty. OTOH having an empty expression could be useful for development as a placeholder for further changes. The presence of empty expressions causes issues during the upgrade from <17.4 to higher versions. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197281
### Issue: The curent compute method of the location_id field of quant packages is not accurate as it is currently set to the first existing quant and not to the only existing quant with a positive quantity for that package. ### Steps to reproduce (issue in barcode): - In the settings enable: Multi-Step Routes, Operations > Packages - Create a storable product - Update the on hand quantity: - 10 units in package PK in WH/STOCK - Inventory > Configuration > Warehouse Management > L
Original PR description
### Issue: The curent compute method of the location_id field of quant packages is not accurate as it is currently set to the first existing quant and not to the only existing quant with a positive…
### Issue:
The curent compute method of the location_id field of quant packages is not accurate as it is currently set to the first existing quant and not to the only existing quant with a positive quantity for that package.
### Steps to reproduce (issue in barcode):
- In the settings enable: Multi-Step Routes, Operations > Packages
- Create a storable product
- Update the on hand quantity:
- 10 units in package PK in WH/STOCK
- Inventory > Configuration > Warehouse Management > Locations
- Create 2 warehouse locations: WH/LOC1, WH/LOC2
- Go to the barcode app and proceed with the scans: i. Scan the internal transfer picking type ii. Scan WH/STOCK as a source location iii. Scan the package name (PK) iv. Scan WH/LOC1 as destination location
- Leave the barcode app without validation
- Go to the barcode app and proceed with the scans: i -> iii, iv'. Scan WH/LOC2 as destination location
- Validate the picking
- Proceed an other picking via the barcode app to follow up: i. Scan the internal transfer picking type ii. Scan WH/LOC2 as a source location iii. Scan the package name (PK)
#### > the package is not found and added. You rather trigger a notification: no package You are expected to scan one or more products or a package available at the picking location
### Cause of the issue:
After the picking validation, the location_id of the package should havebeen updated to WH/LOC2 but it is still WH/Stock since you have a reserved quantity on that quant and it was not cleaned:
https://github.com/odoo/odoo/blob/081215d1220d6a362087aa33c304a452893b1dca/addons/stock/models/stock_quant.py#L1482-L1490
opw-4574169
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#197824
Forward-Port-Of: odoo/odoo#197735This parameter should have been optional from the beginning. We changed it now because it causes problems when trying to use the TestEdi class with other Tests (Example: AR Website Sales) Forward-Port-Of: odoo/enterprise#79401 Forward-Port-Of: odoo/enterprise#78014
Original PR description
This parameter should have been optional from the beginning. We changed it now because it causes problems when trying to use the TestEdi class with other Tests (Example: AR Website Sales) Forward-Port-Of: odoo/enterprise#79401 Forward-Port-Of: odoo/enterprise#78014
- update the `co2_fee_min, health_indice` paramters values Task: 4563950 Forward-Port-Of: odoo/enterprise#78999
Original PR description
- update the `co2_fee_min, health_indice` paramters values Task: 4563950 Forward-Port-Of: odoo/enterprise#78999
Test that when creating a receipt or internal transfer using the barcode app, the description_picking field of the move_line is not empty. Steps to reproduce the issue: - Create a product with a description for receipts (e.g., 'receipt'). - In the barcode app, create a new receipt and add the product (leave it in draft). - In the inventory app, check the corresponding receipt. - The move_line has no description_picking, even though the product has one. community: https://github.com/o
Original PR description
Test that when creating a receipt or internal transfer using the barcode app, the description_picking field of the move_line is not empty. Steps to reproduce the issue: - Create a product with a description for receipts (e.g., 'receipt'). - In the barcode app, create a new receipt and add the product (leave it in draft). - In the inventory app, check the corresponding receipt. - The move_line has no description_picking, even though the product has one. community: https://github.com/odoo/odoo/pull/193996/files opw-4406582 Forward-Port-Of: odoo/enterprise#79349
This commit fixes an issue with knowledge's members permission computation. If the additional fields given to the method weren't valid fields, the computation would crash and return an error. With this fix we filter the valid additional_fields provided so that we only use those for the computation. task-4562838 Forward-Port-Of: odoo/enterprise#79221
Original PR description
This commit fixes an issue with knowledge's members permission computation. If the additional fields given to the method weren't valid fields, the computation would crash and return an error. With this fix we filter the valid additional_fields provided so that we only use those for the computation. task-4562838 Forward-Port-Of: odoo/enterprise#79221
Change the "up to this date" to "before this date", to specify that its upper limit is excluded. Otherwise, when you set 31/12/24 in this field and Odoo cancels all the entries up to 30/12/24 and leave the 31/12/24 entries, you'll be disappointed. Task [link](https://www.odoo.com/odoo/project/967/tasks/4447369) task-4447369 Forward-Port-Of: odoo/enterprise#79240 Forward-Port-Of: odoo/enterprise#79105
Original PR description
Change the "up to this date" to "before this date", to specify that its upper limit is excluded. Otherwise, when you set 31/12/24 in this field and Odoo cancels all the entries up to 30/12/24 and leave the 31/12/24 entries, you'll be disappointed. Task [link](https://www.odoo.com/odoo/project/967/tasks/4447369) task-4447369 Forward-Port-Of: odoo/enterprise#79240 Forward-Port-Of: odoo/enterprise#79105
The require_partner_bank_account flag on the payment shouldn't require the allow_out_payment flag on it when the payment type is inbound as it leads to confusion. This generates an issue with the l10n_it_riba RiBa payment method. It requires the bank account, but the money is incoming, not outgoing. Community PR: odoo/odoo#197141 Old Enterprise PR: odoo/enterprise#77901 Task [link](https://www.odoo.com/odoo/project/967/tasks/) task-4497749 Forward-Port-Of: odoo/enterprise#78959
Original PR description
The require_partner_bank_account flag on the payment shouldn't require the allow_out_payment flag on it when the payment type is inbound as it leads to confusion. This generates an issue with the l10n_it_riba RiBa payment method. It requires the bank account, but the money is incoming, not outgoing. Community PR: odoo/odoo#197141 Old Enterprise PR: odoo/enterprise#77901 Task [link](https://www.odoo.com/odoo/project/967/tasks/) task-4497749 Forward-Port-Of: odoo/enterprise#78959
### Issue: The barcode relies heavily on the data fetched in its LazyCache to work properly (in order to avoid rpc call's each time records data's are needed). However, some of these data's are loaded using search methods that ignore archived records by default. This leads to the creation of a cache that do not contains records that are expected to be there and hence will lead to tracebacks. ### Steps to reproduce: - In the settings enable "Multi-Step Routes" - Inventory > Configuratio
Original PR description
### Issue: The barcode relies heavily on the data fetched in its LazyCache to work properly (in order to avoid rpc call's each time records data's are needed). However, some of these data's are…
### Issue: The barcode relies heavily on the data fetched in its LazyCache to work properly (in order to avoid rpc call's each time records data's are needed). However, some of these data's are loaded using search methods that ignore archived records by default. This leads to the creation of a cache that do not contains records that are expected to be there and hence will lead to tracebacks. ### Steps to reproduce: - In the settings enable "Multi-Step Routes" - Inventory > Configuration > Warehouse Management > Locations - Create a new location WH/Stock/Love and a children location WH/Stock/Love/Layer - Create and confirm an internal transfer from WH/Stock to WH/Stock/Love for 1 unit of any storable product in stock - Change the location dest of the move line to WH/Stock/Love/Layer. - Archive the location WH/Stock/Love - Open your internal transfer in the barcode App. #### > Traceback: An error occured in the owl lifecycle... Record stock.location with id=... doesn't exist in the cache, it should return by the server at LazyBarcodeCache.getRecord. ### Cause of the issue: When entering the barcode man component, a call of the `get_barcode_data` is launched to fetch and populate the barcode data's and data are added to the barcode lazy cache in order to retreive record values without additional rpc calls: https://github.com/odoo/enterprise/blob/cc21959226e0bdb6b840f5023f08b2fdc0590023/stock_barcode/static/src/components/main.js#L76-L93 https://github.com/odoo/enterprise/blob/cc21959226e0bdb6b840f5023f08b2fdc0590023/stock_barcode/static/src/models/barcode_model.js#L32-L34 For instance, when redering the picking template, the location dest id will be retreived from the cache: https://github.com/odoo/enterprise/blob/cc21959226e0bdb6b840f5023f08b2fdc0590023/stock_barcode/static/src/components/line.js#L7-L9 https://github.com/odoo/enterprise/blob/cc21959226e0bdb6b840f5023f08b2fdc0590023/stock_barcode/static/src/models/barcode_picking_model.js#L1077-L1079 The traceback occurs because the record was actually never added to the data's and hence never added to the cache because part of the `get_barcode_data` call is performed with searchs that ignore completely the archived records (unless the 'active_test' key is in the context): https://github.com/odoo/enterprise/blob/cc21959226e0bdb6b840f5023f08b2fdc0590023/stock_barcode/models/stock_picking.py#L102-L106 opw-4423110 Forward-Port-Of: odoo/enterprise#79069 Forward-Port-Of: odoo/enterprise#78297
Forward-Port-Of: odoo/enterprise#79261
Original PR description
Forward-Port-Of: odoo/enterprise#79261
Since deductions are negative in the total, we need to invert accounts for them to be properly posted in the inverse credit and debit accounts. Forward-Port-Of: odoo/enterprise#79423
Original PR description
Since deductions are negative in the total, we need to invert accounts for them to be properly posted in the inverse credit and debit accounts. Forward-Port-Of: odoo/enterprise#79423