Thursday, March 27, 2025
24 changes · saas-17.4
Resolved issues and error corrections
This update adjusts an automated test so it no longer depends on a field that is only available in Odoo Enterprise. It helps keep Community edition validation reliable without changing customer-facing manufacturing or purchasing behavior.
Original PR description
### Issue: The community runs of the test: `test_portal_subcontractor_record_production_with_dropship` fail since the field `backorder_ids` of the mrp.production model is part of the `stock_barcode_mrp` module (part of the entreprise repo). runbot-build-error-159951 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The purchase order screen no longer shows the forecast icon for products that are not kept in inventory, such as services. This avoids showing irrelevant stock information and reduces confusion when buyers create purchase orders.
Original PR description
Steps to reproduce: - Create a non-storable product (e.g. a service) - Create a new RFQ - Add that product to a PO line Issue: The forecast icon is visible, even though the product is non-storable and the forecast doesn't make any sense. 73170f0 was a bit too optimistic on the invisible condition, as it needs a field directly on the model to be able to check these clauses. So we add a related as it's done for other. opw-4672513 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue in the website form editor where changing an empty linked field from a dropdown list to radio buttons could trigger an error. This makes form editing more stable and prevents interruptions while configuring website forms.
Original PR description
Steps to reproduce: 1. Drop the website_form snippet. 2. Select name field & change with the many2one field having no record. 3. Switch the type: "dropdown list" => "radio" --> It will throw a traceback : This commit, fix the uncaught promise by adding validation before using variable. task-3932086
Miscellaneous changes
the xmlid `hr_expense.mail_alias_expense` can be deleted by the user, don't raise error if xmlid is not found. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203002
Original PR description
the xmlid `hr_expense.mail_alias_expense` can be deleted by the user, don't raise error if xmlid is not found. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203002
**Before this commit:** The fiscal position computation method did not depend on `gst_treatment`, causing issues where changes to `gst_treatment` were not detected. As a result, the computation did not trigger as expected, leading to incorrect fiscal position determination. **After this commit:** The computation method now depends on `gst_treatment`, ensuring that any changes to it trigger a recalculation. This guarantees accurate fiscal position computation as required. --- I confi
Original PR description
**Before this commit:** The fiscal position computation method did not depend on `gst_treatment`, causing issues where changes to `gst_treatment` were not detected. As a result, the computation did not trigger as expected, leading to incorrect fiscal position determination. **After this commit:** The computation method now depends on `gst_treatment`, ensuring that any changes to it trigger a recalculation. This guarantees accurate fiscal position computation as required. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203445
Before this change, if a jsonrpc handler was successful but returned the value `None` the dispatcher would return a response object containing just the `jsonrpc` and `id` keys. This is an invalid response according to [JSON-RPC 2.0 Specification section 5 "Response Object"][jsonrpc-response]: > Either the result member or error member MUST be included [...] [jsonrpc-response]: https://www.jsonrpc.org/specification#response_object Forward-Port-Of: odoo/odoo#203270
Original PR description
Before this change, if a jsonrpc handler was successful but returned the value `None` the dispatcher would return a response object containing just the `jsonrpc` and `id` keys. This is an invalid response according to [JSON-RPC 2.0 Specification section 5 "Response Object"][jsonrpc-response]: > Either the result member or error member MUST be included [...] [jsonrpc-response]: https://www.jsonrpc.org/specification#response_object Forward-Port-Of: odoo/odoo#203270
* stock{,_barcode, _barcode_quality_control}, quality_control ### Issue: Quality checks per operation and per product are generated by an override of the action confirm of the move. However, if a move line is created on a non draft picking, it will end up in a move that will never be confirmed. This happends because the move is created with a state to match its already existing picking and hence is not confirmed at creation and since only draft pickings are confirmed at the start of the bu
Original PR description
* stock{,_barcode, _barcode_quality_control}, quality_control ### Issue: Quality checks per operation and per product are generated by an override of the action confirm of the move. However, if a…
* stock{,_barcode, _barcode_quality_control}, quality_control
### Issue:
Quality checks per operation and per product are generated by an override of the action confirm of the move. However, if a move line is created on a non draft picking, it will end up in a move that will never be confirmed. This happends because the move is created with a state to match its already existing picking and hence is not confirmed at creation and since only draft pickings are confirmed at the start of the button validate. As a result, we will not create the quality checks related to these additional moves.
The above issue can be triggered in many situations. Here are the two major ones:
### Use case I:
Creating a delivery or an internal transfer on the fly from the barcode app.
### Steps to reproduce:
- Create a storable product P with a barcode: XXX
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product: Control per: "Operation" Operations: "Delivery"
- Go to the barcode app > Operations > Delivery > New
- Scan your product
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.
### Cause of the issue:
The `save_barcode_data` will launch the creation of the move line related to the barcode line you edited from the barcode app. During the create of this 'stock.move.line', an associated move will be created and its initial "state" will be the current state of the picking: https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L354-L356 https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L942 At this point the picking state is "draft" and the move will be correctly created in draft. However, just a few lines after its creation, we will check if a reservation should be done with that move and if its state should be recomputed:
https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L379-L396 the discrepancy is caused by the fact that `move._should_bypass_reservation` will be true if the picking is a receipt and false for the other types because you should bypass reservation for moves whose source is not an internal location but you should not for others. This will leave the moves and picking in draft state if its a receipt and update it for other types. However, only draft pickings are confirmed at the beginning of the button validate: https://github.com/odoo/odoo/blob/b0cfeecacfc6b95659778dfe4d62435556aaa92c/addons/stock/models/stock_picking.py#L1131-L1133
### Use case II:
Create and confirm a picking of any type so that it ends up being assigned. Add manually a move line via the detailled operations.
### Steps to reproduce:
- Create two storable product P1 and P2 put 10 units of both in stock
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product P2: Control per: "Operation" Operations: "Delivery"
- Create and confirm a Delivery for 1 unit P1
- Go to Detailed Operations > create a new line for 1 unit of P2
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.
### Cause of the issue:
For the same reasons as above, the newly created move is assigned as it mimics the state of the current picking which is assigned since we have already reserved the already existing move.
### Fix:
We ensure the creation of quality checks for moves that end up being created but will never be confirmed.
### Technical limitation:
Unfortunately, it is not possible to manage the use case of quality checks related the component of a kit product without disrupting the barcode flows. Indeed, in barcode flows, the move line as well as its related move is created by a `save_barcode_data`. If we were to confirm the newly created moves rather than just trying to create the QC, it would indeed first explode the bom and then create the related QC for each component. However, the barcode data would not coincide anymore with the back end data since the line we just saved would have been exploded at backend creation. For that reason we do not yet support the above use cases for kit products.
Enterprise: https://github.com/odoo/enterprise/pull/81850
opw-4480104
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#202725Test introduced in cbb753d6 fails because the `attribute_line_ids` field is not visible by default in product forms. Fixes [runbot error 161456](https://runbot.odoo.com/odoo/runbot.build.error/161456) Forward-Port-Of: odoo/odoo#203225
Original PR description
Test introduced in cbb753d6 fails because the `attribute_line_ids` field is not visible by default in product forms. Fixes [runbot error 161456](https://runbot.odoo.com/odoo/runbot.build.error/161456) Forward-Port-Of: odoo/odoo#203225
- Adjusting fetchmail_server behavior to read specific fuel taxes from vendor bills, which can be extended for other taxes. - Adding the functionality of manually uploading CL EDI documents through fetchmail_server functions. Unrecognized documents are parsed as vendor bills. task-4359365 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190873
Original PR description
- Adjusting fetchmail_server behavior to read specific fuel taxes from vendor bills, which can be extended for other taxes. - Adding the functionality of manually uploading CL EDI documents through fetchmail_server functions. Unrecognized documents are parsed as vendor bills. task-4359365 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190873
Steps to reproduce: ------------------- - Switch to a Mexican company (or any company with cash basis option enabled). - Go to analytic plans and set at least one plan to mandatory. - Create a vendor bill, with a line having a vat (16% for example), and confirm the bill. - Click on credit note, try to confirm the credit note, it will show error. Cause ----- The cash basis entry created doesn't copy the display type of the original move lines, so the move lines of the taxes will get the
Original PR description
Steps to reproduce: ------------------- - Switch to a Mexican company (or any company with cash basis option enabled). - Go to analytic plans and set at least one plan to mandatory. - Create a vendor bill, with a line having a vat (16% for example), and confirm the bill. - Click on credit note, try to confirm the credit note, it will show error. Cause ----- The cash basis entry created doesn't copy the display type of the original move lines, so the move lines of the taxes will get the default display type (product). And this affects the function that applies the mandatory analytic plans, as it filters out lines that have display_type != product. Fix --- Add lines to copy the display_type for the move lines of the cash basis. opw-4579419 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200389
Versions -------- - 17.0+ Steps ----- 1. Open website in French; 2. select a pricelist using CHF as currency; 3. add a product to the wishlist; 4. open wishlist in mobile view. Issue ----- With the increased amount of space the currency symbol needs, along with the translation of "Add", the view gets truncated. Cause ----- View was probably designed with only English & USD in mind. Solution -------- Same approach as commit ba2a0d7e33e8 took for the product configurator:
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Open website in French; 2. select a pricelist using CHF as currency; 3. add a product to the wishlist; 4. open wishlist in mobile view. Issue ----- With the increased amount of space the currency symbol needs, along with the translation of "Add", the view gets truncated. Cause ----- View was probably designed with only English & USD in mind. Solution -------- Same approach as commit ba2a0d7e33e8 took for the product configurator: - In full view, display `<fa-shopping-cart> Add` - On mobile, display `<fa-shopping-cart>` opw-4624112 Forward-Port-Of: odoo/odoo#202650
Steps to reproduce: - Access with the demo user - Open Timesheet dashboard - Switch to list view Issue: Access error will raise Since commit https://github.com/odoo/odoo/commit/0258a627addf678d2c9b66bd8ee6752905fbac8f Readonly account users have now read access to analytic account lines. However, when sale_timesheet is installed, in the lowest access right it is possible to see only the own timesheets, so the rule needed to be limited as it occurs with Billing users. Forward-
Original PR description
Steps to reproduce: - Access with the demo user - Open Timesheet dashboard - Switch to list view Issue: Access error will raise Since commit https://github.com/odoo/odoo/commit/0258a627addf678d2c9b66bd8ee6752905fbac8f Readonly account users have now read access to analytic account lines. However, when sale_timesheet is installed, in the lowest access right it is possible to see only the own timesheets, so the rule needed to be limited as it occurs with Billing users. Forward-Port-Of: odoo/odoo#203460
Steps: - create a stage from "To-Do" app - reload the page Actual result: - stage disappear Expected result: - stage is shown as personal stage opw-4637169 Forward-Port-Of: odoo/odoo#203057
Original PR description
Steps: - create a stage from "To-Do" app - reload the page Actual result: - stage disappear Expected result: - stage is shown as personal stage opw-4637169 Forward-Port-Of: odoo/odoo#203057
An incorrect date being represented (14/11/2007 is displayed as 20/07/1114) on the payment field. The date was parsed two times with the format of the user's language, while the first parse should be based on the current format of the database. To reproduce: - Change user language to Spanish or French. - Register a payment for an invoice with a payment date between October 1st and December 31st, from 2001 to 2012. - "Paid on 20/07/1114" appears. Ticket [link](https://www.odoo.com/odoo/
Original PR description
An incorrect date being represented (14/11/2007 is displayed as 20/07/1114) on the payment field. The date was parsed two times with the format of the user's language, while the first parse should be based on the current format of the database. To reproduce: - Change user language to Spanish or French. - Register a payment for an invoice with a payment date between October 1st and December 31st, from 2001 to 2012. - "Paid on 20/07/1114" appears. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4486653) opw-4486653 Forward-Port-Of: odoo/odoo#203535 Forward-Port-Of: odoo/odoo#202258
Before this commit, customers were facing problems during the first synchronization related to the abundance of invitations sent through Outlook from previously created events in Odoo side. This should not happen because most of the time it is not useful synchronizing events that were already created before starting the synchronization with Outlook (from feedbacks discussed with customers and internally). After this commit, we no longer synchronize events that were created before the first sy
Original PR description
Before this commit, customers were facing problems during the first synchronization related to the abundance of invitations sent through Outlook from previously created events in Odoo side. This should not happen because most of the time it is not useful synchronizing events that were already created before starting the synchronization with Outlook (from feedbacks discussed with customers and internally). After this commit, we no longer synchronize events that were created before the first synchronization of any user in a database if we don't find any token created in it (i.e. if no user synchronized its Odoo Calendar with Outlook before this improvement). In case of any user already have synchronized its calendar with Outlook, we won't change the synchronization behavior (since the biggest part of the invitations were already sent). task-4294884 Forward-Port-Of: odoo/odoo#199824 Forward-Port-Of: odoo/odoo#185911
This commit ensures that sheet names in exported excel files are unique. The names may not be unique in case a composite report contains multiple section reports all having the same very long prefix. An example to that could be found in l10n_fr_reports: 1) IMB - Intermediate management balances 2) IMB - Intermediate management balances (2024) task-4678129 Forward-Port-Of: odoo/enterprise#82333
Original PR description
This commit ensures that sheet names in exported excel files are unique. The names may not be unique in case a composite report contains multiple section reports all having the same very long prefix. An example to that could be found in l10n_fr_reports: 1) IMB - Intermediate management balances 2) IMB - Intermediate management balances (2024) task-4678129 Forward-Port-Of: odoo/enterprise#82333
### Steps to reproduce: - Accounting > Dashboard > Bank > Import Statement - Select a QIF file with a transaction having a total of 0 - Traceback ### Cause: The QIF file parser (`_parse_bank_statement_file`) does not return `unique_import_id` for transactions. In [`_create_bank_statements`](https://github.com/odoo/enterprise/blob/316b7bdc7781d5d72d91430f74de35fdafb0bf84/account_bank_statement_import/models/account_journal.py#L261-L269) when the amount is 0, the code tries to read `line_va
Original PR description
### Steps to reproduce: - Accounting > Dashboard > Bank > Import Statement - Select a QIF file with a transaction having a total of 0 - Traceback ### Cause: The QIF file parser (`_parse_bank_statement_file`) does not return `unique_import_id` for transactions. In [`_create_bank_statements`](https://github.com/odoo/enterprise/blob/316b7bdc7781d5d72d91430f74de35fdafb0bf84/account_bank_statement_import/models/account_journal.py#L261-L269) when the amount is 0, the code tries to read `line_vals['unique_import_id']` so an error is raised. ### Solution: The read is done to store the skipped lines in `ignored_statement_lines_import_ids`. This variable is then only used to get the number of skipped lines. https://github.com/odoo/enterprise/blob/316b7bdc7781d5d72d91430f74de35fdafb0bf84/account_bank_statement_import/models/account_journal.py#L291 The fix is to increment a counter instead of storing the lines. opw-4656142 Forward-Port-Of: odoo/enterprise#81944
Certain reports were incorrectly referring to DIAN, even though the Industry and Commerce Tax (ICA) is administered at the district level. According to Colombian regulations (e.g., Decree 807 of 1993, Agreement 65 of 2002 for Bogotá), the collection and administration of ICA falls under the local Secretariat of Finance, not DIAN. This commit adds logic so that if the report is for ICA, it shows the correct reference to the Secretariat of Finance; otherwise, it preserves the reference to DIAN.
Original PR description
Certain reports were incorrectly referring to DIAN, even though the Industry and Commerce Tax (ICA) is administered at the district level. According to Colombian regulations (e.g., Decree 807 of 1993, Agreement 65 of 2002 for Bogotá), the collection and administration of ICA falls under the local Secretariat of Finance, not DIAN. This commit adds logic so that if the report is for ICA, it shows the correct reference to the Secretariat of Finance; otherwise, it preserves the reference to DIAN. Forward-Port-Of: odoo/enterprise#82109 Forward-Port-Of: odoo/enterprise#79630
It is possible for a user to sync an existing whatsapp account and only after install some whatsapp bridge module. In that case the user will get an error as the template is created on the existing account with an existing name. We now prevent using the default value if a template with the same name already exists on it. task-4369979 Forward-Port-Of: odoo/enterprise#79786
Original PR description
It is possible for a user to sync an existing whatsapp account and only after install some whatsapp bridge module. In that case the user will get an error as the template is created on the existing account with an existing name. We now prevent using the default value if a template with the same name already exists on it. task-4369979 Forward-Port-Of: odoo/enterprise#79786
In the bank reconciliation widget, when the transaction_details of bank statement lines get formatted by calling json.loads(), an error will show if some strings contain control characters (`\n`, `\t`, `\r`, `\0`). Adding the parameter `strict=False` to the call to json.loads would allow such characters to be kept by the formatting. In the view, they will not be used (any of those 4 chars will simply be considered a whitespace). One could add `style="white-space: pre-line"` as an attribut
Original PR description
In the bank reconciliation widget, when the transaction_details of bank statement lines get formatted by calling json.loads(), an error will show if some strings contain control characters (`\n`, `\t`, `\r`, `\0`). Adding the parameter `strict=False` to the call to json.loads would allow such characters to be kept by the formatting. In the view, they will not be used (any of those 4 chars will simply be considered a whitespace). One could add `style="white-space: pre-line"` as an attribute to the span tag of those element, but this is not necessary. This PR simply aims to patch the already existing data in databases. opw-4480250 Forward-Port-Of: odoo/enterprise#78684
When drag-and-dropping a CSV in the bank journal, the statements lines don't get reconciled directly while they should (if a reco model allows it). Users have to wait for the auto-reconcile cron to run. After the statement and its lines have been created through import, we now trigger the cron computation. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4545446) opw-4545446 Forward-Port-Of: odoo/enterprise#81958 Forward-Port-Of: odoo/enterprise#81587
Original PR description
When drag-and-dropping a CSV in the bank journal, the statements lines don't get reconciled directly while they should (if a reco model allows it). Users have to wait for the auto-reconcile cron to run. After the statement and its lines have been created through import, we now trigger the cron computation. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4545446) opw-4545446 Forward-Port-Of: odoo/enterprise#81958 Forward-Port-Of: odoo/enterprise#81587
- Adjusting fetchmail_server behavior to read specific fuel taxes from vendor bills, which can be extended for other taxes. - Adding the functionality of manually uploading CL EDI documents to account_move. Unrecognized documents are parsed as vendor bills. - Adjusting fetchmail_server methods to work with manual upload process. - Adding relevant tests for specific fuel taxes. task-4359365 Forward-Port-Of: odoo/enterprise#76630
Original PR description
- Adjusting fetchmail_server behavior to read specific fuel taxes from vendor bills, which can be extended for other taxes. - Adding the functionality of manually uploading CL EDI documents to account_move. Unrecognized documents are parsed as vendor bills. - Adjusting fetchmail_server methods to work with manual upload process. - Adding relevant tests for specific fuel taxes. task-4359365 Forward-Port-Of: odoo/enterprise#76630
* stock{,_barcode, _barcode_quality_control}, quality_control ### Issue: Quality checks per operation and per product are generated by an override of the action confirm of the move. However, if a move line is created on a non draft picking, it will end up in a move that will never be confirmed. This happends because the move is created with a state to match its already existing picking and hence is not confirmed at creation and since only draft pickings are confirmed at the start of the bu
Original PR description
* stock{,_barcode, _barcode_quality_control}, quality_control ### Issue: Quality checks per operation and per product are generated by an override of the action confirm of the move. However, if a…
* stock{,_barcode, _barcode_quality_control}, quality_control
### Issue:
Quality checks per operation and per product are generated by an override of the action confirm of the move. However, if a move line is created on a non draft picking, it will end up in a move that will never be confirmed. This happends because the move is created with a state to match its already existing picking and hence is not confirmed at creation and since only draft pickings are confirmed at the start of the button validate. As a result, we will not create the quality checks related to these additional moves.
The above issue can be triggered in many situations. Here are the two major ones:
### Use case I:
Creating a delivery or an internal transfer on the fly from the barcode app.
### Steps to reproduce:
- Create a storable product P with a barcode: XXX
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product: Control per: "Operation" Operations: "Delivery"
- Go to the barcode app > Operations > Delivery > New
- Scan your product
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.
### Cause of the issue:
The `save_barcode_data` will launch the creation of the move line related to the barcode line you edited from the barcode app. During the create of this 'stock.move.line', an associated move will be created and its initial "state" will be the current state of the picking: https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L354-L356 https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L942 At this point the picking state is "draft" and the move will be correctly created in draft. However, just a few lines after its creation, we will check if a reservation should be done with that move and if its state should be recomputed:
https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L379-L396 the discrepancy is caused by the fact that `move._should_bypass_reservation` will be true if the picking is a receipt and false for the other types because you should bypass reservation for moves whose source is not an internal location but you should not for others. This will leave the moves and picking in draft state if its a receipt and update it for other types. However, only draft pickings are confirmed at the beginning of the button validate: https://github.com/odoo/odoo/blob/b0cfeecacfc6b95659778dfe4d62435556aaa92c/addons/stock/models/stock_picking.py#L1131-L1133
### Use case II:
Create and confirm a picking of any type so that it ends up being assigned. Add manually a move line via the detailed operations.
### Steps to reproduce:
- Create two storable product P1 and P2 put 10 units of both in stock
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product P2: Control per: "Operation" Operations: "Delivery"
- Create and confirm a Delivery for 1 unit P1
- Go to Detailed Operations > create a new line for 1 unit of P2
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.
### Cause of the issue:
For the same reasons as above, the newly created move is assigned as it mimics the state of the current picking which is assigned since we have already reserved the already existing move.
### Fix:
We ensure the creation of quality checks for moves that end up being created but will never be confirmed.
### Technical limitation:
Unfortunately, it is not possible to manage the use case of quality checks related the component of a kit product without disrupting the barcode flows. Indeed, in barcode flows, the move line as well as its related move is created by a `save_barcode_data`. If we were to confirm the newly created moves rather than just trying to create the QC, it would indeed first explode the bom and then create the related QC for each component. However, the barcode data would not coincide anymore with the back end data since the line we just saved would have been exploded at backend creation. For that reason we do not yet support the above use cases for kit products.
Community: https://github.com/odoo/odoo/pull/202725
opw-4480104
Forward-Port-Of: odoo/enterprise#81850Versions -------- - 17.0+ Steps ----- 1. Have a rental product with a minimum rental duration of 1 day; 2. open its eCommerce page; 3. select two days in the rental period datepicker; 4. go to cart; 5. go back to the product page and refresh. Issue ----- The product is displayed with a rental period of 3 days. Cause ----- Commit 0573ad5b7007 attempted to add a timezone correction when retrieving DateTime values from the server. When duration isn't with hours, it gets the `st
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a rental product with a minimum rental duration of 1 day; 2. open its eCommerce page; 3. select two days in the rental period datepicker; 4. go to cart;…
Versions -------- - 17.0+ Steps ----- 1. Have a rental product with a minimum rental duration of 1 day; 2. open its eCommerce page; 3. select two days in the rental period datepicker; 4. go to cart; 5. go back to the product page and refresh. Issue ----- The product is displayed with a rental period of 3 days. Cause ----- Commit 0573ad5b7007 attempted to add a timezone correction when retrieving DateTime values from the server. When duration isn't with hours, it gets the `startOf` of the start datetime, and the `endOf` of the end datetime as a means of converting datetimes to dates. Issue is that if start date is e.g. 2025-03-23 23:00:00 and end date is 2025-03-25 22:59:59 due to timezone correction, the `startOf` of the start date is 2025-03-23 and the `endOf` of the end date is 2025-03-25 due to being adjusted -1 hours from UTC. This results in an apparent time delta of 3 days, while the actual delta should be 2 days. Solution -------- Leave the datetime values as is, as there is other logic in place that correctly converts them to date values on the frontend. opw-4583312 Forward-Port-Of: odoo/enterprise#81849