Odoo Changelog — 2024-10-09

Wednesday, October 9, 2024

7 changes · 17.0

Bug Fixes(7)

Resolved issues and error corrections

[FIX] website_sale_stock_renting: get latest selected product id

Enterprise17.0website_sale_stock_rentingMEDIUM

Fixed a bug where switching between product variants in the rental shop would incorrectly show unavailable dates for all variants instead of just the selected one. Now when customers select a different size or variant of a rental product, the calendar accurately reflects availability for that specific variant only.

Original PR description

Problem:
Once we set the product ID in `WebsiteSaleDaterangePicker`, it doesn't get updated if it has a truthy value. However, it should update because a different variant (product ID) can be selected.

Steps to reproduce:

- Install a database with website, eCommerce, and Rental (ensure the "website_sale_stock_renting" module is installed).
- Create a product that can be rented with 3 variants.
- Add a daily rate of your choice.
- In the Sales tab, untick the option "Continue selling if out-of-stock."
- Restock 1 quantity of each variant and publish the product on the website.
- From the shop, rent the product with variant size S for one week.
- Return to the shop and select another variant (M or L). The calendar will incorrectly show the rental days in red, as if M & L are also already rented. However, they can still be rented.

opw-4115519

#rental#ecommerce#product-variants#calendar#availability

[FIX] helpdesk_repair: don’t link repair moves to the return

PR #71337

Enterprise17.0helpdesk_repairMEDIUM

This fix resolves an issue where products added to repair orders were being incorrectly included in return shipments. When creating a repair order from a helpdesk ticket, the system was unintentionally linking repair inventory movements to the original return picking. The fix uses a more targeted approach to associate repair orders with returns without affecting the inventory movements created during repairs.

Original PR description

### Steps to reproduce:
- Create a Helpdesk team with the options "Return" and "Repairs"
- Create a product, sell 1 unit and deliver it.
- Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket.
- Create an associated repair order and add a line for an other product in the part tabs
- Go back to the return picking

#### > the product added to the repair was also added to the return picking

### Cause of the issue:

A `default_picking_id` is added to the context of the form view of the repair order by the `_prepare_repairs_default_value` of the `action_repair_order_form` so that it prefils the form of the repair: https://github.com/odoo/enterprise/blob/e74b05fa7a777053fd0e2cd5a265de365e1e434a/helpdesk_repair/models/helpdesk_ticket.py#L36-L40 https://github.com/odoo/enterprise/blob/e74b05fa7a777053fd0e2cd5a265de365e1e434a/helpdesk_repair/models/helpdesk_ticket.py#L55-L56 However, this values stays in the context and will be added as a default value for each of the move that will be creted from this view.

### Fix:

Thanks to commit odoo/odoo@3898d61046cc0338082fdcbe0df282241372361a, we now have a default getter that can be used to associate a default picking id to the repair order when necessary without the need to put a `default_picking_id` in the context.

opw-4159779

#helpdesk#repair#returns#inventory#bug fix

[FIX] whatsapp, *: lost persona name and write_data in reaction format

PR #69056

Enterprise17.0whatsapptest_whatsappMEDIUM

This fix restores missing persona name and data information that was being lost when processing WhatsApp message reactions. The issue affected how reaction metadata was being formatted and stored, which has now been corrected to ensure complete information is preserved during WhatsApp interactions.

Original PR description

* test_whatsapp

odoo/odoo#178173

#whatsapp#messaging#reactions#data integrity

[FIX] account_reports: allow a super().action_post() to return res

PR #71324

Enterprise17.0account_reportsMEDIUM

This fix resolves an issue where external API calls to post invoices were failing due to a missing return statement in the action_post() method. The method now properly returns a value, allowing external systems to successfully post invoices through the API without encountering errors.

Original PR description

Method `action_post()` was added in 17.0 as a front-end helper funcion to initialize `_post()`. This method is expected to return a value, however, `action_post()` was missing the intended `return` statement. This causes external API calls to `action_post()` to fail since `_xmlrpc()` does not allow `NoneType` values.

