Daily updates from Odoo
Monday, February 10, 2025
7 changes · saas-17.2
Resolved issues and error corrections
This fixes a display issue in the mass mailing editor where the snippet sidebar could slide under the control panel when using the Event Promo template at higher browser zoom levels. The sidebar now adjusts to the template height while scrolling, keeping the editor controls visible and easier to use.
Original PR description
How to reproduce: 1. create a new mailing. 2. from the existing available Mail Body templates, select Event Promo. 3. zoom In to around 125% or greater scale. 4. scroll the page to the end. Issue: 5.…
How to reproduce: 1. create a new mailing. 2. from the existing available Mail Body templates, select Event Promo. 3. zoom In to around 125% or greater scale. 4. scroll the page to the end. Issue: 5. as you scroll, you will notice the snippet sidebar stays sticky till a certain point, but as we reach the end of the template itself, and the page starts to scroll, the sidebar goes under the control panel. video of the issue --> https://www.awesomescreenshot.com/video/33360044?key=46734c8ba59b1144830c3939e24ed12f Reason: 7. in previous version (i.e. 17.0) the sidebar's top and bottom was dynamically controlled on every scroll. refer --- https://github.com/odoo/odoo/blob/17.0/addons/mass_mailing/static/src/js/mailing_mailing_view_form_full_width.js#L91-L96 8. we use `position: sticky` in the current version to achieve that outcome, but when the template itself starts to scroll, the stickiness disappears. Fix: 9. once the page has started scrolling we recalculate the height of the sidebar to match it with the height of the template. Task-4137980
Fixed a display issue in mass mailing templates where the editing sidebar could overlap the email content after returning to a template. This makes template editing more reliable and prevents layout confusion for users.
Original PR description
Previously, the has_snippets_sidebar class was only applied when clicking the template during creation. Now, the fix ensures that the class is correctly applied on load, preventing the body from overlapping with the sidebar when returning to the template. Task-4266339
This fixes an issue where the second step of a two-step delivery could be sent to the general customer location instead of the specific customer sub-location. Businesses using detailed customer delivery locations will now see stock transfers created with the correct destination, reducing delivery errors and manual corrections.
Original PR description
to reproduce: ============= - make warehouse with 2-step delivery - create contact with Customer Location = Partners/Customers/Test (make sure location type = Customer location) - create a sale order with this contact - confirm the sale order - confirm first delivery -> the second delivery is created but the destination location is set to **Partners/Customers** instead of **Partners/Customers/Test** Problem: ======== - starting from 17.2 the second pick is created after validating the first one at creation used vals received from the move has the wrong destination location, it will be recomputed after creating the second pick but it's too late to change the destination location of the second pick Solution: ========= - recompute the destination location of move when preparing vals of the second pick opw-4374075 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Spreadsheet pivot formulas now show the available measures when a user enters an invalid measure. This helps users correct mistakes faster and reduces confusion when working with pivot reports.
Original PR description
Before this commit, applying a pivot formula with an invalid measure returns an error message without showing possible measures. This commit fixed that Task 3754942 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The FACe/Factura-e section on invoices now appears only when the related company is located in Spain. This avoids showing Spain-specific electronic invoicing fields to companies in other countries, reducing confusion for users.
Original PR description
We should show the FACe/Factura-e section on invoice when the related company is located in Spain. opw-4397651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a payment validation issue where incoming payments could be blocked by a requirement intended for outgoing payments. It helps avoid confusion and supports payment methods such as Italian RiBa that need a bank account for incoming money without treating it as an outgoing payment.
Original PR description
The `require_partner_bank_account` flag on the payment shouldn't require the `allow_out_payment` flag on it when the payment type is `inbound` as it leads to confusion. This generates an issue with the `l10n_it_riba` RiBa payment method. It requires the bank account, but the money is incoming, not outgoing. Enterprise PR: odoo/enterprise#77901 Task [link](https://www.odoo.com/odoo/project/967/tasks/4497749) task-4497749
This fix improves how invoice changes are protected from unintended automatic recalculations during updates. It helps keep accounting data consistent when invoices or invoice lines are created or modified.
Original PR description
Missing commit from the forward-port of https://github.com/odoo/odoo/pull/193528