Daily updates from Odoo
Tuesday, April 8, 2025
13 changes · 18.0
New functionality added to Odoo
Android point-of-sale devices can now manage content on an external customer-facing screen. This enables shops using mobile POS hardware with secondary displays to show checkout information to customers more clearly.
Original PR description
Implemented a communication bridge to enable customer display support on Android PoS devices with external screens. This allows the frontend web application to control content displayed on the secondary screen. See https://github.com/odoo/mobile/pull/252 See https://github.com/odoo/mobile/pull/254 task-4456187
Enhancements to existing features
This update aligns Indian HSN summary calculations with Odoo’s standard tax calculation engine, reducing custom logic and improving consistency across invoices and point of sale receipts. It also improves how small tax rounding differences are spread across lines, making totals fairer and more accurate.
Original PR description
Since 18.0, the taxes computation engine is managing the round globally. It means we have helpers and tools to manage features based on multiple base lines at a time. The hsn summary was using a custom representation of a base line with an explicit call to the low level _get_tax_details method. This commit removes this custom code to use the generic base lines instead. Also, this commit adds a test in POS to ensure the feature is working. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Belgian payroll now supports mobility budget payments in salary rules and related payroll inputs. The update also includes these amounts in the required DmfA social security declaration, helping employers stay compliant with Belgian reporting rules.
Resolved issues and error corrections
This fix prevents the Point of Sale from returning to the first screen when a customer takes longer to complete an online payment. It helps preserve the current order during checkout, avoiding lost payment context and hanging orders.
Original PR description
Description of the issue/feature this PR addresses: When doing online payment in POS, customer may take some time and the POS may go to idle state. This causes when it goes to idle and back to alive,…
Description of the issue/feature this PR addresses: When doing online payment in POS, customer may take some time and the POS may go to idle state. This causes when it goes to idle and back to alive, it will direct to the first screen. Steps to reproduce: - Create POS & setup POS online payment (use Demo online payment) - Open POS, add a product, go to payment screen, select the online payment method - Let it go to idle state (triggered by useIdleTimer) - Move the cursor, or at least make it back to active state - You'll see the screen be redirected to first screen - Do the payment, it will redirect to TicketScreen with empty order info, and when you click new order the previous one is still hanging there Alternatively take a look at the recording: https://github.com/user-attachments/assets/b8e8ae81-df04-41e0-b122-002413714735 Current behavior before PR: - Because it bounces to first screen, when attempting payment the pos does not have the order state Desired behavior after PR is merged: - Do not redirect if in payment screen, so that order context won't be lost --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Restaurant self-order receipts now show a valid unique order code, and their QR codes and links open the correct ticket page. This prevents customers from landing on broken pages when downloading or viewing receipts after ordering from the mobile menu.
Original PR description
Steps: === - Open the restaurant's POS system. - Configure it for self-invoicing with QR code + link. - Access the restaurant's mobile menu. - Place an order and download the receipt. Issue: === - The receipt shows an incorrect unique code. - The QR code and link redirect to `undefined/pos/ticket`. Fix: === - Corrected the system to generate a valid unique code for each order. - Fixed the QR code and link to properly redirect to the correct page. Task: 4512074
This fix prevents an unexpected error when users manually revalue lot- or serial-tracked inventory after lot-based valuation has been disabled. Instead of crashing, the system now shows a clear validation message when no remaining quantity is available to revalue, helping users avoid disruption in inventory valuation workflows.
Original PR description
Issue Before This Commit: ============================ When attempting to add a new valuation for a lot/serial-tracked product using the 'Add Manual Valuation' button while the 'Group By Lot' filter…
Issue Before This Commit: ============================ When attempting to add a new valuation for a lot/serial-tracked product using the 'Add Manual Valuation' button while the 'Group By Lot' filter is applied, a 'ZeroDivisionError: float division by zero' traceback occurs. Steps to Reproduce: ============================ - Install the stock_account module. - Create a product, enable Lot/Serial tracking, and assign it to the Furniture category. - Update the quantity and assign a lot/serial number, which creates a valuation layer for this lot-tracked product. - Disable Valuation by Lot/Serial Number for the product. - Go to Valuation, apply the Group By Lot filter, and try to create a new valuation by clicking Add Manual Valuation. - Click on the Revalue button it will give an Error. With This Commit: ============================ The issue occurs because when revaluing layers using the 'Add Manual Valuation' button, all layers have 0 remaining quantity. This happens if 'Valuation by Lot/Serial Number' was initially enabled, creating valuation layers for lot/serial-tracked products, and later disabled. As a result, all valuation layers associated with lot/serial numbers have zero remaining quantity. When attempting to revalue these layers while using the 'Group By Lot' filter, the error occurs. This commit ensures that if all layers have 0 remaining quantity, a validation error is raised to prevent the issue. task - [4668497](https://www.odoo.com/odoo/my-tasks/4668497)
New trial databases using the Argentine localization could fail during setup when company data was automatically filled with a foreign tax ID. This change prevents the Argentine CUIT identifier from being applied unless the existing tax ID is valid, allowing setup to complete smoothly.
Original PR description
### Steps to reproduce: - Create a new DB on odoo.com/trial with Argentinean localization, and your Odoo email. - After installation, a validation is raised: "Invalid length for CUIT". ### Here is…
### Steps to reproduce: - Create a new DB on odoo.com/trial with Argentinean localization, and your Odoo email. - After installation, a validation is raised: "Invalid length for CUIT". ### Here is what happens: 1. When creating a new company, the enrich function tries to complete data. If you created the database with an `odoo.com` email for example, the Company will be filled with a Belgian VAT. https://github.com/odoo/odoo/blob/5bb57a916d3069cd609e07d401dd3b4c39f85954/addons/partner_autocomplete/models/res_company.py#L23-L28 2. The l10n_ar is then installed, and the CUIT will be set as the default identification. https://github.com/odoo/odoo/blob/9a44bc80a5f8bd1cfcb05a3a9f4abdbd67228488/addons/l10n_ar/models/account_chart_template.py#L37 3. Finally, the validation is triggered by the modification above. Obviously the Belgian VAT is not compatible with the CUIT format, which leads to a User Error. https://github.com/odoo/odoo/blob/4c1d2025118b98e89c131a32d46015d9c6a3b032/addons/l10n_ar/models/res_partner.py#L56-L57 Note: to reproduce in local, you have to add IAP credits. ### Solution: Solution: When installing the l10n_ar package, let's only set CUIT as a default if the validation passes. opw-4609583
This fixes an issue in the HTML editor where selecting text near the top of content could unexpectedly scroll down to a large image. Users can now select the intended text more reliably in task descriptions and other rich text fields.
Original PR description
**Problem**: Scroll was not working properly on selection change. **Solution**: Use the `getBoundingClientRect` of `Range` to calculate scrolling, which is more accurate in this case. Handle edge cases where the range consists only of `br` elements, which have no size or position. **Steps to reproduce**: 1. Go to Project → Task. 2. Type something and press `Shift + Enter` two or three times. 3. Press `Shift + Enter` twice. 4. Add a large image, making the scrollbar appear. 5. Go to the top and try selecting the text. - **Issue**: The scroll automatically moves down to the image every time, preventing selection of the intended text. **opw-4686994** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a point of sale issue where, after validating an order, the system could stay on the Payment screen instead of moving to the Receipt screen. It affects setups using automatic receipt printing with a configured POS printer when receipt preview is not skipped, helping cashiers complete sales without manual navigation.
Original PR description
Before this commit, when automatic receipt printing was enabled, a POS printer was configured, and the "Skip Preview" option was not enabled, the POS remained on the Payment screen after order validation instead of switching to the Receipt screen. opw-4656023 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Belgian payroll calculations now use the latest FFE rates effective through January 2025. This helps ensure payslips and related payroll accounting stay aligned with current Belgian requirements.
Belgian payroll now excludes employees who started after June 30 from receiving the 13th month bonus when they are not eligible. The tax rate calculation for this bonus is also corrected so payroll can consistently compute the proper withholding amount.
Original PR description
This PR excludes the employees that started after the 30/06 of the 13th month. They are not elligeable as they started more than 6 months before the payment of the bonus. As part of this PR, the computation of the correct tax rate has been fixed. The amount is bounded so that a tax rate can always be computed. task-4583139
Fixes issues in Gantt scheduling notifications when tasks with dependencies are rescheduled. Users can now undo schedule changes only when the system has enough information to restore them, and warning messages display correctly instead of causing errors.
Original PR description
## [FIX] web_gantt: make sure orm service is defined in gantt renderer Before this commit, when the user reschedules his task with dependencies by clicking on any arrow displayed in the gantt…
## [FIX] web_gantt: make sure orm service is defined in gantt renderer Before this commit, when the user reschedules his task with dependencies by clicking on any arrow displayed in the gantt connector. A notification is displayed to notify the user the action is done with success, that notification also contains an `Undo` button to let the user to undo the rescheduling made. However, if the user clicks on the undo button, a traceback occurs. The reason is because `orm` service is not defined in the gantt renderer. This commit makes sure the orm service is defined in the gantt renderer to be able to call the `action_rollback_scheduling` method. ## [FIX] web_gantt: don't display undo button if old vals are not given Before this commit, after the `web_gantt_schedule` call was done, a notification is displayed according to the result received by the `web_gantt_schedule` call done. The problem is even if the `old_vals_per_pill_id` is not given when the gantt scheduling has been made with success, the `Undo` button is displayed. The problem is without `old_vals_per_pill_id`, it is impossible to undo the action done, because the initial data before the `web_gantt_schedule` is not known without that data, and so, if the user clicks on `Undo` button a traceback will occur since we cannot retrieve the initial data of the records processed in the `web_gantt_schedule` method. This commit makes sure the `Undo` button is displayed only if we have the information to `undo` the `web_gantt_schedule` method. To know that, the `old_vals_per_pill_id` should be given in the result of `web_gantt_schedule` to be able to revert the changes made by `web_gantt_schedule`. ## [FIX] web_gantt: correctly display warning notification Before this commit, a warning notification was not properly displayed because the method does not return what we expect. Instead of returning the message and notification type, it returns a client action to call `display_notification`. Moreover, the warning notification does not display the right icon, it display `fa-check` instead of `fa-warning`. This commit changes the object returned for the warning to have the expected values returned and changes the icon when the notification is a warning one. task-4687572
Settling a customer's outstanding balance in Point of Sale no longer triggers invoice creation when there are no products involved. This prevents blank-screen crashes in Mexican localization and similar setups that automatically invoice company customers.
Original PR description
Currently, when settling customer's account using the mexican localization, the session crashes after selecting the payment method. Steps to reproduce: ------------------- * Install the mexican…
Currently, when settling customer's account using the mexican localization, the session crashes after selecting the payment method. Steps to reproduce: ------------------- * Install the mexican localization and switch to one of the company * Create a new contact of type "Company" * Create an invoice for that contact so that he has a due amount set * Open session * Select the customer and settle due amount * Select any payment method > Observation: Blank screen Why the fix: ------------ Same issue addressed here but at a different place: https://github.com/odoo/enterprise/commit/e1e1abdd23cead2bcd7b8170da28161c3f5b2e15 Cause by the fact that when a customer of type "company" is selected we automatically invoice orders. https://github.com/odoo/odoo/commit/270779c8250272920d759fbe7b6cfc889e2f5969 Instead of going in the same direction of the first fix, we never set `to_invoice` to true when we are settling customer accounts. It's pointless to set invoice to true when settling accounts as it's impossible to create an invoice without any product. This should also benefit localizations that invoice by default every order by bypassing the invoice in that case. opw-4685842