Daily updates from Odoo
Friday, December 27, 2024
5 changes · 17.0
Resolved issues and error corrections
This update addresses a technical issue where an outdated element was being used in the website's sales functionality. This change ensures the website's sales features continue to operate correctly and avoids potential problems with future updates. It's a routine maintenance fix.
Original PR description
This commit is a backport of https://github.com/odoo/enterprise/commit/697d69d85e9812bdb2329d7604f57c940ae70135 Community pr: https://github.com/odoo/odoo/pull/187674
Odoo push notifications stopped working due to an update in Google's Firebase API. This change updates the necessary software components to align with the latest Firebase version, restoring the ability to send push notifications. This ensures continued functionality for features relying on push notifications.
Original PR description
Google recently updated the Firebase API and deprecated support for the version we are currently using (v6.3.4). As a result, Odoo push notifications are no longer functional. This PR updates the dependencies and API calls to align with the latest Firebase API, ensuring that push notifications can once again be sent from Odoo. see: https://firebase.google.com/docs/cloud-messaging/migrate-v1 task-4247811 Forward-Port-Of: odoo/enterprise#73390
This update corrects a technical issue preventing Amazon from correctly receiving shipping information, which was causing warning messages. We've now included the shipping method (e.g., 'Express' or 'Parcel') alongside the carrier name, ensuring Amazon has complete details and avoiding disruptions to order fulfillment.
Original PR description
Currently, while we send the carrier and the tracking number, we don't send the shipping method. While this doesn't block anything, this lead to Amazon sending warning about incomplete shipping information. Now, we will send: - Carrier name : the delivery_type if any relevant, else the carrier name as fallback. eg: "DHL" - The shipping method: the carrier name. eg: "DHL Express" or "Parcel" opw-4393663 Forward-Port-Of: odoo/enterprise#76156
This update prevents errors during batch delivery validation when using Sendcloud shipping. Previously, a validation error on one order would halt the entire process. Now, orders are processed correctly on the carrier side, even if individual validations fail, ensuring smoother delivery workflows.
Original PR description
### Issue: Certain carrier's API processes validity checks and parcels generation one picking at a time so that on our end we are forced to send requests one at a time at the end of the the…
### Issue: Certain carrier's API processes validity checks and parcels generation one picking at a time so that on our end we are forced to send requests one at a time at the end of the the `_action_done`: https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/stock/models/stock_picking.py#L918 https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/delivery/models/stock_picking.py#L192-L196 However, since a UserError of any of the picking will cause a rollback of the entire batch on Odoo's side, pikcings might end up being processed on the carrier side but non validated on Odoo's side during batch validation. ### Steps to reproduce: - Configure sendcloud shipping method + website + payment providers - In your sendcloud configuration select sendcloud shipping product to not be able to handle products with a weight exceeding 10 kg e.g; bpost @home (0-10kg). - Create 2 storable products with respective weigth 1 and 100 kg. - Publish them on the website for sale. - Open a private window, make an order via the website for the 1kg product by filling your cart and use sendcloud as carrier. - Repeat the operation with the other product to generate a seconde SO. - Back to your main window > Inventory Overview > Delivery Orders - Select both deliveries > Action > Validate (in batch) #### > While the first delivery order was processed on carrier side (can be checked on sendcloud's website) #### > the UserError of the second DO rollbacked its validation in Odoo. ### Fix: As such, and since the carrier requests needs to happen after we have validated the pickings in Odoo, we should avoid any rollback of the transaction once any requests has already been successfully treated on the carrier side. ### Note: It is not possible restructure the code to use `senf.env.cr.savepoint` in a loop in order to reset the validation of pickings that are not valid on the carrier side because savepoints can't be used more than 64 times before the server crashes and hence can't be used in record loops. community: https://github.com/odoo/odoo/pull/190320 opw-4357325 Forward-Port-Of: odoo/enterprise#75502
This update fixes an issue where debit notes created from invoices were defaulting to the wrong document type (33) when the EDI module was active. The change ensures the correct document type (56) is used, aligning with SII requirements and preventing errors in electronic invoicing. This ensures compliance and accurate data transmission.
Original PR description
Users creating a debit note from an invoice will need to pay attention to the document type that, with the EDI module installed, is set by taking into account only the partner 'Taxpayer Type' and not the move type (i.e. debit note) - Have an invoice with document type "(33) Factura Electrónica" accepted by SII - Create the debit note from the invoice Issue: default document type will be 33, while it should be 56 opw-4292111 Forward-Port-Of: odoo/enterprise#76011