Daily updates from Odoo
Friday, November 14, 2025
32 changes · saas-18.3
Enhancements to existing features
Product names and descriptions sent for Indian e-invoicing and e-waybill generation are now automatically shortened when they exceed the required character limits. This helps ensure the exported data stays valid and avoids failures when submitting documents to the authorities.
Original PR description
Product descriptions in invoice lines must comply with character limits: - E-invoicing: maximum 300 characters - E-waybill: maximum 100 characters for both product names and descriptions Descriptions exceeding these limits are automatically truncated in the generated JSON. task-5061450 Forward-Port-Of: odoo/odoo#228549
Resolved issues and error corrections
This update keeps long product attribute text inside the product card when browsing products in the sales catalog. It improves the appearance of the interface and prevents the layout from looking broken or misaligned.
Original PR description
**Steps to reproduce:** 1. Go to Products > Create a new product. 2. Add or create a new attribute and set a long text value. 3. Go to Sales > Open any quotation. 4. In the sale order line, click on…
**Steps to reproduce:** 1. Go to Products > Create a new product. 2. Add or create a new attribute and set a long text value. 3. Go to Sales > Open any quotation. 4. In the sale order line, click on "Catalog" and search for the created product. **Issue:** - The attribute value text overflows outside the product card in the kanban view, causing layout misalignment and making the UI look broken. <img width="647" height="225" alt="image" src="https://github.com/user-attachments/assets/80ce5eb5-ba00-4545-a981-57f08889ab0f" /> **Cause:** - The inner <div> containing the attribute text did not have overflow control, allowing long text to exceed the card boundary. **Solution:** - Added the Bootstrap class overflow-hidden to the <div> to ensure the content stays within the container and prevents layout breakage. <img width="587" height="171" alt="image" src="https://github.com/user-attachments/assets/ae76186b-4ec9-410c-9ac4-99bdbd4b4493" /> **opw-5222002** Forward-Port-Of: odoo/odoo#234478
This change makes connection status notifications more consistent when a browser connection is lost unexpectedly. It ensures users and background services receive the full sequence of reconnecting and reconnect events, which helps avoid missed updates and reduces test failures.
Original PR description
The websocket worker broadcasts events that track connection state changes (connect, disconnect, reconnecting, reconnect). Sometimes a WebSocket can close without the client noticing, leaving it…
The websocket worker broadcasts events that track connection state changes (connect, disconnect, reconnecting, reconnect). Sometimes a WebSocket can close without the client noticing, leaving it stuck in the `CLOSING` state. If the client starts the worker during this period, the worker detects the issue and triggers a disconnect event, but neither reconnecting nor reconnect is emitted. Conceptually, reconnecting/reconnect should fire on any unexpected loss of connection. This patch ensures those events are properly triggered in this case. This also fixes a runbot error ([1]) where a test simulates the loss of the connection. The test sometimes runs before another service's call to `bus_service.start`, reproducing this exact scenario. [1]: https://runbot.odoo.com/odoo/runbot.build.error/223185 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#235319
This change prevents an error that could occur when the system checks which message was last seen by everyone in a conversation. It makes the check more reliable when some participant details are missing, improving chat stability for users.
Original PR description
The `lastMessageSeenByAllId` compute function sometimes crashes when the persona linked to a member is unknown. This occurs because the compute function compares the member's persona to determine if it belongs to the current user. However, members are not always sent along with their persona. The compute function should instead compare the member directly to the current user's member. This fixes the issue and makes more sense. 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#235338 Forward-Port-Of: odoo/odoo#235253
The website now hides mega menu links when the linked content is not visible to the visitor, both on desktop and mobile. This prevents users from seeing and opening empty menu entries, making the navigation cleaner and less confusing.
Original PR description
Before this commit, when setting the mega menu content visibility, the navbar link would still appear even if the user does not have access to the mega menu content. This commit hides the navbar link for the mega menu in the mobile and desktop view when the user does not have access to the mega menu content, in order to prevent unnecessary elements in the navbar. Steps to reproduce the bug: - Add a mega menu element in the navbar - Open the mega menu - Set the mega menu content visibility to conditional (logged in) - Open the website while logged out (The mega menu link is here but the content is not displayed. However, the dropdown is still opened but it is empty.) task-3992066 Forward-Port-Of: odoo/odoo#235289 Forward-Port-Of: odoo/odoo#179454
This update fixes the Italian e-invoicing setup so share capital is not forced for company types where it is not legally required. It prevents unnecessary validation errors and makes company registration details easier to complete correctly.
Original PR description
Share capital should not be mandatory for non limited liability company. [Ticket link](https://www.odoo.com/odoo/project.task/5131029) opw-5131029 Forward-Port-Of: odoo/odoo#235498
We updated the self-order IoT component so it can correctly read the newer image version date format. This prevents version checks from failing and helps keep device updates working smoothly.
Original PR description
New image versions are formatted as YYYY.MM.DD instead of YY.MM. The previous can be casted to float, but not the new one. We then only take the year and month to before casting. Forward-Port-Of: odoo/enterprise#99416
This change fixes the hamburger-style website menu so submenu labels inherit the header’s selected font size. As a result, when the navbar format is updated, the menu stays visually consistent with the rest of the header.
Original PR description
Steps to reproduce: =================== - Create a menu and a submenu - Change the header template to the hamburger menu - Update the navbar format ->The format of the submenu's parent is not updated. Cause: ====== The menu in the hamburger layout uses the `.accordion-button` class, which applies a fixed base font size defined here: https://github.com/odoo/odoo/blob/ebb250d3b56970c09ffb5ebefef38f97c622c33d/addons/web/static/lib/bootstrap/scss/_accordion.scss#L37 This prevents the submenu text from inheriting the updated header font-size. Solution: ========= Allow the `.accordion-button` font size to inherit from its parent. This ensures that submenu text correctly follows the header's font-size setting. opw-5223664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234276
This update lets users create a debit note from an existing credit note in the Argentine localization. It removes an error that blocked this correction flow, making it easier to reverse and adjust documents when a credit note was issued by mistake.
Original PR description
Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com> THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17 ORIGINAL PR: https://github.com/odoo/odoo/pull/205430 Description of…
Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com> THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17 ORIGINAL PR: https://github.com/odoo/odoo/pull/205430 Description of the issue/feature this PR addresses: - In debit notes wizards: If we make a wrong credit note and we want to correct it we must generate a debit note related to it. Currently odoo only allows to generate debit notes from an invoice. Steps to reproduce the error. - Install the Argentine localization - Create an invoice and post it - From the invoice using the wizard create a credit note and post it. From the credit note open the wizard to create a debit note. On submit the wizard we obtain an exception "You can not use a credit_note document type with a invoice" This happens because the debit note wizard use copy method without change the l10n_latam_document_type_id value. Current behavior before PR: When creating a debit note from a credit note get an error. Desired behavior after PR is merged: We can create a debit memo from a credit note. opw-4304256 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#233875 Forward-Port-Of: odoo/odoo#225501
This fix ensures that restaurant self-orders placed with online payment and “Pay After Meal” selected are sent to the kitchen display as expected. It prevents orders from being missed in preparation, helping staff start work on time and avoid service delays.
Original PR description
Configuration: ------------------------- - Restaurant Mode - Self-Order Mode: “QR + Ordering” - Service At: Table Issue : Order Not coming in Preparation Display for (Pay-After-Meal) Online ---------------------------------------------------- Steps to Reproduce: 1. Open the Restaurant. 2. Place an order from the mobile self-order with “Pay After Meal” enabled. 3. Set online payment. 4. order does not appear in the kitchen display. Cause: - The system only sent paid orders to the kitchen, skipping pay-after-meal case. Fix: - Updated logic to send all orders to the kitchen when “Pay After Meal” is selected, --------------------------------------------------- Task-5106704 Related PR- https://github.com/odoo/odoo/pull/231005
This update adjusts how test time is allocated so slower environments can complete the checks more reliably. It helps prevent occasional false failures in the editor test suite without changing normal user behavior.
Original PR description
Split the test timer between the four tests rather than applying
a single timer over all of them, for when the runbot is slower.
runbot-233975
Forward-Port-Of: odoo/odoo#235313This change corrects how certain bank export settings are read so the system can access them reliably. It helps avoid errors when generating payment files and ensures the process works as expected for users with standard permissions.
Original PR description
Forward-Port-Of: odoo/enterprise#99359
This change fixes a problem where empty layout rows could trigger an error in the website editor. It adds safeguards so the editor handles empty rows cleanly instead of showing a traceback, improving reliability for users editing page content.
Original PR description
When a .row div was empty, the _areColsCustomized function was called with an empty HTMLCollection. This caused a traceback when the function tried to access columnEls[0]. This commit adds a safety check to _getNbColumns for avoiding extra calls to _areColsCustomized when columnEls is empty. And we also add a similar check to _areColsCustomized for safety, since it's also being called through the _computeWidgetVisibility. opw-5121738 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235555
This update prevents the footer from overlapping invoice content when the Wave document layout is viewed on mobile devices. It keeps the document preview stable so multi-line footers display correctly and do not cover important information.
Original PR description
In the Wave layout, a multi-line footer overlaps document information when the portal view is opened from a mobile interface. Steps to reproduce: - Open Settings > General settings > Configure Document Layout - Select Wave layout and add a multi-line footer - Open an invoice, go to portal preview, switch to mobile view Issue: The footer overlaps invoice information. This occurs because the boundaries of the SVG drawing are not well defined and it will unexpectedly shrink. opw-5023032 Forward-Port-Of: odoo/odoo#230230
This update fixes a display issue in the product catalog view where long attribute values could spill outside the product card and disrupt the layout. The product image and text now stay neatly contained, improving the appearance and readability of quotations and product selections.
Original PR description
Steps to reproduce: 1. Go to Products > Create a new product. 2. Add or create a new attribute with a long text value. 3. Go to Sales > Open any quotation. 4. In the sale order line, click on…
Steps to reproduce: 1. Go to Products > Create a new product. 2. Add or create a new attribute with a long text value. 3. Go to Sales > Open any quotation. 4. In the sale order line, click on "Catalog" and search for the created product. Issue: - The product image and attribute value text overflow outside the product card in the kanban view, causing layout misalignment and breaking the UI design. <img width="647" height="225" alt="image" src="https://github.com/user-attachments/assets/afc592bb-e25a-4d81-882b-0e7cc7ad1064" /> Cause: - The inner div containing the attribute text lacked overflow control, allowing long text to exceed the container width and pushing other elements. Solution: - Added the Bootstrap class `overflow-hidden` to the div element to ensure the image and text remain properly contained within the card layout. <img width="587" height="171" alt="image" src="https://github.com/user-attachments/assets/580ce1e5-42bd-4c2d-b6bf-14315759626d" /> - In forward-port 18.3 Added m-1 instead of m-0 before : <img width="345" height="162" alt="image" src="https://github.com/user-attachments/assets/36d4aed2-b285-44be-884a-6bf94df854a3" /> After : <img width="379" height="212" alt="image" src="https://github.com/user-attachments/assets/3832a691-2f60-4cc1-8176-8aebd0f8973a" /> opw-5222002 Forward-Port-Of: odoo/odoo#235214
This change fixes an intermittent test failure in the web interface by waiting for the error dialog to actually appear before checking it. It makes the test more reliable and reduces false failures during automated runs.
Original PR description
Before this commit, the test sometimes failed because we didn't wait enough before checking the presence of the error dialog. The `unhandledrejection` event being thrown asynchronously, simply waiting for an animation frame isn't enough. We can only wait for the dialog to be displayed. runbot error~234017 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#235464
This update corrects how guided tours move backward when a warning step is present. Warning steps are now skipped properly, so users are no longer briefly taken to an ignored step before returning to the correct place in the tour.
Original PR description
Before this commit, the backward wasn't ignoring the warn steps. So, if the backward go to the previous step (warn's one) and the trigger is on the page, the tour interactive put the cursor there. But the step is then ignored and go back the step you came from. Now, the warn's steps are ignored. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235511
This update corrects how local fixed taxes are shown in Mexican CFDI documents. Previously, a fixed tax amount could be multiplied by 100 in the XML, which produced incorrect tax values; now the amount is handled properly so invoices are generated with the right local tax information.
Original PR description
Steps to reproduce: 1. With an MX Company setup configure a new tax as follows - Tax Computation: Fixed - SAT Tax Type: Local - Factor Type: Cuota - Amount: 5 2. Create a customer invoice with the tax 3. Generate CFDI Issue: In the XML the ImpuestosLocales node contains `<implocal:TrasladosLocales ImpLocTrasladado="VAT 0%" Importe="20.00" TasadeTraslado="500.00"/>` The tax fixed amount was multiplied by 100 This occurs because we don't check if the tax is fixed when normalizing the amount opw-5132807 Forward-Port-Of: odoo/enterprise#98988
Purchase orders that have been locked are now protected from cancellation. If someone wants to cancel one, they must first unlock it, which helps prevent accidental changes and keeps order records more reliable.
Original PR description
Issue before this commit: ========================== Locked purchase orders could still be cancelled, which defeats the purpose of locking them. Steps to reproduce: ========================== 1. Install the `purchase` module. 2. Enable "Lock Confirmed Orders" in the configuration. 3. Create and confirm a purchase order. 4. Lock the purchase order. 5. Try to cancel it → the PO still gets cancelled despite being locked. After this commit: =========================== Cancelling a locked purchase order is no longer allowed. If a user tries to cancel a locked PO, a UserError will be raised instructing them to unlock it first. Locking a purchase order is intended to prevent accidental changes, including edits and cancellations, once the order is confirmed. With this change, users must explicitly unlock a purchase order before cancelling it, ensuring better control and data integrity. TaskId: 4760864
This change prevents an error that could occur when users tried to reopen a product’s configuration from a quotation line after the product name had been removed. It ensures the Edit Configuration option only appears when it is valid to use, avoiding disruptions during sales order editing.
Original PR description
Currently, when a user adds a configurable product to an order line, and remove the name of product and click on `Edit Configuration` (pencil icon) error is encountered. **Steps to Reproduce:** -…
Currently, when a user adds a configurable product to an order line, and remove the name of product and click on `Edit Configuration` (pencil icon) error is encountered. **Steps to Reproduce:** - Install Sales module - Create a Quotation - Add a product(e.g Acoustic Bloc Screen), then only remove the name from the orderline and click on **edit button(pencil Icon)**. **Error:** `TypeError: SaleProductConfiguratorController.sale_product_configurator_get_values()` `missing 1 required positional argument: 'product_template_id'` **Root Cause:** When a user clicks on Edit configuration, the client-side JavaScript makes an RPC call to the server, targeting the `sale_product_configurator_get_values`. which expects product_template_id at [1] and since it is removed from order line the error is encountered. [1]- https://github.com/odoo/odoo/blob/1b657cf1e1ce43874a3ede307b2f8ad68216aa56/addons/sale/controllers/product_configurator.py#L11-L13 **Solution:** This commit prevents the error by correcting `depends` on the field `is_configurable_product`, which will ensure that edit button will be only present if the configurable product is selected. Sentry-5741581459, 6925770690 Forward-Port-Of: odoo/odoo#217464
The OEE value shown on a workcenter is now calculated using the same exact numbers as the detailed report. This removes small discrepancies caused by intermediate rounding, so users see consistent and more accurate performance figures.
Original PR description
**Current behavior:** The form view for a workcenter has an OEE smart button which can display a different value from the real OEE displayed by the `mrp_workcenter_productivity_report_oee` displayed…
**Current behavior:** The form view for a workcenter has an OEE smart button which can display a different value from the real OEE displayed by the `mrp_workcenter_productivity_report_oee` displayed when actually clicking the button and looking at the report. **Expected behavior:** Same values **Steps to reproduce:** 1. Make a workcenter and a BoM with an operation performed at the workcenter 2. Use the BoM in an MO such that there is some un-productive time (e.g., recorded production duration takes longer than expected duration) * example: 0:20 expected, 1:01 actual 3. Go to the workcenter list view -> click on the created workcenter -> look at OEE smart button display value -> click on it to see report -> report values are different **Cause of the issue:** the `oee` field on the workcenter is computed with rounded intermediary `blocked_time` and `productive_time` values, the actual report uses the raw values. **Fix:** Don't use the rounded intermediary values in computing `oee`. Post-this-diff, we actually do one less `_read_group` (along with computing a more accurate field value). opw-4795463 Forward-Port-Of: odoo/odoo#232730 Forward-Port-Of: odoo/odoo#218310
This fix ensures invoices sent to ZATCA use the right electronic path when the customer contact belongs to a parent company. In those cases, the system now treats the invoice as a company invoice and sends it through the clearance process instead of the reporting process, avoiding incorrect submission handling.
Original PR description
…earance or reporting api When sending an invoice to ZATCA, if the contact is an individual, the invoice is sent through the reporting API, and if the contact is a company, the invoice is sent through the clearance API. As of now, if the contact has a parent company, the invoice is sent through the report api. However, we need to make sure that in this case, the invoice goes through the clearance api. The fix introduced simply checks the partner_id.commercial_partner_id to decide whether the invoice is a simplified invoice (i.e. through the reporting api) or not. Task-5085142 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#234691
Fixed an issue where duplicating a spreadsheet tab could sometimes show outdated content because the browser reused an old cached response. The system now sends explicit cache instructions so users see the most recent spreadsheet data when duplicating tabs.
Original PR description
It happens that browser may use a cache if there's no explicit cache control/expiration time: https://httpwg.org/specs/rfc9111.html#heuristic.freshness Steps to reproduce (non-deterministic): - create a new spreadsheet - do some changes, edit a few cells - right click on the tab and hit "Duplicate" => the spreadsheet is not up-to-date on the duplicated tab. The browser loaded the response from "disk cache" instead of fetching the latest data from the server. I'm using Chrom Version 142.0.7444.162 (Official Build) (64-bit) We add an explicit cache control. Forward-Port-Of: odoo/enterprise#99426
Follow-up reminder emails now correctly send any attachments and dynamic reports configured on the email template. This ensures customers receive the full set of documents expected when a payment reminder is sent.
Original PR description
### Issue: We can add attachments and dynamic report to the email templates, but they are not sent with follow-ups. ### Steps to reproduce: - Go to the "Payment reminder" email template - Under the…
### Issue: We can add attachments and dynamic report to the email templates, but they are not sent with follow-ups. ### Steps to reproduce: - Go to the "Payment reminder" email template - Under the page "Content", add an attachment by clicking the "Attachments" button - Under the page "Settings", add a dynamic report - Create an overdue invoice for a partner - Go on the form view of the partner, "Accounting" page - Click "Send", make sure the template used is the one with the attachments - Send - The attachments on the template and the dynamic report are not sent ### Cause: The mail template to send the follow-ups is only used to prefill the wizard. ### Solution: Add the template in `_get_wizard_options()` to add the template in the option and later use it to add/generate its attachments. This commit also refactors how the attachments are computed: The previous code was adding the invoices PDFs then removing them. The whole process was confusing. Now `options['attachment_ids']` is appended in `_get_followup_attachments()` with the desired attachments depending on the options. opw-5147736 Forward-Port-Of: odoo/enterprise#98454
Refunds initiated from Helpdesk now create a credit note with only the product selected by the user. This also limits the product suggestions to the products linked to the original sales order, reducing mistakes and preventing unrelated items from being refunded.
Original PR description
_ ## Short functional explanation of the error Let's say a customer buys 2 products. An SO is created. This customer wants to refund only one of the 2 products. He sends a ticket to helpdesk and we…
_ ## Short functional explanation of the error Let's say a customer buys 2 products. An SO is created. This customer wants to refund only one of the 2 products. He sends a ticket to helpdesk and we click on refund. Even if we specify the product to refund, this action creates a credit note containing both products (previously present on the SO) instead of only the one to refund. Additionally, when selecting the product, we could see in the dropdown of suggestions all the existing products, instead of only the ones related to the SO. ## Reproduction Steps 1. Create a SO containing 2 different products and confirm it. 2. Create a regular invoice and confirm. 3. Go to Helpdesk. Click on the configuration tab, and helpdesk teams. 4. Click on your helpdesk team, scroll down. In After-Sales, check "Refunds". 5. Create a ticket and specify the customer who wants to refund. Make sure the correct helpdesk team is assigned. 6. Click on refund. It opens the wizard. Specify the product to refund and the Invoices to Refund. 7. Click on reverse. ### Expected behavior A credit note containing only the specified product to refund should be created. ### Unexpected behavior The created credit note contains both products originally present on the SO. ## Origin of the issue When issuing a refund from helpdesk_stock_account, this piece of code is called: https://github.com/odoo/enterprise/blob/2051e84c55618c64179c4b9f3e99f4e795bacd32/helpdesk_stock_account/wizard/account_move_reversal.py#L16-L17 which calls the ```reverse_moves``` method in the helpdesk_account.py file, which itself calls the ```reverse_moves``` method in the account_move_reversal.py file, in the account module, and so on. Finally, we arrive in the account_move.py file. In the ```_reverse_moves``` of this file, we can see the code: https://github.com/odoo/odoo/blob/bee7fc1f955c52a88b527ad9a2ddf0021529bbc7/addons/account/models/account_move.py#L4937-L4947 where we simply copy all the lines of the move in the SO without filtering them. As a result, we get the lines of the product we don't want to refund __ opw-5148789 Forward-Port-Of: odoo/enterprise#98771
This update fixes a timing issue in batch barcode processing so the system correctly waits for an underlying operation to finish before moving on. It reduces occasional scan failures during batch picking and makes barcode workflow behavior more reliable for users.
Original PR description
Commit bc9247d46225c696842bc7b0e3c883320231ab1b has introduced an override of the `processBarcode` method. However, it does not return nor await the super call. In particular, in the case where the super call should be done the overrides returns "undefine" rather than a promess to await and hence that call is not awaited anymore. Note: This error has been noticed from the fact that the test `test_barcode_batch_scan_lots` sometimes fails on step 29/31. runbot-233631 Forward-Port-Of: odoo/enterprise#99303
When users reconcile an invoice from the invoice screen, Odoo will no longer automatically treat a short payment as fully settled. The invoice now remains partially paid unless the user explicitly chooses a write-off, which helps avoid misleading payment status and accounting errors.
Original PR description
When reconciling an invoice from the invoice form view, Odoo currently applies the payment tolerance logic and marks the invoice as fully paid even when the payment amount does not actually cover the full residual. Reconciliation from the invoice should never auto-close the invoice. It must remain partially paid unless the user explicitly triggers a write-off. This PR disables tolerance-based full reconciliation when the matching is initiated from the invoice. task-5246513 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
This update prevents partner records from storing the same fiscal country code twice, which could happen for some U.S. companies. It avoids a display issue on partner forms and keeps the underlying data cleaner without changing how users work.
Original PR description
Recently we started considering `country_code` as part of the `fiscal_country_codes` [1]. Because of this, the field can now contain duplicates. If your active company is a US one, and you set United States as the country on the partner you end up with `US,US`. It breaks some (admittedly fragile) invisible conditions on the `res.partner` form view [2]. Although we could fix those conditions, it would require everyone to update the module, and having duplicate country codes in `fiscal_country_codes` field doesn't serve any purpose anyway. [1] https://github.com/odoo/odoo/pull/229584 [2] https://github.com/odoo/enterprise/pull/62615 opw-5248844 opw-5241556 Forward-Port-Of: odoo/odoo#235652
When returning to a Kanban view after removing a grouping, the system now correctly restores the record limit. This prevents the view from trying to load an excessive number of records, which could slow down the page or cause a crash.
Original PR description
Steps to reproduce ================== - Add a group by in the kanban product view - Switch to the list view - Remove the group by - Switch back to the kanban view -> No limit is applied, and the webclient can crash if too many records are returned. Cause of the issue ================== The groupsLimit is set as MAX_SAFE_INTEGER in the kanban view https://github.com/odoo/odoo/blob/df959e05ac9cf3136d1724bc80b7597a70932225/addons/web/static/src/views/kanban/kanban_controller.js#L168 Which is then reused as the limit https://github.com/odoo/odoo/blob/df959e05ac9cf3136d1724bc80b7597a70932225/addons/web/static/src/model/relational_model/relational_model.js#L368 Solution ======== There is already a code path to reset the limit when switching from grouped to ungrouped, but is wasn't called on the first load (when this.root isn't set yet) opw-5167769 Forward-Port-Of: odoo/odoo#235598 Forward-Port-Of: odoo/odoo#235232
Event registration emails will no longer show a price when the attendee’s ticket is fully discounted and the total is zero. This avoids confusing customers with an amount that is not actually due.
Original PR description
Steps to reproduce: 1. Create a new sale order with an event ticket line 2. Apply a 100% discount on the ticket line 3. Confirm the sale order 4. Check on the new attendee created, the mail sent to the attendee. Current behavior: The email shows the unit price without the discount applied which can be confusing for the customer as it might look like they need to pay that amount. After this commit: The email will just show the confirmation of the registration to the event withouth mentioning the price when the total price is 0. opw-5122776 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235482
Miscellaneous changes
In order to put the localization translations on Weblate, we did some cleanup of the POT and PO files for them: - Re-exported all POT files - Removed POT files for countries that don't need other languages than English - Removed all `i18n_extra` folders and moved any existing translations over to the `i18n` folder - Updated PO file names by removing superfluous country codes, or simply correcting wrong ones - Removed PO files for irrelevant languages in a localization - Updated the PO file
Original PR description
In order to put the localization translations on Weblate, we did some cleanup of the POT and PO files for them: - Re-exported all POT files - Removed POT files for countries that don't need other languages than English - Removed all `i18n_extra` folders and moved any existing translations over to the `i18n` folder - Updated PO file names by removing superfluous country codes, or simply correcting wrong ones - Removed PO files for irrelevant languages in a localization - Updated the PO files according to the POT files using `msgmerge` - Added new PO files for missing languages We also updated the `.weblate.json` file to add all the localizations in a separate Weblate project, limited to the languages they support. task-5169642 Related: https://github.com/odoo/enterprise/pull/99389 saas-18.2: https://github.com/odoo/odoo/pull/234739 saas-18.4: https://github.com/odoo/odoo/pull/235120
In order to put the localization translations on Weblate, we did some cleanup of the POT and PO files for them: - Re-exported all POT files - Removed POT files for countries that don't need other languages than English - Removed all `i18n_extra` folders and moved any existing translations over to the `i18n` folder - Updated PO file names by removing superfluous country codes, or simply correcting wrong ones - Removed PO files for irrelevant languages in a localization - Updated the PO file
Original PR description
In order to put the localization translations on Weblate, we did some cleanup of the POT and PO files for them: - Re-exported all POT files - Removed POT files for countries that don't need other languages than English - Removed all `i18n_extra` folders and moved any existing translations over to the `i18n` folder - Updated PO file names by removing superfluous country codes, or simply correcting wrong ones - Removed PO files for irrelevant languages in a localization - Updated the PO files according to the POT files using `msgmerge` - Added new PO files for missing languages We also updated the `.weblate.json` file to add all the localizations in a separate Weblate project, limited to the languages they support. task-5169642 Related: https://github.com/odoo/odoo/pull/235503 saas-18.2: https://github.com/odoo/enterprise/pull/99009 saas-18.4: https://github.com/odoo/enterprise/pull/99189