Friday, March 21, 2025
14 changes
Resolved issues and error corrections
On mobile devices, pressing Enter in Discuss now creates a new line instead of sending the message. This prevents accidental message sending and makes writing multi-line messages possible for mobile users.
Original PR description
The composer should not send the current input on Enter key when being on a mobile device, since it is impossible for them to create a new line with either ctrl-Enter or alt-enter. [FIX] mail: Discuss on Mobile - Enter key behavior The composer should not send the current input on Enter key when being on a mobile device, since it is impossible for them to create a new line with either ctrl-Enter or alt-enter. Task-4209142
Mobile sales order entry now includes the required price information to calculate quantity-based discounts correctly. This ensures customers using mobile views see the expected discounted unit price when order quantities meet pricelist rules.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a pricelist with any discount on all products with a minimum quantity of 5; 2. Create a new sale order in mobile view; 3. Create a new sale order line, select any product and set a quantity higher than 5. Issue ----- The price unit isn't discounted as expected. Cause ----- `_compute_price_unit` needs `technical_price_unit` which is missing from the mobile view. Solution -------- Add `technical_price_unit` to mobile sale order views. opw-4569731 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
Canceled order lines in Point of Sale are now included on preparation tickets. This helps kitchen or preparation teams see cancellations clearly and avoid preparing items that customers no longer want.
Original PR description
- Fix issue where canceled orderlines were not printed on the preparation ticket. task-id: 4663618 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Rental orders for kit-based products can now be picked up without incorrectly trying to update stock for the kit itself. This prevents a blocking error and ensures the system handles the kit's components as expected during rental pickup.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- Can be rented: True
- tracked by quantity
- BoM:
- type: kit
- component: C1
- Create a rental order with one unit of P1
- confirm it
- Click on pickup:
- validate the wizard
Problem:
A user error is triggered:
"You should update the components' quantity instead of directly updating the quantity of the kit product."
This happens because the system attempts to update the available quantity of the kit product in the quants.
opw-4572337This fixes a point of sale issue where a global discount could remain in the order even after all products were removed. It prevents customers from checking out a cart that contains only a discount, improving order accuracy and reducing payment mistakes.
Original PR description
## Current behavior before PR: The global discount (if configured) in the POS module persist in the order line (summary order) even when there is no product present in it. ## Steps to reproduce / Description of the issue feature this PR addresses: - Install `POS` module - Go to `POS` -> `Configuration` -> `Settings` - Search for `Global Discount` check the tick mark and save it - Open that particular shop for which Global Discount is configured - Add some products to the cart - Apply Global Discount to the order(`Actions` -> `Discount`) - Remove all the products from the cart except the discount and then checkout that cart, it will let you do the payment. ## Desired behavior after PR is merged: If global discount is applied to the cart and if user removes the product then discount order line won't persist anymore. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Gift card activity is now recorded correctly when a card is used in a point-of-sale order. This helps businesses keep accurate customer loyalty and gift card records, reducing confusion during balance checks or customer service follow-up.
Original PR description
Loyalty history for gift cards was not working properly. The history was not being updated when a gift card was used in a POS order. Steps to reproduce: ------------------- * Create some gift cards * Use one in the PoS to make an order > Observation: The history is not updated accordingly Why the fix: ------------ Instead of relying only on `coupon_updates` we check that card id provided exist before creating the history record. opw-4546985-1
Italian e-invoice XML exports now convert unit prices into the company currency when invoices are issued in a foreign currency. This keeps unit prices aligned with total prices and avoids incorrect electronic invoice values for Italian companies.
Original PR description
Requirements: l10n_it_edi, IT company - Change the exchange rate between EUR and USD (or any foreign currency) to 2. - Create an invoice in USD with one product priced at 100, then generate the XML.…
Requirements: l10n_it_edi, IT company - Change the exchange rate between EUR and USD (or any foreign currency) to 2. - Create an invoice in USD with one product priced at 100, then generate the XML. In the XML, PrezzoUnitario (price unit) is not equal to PrezzoTotale (price total), even though there is only one quantity. When using a currency other than the company currency, PrezzoUnitario is in the foreign currency (here, USD). Both PrezzoTotale and PrezzoUnitario should be in the company currency. The test test_export_foreign_currency xml has also been updated to reflect recent changes. Specifically, in the XML export: - The price unit is recorded as 1068.11(USD). - To total price is recorded as 841.49(EUR) which was converted from 907.49(USD). - Knowing there is a 15% discount, the correct unit price should be 841.49(EUR) / 0.85 = 990(EUR) (similar logic to justify changing the other xml) opw-4593300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a bank statement line is disconnected from an invoice, Odoo now correctly resets the related payment status instead of leaving it marked as paid. This helps accounting teams avoid misleading payment records after reconciliation changes.
Original PR description
Before this commit, when doing the reconciliation of a statement line with an invoice without a journal entry, we were trying to find a matching payment for that statement line and setting it as paid. However, it didn't do the opposite when breaking the matching between the invoice and the statement line. This commit adds that opposite behavior.
Time off for flexible resources is now shown correctly as unavailable time in the Planning Gantt view. This helps planners avoid assigning work during approved leave and prevents calculation issues for resources with flexible or missing calendars.
Original PR description
Prior to this commit, flexible resources did not have their leaves reflected as gray cells in the planning gantt view. This was due to the work_intervals being ignored for the calculation of flexible resources availability. This commit adds measures to handle the leaves for flexible resources by setting a dummy attendance (which covers the whole length of the period in gantt interval), and then injects their leaves interval. To replicate: 1. set a timeoff to a flexible resource 2. open planning app 3. in the gantt view, the day in which the timeoff was set should be grayed. ticket-id: 4492625 enterprise: [79532](https://github.com/odoo/enterprise/pull/79532) 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
Reconciled batch payments now keep showing the full combined payment amount instead of incorrectly appearing as zero. This helps accounting users review batch payments accurately after matching them with bank transactions.
Original PR description
[[FIX] account_batch_payment: show correct amount in reconciled batch payments](https://github.com/odoo/enterprise/pull/80862/commits/d9f837d4bb459a10e74b65c10204e2c31573e7a5) **Issue:** When…
[[FIX] account_batch_payment: show correct amount in reconciled batch payments](https://github.com/odoo/enterprise/pull/80862/commits/d9f837d4bb459a10e74b65c10204e2c31573e7a5) **Issue:** When reconciling a batch payment, its amount is incorrectly displayed as zero in the list view. **Steps to Reproduce:** 1. Install the Accounting app. 2. Navigate to Accounting > Customers > Payments. 3. Create or select two payments, then click Create Batch. 4. Validate the batch payment. 5. Go to Dashboard > Transactions. 6. Create a new transaction with the same value as the batch payment. 7. Click on the transaction, select the batch payment, and click Validate to reconcile them. 8. Navigate to Customers > Batch Payments. 9. Observe that the batch payment in the list view shows an amount of zero. Expected Behavior: The list view should display the sum of the payments included in the batch. Actual Behavior: The amount displayed in the list view is always zero after reconciliation. **Root Cause** During reconciliation, when execution reaches line 138 in account_batch_payment.py https://github.com/odoo/enterprise/blob/08084d8423a7d75c1ee2647256e01a464eec0b14/account_batch_payment/models/account_batch_payment.py#L137 , the batch payments are already in the paid state. However, _valid_payment_states() https://github.com/odoo/enterprise/blob/08084d8423a7d75c1ee2647256e01a464eec0b14/account_batch_payment/models/account_batch_payment.py#L69-L70 calls _get_invoice_in_payment_state(), which returns "in_payment". As a result, _valid_payment_states() only returns "in_process", excluding payments in the "paid" state from the computation. Consequently, in _compute_from_payment_ids(), the loop over valid payments is skipped, leaving the amount variable at its initial value of zero. https://github.com/odoo/enterprise/blob/08084d8423a7d75c1ee2647256e01a464eec0b14/account_batch_payment/models/account_batch_payment.py#L132-L162 **Fix** Always compute `amount`. Skip `amount_residual` and `amount_residual_currency` for valid payment states. Opw-4585624
Customer statements now include entries from all journal types, not only sales or payment-related journals. This gives customers and finance teams a more complete and accurate view of account activity.
Original PR description
Customer statement should includes all journals opw-4617548 opw-4631371 opw-4587303
Rental pickups for products sold as kits now correctly adjust the kit components instead of the parent kit product. This prevents an error during pickup validation and lets users complete rental orders involving kit-based products.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- Can be rented: True
- tracked by quantity
- BoM:
- type: kit
- component: C1
- Create a rental order with one unit of P1
- confirm it
- Click on pickup:
- validate the wizard
Problem:
A user error is triggered:
"You should update the components' quantity instead of directly updating the quantity of the kit product."
This happens because the system attempts to update the available quantity of the kit product in the quants.
opw-4572337Customer statements and follow-up reports now align more closely with the partner ledger by including the same relevant transaction rows, including miscellaneous entries. This gives businesses a more complete and consistent view of partner account activity while keeping the reports concise.
Original PR description
The customer statement should show the same info as the partner ledger, but in a more condensed way (less columns, same rows). Same for the Follow-up report, but here we should by default filter on sales journals. Ticket - 4606122
Time off for flexible resources is now shown correctly as unavailable time in the Planning Gantt view. This helps planners avoid assigning work during full-day or half-day absences and fixes display issues when viewing schedules by day or across multiple days.
Original PR description
…nning gantt Prior to this commit, flexible resources did not have their leaves reflected as gray cells in the planning gantt view. This was due to the work_intervals being ignored for the…
…nning gantt Prior to this commit, flexible resources did not have their leaves reflected as gray cells in the planning gantt view. This was due to the work_intervals being ignored for the calculation of flexible resources availability. This commit adds measures to handle the leaves for flexible resources by setting a dummy attendance (which covers the whole length of the period in gantt interval), and then injects their leaves intervals. To replicate: 1. set timeoffs to a flexible resource (whole day and half day) 2. open planning app 3. in the gantt view, the day in which the timeoff was set for a whole day should be fully grayed (in the default month granularity view) 4. when selecting only a day as the granularity of the gantt view, the day in which the timeoff was set for a half day should be half grayed. (from 00:00-12:00 in case of a morning timeoff, and from 12:00-24:00 in case of an afternoon timeoff) ticket-id: 4492625 community: [198032](https://github.com/odoo/odoo/pull/198032)