Daily updates from Odoo
Navigate
Branch
Thursday, August 8, 2024
49 changes
23 changes
Resolved issues and error corrections
This fixes an issue where IoT devices could be blocked from connecting to Odoo's live update service because they do not send browser version information. The check now applies only to browser connections, avoiding unnecessary IoT device updates and helping existing deployments keep working.
Original PR description
Since [1], outdated websocket connections are refused by the server. However, the IOT connects to the websocket endpoint without passing any version. In order to pass the version, IOT devices should be updated which is cumbersome. This PR fixes the issue by enforcing this check for browsers only. [1]: https://github.com/odoo/odoo/pull/174962
Fixed an issue where Indian POS receipts did not show tax information in the HSN summary for products with HSN codes. This ensures receipts include the expected tax breakdown, helping businesses provide accurate billing information.
Original PR description
Steps to reproduce : -------------------------- - Install pos and l10n_in - Go to products - Create a product with HSN code and set tax - Open a session - Add that product to cart - Order and pay the bill Issue : ------- Opened reciept doesn't contain tax information on the HSN summary section Cause : --------- Trying to fetch data which wasn't sent from arguments causing the related computations NaN and 0. Fix : ----- Passed the argument correctly. task: 4095698
This fixes how Point of Sale calculates taxed list prices by using the correct fiscal position for each order, including orders that have already been paid. It helps prevent inaccurate displayed or computed prices in specific checkout scenarios.
Original PR description
Before this commit, the computation of the orderLine taxed list price incorrectly used the selected order's fiscal position, even for paid orders. This could lead to inaccurate pricing in certain scenarios. opw-4093746 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Currently, If 'MerchantTrns' is not available due to failed transactions, The System only sends a notification but does not return it. therefore errors occur from here [1] due to the unavailable of 'MerchantTrns'. link [1]: https://github.com/odoo/odoo/blob/ede5da1f72088ac1f78c9bc5206ccd666dce8c3d/addons/pos_viva_wallet/models/pos_payment_method.py#L118 To resolve this issue, return a send notification if 'MerchantTrns' is not available in 'data_webhook'. Related PR: https://github.com
Original PR description
Currently, If 'MerchantTrns' is not available due to failed transactions, The System only sends a notification but does not return it. therefore errors occur from here [1] due to the unavailable of 'MerchantTrns'. link [1]: https://github.com/odoo/odoo/blob/ede5da1f72088ac1f78c9bc5206ccd666dce8c3d/addons/pos_viva_wallet/models/pos_payment_method.py#L118 To resolve this issue, return a send notification if 'MerchantTrns' is not available in 'data_webhook'. Related PR: https://github.com/odoo/odoo/pull/171764 Sentry - 5466498742 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174801
### Steps to reproduce: - Install Purchase and Accounting - Go in Accounting > Configuration > Accounting > Taxes - Select the line with "Tax Type" equal to "Purchases" - In advanced options tick "Included in Price" - In the Purchase app create a new RFQ and add the tax - Confirm the order and receive the products - In the Purchase Order form view go in Action > Accrued Expense Entry - Change the date to a month from now, lines should appear - These lines have the price including the ta
Original PR description
### Steps to reproduce: - Install Purchase and Accounting - Go in Accounting > Configuration > Accounting > Taxes - Select the line with "Tax Type" equal to "Purchases" - In advanced options tick "Included in Price" - In the Purchase app create a new RFQ and add the tax - Confirm the order and receive the products - In the Purchase Order form view go in Action > Accrued Expense Entry - Change the date to a month from now, lines should appear - These lines have the price including the taxes, it should be without ### Cause: The calculation of the problematic price is `qty_to_invoice * price_unit`, which is problematic with included taxes. ### Solution: Instead of calculating the price we use the `price_subtotal` calculated by the `compute_all` method. We can not use `price_subtotal` of the line as it includes the whole quantity and not only the quantity to invoice. opw-4045737 Forward-Port-Of: odoo/odoo#175931 Forward-Port-Of: odoo/odoo#173662
Issue 1: --- ### Steps to reproduce: - Create a storable product P tracked by SN - Create a consumable (or a storable with 5 units on hand) product COMP 1 and a storable product COMP 2 (without units on hand) - Create a BOM for P with an operation op 1 and two component lines: - 1 x COMP 1 consumed in op 1 - 1 x COMP 2 consumed in op 1 - Create and confirm an MO for 5 units of P - Go to the shopfloor and click on register production. **> the qty is updated to 1 on COMP 2
Original PR description
Issue 1: --- ### Steps to reproduce: - Create a storable product P tracked by SN - Create a consumable (or a storable with 5 units on hand) product COMP 1 and a storable product COMP 2 (without units…
Issue 1:
---
### Steps to reproduce:
- Create a storable product P tracked by SN
- Create a consumable (or a storable with 5 units on hand) product
COMP 1 and a storable product COMP 2 (without units on hand)
- Create a BOM for P with an operation op 1 and two component lines:
- 1 x COMP 1 consumed in op 1
- 1 x COMP 2 consumed in op 1
- Create and confirm an MO for 5 units of P
- Go to the shopfloor and click on register production.
**> the qty is updated to 1 on COMP 2 but to 5/1 on COMP 1**
As such, if you click on the 5/1, 5 units of COMP 1 will be consumed to produce only one unit of P
### Cause of the issue:
When you confirm the MO, since Comp 1 is a consumable its quantity is automatically set to 5.0 because reservation are bypassed. On the other hand, since Comp 2 is a storable without on hand qty, its quantity stays at 0.0. When you click on register production, or on the plus sign will trigger a call of the "_set_qty_producing" method. This call will update the qty_producing of the final product:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1214-L1218
However, the update of the qty consumed by the raw move will be bypassed because of these lines:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1225-L1226
https://github.com/odoo/enterprise/blob/0646022d7726a0cc183b191ca5be4e4bb4368f93/mrp_workorder/models/stock_move.py#L10-L13
And the quantity will therefore not be updated by these lines:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1228-L1231
However, as the quantity is not set to 0, it will be displayed as "quantity/should_consume_qty" and clicking on the raw move line will not update the quantity so 5 units will be marked as consumed ("picked").
Issue 2
---
### Steps to reproduce:
- Enable Multi-Step routes in the settings
- Go Inventory > Configuration > Warehouse Management > Warehouses
- Enable 2-step manufacturing on your Warehouse
- Create 2 storable products:
- product P: tracked by SN
- product COMP: tracked by lot
- Update the "on hand qty" of COMP by creating a lot with 10 units
- Create and confirm a manufacturing order for 1 unit of P
- Assign a serial number to the final product
- Validate the transfer of components from stock to preproduction (The lot is automatically used on this transfer as it is available)
### Expected behavior:
Since the lot of COMP was used in the transfer from stock to preproduction it should be displayed on the raw move of the MO.
### Current behavior:
The raw move is not updated.
Note: if the transfer is validated before we assign a serial number to the final product, the lot of the component is correctly updated.
### Cause of the issue:
When the 'action_generate_serial' is triggered in order to assign a SN to the final product P, the '_set_qty_producing' is called in order adapt the quantities of the MO (produce only one unit and consume accordingly):
https://github.com/odoo/odoo/blob/37c67ba6d2bef0bdca715619f117c3124ef5d334/addons/mrp/models/mrp_production.py#L1397-L1398
https://github.com/odoo/odoo/blob/37c67ba6d2bef0bdca715619f117c3124ef5d334/addons/mrp/models/mrp_production.py#L1215-L1231
Now, changing the quantity of the stock move of the component to a positive quantity will trigger the inverse method '_set_quantity' of that field to adapt reservation by creating a stock.move.line. Therefore, validating the transfer of components from stock to pre-production will not update the lot of components on the raw move because the computed need will be at 0 here:
https://github.com/odoo/odoo/blob/3097ea49705a1b6319be9677152d65ebe3ce515b/addons/stock/models/stock_move.py#L1689-L1697
and the '_update_reserved_quantity' call will therefore be empty.
Issue 1: opw-3887580 and opw-3863572
Issue 2: opw-3925894
Enterprise: https://github.com/odoo/enterprise/pull/63912
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#175050
Forward-Port-Of: odoo/odoo#168205Fixed error on compute method when more of one wizard is created and tried to get the `mail_partner_ids`. This section is for `invoice_single` records, so, if you send multiple move_ids a singleton error is returned because you send the moves of all the wizards. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175266
Original PR description
Fixed error on compute method when more of one wizard is created and tried to get the `mail_partner_ids`. This section is for `invoice_single` records, so, if you send multiple move_ids a singleton error is returned because you send the moves of all the wizards. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175266
When settling a sale order in PoS and using shiplater, there was no serial number on the ship later picking Steps to reproduce: ------------------- * Setup a product to be tracked by serial number * Update stock for this product and create 2 SN * Create an order with 2 quants of this product * Setup the PoS to allow ship later * Open PoS and load the sale order * Validate the order with ship later > Observation: The picking created for the pos order has no serial number Why the fi
Original PR description
When settling a sale order in PoS and using shiplater, there was no serial number on the ship later picking Steps to reproduce: ------------------- * Setup a product to be tracked by serial number *…
When settling a sale order in PoS and using shiplater, there was no serial number on the ship later picking Steps to reproduce: ------------------- * Setup a product to be tracked by serial number * Update stock for this product and create 2 SN * Create an order with 2 quants of this product * Setup the PoS to allow ship later * Open PoS and load the sale order * Validate the order with ship later > Observation: The picking created for the pos order has no serial number Why the fix: ------------ There is no serial number on the pos order picking because at the moment we try to create it the quantities are still reserved for the sale order To fix it we unreserve the quantities before creating the new picking. We also make sure that if not all the quantities are paid in the PoS, they are reserved again. https://github.com/odoo/odoo/pull/173389/files#diff-3f2dda6b95e58f16fb47dc8e8d49e369cc93ee700fbef7975c472514b1888a8aR105-R107 opw-4005925 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173389
location_menu_ids field domain was set to match a menu_type that doesn't exist. [reproduce orginal bug] - install website_event - open some event in debug mode - Edit -> select "Website Submenu" -> Save - Edit -> select "Website Submenu" -> deselect "Website Submenu" -> Save - Open Event's page, BUG: location menu duplicated opw-4049804 PS. enums :+1: string collections :-1: Forward-Port-Of: odoo/odoo#175052 Forward-Port-Of: odoo/odoo#174891
Original PR description
location_menu_ids field domain was set to match a menu_type that doesn't exist. [reproduce orginal bug] - install website_event - open some event in debug mode - Edit -> select "Website Submenu" -> Save - Edit -> select "Website Submenu" -> deselect "Website Submenu" -> Save - Open Event's page, BUG: location menu duplicated opw-4049804 PS. enums :+1: string collections :-1: Forward-Port-Of: odoo/odoo#175052 Forward-Port-Of: odoo/odoo#174891
In some cases, this test can fail if the logs are not exactly in the expected order. See some examples here: https://runbot.odoo.com/runbot/build/66341605 https://runbot.odoo.com/runbot/build/66320898 https://runbot.odoo.com/runbot/build/66320884 After this commit, the order of the logs does not matter for the test. Also, in case the test does fail, the logs are visible in the traceback (instead of being suppressed by the log catcher) --- I confirm I have signed the CLA and read t
Original PR description
In some cases, this test can fail if the logs are not exactly in the expected order. See some examples here: https://runbot.odoo.com/runbot/build/66341605 https://runbot.odoo.com/runbot/build/66320898 https://runbot.odoo.com/runbot/build/66320884 After this commit, the order of the logs does not matter for the test. Also, in case the test does fail, the logs are visible in the traceback (instead of being suppressed by the log catcher) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175344
Chilean customers are not required to provide a Zip Code, as this information is not commonly used in the country. task-4048931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175736 Forward-Port-Of: odoo/odoo#172954
Original PR description
Chilean customers are not required to provide a Zip Code, as this information is not commonly used in the country. task-4048931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175736 Forward-Port-Of: odoo/odoo#172954
Steps to reproduce the bug: - Create a storable product “P1” with BoM - Component: 1 unit of C1 tracked by Serial Number - Update the quantity of P1 with “SN1” - Create a MO to produce one unit of P1: - Confirm it - Select “SN1” for C1 - Validate the MO - Create a repair order to remove C1 from P1 and confirm, start, and complete the repair: - Destination location: WH/Stock - Serial Number: “SN1” - Perform the same steps to add C1 (SN1) into P1 again. -
Original PR description
Steps to reproduce the bug: - Create a storable product “P1” with BoM - Component: 1 unit of C1 tracked by Serial Number - Update the quantity of P1 with “SN1” - Create a MO to produce one unit of…
Steps to reproduce the bug:
- Create a storable product “P1” with BoM
- Component: 1 unit of C1 tracked by Serial Number
- Update the quantity of P1 with “SN1”
- Create a MO to produce one unit of P1:
- Confirm it
- Select “SN1” for C1
- Validate the MO
- Create a repair order to remove C1 from P1 and confirm, start, and complete the repair:
- Destination location: WH/Stock
- Serial Number: “SN1”
- Perform the same steps to add C1 (SN1) into P1 again.
- Remove C1 (SN1) a second time.
* After these steps, C1 with SN1 is available in stock.
- Create a new MO to produce one unit of P1:
- Confirm and select “SN1” for C1
- Try to validate it
Problem:
When checking the availability on the MO, SN1 is correctly
reserved. However, when marking the second MO as done, a User Error is
displayed: "The serial number SN1 used for component C1
has already been consumed."
opw-4029309
Forward-Port-Of: odoo/odoo#175600
Forward-Port-Of: odoo/odoo#173191Revert of: https://github.com/odoo/odoo/commit/be911c2c587f7e191d141ae37602ddc590a8737a **Steps to reproduce the bug:** - Go to accounting settings: - Enable “Automatic Accounting” option - Set the “Production Account” to False - Go to the product category “All”: - Costing Method: AVCO - Create a storable product P1: - product category: All - BoM: - Component: C1 - Type: subcontracting - subcontractor: Azure interior - C1: cost = $1
Original PR description
Revert of: https://github.com/odoo/odoo/commit/be911c2c587f7e191d141ae37602ddc590a8737a **Steps to reproduce the bug:** - Go to accounting settings: - Enable “Automatic Accounting” option - Set the…
Revert of: https://github.com/odoo/odoo/commit/be911c2c587f7e191d141ae37602ddc590a8737a
**Steps to reproduce the bug:**
- Go to accounting settings:
- Enable “Automatic Accounting” option
- Set the “Production Account” to False
- Go to the product category “All”:
- Costing Method: AVCO
- Create a storable product P1:
- product category: All
- BoM:
- Component: C1
- Type: subcontracting
- subcontractor: Azure interior
- C1: cost = $1
- Create a purchase order:
- vendor: Azure interior
- product: P1
- Confirm the PO
- try to receive the picking
**Problem**:
An userError is raised:
“Cannot find a stock input account for the product “P1”. You must define one on the product category, or on the location, before processing this operation.”
This commit make the production account optional and fallback with input/output accounts
Opw-3990006
Forward-Port-Of: odoo/odoo#175895
Forward-Port-Of: odoo/odoo#169839Due to the `qty_to_order` field on `stock.orderpoint` being a stored computed field, it needs to be recalculated every time one or more of its dependencies could have changed, to keep a consistent record in the database. It is, however, dependent on the `qty_forecast` field which is a non-stored computed field, depending itself on all the stock moves that are linked to the product set on the orderpoint. This results in a complete recalculation of the `qty_on_hand`, `qty_forecast` and `qty_to_o
Original PR description
Due to the `qty_to_order` field on `stock.orderpoint` being a stored computed field, it needs to be recalculated every time one or more of its dependencies could have changed, to keep a consistent…
Due to the `qty_to_order` field on `stock.orderpoint` being a stored computed field, it needs to be recalculated every time one or more of its dependencies could have changed, to keep a consistent record in the database. It is, however, dependent on the `qty_forecast` field which is a non-stored computed field, depending itself on all the stock moves that are linked to the product set on the orderpoint. This results in a complete recalculation of the `qty_on_hand`, `qty_forecast` and `qty_to_order` on ALL the orderpoints linked to a product every time some `stock.move` has been touched or created with that product. Even if many of those orderpoints may not even be located in the concerned warehouse. This situation can create a performance bottleneck when just processing pickings, as its constantly (and often pointlessly) recalculating these field values to store. This becomes a major issue in case the concerned database contains many warehouses with many different orderpoints. This issue is remedied in a more permanent way for master in [1], but due to the stable policy we use a different approach here: The `qty_to_order` field on `stock.orderpoint` is now no longer dependent on `qty_forecast`. Instead, when creating `stock.moves` or writing on its `state`, `product_uom_qty` or `date` fields, we manually trigger a recalculation of the `qty_to_order` on all the orderpoints on the relevant product, but only in the relevant warehouses. In case there is no relevant warehouse for the `stock.move` (none on the source or destination move), we fall back to the previous behavior of recalculating `qty_to_order` for all orderpoints linked to the product. [1] https://github.com/odoo/odoo/pull/159432 task-3822497 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176003 Forward-Port-Of: odoo/odoo#164300
An error occurs when adding a printer with accents in its name. When trying to print, no error is shown to the user, only an error log in the console. The issue is due to the get_identifier() function in the Printer class, which uses a regex that does not allow accents. Steps to reproduce: 1. Add a printer with an accent in its name in Cups. 2. Synchronize the IoT box to Odoo. 3. Enable some reports printing on the IoT box for the new device. 4. Try to print a report with the new print
Original PR description
An error occurs when adding a printer with accents in its name. When trying to print, no error is shown to the user, only an error log in the console. The issue is due to the get_identifier() function in the Printer class, which uses a regex that does not allow accents. Steps to reproduce: 1. Add a printer with an accent in its name in Cups. 2. Synchronize the IoT box to Odoo. 3. Enable some reports printing on the IoT box for the new device. 4. Try to print a report with the new printer. 5. Then: 1. No error is displayed for the end user. 2. An error is logged in the console. Solution: Use a different regex approach by disallowing certain characters instead of allowing only specific ones. opw-4070003 Forward-Port-Of: odoo/odoo#175974
After this commit, the option to hide the YouTube logo is removed from the video options because the parameter is no longer supported since August 15, 2023, in the YouTube API. For more information, see: https://developers.google.com/youtube/player_parameters#modestbranding opw-4078086 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175932 Forward-Port-Of: odoo/odoo#175691
Original PR description
After this commit, the option to hide the YouTube logo is removed from the video options because the parameter is no longer supported since August 15, 2023, in the YouTube API. For more information, see: https://developers.google.com/youtube/player_parameters#modestbranding opw-4078086 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175932 Forward-Port-Of: odoo/odoo#175691
With an IT company setup Create a BILL in foreign currency with tax Go to List view Activate field VAT (l10n_it_edi_amount_vat_signed) Issue: VAT amount is in company currency (symbol in foreign), it should be in foreign currency opw-4034566 Forward-Port-Of: odoo/odoo#172220
Original PR description
With an IT company setup Create a BILL in foreign currency with tax Go to List view Activate field VAT (l10n_it_edi_amount_vat_signed) Issue: VAT amount is in company currency (symbol in foreign), it should be in foreign currency opw-4034566 Forward-Port-Of: odoo/odoo#172220
With an ES company setup Create an invoice having line with taxes: 21% and 15% WHI Send&Print Download the facturae xml Validate the xml on the face website [1] Issue: validation will fail with error """ Línea xyz: Element 'TaxesWithheld': This element is not expected. Expected is one of ( LineItemPeriod, TransactionDate, AdditionalLineItemInformation, SpecialTaxableEvent, ArticleCode, Extensions ). """ This occurs because, according to official specs [2] in element InvoiceLine (3.
Original PR description
With an ES company setup Create an invoice having line with taxes: 21% and 15% WHI Send&Print Download the facturae xml Validate the xml on the face website [1] Issue: validation will fail with error """ Línea xyz: Element 'TaxesWithheld': This element is not expected. Expected is one of ( LineItemPeriod, TransactionDate, AdditionalLineItemInformation, SpecialTaxableEvent, ArticleCode, Extensions ). """ This occurs because, according to official specs [2] in element InvoiceLine (3.1.6.1) TaxesWithheld (3.1.6.1.21) should precede 'TaxesOutput' (3.1.6.1.22) [1] https://face.gob.es/es/facturas/validar-visualizar-facturas [2] https://www.facturae.gob.es/formato/Versiones/Esquema_castellano_v3_2_x_06_06_2017_unificado.pdf opw-3981213 Forward-Port-Of: odoo/odoo#172496
Create a sale order connected to an analytic account. Create a vendor bill and on the line: - use the same analytic account - add a price such that the abnormal_amount_warning is triggered. (example: 20000000001) - add a product line in the vendor bill which can be expensed and which has reinvoice expenses policy set to “Cost” Click on Confirm, the warning will show, click on “Confirm” again Issue: An error related to stock move record will show This occurs because in order to show th
Original PR description
Create a sale order connected to an analytic account. Create a vendor bill and on the line: - use the same analytic account - add a price such that the abnormal_amount_warning is triggered. (example: 20000000001) - add a product line in the vendor bill which can be expensed and which has reinvoice expenses policy set to “Cost” Click on Confirm, the warning will show, click on “Confirm” again Issue: An error related to stock move record will show This occurs because in order to show the warning wizard we add in context `default_move_ids` Then we don't cleanup the context, so if, during post, an inventory-related flow is triggered, it may accidentally use the context flag still set, raising an error as it will look for the wrong record opw-4021038 Forward-Port-Of: odoo/odoo#174894
Since version 17.0, there is an issue with the Text Cover snippet where the scroll button becomes deformed and takes up the entire height of the snippet when the scroll down button is toggled and the snippet is set to 100% height. The problem occurs because the `.s_text_cover` CSS rule `.s_text_cover > *` applies `min-height: inherit;` to all direct children, including the scroll button. To resolve this, the CSS rule has been updated to exclude the scroll button from inheriting the minimum
Original PR description
Since version 17.0, there is an issue with the Text Cover snippet where the scroll button becomes deformed and takes up the entire height of the snippet when the scroll down button is toggled and the snippet is set to 100% height. The problem occurs because the `.s_text_cover` CSS rule `.s_text_cover > *` applies `min-height: inherit;` to all direct children, including the scroll button. To resolve this, the CSS rule has been updated to exclude the scroll button from inheriting the minimum height by adding a `:not(.o_scroll_button)` selector. task-4091232 Forward-Port-Of: odoo/odoo#175660
Steps to reproduce: - Have a user have no inventory rights and User rights for sales - As that user, create a sale order that sells a storable product, which has at least one picking related to it in progress - Click on the forecast icon then on 'View Forecast' Issue: An access error will be triggered, as the user doesn't have the rights to consult `stock.valuation.layer` records. These records being useless for the forecast report itself, we can restrict instead what fields are read f
Original PR description
Steps to reproduce: - Have a user have no inventory rights and User rights for sales - As that user, create a sale order that sells a storable product, which has at least one picking related to it in progress - Click on the forecast icon then on 'View Forecast' Issue: An access error will be triggered, as the user doesn't have the rights to consult `stock.valuation.layer` records. These records being useless for the forecast report itself, we can restrict instead what fields are read for the moves, to only fetch actually required fields. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175655
In some rare cases, the payment status poll can enter the post-processing of a given transaction and conflict with the post-processing triggered by a webhook notification, for the same transaction. If the transaction is linked to a sale.order, both transactions will try to add the partner as follower during the post-processing, leading to a violation of the unique constraint ensuring that two mail.followers rows won't target the same record and partner. psycopg2.errors.UniqueViolation: dup
Original PR description
In some rare cases, the payment status poll can enter the post-processing of a given transaction and conflict with the post-processing triggered by a webhook notification, for the same transaction. If the transaction is linked to a sale.order, both transactions will try to add the partner as follower during the post-processing, leading to a violation of the unique constraint ensuring that two mail.followers rows won't target the same record and partner. psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "mail_followers_mail_followers_res_partner_res_model_id_uniq" DETAIL: Key (res_model, res_id, partner_id)=(sale.order, 20205, 94178) already exists. This commit makes sure that this kind of psycopg exceptions are caught and retried so that this kind of error is not shown to the user and the polling is successfully triggered a second time. opw-4000159 Forward-Port-Of: odoo/odoo#175836
**Current behavior before PR:** If a partner has `im_status` set to `away/bot` or is on leave, causing their `im_status` to be suffixed with `leave_`, they were placed into the `Offline` category. While except if they are `offline` they should have been placed in `Online` category. **Desired behavior after PR is merged:** If a member has `offline/im_partner` status, only then they are placed into `Offline` category. **Task**-[4101827](https://www.odoo.com/odoo/project.task/4101827)
Original PR description
**Current behavior before PR:** If a partner has `im_status` set to `away/bot` or is on leave, causing their `im_status` to be suffixed with `leave_`, they were placed into the `Offline` category. While except if they are `offline` they should have been placed in `Online` category. **Desired behavior after PR is merged:** If a member has `offline/im_partner` status, only then they are placed into `Offline` category. **Task**-[4101827](https://www.odoo.com/odoo/project.task/4101827) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176083 Forward-Port-Of: odoo/odoo#176031
17 changes
Enhancements to existing features
Website badges and tags have been redesigned to use consistent colors and sizing across website-related modules. This improves visual consistency, readability, and editing reliability while keeping a fallback for special cases such as shopping cart or dropdown badges.
Original PR description
task-3858047 - requires https://github.com/odoo/odoo/pull/162935 | Master | This PR | |--------|--------| | <img alt="image"…
task-3858047 - requires https://github.com/odoo/odoo/pull/162935 | Master | This PR | |--------|--------| | <img alt="image" src="https://github.com/user-attachments/assets/b5cd8c0a-9e32-4bc4-9d67-4c22cf615a4c"> | <img alt="image" src="https://github.com/user-attachments/assets/905c9840-8630-44c9-a89e-8111a88e11be"> | ---------------------------------------------- This PR has two main goals : ### Standardize color management for tags Rather than tweaking the `$o-colors` map differently in each module, we decided to expand the implementation made in https://github.com/odoo/odoo/commit/d767b0554ead887b6caf6e8b1813e50a2492f5d4 and make it standard to the `website_*` modules. ### Rework the badge and o_badge elements The objective is to improve/harmonize the design, streamline bootstrap inheritance and ease edition. The ability to apply arbitrary colors has been removed since using the "Style" dropdown ensures consistency and avoids issues related to text readability. Moreover, the sizing of s_badge scale with its immediate parent element has been changed, in line with bootstrap default behavior. ### (Extra) Provide an exit door for corner cases scenarios This new system shows its limits in some corner cases, mainly `dropdown-toggle.badge` and for our shopping cart button. To ensure a good visual result in any case, we allow the use of the old badge design, by using a combination of `.badge.bg-*`. This should be limited to corner cases scenarios of course, in order to consolidate the general front-end badges design. ----------------------- **Note**: the data-xml of the snippet was increased because: - Old untouched badges are still ok but not pretty - Old badges whose class changed may not use the same color anymore - Old badges with custom colors are now ugly and options do not work
The Point of Sale interface has been redesigned across several related POS modules to make daily sales workflows clearer and more visually modern. This improves usability for staff using payment, login, restaurant appointment, and customer settlement screens.
Original PR description
*: pos_restaurant_appointment, pos_blackbox_be, pos_hr_mobile, pos_settle_due This PR implements a comprehensive redesign of the POS interface, featuring substantial enhancements in usability and aesthetics. The main objective is to improve the overall user experience and deliver a visually new appealing interface. task-3954669 COM: https://github.com/odoo/odoo/pull/176016
Planning progress now includes sales order lines even when planning was not originally enabled on them, as long as they are manually selected in planning. This makes progress bars better reflect the work that has actually been planned and avoids undercounting hours.
Original PR description
Currently, the fields 'planning_hours_planned' and 'planning_hours_to_plan' are calculated by filtering out SOLs that don't have planning enabled or that are in the draft or sent state, and by converting the quantity of these SOL to hours according to the unit. The problem with this is that if we manually choose an SOL that doesn't have planning enabled in the planning slot, it does not count in the progress bar. This PR changes the filters to include SOLs that have planning disabled. task-3857649
Spreadsheet charts inserted from Odoo reports can now be clicked to open the business records behind a bar or pie slice. This helps users move from a chart insight directly to the relevant detailed records, while keeping the correct originating view context.
Original PR description
## Task Description This task adds the possibility to see the records related to a bar/pie part in a Odoo chart in Spreadsheet (included via the "Insert in spreadsheet" action) ## Related Task - Task: 3806411
Resolved issues and error corrections
The Planning calendar popover now hides its footer when a user does not have permission to edit or delete a planning slot. This removes a confusing empty area and makes the interface cleaner for users with limited access rights.
Original PR description
**Current behaviour before PR:** In planning app calendar view, when user has no rights to edit or delete a record then clicking on a planning slot opens a calendar popover with empty footer. Steps to reproduce: - Set no editing rights for demo user for planning app. - Log in as demo user, open planning app. - Switch to calendar view, click on a planning slot. - Notice that calendar popover gets opened with empty footer. **Desired behaviour after PR:** Popover footer shouldn't be displayed at all if user has no rights. task-3823315
Peruvian invoices are now checked to avoid duplicate invoice names when companies share the same RUC. This prevents reporting collisions with SUNAT and helps businesses avoid submission errors or compliance issues.
Original PR description
In Peru, the name we use to report an invoice to SUNAT is composed from the sending company's RUC, the document type code and the numbers from the invoice name. To avoid collisions when sending to SUNAT, we want to prevent Peruvian invoices from having the same name if they belong to companies with the same RUC. Note: I wanted to implement this as a SQL constraint originally, but since some of the data that should be taken into account for the constraint (company fiscal country being Peru, company RUC) doesn't reside in the account.move table, I think the only option is to make this a Python constraint. This means it would not be added on upgrade, but would be active for all invoices in the new version. opw-3900393
The Data Cleaning module now limits a click action to the intended view instead of applying it more broadly. This prevents unintended behavior in base model views and keeps navigation/actions consistent for users.
Original PR description
Since #64854 view_model_tree inherited an action on click that was meant only for a specific view this action has been moved to a primary inherited view. Related to task-id: 3861100
Code cleanup and technical improvements
The editor toolbar configuration was updated to follow the same structure as the command menu, making it easier to organize and extend. This helps teams add toolbar actions within existing categories more consistently across areas such as appointments, knowledge articles, and report editing.
Original PR description
The purpose of this commit is to modify the api used to define toolbar elements so that it is like the powerbox api. We're therefore going to replace toolbarGroup by toolbarCategory/toolbarCommands. These are the equivalents of powerboxCategory and powerboxCommands. Thanks to this new API, a plugin can add a command to an existing category.
Miscellaneous changes
Before this commit: When the user chooses a pickup point, the res.partner of the sale order is replaced with data from the pickup point, while the previously set customer's data is set as the partner's parent. And Sendcloud relies on a service_point_id field in its API rather than a raw address. Which causes double printing of the service point address on the label. Moreover, Sendcloud explicitly requires the customer's (and not the pickup point) address in its API. After this commit:
Original PR description
Before this commit: When the user chooses a pickup point, the res.partner of the sale order is replaced with data from the pickup point, while the previously set customer's data is set as the partner's parent. And Sendcloud relies on a service_point_id field in its API rather than a raw address. Which causes double printing of the service point address on the label. Moreover, Sendcloud explicitly requires the customer's (and not the pickup point) address in its API. After this commit: Both the service_point_id and the customer's delivery address are sent to Sendcloud. Both addresses are printed on the label correctly. opw-3977565 Forward-Port-Of: odoo/enterprise#65354
Sync between Transifex and Github has been broken lately. Some fixes need to be deployed asap. This commit manually sync pt-BR translations. See also - odoo/odoo#175298 - odoo/odoo#176035 Community: https://github.com/odoo/odoo/pull/176134 Forward-Port-Of: odoo/enterprise#68141
Original PR description
Sync between Transifex and Github has been broken lately. Some fixes need to be deployed asap. This commit manually sync pt-BR translations. See also - odoo/odoo#175298 - odoo/odoo#176035 Community: https://github.com/odoo/odoo/pull/176134 Forward-Port-Of: odoo/enterprise#68141
The default _generate_payslip method is using structure type instead of structure. Therefore it generates wrong payslip under BE structure. Forward-Port-Of: odoo/enterprise#67770
Original PR description
The default _generate_payslip method is using structure type instead of structure. Therefore it generates wrong payslip under BE structure. Forward-Port-Of: odoo/enterprise#67770
The Issue: Before this commit, the test always assumed the existence of the 'Deco Addict' partner. However, in the 'no demo' test, we run tests without demo data, so this partner does not exist. The Fix: Create the demo Partner runbot-58765 Forward-Port-Of: odoo/enterprise#67811
Original PR description
The Issue: Before this commit, the test always assumed the existence of the 'Deco Addict' partner. However, in the 'no demo' test, we run tests without demo data, so this partner does not exist. The Fix: Create the demo Partner runbot-58765 Forward-Port-Of: odoo/enterprise#67811
Version: saas-17.2 Before this commit: the warning notification for the auto plan would stay on the screen even when navigating to another page. cause: the warning notification were set to be sticky but did not properly handle removing the notification when navigate to another page. Solution: added a method to remove notifications after navigating to another page. task-4023197 Forward-Port-Of: odoo/enterprise#67870 Forward-Port-Of: odoo/enterprise#66037
Original PR description
Version: saas-17.2 Before this commit: the warning notification for the auto plan would stay on the screen even when navigating to another page. cause: the warning notification were set to be sticky but did not properly handle removing the notification when navigate to another page. Solution: added a method to remove notifications after navigating to another page. task-4023197 Forward-Port-Of: odoo/enterprise#67870 Forward-Port-Of: odoo/enterprise#66037
Version: saas-17.1 Before this commit: the notification for the auto plan would stay on the screen even when navigating to another page. cause: the notification were set to be sticky but did not properly handle removing the notification when navigate to another page. Solution: added a method to remove notifications after navigating to another page. task-4023197 Forward-Port-Of: odoo/enterprise#67852 Forward-Port-Of: odoo/enterprise#66038
Original PR description
Version: saas-17.1 Before this commit: the notification for the auto plan would stay on the screen even when navigating to another page. cause: the notification were set to be sticky but did not properly handle removing the notification when navigate to another page. Solution: added a method to remove notifications after navigating to another page. task-4023197 Forward-Port-Of: odoo/enterprise#67852 Forward-Port-Of: odoo/enterprise#66038
This PR does 2 things: - clean up pot/po files had manually adjustments done to them (see specific commit for cleanup process) - added some missing translations
Original PR description
This PR does 2 things: - clean up pot/po files had manually adjustments done to them (see specific commit for cleanup process) - added some missing translations
Before this PR: - the HSN code on products determined HSN code warnings. After this PR: - This update modifies the computation of HSN warnings based on journal items rather than products. This change enhances the accuracy of HSN code validation by focusing on the financial entries. Task ID: 4085936 Forward-Port-Of: odoo/enterprise#67685
Original PR description
Before this PR: - the HSN code on products determined HSN code warnings. After this PR: - This update modifies the computation of HSN warnings based on journal items rather than products. This change enhances the accuracy of HSN code validation by focusing on the financial entries. Task ID: 4085936 Forward-Port-Of: odoo/enterprise#67685
Steps: - Install `web_studio` - Open Studio report view from any model (e.g: Users) - Double click on any report kanban card - Crash because component is destroyed In this case: - First click create the first `ReportEditorModel` https://github.com/odoo/enterprise/blob/cebfacec4e5c6f24ed7f915da204867e39ba53ca/web_studio/static/src/client_action/report_editor/report_editor_model.js#L401 - This first instance of `ReportEditorModel` make two calls via `this.loadReportDa
Original PR description
Steps: - Install `web_studio` - Open Studio report view from any model (e.g: Users) - Double click on any report kanban card - Crash because component is destroyed In this case: - First click create…
Steps:
- Install `web_studio`
- Open Studio report view from any model (e.g: Users)
- Double click on any report kanban card
- Crash because component is destroyed
In this case:
- First click create the first `ReportEditorModel`
https://github.com/odoo/enterprise/blob/cebfacec4e5c6f24ed7f915da204867e39ba53ca/web_studio/static/src/client_action/report_editor/report_editor_model.js#L401
- This first instance of `ReportEditorModel` make two calls via `this.loadReportData` (rpc) and `this.loadModelEnv` (orm.search)
- Second click create a second instance of `ReportEditorModel` which destroys the first instance to replace it.
- The problem is that the RPC of the first instance has not yet had time to execute, so by the time it arrives the component is already destroyed, which causes the problem
This commit fixes the problem by checking the state of reportEditorModel, if it is destroyed we don't call the loaders
opw-3973038
Forward-Port-Of: odoo/enterprise#68041
Forward-Port-Of: odoo/enterprise#648769 changes
Enhancements to existing features
This update improves how discounts are handled in Ecuador electronic invoices. Previously, negative invoice lines (global discounts) were not accepted by the Ecuador government. The system now automatically converts these negative lines into proper discounts applied to positive line items, ensuring compliance with government requirements.
Original PR description
As negative invoice lines, aka global discounts, are not accepted by the Ecuador government, we transform them into discounts of the positives lines for the e-invoice. task-3752009
Resolved issues and error corrections
This fix resolves an issue where quality control labels were not printing to IoT printers and were being downloaded instead. The problem was caused by a data format mismatch where the printer device information needed to be converted to the correct format. Now labels will print automatically to the IoT printer as intended.
Original PR description
Before this commit: Having a quality control point using "Print label" with an IoT printer will not print anything and download the file. This happened due to the JS function `iotReportActionHandler` ignoring the device sent as it expected it to be a list, see: https://github.com/odoo/enterprise/blob/1412cd3edc6005b05d43d42828e6647ee58594ae/iot/static/src/iot_report_action.js#L21 Therefore, defaulting to the behavior of downloading the file After this commit: Print the label automatically to the IoT like expected opw-4032741,4017327,3895056
This update fixes a compatibility issue that prevented Argentine companies from testing their AFIP Web Services connections in Odoo 17. The fix removes outdated code that relied on a function removed from the PyOpenSSL library, ensuring the system works properly with Python 3.12 and newer versions.
Original PR description
### Steps to reproduce * install python 3.12 * install odoo's python required libraries (requirements.txt) * install `l10n_ar_edi` * switch to an Argentinean company * in the Invoicing settings, under the AFIP Web Services section, click 'Test Connections' You should be met with the following error: `AttributeError: module 'lib' has no attribute 'PKCS7_sign'` ### Cause `PKCS7_sign()` was removed in recent version of `pyopenssl`. opw-4085411 opw-4085389
This fix resolves a test failure in the website rental module that occurred when running tests without demo data. The test was failing because user timezone information wasn't properly specified. By setting the timezone directly in the test, the availability test now runs reliably regardless of whether demo data is present.
Original PR description
before this commit [test_availability_in_clients_tz](https://runbot.odoo.com/runbot/build/66644573) was breaking when not having demo data. Was first introduced in https://github.com/odoo/enterprise/pull/61047 Now we fix the issue where test test_availability_in_clients_tz without demo data as user does not have tz specified by specifying it in the test itself.
This fix resolves a critical error that occurred when viewing the French "Intermediate Management Balances" financial report after upgrading from version 16 to version 17. The report was failing to display due to incorrect ordering of report line items. By adding proper sequencing to the report lines, the fix ensures that parent report sections are loaded before their child sections, allowing the report to display correctly on migrated databases.
Original PR description
**Description** A [recent](https://github.com/odoo/enterprise/commit/76d9188767e26c4ae1f815334af5ca3ac6c5fcdf) change in the l10n_fr_reports **IMB - Intermediate management balances** created a new…
**Description**
A [recent](https://github.com/odoo/enterprise/commit/76d9188767e26c4ae1f815334af5ca3ac6c5fcdf) change in the l10n_fr_reports **IMB - Intermediate management balances** created a new child and parent hierarchy between report lines that never existed before. This causes a traceback when opening the report on migrated databases.
The report lines must be loaded in an order where parent lines come before their children. The sorting of `account.report.line` model is by `sequence, id`, where `sequence` column (if unchanged) remains null, causing lines to be sorted by `id`. The change caused larger id records to be assigned as the parent of smaller id records, violating the required hierarchy and raising a traceback.
**Traceback :**
```py
File "/home/odoo/src/enterprise/17.0/account_reports/models/account_report.py", line 4386, in get_report_information
'lines': self._get_lines(options, all_column_groups_expression_totals=all_column_groups_expression_totals, warnings=warnings),
File "/home/odoo/src/enterprise/17.0/account_reports/models/account_report.py", line 2123, in _get_lines
parent_generic_id = line_cache[line.parent_id]['id'] if line.parent_id else None # The parent line has necessarily been treated in a previous iteration
KeyError: account.report.line(338,)
```
**steps to reproduce**
1. install 'l10n_fr' and 'account_accountant' in a demo database of version 16
2. migrate it to version 17.
3. go to Reporting->Profit and Loss (Fr company should be selected)
4. Change Report to "IMB - Intermediate management balances"
Note: This PR is created by this [suggestion](https://github.com/odoo/upgrade/pull/6267#issuecomment-2244373973).This fix resolves a system error that occurred when users tried to add an existing attendee's email as a guest to an appointment booking. The issue happened because the system was creating duplicate attendee records instead of recognizing the email already existed. Now the system properly checks for existing attendees before creating new ones, allowing users to smoothly add guests without encountering errors.
Original PR description
This traceback arises when the user adds an existing attendee email to a guest email while adding a guest. To reproduce this traceback: 1) Install `website_appointment` 2) Choose any `appointment`…
This traceback arises when the user adds an existing attendee email to a guest email while adding a guest. To reproduce this traceback: 1) Install `website_appointment` 2) Choose any `appointment` from the website 3) Click on `Appointment Type` in the right corner and on the `options page` enable `Allow Guests` 4) Get back to the website and select one user, date & time 5) Now give Email value as email in Guests 6) Confirm Appointment Error:- ``` ValueError: Expected singleton: calendar.attendee(4762, 4763) ``` When the user adds a guest with the current user email, multiple attendees will be created with the same partner ID in a calendar event (see below) https://github.com/odoo/enterprise/blob/1aff50d91fad45221377591b80ca8b1df2ecb593/appointment/models/appointment_type.py#L944-L955 This leads to the above traceback from here https://github.com/odoo/enterprise/blob/1aff50d91fad45221377591b80ca8b1df2ecb593/appointment/controllers/calendar.py#L103 This commit will resolve the issue by filtering out the existing attendees while creating a new attendee from the guest email. sentry-5646921453
This fix prevents automatic population of Peppol fields when using Mexico's localization module. Previously, the system would incorrectly fill these fields based on the Mexican VAT format, causing validation errors. Now these unused fields remain empty for Mexican companies, eliminating the need for manual correction.
Original PR description
Version: 17.0+ Current Behavior: Peppol fields are automatically populated based on the `vat` field of the res.partner record. With l10n_mx localization installed the `vat` field is based on the first two letters of the first name and the first letter of the last name. However, the peppol fields with be automatically computed if the first two letters are similar to country codes. Purpose of this PR: This PR overrides the peppol computation so that the peppol fields are emptied when l10n_mx_edi is installed. These fields are unused in l10n_mx localization so they can be omitted. Steps to Reproduce on Runbot: 1) Install accounting and contacts 2) Create a contact with l10n_mx vat format (i.e. ESPN0101011E2) 3) Navigate to the Accounting Tab of the partner record and find that the peppol fields are filled. Notes: In the current behavior, the user will have to manually empty the peppol fields to avoid receiving the error of incorrect peppol format. opw-4074094
This update fixes how XML documents are formatted in the Mexican localization modules to improve compatibility with third-party vendors. The change ensures XML declarations use double quotes instead of single quotes, which some external systems require for proper validation. This makes the generated documents more universally compatible without changing any functionality.
Original PR description
This commit refactors the generation of pretty printed raw xml string to a helper function in `l10n_mx_edi.document` for `l10n_mx_edi` and `l10n_mx_reports`. It modifies the xml declaration to be a custom generated string, which only difference from the normal one is that it uses double quoted string rather than single quoted string in it. This way, the top file of the generated xml string will look like this: ```xml <?xml version="1.0" encoding="UTF-8"?> ``` This ensures as much support as possible from third party vendors because some do not consider single quoted string to be valid (even though it should be). related opw-4085399 task-id: no task
This fix resolves an issue where converting a helpdesk ticket to a sales lead would fail in certain situations. The problem occurred when the system had many helpdesk teams but fewer sales teams, causing a configuration conflict. Users can now successfully convert helpdesk tickets to leads without encountering errors.
Original PR description
Prior to this fix, trying to convert a helpdesk ticket to a lead would fail if the default_team_id was set and beyond the possible IDs for crm.team records. This happens in installations with a large number of helpdesk teams and relatively few sales teams.