Daily updates from Odoo
Tuesday, February 18, 2025
48 changes
3 changes
Resolved issues and error corrections
This fix prevents plain text messages from being mistaken for HTML content, such as links or other rich message features. Users should see fewer incorrect highlights or message behaviors when searching and viewing messages in Discuss and mail-related areas.
Original PR description
When message content is not markup(), it will not render its content as HTML but as text when using t-out. This case was not taken into account when manually processing the content, leading to incorrectly detecting links or other features within purely text content. Those are now properly ignored.
Miscellaneous changes
Refactor the `_run_manufacture` method in the `stock.rule` model to have a separate method to build the domain used to find an existing manufacturing order that can handle the procurement request. Having a separate method provides an easier way to extend the domain in other modules. A similar approach is already used in the `_run_buy` method. Description of the issue/feature this PR addresses: Patching the entire `_run_manufacture` method is required to change the MO domain. Current behav
Original PR description
Refactor the `_run_manufacture` method in the `stock.rule` model to have a separate method to build the domain used to find an existing manufacturing order that can handle the procurement request. Having a separate method provides an easier way to extend the domain in other modules. A similar approach is already used in the `_run_buy` method. Description of the issue/feature this PR addresses: Patching the entire `_run_manufacture` method is required to change the MO domain. Current behavior before PR: The domain is built inside the `_run_manufacture` method Desired behavior after PR is merged: The domain is built in a dedicated method that can be easily overwritten in custom modules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196156
Currently, a traceback is occurring when the user tries to create a new put-away record and remove the `location_in_id`. To reproduce this issue: 1) Install Inventory 2) Enable multi-step routes from inventory settings 3) Create a new putaway rules record from inventory configuration 4) Remove the `when product arrives in` value Error:- ``` TypeError: startswith first arg must be str or a tuple of str, not bool ``` When the user removes the `location_in_id`, an onchange meth
Original PR description
Currently, a traceback is occurring when the user tries to create a new put-away record and remove the `location_in_id`. To reproduce this issue: 1) Install Inventory 2) Enable multi-step routes from…
Currently, a traceback is occurring when the user tries to create a new put-away record and remove the `location_in_id`. To reproduce this issue: 1) Install Inventory 2) Enable multi-step routes from inventory settings 3) Create a new putaway rules record from inventory configuration 4) Remove the `when product arrives in` value Error:- ``` TypeError: startswith first arg must be str or a tuple of str, not bool ``` When the user removes the `location_in_id`, an onchange method `_onchange_location_in` triggers. https://github.com/odoo/odoo/blob/239d18c8689d38e11783716b7e14a5204daed98a/addons/stock/models/product_strategy.py#L80-L83 We get the `loc_in` value as an empty recordset, because the user removed the `location_in_id` value. So it will lead to the above traceback from the below line https://github.com/odoo/odoo/blob/239d18c8689d38e11783716b7e14a5204daed98a/addons/stock/models/stock_location.py#L453-L455 sentry-6210564390 Forward-Port-Of: odoo/odoo#195555
8 changes
Enhancements to existing features
This update aligns several parts of Odoo with newer message recipient behavior. It helps keep salary offers, knowledge discussions, Studio tests, and WhatsApp security checks consistent with the latest communication changes.
Code cleanup and technical improvements
Point of Sale number handling now uses actual rounding precision instead of only decimal counts when comparing or rounding values. This improves accuracy for currencies and units that round to values like 0.05, 0.1, 5, or 10, reducing inconsistencies in payments, quantities, and fiscal documents.
Original PR description
https://github.com/odoo/odoo/pull/197447
Miscellaneous changes
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
task-4410808 community: https://github.com/odoo/odoo/pull/197583 Forward-Port-Of: odoo/enterprise#79237
Original PR description
task-4410808 community: https://github.com/odoo/odoo/pull/197583 Forward-Port-Of: odoo/enterprise#79237
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
Scenario ======== the subscription cron that automate the payment, start a payment transaction get the response and post process the the payment. In the meanwhile, the webhook receive also the response and try to post a message on the invoice in _log_message_on_linked_documents This lead to concurrent update on the invoice Solution ======== use _get_invoices_to_notify to remove the invoice currenctly handled by the invoice cron from the payment notification. The notification won
Original PR description
Scenario ======== the subscription cron that automate the payment, start a payment transaction get the response and post process the the payment. In the meanwhile, the webhook receive also the response and try to post a message on the invoice in _log_message_on_linked_documents This lead to concurrent update on the invoice Solution ======== use _get_invoices_to_notify to remove the invoice currenctly handled by the invoice cron from the payment notification. The notification won't appear on the invoice in this flow, that's not a problem. Payment notification is also set on the sale order Forward-Port-Of: odoo/enterprise#79125
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
Forward-Port-Of: odoo/enterprise#79261
Original PR description
Forward-Port-Of: odoo/enterprise#79261
37 changes
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
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 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-prPoint 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 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
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
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
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
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