Daily updates from Odoo
Friday, December 27, 2024
40 changes
7 changes
Miscellaneous changes
In this commit: - Updated the error message for retrieving the Bearer Token during Viva Wallet payment requests. - The new message clearly states: `Unable to retrieve Viva Wallet Bearer Token: Please verify that the Client ID and Client Secret are correct` - This improvement provides more explicit guidance to users, making it easier to identify and resolve configuration issues. task- 4383616 Forward-Port-Of: odoo/odoo#191765
Original PR description
In this commit: - Updated the error message for retrieving the Bearer Token during Viva Wallet payment requests. - The new message clearly states: `Unable to retrieve Viva Wallet Bearer Token: Please verify that the Client ID and Client Secret are correct` - This improvement provides more explicit guidance to users, making it easier to identify and resolve configuration issues. task- 4383616 Forward-Port-Of: odoo/odoo#191765
This commit adds the parameter `sanitize_overridable=True` to the `description` field of `website_slides` slides. It means that the description can now be properly edited as an user with enough rights. The issue is that the `slide.description` field is sanitized after saving a `slide/*` page, which removes `<button>` elements. This is not easily testable in version 16.0 because no blocks contain `<button>` elements. However, starting from version 18.0, new blocks like the `accordion` block in
Original PR description
This commit adds the parameter `sanitize_overridable=True` to the `description` field of `website_slides` slides. It means that the description can now be properly edited as an user with enough rights. The issue is that the `slide.description` field is sanitized after saving a `slide/*` page, which removes `<button>` elements. This is not easily testable in version 16.0 because no blocks contain `<button>` elements. However, starting from version 18.0, new blocks like the `accordion` block include buttons, and these are removed after saving a `slide/*` page when they are dropped into it. opw-4273436 Forward-Port-Of: odoo/odoo#190620
Before this commit, even if no foldable link items were present in the navbar of a website header, the function to check if items needed to be hidden was still executed. After this commit, if no foldable items are present in the navbar, the function is not executed. Running the function when no items are present can, in rare cases, cause errors (e.g., starting from version 17.0, if the "sales 1" header template contains no links and the page is zoomed). This is why we addressed this issue
Original PR description
Before this commit, even if no foldable link items were present in the navbar of a website header, the function to check if items needed to be hidden was still executed. After this commit, if no foldable items are present in the navbar, the function is not executed. Running the function when no items are present can, in rare cases, cause errors (e.g., starting from version 17.0, if the "sales 1" header template contains no links and the page is zoomed). This is why we addressed this issue in this commit. opw-4390661 Forward-Port-Of: odoo/odoo#191708 Forward-Port-Of: odoo/odoo#191233
Chilean users cannot succesfully create the credit note (with document type 61) of a Vendori bill (type 46) because of a conflict on the document number input method - Open Vendor Bills journal and enable 'Use Documents?' - Create a Bill with document type '(46) Factura de Compra Electrónica' - Create the credit note - In the Wizard: select 'Full Refund', Document Type 61, Confirm Issue: The system blocks the action because the new move is missing the document number opw-4268371 For
Original PR description
Chilean users cannot succesfully create the credit note (with document type 61) of a Vendori bill (type 46) because of a conflict on the document number input method - Open Vendor Bills journal and enable 'Use Documents?' - Create a Bill with document type '(46) Factura de Compra Electrónica' - Create the credit note - In the Wizard: select 'Full Refund', Document Type 61, Confirm Issue: The system blocks the action because the new move is missing the document number opw-4268371 Forward-Port-Of: odoo/odoo#188481
**Current behavior before PR:** When transforming an image, if we click on transform button again, it resets the transformation of that image but transform button remain active. **Desired behavior after PR is merged:** Now, If transformation container is open and user clicks on transform button then image gets reset and button gets inactive as there is no transformation. task-4251662 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr For
Original PR description
**Current behavior before PR:** When transforming an image, if we click on transform button again, it resets the transformation of that image but transform button remain active. **Desired behavior after PR is merged:** Now, If transformation container is open and user clicks on transform button then image gets reset and button gets inactive as there is no transformation. task-4251662 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190556 Forward-Port-Of: odoo/odoo#189588
A new account template got the id pcg_468. The issue is that it is the same as a previous group. When you reload the CoA, it will try to access the data behind each xmlid of account template. It will then access a group template thinking it's an account, resulting in a bad field access and a traceback. Appeared due to a bad fw-port of https://github.com/odoo/odoo/commit/0ebf80b613d229ef5fb07ea97d406496f9df6254 (also fixed the typo in the code) --- I confirm I have signed the CL
Original PR description
A new account template got the id pcg_468. The issue is that it is the same as a previous group. When you reload the CoA, it will try to access the data behind each xmlid of account template. It will then access a group template thinking it's an account, resulting in a bad field access and a traceback. Appeared due to a bad fw-port of https://github.com/odoo/odoo/commit/0ebf80b613d229ef5fb07ea97d406496f9df6254 (also fixed the typo in the code) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191827
Issue 1 --- Trying to validate a receipt related to a landed cost account line for a product using a uom from a different uom category will raise a userError that do not allow you to validate the receipt. ### Steps to reproduce: - Create a product: - real time property valuation - average cost method - on ordered quantities control policy - UOM from an other category han "Unit" e.g. kg - Create and confirm a PO for 100 k units at 1.35 each - Create an invoice for
Original PR description
Issue 1 --- Trying to validate a receipt related to a landed cost account line for a product using a uom from a different uom category will raise a userError that do not allow you to validate the…
Issue 1
---
Trying to validate a receipt related to a landed cost account line for
a product using a uom from a different uom category will raise a
userError that do not allow you to validate the receipt.
### Steps to reproduce:
- Create a product:
- real time property valuation
- average cost method
- on ordered quantities control policy
- UOM from an other category han "Unit" e.g. kg
- Create and confirm a PO for 100 k units at 1.35 each
- Create an invoice for 23 k, receive 23k units and backorder
- Create a landed cost on the invoice for 23k units in the company currency units
- Post the invoice
- Create a second invoice for 27k units and post it
- Try to validate the receipt of the 27k units more units
> UserError: The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure kg > defined on the product.
### Cause of the issue:
Since Commit 32543ce9356f228d087d17a0ead1e0a80449e5de The landed_cost account lines related to a given stock move are also considered in the `_get_price_unit` call of stock moves:
https://github.com/odoo/odoo/blob/1b999e4b358eabe80cb3d636cd7bc348c5b85a1b/addons/purchase_stock/models/stock_move.py#L60
https://github.com/odoo/odoo/blob/1b999e4b358eabe80cb3d636cd7bc348c5b85a1b/addons/stock_landed_costs/models/purchase.py#L11-L16
However, the uom related to the landed cost account line might not match the uom category of the product related to the move. As such, this line will raise a UserError:
https://github.com/odoo/odoo/blob/da1f44c2296486c0267a7bdbbe3a314ada3aa679/addons/purchase_stock/models/stock_move.py#L70
https://github.com/odoo/odoo/blob/da1f44c2296486c0267a7bdbbe3a314ada3aa679/addons/uom/models/uom_uom.py#L223-L227
Issue 2
---
### Steps to reproduce
- Create a product invoiced on ordered quantities
- Create a PO and a bill for it, post the bill
- Receipt half the quantity
- Add a landed cost product on the PO, create a second bill for this landed cost product. Create and validate the landed cost.
- Receipt the second half quantity.
### Issue:
The valuation of the second transfer is too low
### Cause of the Issue 2:
To get the price unit for "on ordered qty" policy, We compute the ratio of already receipt value on already invoiced value:
https://github.com/odoo/odoo/blob/4f6353ec8a7306fbf63e95e8e02248d72f413aa3/addons/purchase_stock/models/stock_move.py#L84
The issue is the receipt value is increase by the landed costs value because the receipt valuation layer is linked to the landed cost valuation layer. But the product invoice line is not linked to the landed costs invoice line. Resulting in a invoice value under valuated.
This commit will ingnore the receipt values coming from landed costs so that the landed costs value will be added to the total invoiced value and not removed from the value here:
https://github.com/odoo/odoo/blob/cfb7a3593c5a4b313bdfd8628fe1b0dfe7e73823/addons/purchase_stock/models/stock_move.py#L72
*if* the landed cost has it's own invoice line.
Revert Commit 32543ce9356f228d087d17a0ead1e0a80449e5de
Authored-by: Whenrow <whe@odoo.com>
Issue 1: opw-4389366
Issue 2: opw-4354498
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#191892
Forward-Port-Of: odoo/odoo#1912258 changes
Enhancements to existing features
Point of Sale no longer needs extra country-specific customizations for blocking mixed refund and sales orders, because this behavior is now handled by default. This reduces duplicated logic and helps keep Chilean electronic invoicing and Belgian blackbox POS flows aligned with the standard process.
Original PR description
Community PR Odoo/Odoo#189329 changes the return value of the `PosOrder` method `doNotAllowRefundAndSales` to `true`, so that some patches are no longer relevant. Community PR: 189329 task-4369388
Miscellaneous changes
**Before this PR:** In studio, in some report, trying to add a video using video commnad throws traceback. Adding a video doesn't make sense in a report so the video command shouldn't be available in report at the first place. **After this PR:** This commit aims to remove video command from studio report. task-4285231 Forward-Port-Of: odoo/enterprise#73971
Original PR description
**Before this PR:** In studio, in some report, trying to add a video using video commnad throws traceback. Adding a video doesn't make sense in a report so the video command shouldn't be available in report at the first place. **After this PR:** This commit aims to remove video command from studio report. task-4285231 Forward-Port-Of: odoo/enterprise#73971
Currently, while we send the carrier and the tracking number, we don't send the shipping method. While this doesn't block anything, this lead to Amazon sending warning about incomplete shipping information. Now, we will send: - Carrier name : the delivery_type if any relevant, else the carrier name as fallback. eg: "DHL" - The shipping method: the carrier name. eg: "DHL Express" or "Parcel" opw-4393663 Forward-Port-Of: odoo/enterprise#76156
Original PR description
Currently, while we send the carrier and the tracking number, we don't send the shipping method. While this doesn't block anything, this lead to Amazon sending warning about incomplete shipping information. Now, we will send: - Carrier name : the delivery_type if any relevant, else the carrier name as fallback. eg: "DHL" - The shipping method: the carrier name. eg: "DHL Express" or "Parcel" opw-4393663 Forward-Port-Of: odoo/enterprise#76156
Update the open sale/purchase journals query to include credit notes/refunds, and override the 'Bills to validate' filter to be consistent with the dashboard query which is overridden for `account_3way_match` Forward-Port-Of: odoo/enterprise#74765
Original PR description
Update the open sale/purchase journals query to include credit notes/refunds, and override the 'Bills to validate' filter to be consistent with the dashboard query which is overridden for `account_3way_match` Forward-Port-Of: odoo/enterprise#74765
In this commit: ================ This commit updates text strings Task-4364406 Related community PR-https://github.com/odoo/odoo/pull/189263 Forward-Port-Of: odoo/enterprise#76218 Forward-Port-Of: odoo/enterprise#74949
Original PR description
In this commit: ================ This commit updates text strings Task-4364406 Related community PR-https://github.com/odoo/odoo/pull/189263 Forward-Port-Of: odoo/enterprise#76218 Forward-Port-Of: odoo/enterprise#74949
Previously, synchronization management was faulty when two devices created a command at the same time. One would override the other. To overcome this problem, when sending the command to the server, we check whether the table used by the command already contains a command. If so, they are merged. When different devices use the same PoS, when an order is created on one of them, it is directly synchronized with the others. This makes it possible to calculate the various table states with gre
Original PR description
Previously, synchronization management was faulty when two devices created a command at the same time. One would override the other. To overcome this problem, when sending the command to the server, we check whether the table used by the command already contains a command. If so, they are merged. When different devices use the same PoS, when an order is created on one of them, it is directly synchronized with the others. This makes it possible to calculate the various table states with greater precision. As in Master, orders are now identified by UUID rather than ID. The replaceDataByKey function is no longer used; what it used to do is now in loadData. All these fixes are very important in view of the problems encountered by some customers. Forward-Port-Of: odoo/enterprise#75979
Users creating a debit note from an invoice will need to pay attention to the document type that, with the EDI module installed, is set by taking into account only the partner 'Taxpayer Type' and not the move type (i.e. debit note) - Have an invoice with document type "(33) Factura Electrónica" accepted by SII - Create the debit note from the invoice Issue: default document type will be 33, while it should be 56 opw-4292111 Forward-Port-Of: odoo/enterprise#76011
Original PR description
Users creating a debit note from an invoice will need to pay attention to the document type that, with the EDI module installed, is set by taking into account only the partner 'Taxpayer Type' and not the move type (i.e. debit note) - Have an invoice with document type "(33) Factura Electrónica" accepted by SII - Create the debit note from the invoice Issue: default document type will be 33, while it should be 56 opw-4292111 Forward-Port-Of: odoo/enterprise#76011
After this commit : - Quantity in every test case has been updated from float to integer values. task - 4403770 Forward-Port-Of: odoo/enterprise#75863
Original PR description
After this commit : - Quantity in every test case has been updated from float to integer values. task - 4403770 Forward-Port-Of: odoo/enterprise#75863
23 changes
Resolved issues and error corrections
This update bumps a small supporting dependency to stop unnecessary missing-file warnings when Odoo starts or is imported. It helps keep logs cleaner and reduces confusion for teams monitoring system health.
Original PR description
1.2.0 requires GCC profiling records which aren't available on the system Description of the issue/feature this PR addresses: https://github.com/odoo/odoo/issues/191873 Current behavior before PR: Every odoo start/import throws an warning about missing gcda files Desired behavior after PR is merged: No warning about missing files on odoo start/import --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale tests now verify that subcategories appear directly after their parent category when selected. This helps prevent regressions in product navigation and supports a more predictable cashier experience.
Original PR description
In this commit: === - Updated the test case to ensure that when clicking on a parent category, its subcategories are displayed immediately after the parent category.
This fix adjusts the background styling of the editor toolbar and link popover dropdowns in dark mode. It creates a smoother, more consistent visual experience for users editing content in the HTML editor.
Original PR description
Description of the issue this PR addresses: This PR changes the background color of toolbar and link popover dropdown for a smoother UI. task-4356656 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a small error that prevented the system from properly checking whether a required electronic invoicing field exists. It helps avoid issues when processing UBL/CII electronic invoice data after a recent code update.
Original PR description
Looks like the rebase in #191457 introduce a small mistake making the field exist check not working properly. This commit should fix the issue.
The link popover now shows only the button style option that is relevant outside the website module, removing duplicate choices that looked the same. This reduces confusion for users and makes the editor easier to maintain, with tests updated to match the streamlined behavior.
Original PR description
Before this commit, the link popover contained three button styles, default, fill, and flat, which were visually identical. Here’s a summary of each: default: Based on the website module and influenced by the theme. fill: Not affected by theme choice. flat: Specific to the website module. After this commit, the redundant default and flat styles have been removed, as they are only relevant within the website module. The code has been cleaned up to improve maintainability, and tests have been updated to reflect these changes. task-4240795 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in the HTML editor where replacing all selected text could unexpectedly lose the current font styling. Users can now select all content and type new text while keeping the intended style, making editing more predictable.
Original PR description
Description of the issue this PR addresses: Current behavior before PR: Previously, typing after selecting all text using Ctrl+A would reset the font style of the anchorNode of the selection. Desired behavior after PR is merged: Typing after selecting all text using Ctrl+A keeps the font style of the anchorNode of the selection. task-4426710 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Link preview descriptions in the HTML editor now display special characters properly instead of showing encoded text. This makes link previews easier to read and more polished for users editing content.
Original PR description
**Current behavior before PR:** In some url, opening link preview displays special characters as string instead of parsed characters inside description of link preview popover. **Desired behavior after PR is merged:** Now special characters are getting parsed before displaying on popover. task-4345237 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The video insertion option is no longer shown when editing reports in Studio. This prevents users from triggering an error with an action that is not relevant for printable reports.
Original PR description
**Before this PR:** In studio, in some report, trying to add a video using video commnad throws traceback. Adding a video doesn't make sense in a report so the video command shouldn't be available in report at the first place. **After this PR:** This commit aims to remove video command from studio report. task-4285231
The Helpdesk SLA status report graph has been simplified by removing extra fields that made it harder to read. This makes the report clearer for teams reviewing SLA performance without changing the underlying data or process.
Original PR description
This commit's purpose is to clean up the graph view of the sla report analysis model. Some fields were added on the view by a generic improvement task for to handle the widget 'float_time' with grap view. In this case, those fields are a nuisance for readability, so we're getting rid of them. target version 18.0 - master task - 4351830
Documentation and clarification updates
This pull request adds Dorin Hongu's signed Individual Contributor License Agreement to the project's records. It helps ensure contributions are properly authorized and documented for legal compliance.
Original PR description
Add individual CLA for Dorin Hongu This commit adds the Individual Contributor License Agreement (CLA) for Dorin Hongu. It includes their signature, authorization statement, and contact information as per standard requirements. 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 a contributor license agreement record for an individual contributor. It supports Odoo's legal compliance process by documenting that the contributor has confirmed the required agreement before contributing.
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
Issue 1 --- Trying to validate a receipt related to a landed cost account line for a product using a uom from a different uom category will raise a userError that do not allow you to validate the receipt. ### Steps to reproduce: - Create a product: - real time property valuation - average cost method - on ordered quantities control policy - UOM from an other category han "Unit" e.g. kg - Create and confirm a PO for 100 k units at 1.35 each - Create an invoice for
Original PR description
Issue 1 --- Trying to validate a receipt related to a landed cost account line for a product using a uom from a different uom category will raise a userError that do not allow you to validate the…
Issue 1
---
Trying to validate a receipt related to a landed cost account line for
a product using a uom from a different uom category will raise a
userError that do not allow you to validate the receipt.
### Steps to reproduce:
- Create a product:
- real time property valuation
- average cost method
- on ordered quantities control policy
- UOM from an other category han "Unit" e.g. kg
- Create and confirm a PO for 100 k units at 1.35 each
- Create an invoice for 23 k, receive 23k units and backorder
- Create a landed cost on the invoice for 23k units in the company currency units
- Post the invoice
- Create a second invoice for 27k units and post it
- Try to validate the receipt of the 27k units more units
> UserError: The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure kg > defined on the product.
### Cause of the issue:
Since Commit 32543ce9356f228d087d17a0ead1e0a80449e5de The landed_cost account lines related to a given stock move are also considered in the `_get_price_unit` call of stock moves:
https://github.com/odoo/odoo/blob/1b999e4b358eabe80cb3d636cd7bc348c5b85a1b/addons/purchase_stock/models/stock_move.py#L60
https://github.com/odoo/odoo/blob/1b999e4b358eabe80cb3d636cd7bc348c5b85a1b/addons/stock_landed_costs/models/purchase.py#L11-L16
However, the uom related to the landed cost account line might not match the uom category of the product related to the move. As such, this line will raise a UserError:
https://github.com/odoo/odoo/blob/da1f44c2296486c0267a7bdbbe3a314ada3aa679/addons/purchase_stock/models/stock_move.py#L70
https://github.com/odoo/odoo/blob/da1f44c2296486c0267a7bdbbe3a314ada3aa679/addons/uom/models/uom_uom.py#L223-L227
Issue 2
---
### Steps to reproduce
- Create a product invoiced on ordered quantities
- Create a PO and a bill for it, post the bill
- Receipt half the quantity
- Add a landed cost product on the PO, create a second bill for this landed cost product. Create and validate the landed cost.
- Receipt the second half quantity.
### Issue:
The valuation of the second transfer is too low
### Cause of the Issue 2:
To get the price unit for "on ordered qty" policy, We compute the ratio of already receipt value on already invoiced value:
https://github.com/odoo/odoo/blob/4f6353ec8a7306fbf63e95e8e02248d72f413aa3/addons/purchase_stock/models/stock_move.py#L84
The issue is the receipt value is increase by the landed costs value because the receipt valuation layer is linked to the landed cost valuation layer. But the product invoice line is not linked to the landed costs invoice line. Resulting in a invoice value under valuated.
This commit will ingnore the receipt values coming from landed costs so that the landed costs value will be added to the total invoiced value and not removed from the value here:
https://github.com/odoo/odoo/blob/cfb7a3593c5a4b313bdfd8628fe1b0dfe7e73823/addons/purchase_stock/models/stock_move.py#L72
*if* the landed cost has it's own invoice line.
Revert Commit 32543ce9356f228d087d17a0ead1e0a80449e5de
Authored-by: Whenrow <whe@odoo.com>
Issue 1: opw-4389366
Issue 2: opw-4354498
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#191892
Forward-Port-Of: odoo/odoo#191225A new account template got the id pcg_468. The issue is that it is the same as a previous group. When you reload the CoA, it will try to access the data behind each xmlid of account template. It will then access a group template thinking it's an account, resulting in a bad field access and a traceback. Appeared due to a bad fw-port of https://github.com/odoo/odoo/commit/0ebf80b613d229ef5fb07ea97d406496f9df6254 (also fixed the typo in the code) --- I confirm I have signed the CL
Original PR description
A new account template got the id pcg_468. The issue is that it is the same as a previous group. When you reload the CoA, it will try to access the data behind each xmlid of account template. It will then access a group template thinking it's an account, resulting in a bad field access and a traceback. Appeared due to a bad fw-port of https://github.com/odoo/odoo/commit/0ebf80b613d229ef5fb07ea97d406496f9df6254 (also fixed the typo in the code) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191827
Description of the issue this PR addresses: Current behavior before PR: When opening the chatGPT Translate dialog or Alternatives dialog without any selected text it used to provide incorrect output. Desired behavior after PR is merged: Ensure that both dialogs display an error message if no text is selected. task-4325385 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186868
Original PR description
Description of the issue this PR addresses: Current behavior before PR: When opening the chatGPT Translate dialog or Alternatives dialog without any selected text it used to provide incorrect output. Desired behavior after PR is merged: Ensure that both dialogs display an error message if no text is selected. task-4325385 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186868
**Current behavior before PR:** When transforming an image, if we click on transform button again, it resets the transformation of that image but transform button remain active. **Desired behavior after PR is merged:** Now, If transformation container is open and user clicks on transform button then image gets reset and button gets inactive as there is no transformation. task-4251662 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr For
Original PR description
**Current behavior before PR:** When transforming an image, if we click on transform button again, it resets the transformation of that image but transform button remain active. **Desired behavior after PR is merged:** Now, If transformation container is open and user clicks on transform button then image gets reset and button gets inactive as there is no transformation. task-4251662 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190556 Forward-Port-Of: odoo/odoo#189588
Chilean users cannot succesfully create the credit note (with document type 61) of a Vendori bill (type 46) because of a conflict on the document number input method - Open Vendor Bills journal and enable 'Use Documents?' - Create a Bill with document type '(46) Factura de Compra Electrónica' - Create the credit note - In the Wizard: select 'Full Refund', Document Type 61, Confirm Issue: The system blocks the action because the new move is missing the document number opw-4268371 For
Original PR description
Chilean users cannot succesfully create the credit note (with document type 61) of a Vendori bill (type 46) because of a conflict on the document number input method - Open Vendor Bills journal and enable 'Use Documents?' - Create a Bill with document type '(46) Factura de Compra Electrónica' - Create the credit note - In the Wizard: select 'Full Refund', Document Type 61, Confirm Issue: The system blocks the action because the new move is missing the document number opw-4268371 Forward-Port-Of: odoo/odoo#188481
This commit adds the parameter `sanitize_overridable=True` to the `description` field of `website_slides` slides. It means that the description can now be properly edited as an user with enough rights. The issue is that the `slide.description` field is sanitized after saving a `slide/*` page, which removes `<button>` elements. This is not easily testable in version 16.0 because no blocks contain `<button>` elements. However, starting from version 18.0, new blocks like the `accordion` block in
Original PR description
This commit adds the parameter `sanitize_overridable=True` to the `description` field of `website_slides` slides. It means that the description can now be properly edited as an user with enough rights. The issue is that the `slide.description` field is sanitized after saving a `slide/*` page, which removes `<button>` elements. This is not easily testable in version 16.0 because no blocks contain `<button>` elements. However, starting from version 18.0, new blocks like the `accordion` block include buttons, and these are removed after saving a `slide/*` page when they are dropped into it. opw-4273436 Forward-Port-Of: odoo/odoo#190620
In this commit: - Updated the error message for retrieving the Bearer Token during Viva Wallet payment requests. - The new message clearly states: `Unable to retrieve Viva Wallet Bearer Token: Please verify that the Client ID and Client Secret are correct` - This improvement provides more explicit guidance to users, making it easier to identify and resolve configuration issues. task- 4383616 Forward-Port-Of: odoo/odoo#191765
Original PR description
In this commit: - Updated the error message for retrieving the Bearer Token during Viva Wallet payment requests. - The new message clearly states: `Unable to retrieve Viva Wallet Bearer Token: Please verify that the Client ID and Client Secret are correct` - This improvement provides more explicit guidance to users, making it easier to identify and resolve configuration issues. task- 4383616 Forward-Port-Of: odoo/odoo#191765
Google recently updated the Firebase API and deprecated support for the version we are currently using (v6.3.4). As a result, Odoo push notifications are no longer functional. This PR updates the dependencies and API calls to align with the latest Firebase API, ensuring that push notifications can once again be sent from Odoo. see: https://firebase.google.com/docs/cloud-messaging/migrate-v1 task-4247811 Forward-Port-Of: odoo/enterprise#76145 Forward-Port-Of: odoo/enterprise#73390
Original PR description
Google recently updated the Firebase API and deprecated support for the version we are currently using (v6.3.4). As a result, Odoo push notifications are no longer functional. This PR updates the dependencies and API calls to align with the latest Firebase API, ensuring that push notifications can once again be sent from Odoo. see: https://firebase.google.com/docs/cloud-messaging/migrate-v1 task-4247811 Forward-Port-Of: odoo/enterprise#76145 Forward-Port-Of: odoo/enterprise#73390
Currently, while we send the carrier and the tracking number, we don't send the shipping method. While this doesn't block anything, this lead to Amazon sending warning about incomplete shipping information. Now, we will send: - Carrier name : the delivery_type if any relevant, else the carrier name as fallback. eg: "DHL" - The shipping method: the carrier name. eg: "DHL Express" or "Parcel" opw-4393663 Forward-Port-Of: odoo/enterprise#76156
Original PR description
Currently, while we send the carrier and the tracking number, we don't send the shipping method. While this doesn't block anything, this lead to Amazon sending warning about incomplete shipping information. Now, we will send: - Carrier name : the delivery_type if any relevant, else the carrier name as fallback. eg: "DHL" - The shipping method: the carrier name. eg: "DHL Express" or "Parcel" opw-4393663 Forward-Port-Of: odoo/enterprise#76156
Users creating a debit note from an invoice will need to pay attention to the document type that, with the EDI module installed, is set by taking into account only the partner 'Taxpayer Type' and not the move type (i.e. debit note) - Have an invoice with document type "(33) Factura Electrónica" accepted by SII - Create the debit note from the invoice Issue: default document type will be 33, while it should be 56 opw-4292111 Forward-Port-Of: odoo/enterprise#76011
Original PR description
Users creating a debit note from an invoice will need to pay attention to the document type that, with the EDI module installed, is set by taking into account only the partner 'Taxpayer Type' and not the move type (i.e. debit note) - Have an invoice with document type "(33) Factura Electrónica" accepted by SII - Create the debit note from the invoice Issue: default document type will be 33, while it should be 56 opw-4292111 Forward-Port-Of: odoo/enterprise#76011
**Current behavior before PR:** - In web studio, when text is selected and the page is scrolled, the toolbar does not stay aligned with the selected text. **Desired behavior after PR is merged:** - Now, when scrolling in web studio, the toolbar remains fixed to the initial selection. task-4317313 Forward-Port-Of: odoo/enterprise#73656
Original PR description
**Current behavior before PR:** - In web studio, when text is selected and the page is scrolled, the toolbar does not stay aligned with the selected text. **Desired behavior after PR is merged:** - Now, when scrolling in web studio, the toolbar remains fixed to the initial selection. task-4317313 Forward-Port-Of: odoo/enterprise#73656
In a POS restaurant order, when reducing the product quantity of an order line, the reduced display line in the preparation display was always the first one created, regardless of which order line was changed. Steps to reproduce: 1. In the POS restaurant, add a product with a quantity of 2 and an internal note. Confirm the order. 2. Add another order with the same product and internal note but with a quantity of 5. 3. In the kitchen display, change the stage of the first display line
Original PR description
In a POS restaurant order, when reducing the product quantity of an order line, the reduced display line in the preparation display was always the first one created, regardless of which order line…
In a POS restaurant order, when reducing the product quantity of an order line, the reduced display line in the preparation display was always the first one created, regardless of which order line was changed. Steps to reproduce: 1. In the POS restaurant, add a product with a quantity of 2 and an internal note. Confirm the order. 2. Add another order with the same product and internal note but with a quantity of 5. 3. In the kitchen display, change the stage of the first display line (quantity 2) from "To Cook" to "Ready." 4. In the POS, reduce the quantity of the second order line (quantity 5) to 4. Issue: The system reduces the quantity of the first display line (the one in the "Ready" stage). Cause: In `_process_preparation_changes` of `pos_order.py` in the `pos_preparation_display` module, display lines are filtered and sorted based on their creation order. However, since there is no 1-to-1 relation between display lines and order lines, it is impossible to directly target specific display lines. Fix: After this commit, display lines are now sorted based on their stage. Priority for quantity reduction is given to the line in the earliest stage. opw-4354093 Forward-Port-Of: odoo/enterprise#75565
2 changes
Resolved issues and error corrections
This update addresses a technical issue where an outdated element was being used in the website's sales functionality. This change ensures the website's sales features continue to operate correctly and avoids potential problems with future updates. It's a routine maintenance fix.
Original PR description
This commit is a backport of https://github.com/odoo/enterprise/commit/697d69d85e9812bdb2329d7604f57c940ae70135 Community pr: https://github.com/odoo/odoo/pull/187674
This update corrects a technical issue preventing Amazon from correctly receiving shipping information, which was causing warning messages. We've now included the shipping method (e.g., 'Express' or 'Parcel') alongside the carrier name, ensuring Amazon has complete details and avoiding disruptions to order fulfillment.
Original PR description
Currently, while we send the carrier and the tracking number, we don't send the shipping method. While this doesn't block anything, this lead to Amazon sending warning about incomplete shipping information. Now, we will send: - Carrier name : the delivery_type if any relevant, else the carrier name as fallback. eg: "DHL" - The shipping method: the carrier name. eg: "DHL Express" or "Parcel" opw-4393663 Forward-Port-Of: odoo/enterprise#76156