Daily updates from Odoo
Monday, April 28, 2025
15 changes · 18.0
Enhancements to existing features
Kitchen order tickets in Point of Sale now include details from online orders, helping staff better identify and prepare those orders. The receipt rendering was also adjusted to handle changing order details more efficiently.
Original PR description
Following this commit : - getRenderedReceipt method is optimised to pass dynamic values. - o-employee-name class has been added for applying xpath. Enterprise PR: https://github.com/odoo/enterprise/pull/81559 task-4633156
Kitchen order tickets now show the delivery platform name, online delivery status, and preparation time for Urban Piper orders. This helps restaurant staff quickly identify online orders and prioritize preparation without checking separate systems.
Original PR description
Following this commit : - Aggregator name is displayed on KOT i.e Ubereats,Zomato etc. - Since it is an online order, instead of Dine In/ Take out , Delivery/Online should be displayed. - Preparation time is also displayed. Community PR: https://github.com/odoo/odoo/pull/202003 task-4633156
Resolved issues and error corrections
Fixed a problem that could stop Italian electronic invoices from being sent automatically when invoices from multiple companies were processed together. The system now handles each company's invoices separately, helping prevent failed submissions to SDI during batch sending.
Original PR description
Fix an issue when sending invoices asynchronously to SDI from multiple companies. Steps to reproduce: - Setup two Italian companies, A and B - Create and post one invoice in each company - From the list view, batch send both invoices - Run the “Send invoices automatically” scheduled action An error occurs: ValueError: Expected singleton: account_edi_proxy_client.user(4, 3) This happens because both companies try to send their moves simultaneously, but the proxy client is company-specific. This fix groups the invoices by company before sending them. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4725653) opw-4725653
This pull request bundles several fixes and small improvements that make daily Odoo workflows more reliable. It improves payment handling, email server error handling, data exports, point-of-sale down payments, time-off precision, and user interface display details.
Original PR description
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
Fixed an issue where saved default filters using the current user placeholder could cause an internal server error when opening JSON links. Users can now access filtered JSON views such as Sales without disruption.
Original PR description
**Steps to Reproduce:** - Go to Sales - Make a user-defined filter and make it the default filter - Try to access the JSON link (/json/sales) - You will see an error **Issue:** - When users apply…
**Steps to Reproduce:**
- Go to Sales
- Make a user-defined filter and make it the default filter
- Try to access the JSON link (/json/sales)
- You will see an error
**Issue:**
- When users apply default filters like 'My Quotations' or 'My Documents', Odoo saves 'uid' in the filter's domain to represent the logged-in user.
- However, when the system tries to process this filter, it fails because 'uid' is just a placeholder and not a valid value. This results in an **internal server error**, preventing users from applying these filters correctly.
**Cause:**
This issue is caused after this commit: https://github.com/odoo/odoo/pull/182196
- The domain string stored in 'ir.filters' includes 'uid' instead of the actual user ID.
- When Odoo('ast.literal_eval()') tries to evaluate the filter, it doesn’t know what 'uid' means, causing an error.
**Fix:**
- Replace 'uid' with `str(model.env.uid)` before evaluating the domain.
- This ensures 'ast.literal_eval()' processes a valid domain.
**Affected version:** 18.0~master
**opw**-4645608Fixed an issue where kiosk screens could fail to rotate because the saved orientation setting did not match the format expected by the display system. This helps ensure connected kiosk displays use the intended orientation reliably.
Original PR description
Before this commit: ==================== Screen rotation was failing due to a mismatch in the orientation key format. The orientation key was saved in lowercase from the form view, but the set_orientation method expects the key in uppercase to match the format used by xrandr/wlr-randr. After this commit: =================== The orientation key is now properly passed in uppercase using Orientation[data.upper()], ensuring that screen rotation works as expected in kiosk mode. Task-4755613
Invoices will no longer be automatically suggested for PEPPOL sending when the company has not completed PEPPOL registration. This prevents checkout-related automatic invoicing from failing and helps ensure customers can complete card-paid ecommerce orders smoothly.
Original PR description
Use case: - Create an database with eCommerce (`website_sale`) (and for a country where PEPPOL is supported) - Enable `Automatic Invoice` in General Settings. - Configure everything for PEPPOL but do…
Use case: - Create an database with eCommerce (`website_sale`) (and for a country where PEPPOL is supported) - Enable `Automatic Invoice` in General Settings. - Configure everything for PEPPOL but do not register the company (Partner have their PEPPOL EAS and Endpoint correctly configured) - Enable a card payment provider - As a customer, buy something from the shop and paid using a card => When post-processing the customer payment (payment.transaction) we will automatically generate and send the invoice; and while trying to send the invoice we will crash with: `ValueError: Expected singleton: account_edi_proxy_client.user()` The reason is that we try to send the invoice to both email and PEPPOL while the company's registration on PEPPOL was not yet be done. This commit ensure we don't suggest sending by default on PEPPOL if the company is not allowed to send on PEPPOL. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where online shop orders using click-and-collect with pay-at-store could show an error even after the order was successfully confirmed. Customers can now complete these purchases without being blocked by unnecessary post-payment checks.
Original PR description
Steps to reproduce:
1) Enable Click and Collect
2) Configure pick up in store and add a store in US
3) Set the available country to Belgium
4) Enable Pay at the store and set the country to Belgium
5) Go to /shop page and add a storable product
6) Proceed to payment and pay choosing pickup in store delivery method
and pay on site payment method
7) Observe an error
Reason:
/shop/payment/validate checks for payment errors even after the order
was confirmed and payment went through. When confirming a sales order
with pickup in-store dm the partner_shipping_id is changed to the
selected pickup point address. If the countries/zipcodes are not
matched with the ones set on the delivery method or some information is
missing then the result of `_get_delivery_methods` called by
`get_shop_payment_errors` can be empty which causes and error.
Solution:
No need to check for payment errors after payment.
opw-4592939The POS screensaver now properly appears above open popups, preventing confusing overlaps. Restaurant POS login behavior was also corrected so staff can return from the screensaver and open a session without it immediately reappearing.
Original PR description
* = pos_restaurant In this commit: === - Ensured that when a popup is open and the screensaver appears, the popup no longer overlays the screensaver. - Fixed an issue in the restaurant module is installed, after the screensaver appears on the login screen, clicking would bring back the login screen, but attempting to open a session would trigger the screensaver again. task-4607035
Swiss QR bill documents will now display the creditor bank account address, postal code, and city, matching the information embedded in the QR code. This prevents customer confusion and helps ensure Swiss payment slips contain consistent payment details.
Original PR description
Description of the issue/feature this PR addresses: Wrong address/zip/city in Swiss QR bill template. Current behavior before PR: The template for Swiss QR bills uses the company address, zip code and city. Desired behavior after PR is merged: The template for Swiss QR bills uses the address/zip/city of the creditor's bank account. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users signing documents linked to sales orders no longer see an access error after completing the signature. The document was already signed successfully, but this fix removes the confusing error by avoiding a restricted lookup used for the Back button.
Original PR description
current implementation of `_get_linked_record_action` searches in `ir.actions.act_window` model to fetch data to create action for `Back button`, a user might not have access to the this model which comes from "Settings/Administration" group, this leads to Access Error steps to reproduce: 1. install sign and sales module 2. login with demo user 3. create a sign template 4. open a sale order and request a sign 5. sign the document 6. Access error (though the document is signed properly) [opw-4575288](https://www.odoo.com/odoo/project/49/tasks/4575288)
This fixes how subscription upsell lines are matched to their original subscription lines when multiple upsell orders are handled at the same time. It prevents valid upsells from losing their link and avoids duplicate product lines being added to the parent subscription.
Original PR description
Before this commit _compute_parent_line_id make the assumption that a parent line can only be linked to once child: When the parent_line_id is set, it's remove from the pool of possible…
Before this commit _compute_parent_line_id make the assumption that a parent line can only be linked to once child: When the parent_line_id is set, it's remove from the pool of possible parent_line_id Actually this is not the case, different upsell order can have a line that have the same parent. Upsell order A can have line 1 with the same parent as the line 2 of Upsell order B. Before this commit if the parent line of both order were computed at the same time one of them would end up without parent. This situation is getting worse since odoo@42008de (saas-18.1) were all the parent_line_id are recomputed on every upsell order (even already confirmed one) as soon as line on the parent order are touched The follow use case lead to duplicate line on the parent A parent subscription A with 1 product Z Create an upsell B with a line that upsell 1 product Z Create an upsell C with a line that upsell 1 product Z On both upsell the parent line is set properly Confirm Upsell B, the parent line on Upsell C is set to false Confirm Upsell B, the parent subscription ends up with a two line for the product Z After this commit, parent_line_id are computed per order, so one order cannot have two lines with the same parent_line_id but two (or more) different order can have each one line with the same parent_line_id even if their parent_line_id are computed at the same time.
Automatic customer follow-up emails now include the expected invoice attachments, matching the behavior of manually processed follow-ups. This helps ensure customers receive all necessary documents when payment reminders are sent automatically.
Original PR description
### Steps to reproduce: - Create an invoice with a due date past for long time - Accounting > Customers, click on the partner of the invoice - In the page "Accounting" the "Follow-up Status" should…
### Steps to reproduce: - Create an invoice with a due date past for long time - Accounting > Customers, click on the partner of the invoice - In the page "Accounting" the "Follow-up Status" should be "In need of action" - Click the gear to see the actions > "Process Follow-ups" - The follow-up is send without any attachment ### Cause: This [commit](https://github.com/odoo/enterprise/commit/cc759094a32e413cb1b71cbbe7be9dc85ded819f) moved the block of code responsible for getting the attachments from `_send_email` to `execute_followup`. The goal was to generate the attachments even if the "email" option is not selected in the send&print wizard. So basically, always generate the attachments. But the method `execute_followup` is only called when processing the follow-ups manually, via the wizard. So the server action sent the follow-up without attachments. ### Solution: Move the block of code from `execute_followup` to `execute_followup_partner` which is the method called in any case to send the follow-up report. This way we always have attachments with the followup. A lot of tests had to be adapted as they are now calling `export_to_pdf`. The test `test_send_followup_no_due_date` had the option `'manual_followup': True` but no `attachment_ids` which is never supposed to happen, it was crashing [here](https://github.com/odoo/enterprise/blob/2da6836520c4e7760e57062e3e97a22b744baacf/account_followup/models/res_partner.py#L278). opw-4715486
Automatic customer payment follow-ups now include the expected report attachment, matching the behavior of manually triggered follow-ups. This helps ensure customers receive complete follow-up communications without staff intervention.
Original PR description
In cc759094a32e413cb1b71cbbe7be9dc85ded819f, the follow-up report generation was moved from `_send_email` to `execute_followup`, which is only called during manual follow-up processing. As a result, the report was missing when follow-ups were triggered by the cron. This commit moves the report generation logic to `_execute_followup_partner`, which is called in both manual and automatic (cron) cases. Also, patched `_run_wkhtmltopdf` in `TestAccountFollowupReports` to prevent tests from hanging, since PDF generation requires multiple workers and tests run with only one. task-4752110
This update removes obsolete payroll logic that was blocking certain Belgian payroll data imports. Businesses using Belgian payroll can import payslip-related information more reliably, reducing manual work and failed import attempts.