Daily updates from Odoo
Friday, December 27, 2024
16 changes
11 changes
Resolved issues and error corrections
This update bumps a small supporting dependency to stop unnecessary missing-file warnings when Odoo starts or is imported. It helps keep logs cleaner and reduces confusion for teams monitoring system health.
Original PR description
1.2.0 requires GCC profiling records which aren't available on the system Description of the issue/feature this PR addresses: https://github.com/odoo/odoo/issues/191873 Current behavior before PR: Every odoo start/import throws an warning about missing gcda files Desired behavior after PR is merged: No warning about missing files on odoo start/import --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale tests now verify that subcategories appear directly after their parent category when selected. This helps prevent regressions in product navigation and supports a more predictable cashier experience.
Original PR description
In this commit: === - Updated the test case to ensure that when clicking on a parent category, its subcategories are displayed immediately after the parent category.
This fix adjusts the background styling of the editor toolbar and link popover dropdowns in dark mode. It creates a smoother, more consistent visual experience for users editing content in the HTML editor.
Original PR description
Description of the issue this PR addresses: This PR changes the background color of toolbar and link popover dropdown for a smoother UI. task-4356656 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a small error that prevented the system from properly checking whether a required electronic invoicing field exists. It helps avoid issues when processing UBL/CII electronic invoice data after a recent code update.
Original PR description
Looks like the rebase in #191457 introduce a small mistake making the field exist check not working properly. This commit should fix the issue.
The link popover now shows only the button style option that is relevant outside the website module, removing duplicate choices that looked the same. This reduces confusion for users and makes the editor easier to maintain, with tests updated to match the streamlined behavior.
Original PR description
Before this commit, the link popover contained three button styles, default, fill, and flat, which were visually identical. Here’s a summary of each: default: Based on the website module and influenced by the theme. fill: Not affected by theme choice. flat: Specific to the website module. After this commit, the redundant default and flat styles have been removed, as they are only relevant within the website module. The code has been cleaned up to improve maintainability, and tests have been updated to reflect these changes. task-4240795 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in the HTML editor where replacing all selected text could unexpectedly lose the current font styling. Users can now select all content and type new text while keeping the intended style, making editing more predictable.
Original PR description
Description of the issue this PR addresses: Current behavior before PR: Previously, typing after selecting all text using Ctrl+A would reset the font style of the anchorNode of the selection. Desired behavior after PR is merged: Typing after selecting all text using Ctrl+A keeps the font style of the anchorNode of the selection. task-4426710 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Link preview descriptions in the HTML editor now display special characters properly instead of showing encoded text. This makes link previews easier to read and more polished for users editing content.
Original PR description
**Current behavior before PR:** In some url, opening link preview displays special characters as string instead of parsed characters inside description of link preview popover. **Desired behavior after PR is merged:** Now special characters are getting parsed before displaying on popover. task-4345237 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale global invoices now use the currency exchange rate from the original POS order instead of defaulting to 1. This helps Mexican localization documents show the correct TipoCambio value and improves acceptance of invoices created from foreign-currency POS orders.
Original PR description
### Steps to reproduce the issue: 1. Activate Mexican Localization 2. In Mexican Company, add USD as Currency and give it a Rate 3. Create a Sales Journal and a Pricelist with USD as main Currency 4.…
### Steps to reproduce the issue: 1. Activate Mexican Localization 2. In Mexican Company, add USD as Currency and give it a Rate 3. Create a Sales Journal and a Pricelist with USD as main Currency 4. _Point of Sale > Configuration > Settings_: Select a Shop and set the USD Journal and Pricelist 5. Open a Session using the USD Shop and complete some Orders, without invoicing them 6. _Point of Sale > Orders > Orders_, select the created Orders and, in the Actions, Create Global Invoice 7. The document should be accepted, but TipoCambio has a rate of 1.000000. ### Explanation: During the creation of the Global Invoice, the rate is retrieved during `pos.order._prepare_tax_base_line_values` and, since no value is given through POS, the default value is used. https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1242 https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1212-L1213 https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1188-L1193 ### Fix reasoning: `pos.order.currency_rate` is the rate of the Currency at the time the order was created. It is the perfect value to use for `TipoCambio`. We must also adapt workflows that were designed with the absence of `rate` in `tax_base_line_values`. Test in Enterprise opw-4302180
This fixes Mexican Point of Sale global invoices created in a foreign currency so they use the correct exchange rate instead of defaulting to 1.000000. It helps ensure USD POS invoices are accepted and accurately reflect the required currency conversion information.
Original PR description
### Steps to reproduce the issue: 1. Activate Mexican Localization 2. In Mexican Company, add USD as Currency and give it a Rate 3. Create a Sales Journal and a Pricelist with USD as main Currency 4.…
### Steps to reproduce the issue: 1. Activate Mexican Localization 2. In Mexican Company, add USD as Currency and give it a Rate 3. Create a Sales Journal and a Pricelist with USD as main Currency 4. _Point of Sale > Configuration > Settings_: Select a Shop and set the USD Journal and Pricelist 5. Open a Session using the USD Shop and complete some Orders, without invoicing them 6. _Point of Sale > Orders > Orders_, select the created Orders and, in the Actions, Create Global Invoice 7. The document should be accepted, but TipoCambio has a rate of 1.000000. ### Explanation: During the creation of the Global Invoice, the rate is retrieved during `pos.order._prepare_tax_base_line_values` and, since no value is given through POS, the default value is used. https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1242 https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1212-L1213 https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1188-L1193 ### Fix reasoning: Adding test to make sure Foreign Currency can be used in Global Invoice for `pos.order` and rate is correctly set as well. Fix in Community opw-4302180
The video insertion option is no longer shown when editing reports in Studio. This prevents users from triggering an error with an action that is not relevant for printable reports.
Original PR description
**Before this PR:** In studio, in some report, trying to add a video using video commnad throws traceback. Adding a video doesn't make sense in a report so the video command shouldn't be available in report at the first place. **After this PR:** This commit aims to remove video command from studio report. task-4285231
The Helpdesk SLA status report graph has been simplified by removing extra fields that made it harder to read. This makes the report clearer for teams reviewing SLA performance without changing the underlying data or process.
Original PR description
This commit's purpose is to clean up the graph view of the sla report analysis model. Some fields were added on the view by a generic improvement task for to handle the widget 'float_time' with grap view. In this case, those fields are a nuisance for readability, so we're getting rid of them. target version 18.0 - master task - 4351830
5 changes
Resolved issues and error corrections
This update addresses a technical issue where an outdated element was being used in the website's sales functionality. This change ensures the website's sales features continue to operate correctly and avoids potential problems with future updates. It's a routine maintenance fix.
Original PR description
This commit is a backport of https://github.com/odoo/enterprise/commit/697d69d85e9812bdb2329d7604f57c940ae70135 Community pr: https://github.com/odoo/odoo/pull/187674
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