To reproduce:
1) Create an invoice using external API.
2) Attempt a call to action_post() using xmlrpc.
3) TypeError("cannot marshal None unless allow_none is enabled") should appear.

#api#invoice#xmlrpc#bug-fix

[FW][FIX] account_accountant: always display other lines in bank reco.

PR #71504

Enterprise17.0account_accountantMEDIUM

The bank reconciliation widget now displays all lines from a bank transaction, not just the main liquidity and transfer lines. This ensures users can see the complete picture of all transaction details when reconciling bank statements, making the reconciliation process more transparent and complete.

Original PR description

Consider an unreconciled bank statement (line) in the bank reconciliation widget.
Currently only the liquidity and suspense/transfer line of the associated move are shown.
This means that some lines of the move are not shown.

After this commit we show all the line (so i.e. the other lines).

Since the diff is not the nicest:
The commit just removes the outer `if wizard.st_line_id.is_reconciled`.

Forward-Port-Of: odoo/enterprise#71236

#bank reconciliation#visibility#transaction details

[FW][FIX] social: fix various issues

PR #71428

Enterprise17.0socialsocial_facebooksocial_instagramsocial_linkedinsocial_youtubesocial_demoMEDIUM

This update resolves multiple issues preventing users from replying to comments on Facebook, YouTube, Instagram, and LinkedIn posts. Users were experiencing errors when trying to reply to existing comments or comment on posts with certain settings. The fix ensures the system properly handles comment data and validates responses from social platforms, allowing seamless commenting and replies across all supported social media channels.

Original PR description

Commit 1
========

Steps to reproduce the issue:
- add comment to a Facebook/youtube post.
- keeping the `Comments` dialog box open, try replying the same comment.
- we get a traceback.

Reason:
- due to the missing comments data structure, we get an error when trying to add the new comment.
- LOC responsible for the traceback: https://github.com/odoo/enterprise/blob/16.0/social/static/src/xml/social_templates.xml#L311

Fix:
- since the comments data structure is not returned from the post request made to post the commnet, we manually ensure it exists.

Commit 2
========

[FIX] social: fix various issues
1. social_instagram:

ISSUES:
- create a post on the instagram platform with commenting turned off.
- try commenting on it from Odoo. We get a traceback.
- also, if we delete the post from the platform and then try to comment from Odoo,
  we get a traceback.

REASON:
- there is no existing implementation to check if commenting is enabled/disabled
  on the post.

FIX:
- we now check if commenting is enabled or not while trying to add comment on the post

TECHNICAL NOTE:
- the correct way to check if commenting on a post is enabled or not is to request
  a field named `is_comment_enabled`.
- more details --- https://developers.facebook.com/docs/instagram-platform/instagram-graph-api/reference/ig-media
- but to save us from making an extra request, we simply catch the error received to
  when trying to add a comment.

================================================================================

2. social_linkedin

ISSUE:
- delete an existing post from the linkedIn platform.
- now try commenting on it from Odoo. We get a traceback.

REASON:
- The response received from the request to fetch the comments is not validated.

FIX:
- validating the response before further execution.

Task-3759530

Forward-Port-Of: odoo/enterprise#67079

#social media#comments#bug fix#user experience

[FIX] subscription: Recurring plan search not functioning as expected

PR #70464

Enterprise17.0sale_subscriptionMEDIUM

Users can now search for recurring plans by entering text in the search field. Previously, the search feature was not responding to user input even though custom filters were working. This fix enables the search functionality by properly configuring the search view fields.

Original PR description

The search functionality in the Recurring Plan view was not working when users entered text. While custom filters worked, the search field failed to respond to user input because no fields were defined in the search view.

OPW-4116088

#search#recurring_plans#usability

Problem: Once we set the product ID in `WebsiteSaleDaterangePicker`, it doesn't get updated if it has a truthy value. However, it should update because a different variant (product ID) can be selected. Steps to reproduce: - Install a database with website, eCommerce, and Rental (ensure the "website_sale_stock_renting" module is installed). - Create a product that can be rented with 3 variants. - Add a daily rate of your choice. - In the Sales tab, untick the option "Continue selling if out-of-stock." - Restock 1 quantity of each variant and publish the product on the website. - From the shop, rent the product with variant size S for one week. - Return to the shop and select another variant (M or L). The calendar will incorrectly show the rental days in red, as if M & L are also already rented. However, they can still be rented. opw-4115519

### Steps to reproduce: - Create a Helpdesk team with the options "Return" and "Repairs" - Create a product, sell 1 unit and deliver it. - Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket. - Create an associated repair order and add a line for an other product in the part tabs - Go back to the return picking #### > the product added to the repair was also added to the return picking ### Cause of the issue: A `default_picking_id` is added to the context of the form view of the repair order by the `_prepare_repairs_default_value` of the `action_repair_order_form` so that it prefils the form of the repair: https://github.com/odoo/enterprise/blob/e74b05fa7a777053fd0e2cd5a265de365e1e434a/helpdesk_repair/models/helpdesk_ticket.py#L36-L40 https://github.com/odoo/enterprise/blob/e74b05fa7a777053fd0e2cd5a265de365e1e434a/helpdesk_repair/models/helpdesk_ticket.py#L55-L56 However, this values stays in the context and will be added as a default value for each of the move that will be creted from this view. ### Fix: Thanks to commit odoo/odoo@3898d61046cc0338082fdcbe0df282241372361a, we now have a default getter that can be used to associate a default picking id to the repair order when necessary without the need to put a `default_picking_id` in the context. opw-4159779

Method `action_post()` was added in 17.0 as a front-end helper funcion to initialize `_post()`. This method is expected to return a value, however, `action_post()` was missing the intended `return` statement. This causes external API calls to `action_post()` to fail since `_xmlrpc()` does not allow `NoneType` values. To reproduce: 1) Create an invoice using external API. 2) Attempt a call to action_post() using xmlrpc. 3) TypeError("cannot marshal None unless allow_none is enabled") should appear.

Consider an unreconciled bank statement (line) in the bank reconciliation widget. Currently only the liquidity and suspense/transfer line of the associated move are shown. This means that some lines of the move are not shown. After this commit we show all the line (so i.e. the other lines). Since the diff is not the nicest: The commit just removes the outer `if wizard.st_line_id.is_reconciled`. Forward-Port-Of: odoo/enterprise#71236

Commit 1 ======== Steps to reproduce the issue: - add comment to a Facebook/youtube post. - keeping the `Comments` dialog box open, try replying the same comment. - we get a traceback. Reason: - due to the missing comments data structure, we get an error when trying to add the new comment. - LOC responsible for the traceback: https://github.com/odoo/enterprise/blob/16.0/social/static/src/xml/social_templates.xml#L311 Fix: - since the comments data structure is not returned from the post request made to post the commnet, we manually ensure it exists. Commit 2 ======== [FIX] social: fix various issues 1. social_instagram: ISSUES: - create a post on the instagram platform with commenting turned off. - try commenting on it from Odoo. We get a traceback. - also, if we delete the post from the platform and then try to comment from Odoo, we get a traceback. REASON: - there is no existing implementation to check if commenting is enabled/disabled on the post. FIX: - we now check if commenting is enabled or not while trying to add comment on the post TECHNICAL NOTE: - the correct way to check if commenting on a post is enabled or not is to request a field named `is_comment_enabled`. - more details --- https://developers.facebook.com/docs/instagram-platform/instagram-graph-api/reference/ig-media - but to save us from making an extra request, we simply catch the error received to when trying to add a comment. ================================================================================ 2. social_linkedin ISSUE: - delete an existing post from the linkedIn platform. - now try commenting on it from Odoo. We get a traceback. REASON: - The response received from the request to fetch the comments is not validated. FIX: - validating the response before further execution. Task-3759530 Forward-Port-Of: odoo/enterprise#67079

The search functionality in the Recurring Plan view was not working when users entered text. While custom filters worked, the search field failed to respond to user input because no fields were defined in the search view. OPW-4116088