Daily updates from Odoo
Monday, August 4, 2025
10 changes · master
Resolved issues and error corrections
The Preparation Display menu now appears when the restaurant preparation display feature is installed. This prevents users from hitting an error while setting up or exploring demo data and makes the feature easier to access.
Original PR description
Steps to reproduce: --- - Install `point_of_sale` module(without demo) - Point of Sale > Orders > `Preparation Display` - Create new and Load Demo Data(Explore Demo Data) Traceback: --- `AttributeError: The method 'pos.config.load_onboarding_restaurant_scenario' does not exist` In this commit: --- The `Preparation Display` will be visible in the main menu if the `pos_restaurant_preparation_display` module is installed.
This fixes an error that could stop HR from completing an offer after a new hire signed it. The process now avoids closing an incomplete draft contract for new employees while still closing previous contracts correctly for existing employees.
Original PR description
Steps: - Go to Recruitment > create/select an applicant > Create Offer - Sign the offer as the applicant > Sign as HR responsible. Issue: - Validation Error: 'Start date must be earlier than contract end date.' Reason: - When a new employee signs, a contract version is created without start/end dates. - On HR sign, the old version is ended (with end_date) as per earlier fix [#88915], but if the old version has no start_date then it breaks the constraint. Fix: - Only set end_date on old version if start_date exists (for existing employee). - For existing employees, the old contract closes cleanly with end date. - For new hires, we skip setting end_date to avoid constraint issues. task-4948131
Inventory users can now open the map view for receipts and delivery orders even when batch transfer features are not enabled. The change removes a dependency on an optional batch transfer field, preventing an error that blocked access to the map view.
Original PR description
When a user without enabling 'Batch, Wave & Cluster Transfers' from settings, tries to open the map view for any stock transfer operations (e.g., Receipts, Delivery Orders), a error is raised.…
When a user without enabling 'Batch, Wave & Cluster Transfers' from settings, tries to open the map view for any stock transfer operations (e.g., Receipts, Delivery Orders), a error is raised. **Steps to Reproduce:** - Install Inventory App. - Navigate to 'Receipts' or 'Delivery Orders'. - Switch to map view. **Error:** `ValueError: Invalid field 'batch_sequence' on model 'stock.picking'` **Root Cause:** Since [this commit](https://github.com/odoo/enterprise/pull/78373/commits/fddb39104d675af2784559fe2f7cb28f8dc6120b), the `stock.picking.view.map` view has a hardcoded `default_order` attribute that sorts by `batch_sequence` as shown at [1]. This field is only added to the `stock.picking` model when the `stock_picking_batch` module is installed. This creates an invalid view definition, where this optional module is not present, causing an error. **Solution:** This commit resolves the issue by removing the `default_order='batch_sequence'` from the stock picking map view at [1]. This ensures the map view no longer depends on the `stock_picking_batch module`. [1]- https://github.com/odoo/enterprise/blob/5e0380513899f199340620d8ce17eff5b5b6aec3/stock_enterprise/views/stock_picking_map_views.xml#L8 sentry-6732756118 Forward-Port-Of: odoo/enterprise#90399
Manufacturing users who are not HR users can now open the Shop Floor app without an access rights error. The app now looks up an employee only when a barcode is scanned, avoiding restricted employee data access while preserving barcode identification on the shop floor.
Original PR description
**PROBLEM** If a user is in the mrp.group_mrp_user group, but does not belong to hr.group_hr_user, he can't access the shop floor app. **STEP TO REPRODUCE** 1. connect with a user which is a user of manufactring, but not a user of hr. 2. try to go on the shop floor app and notice there is an access right error. **CAUSE** When connecting to the shop floor app, we are trying to get the barcode field on all employee (because we need them if we want to identify an employee on the shop floor app using their barcode). This was added in this commit: https://github.com/odoo/enterprise/commit/b3fb0073a15adcc799a5681284f0cfd2308764b8 The barcode field is only accessible to member of hr.group_hr_user. **FIX** Instead of getting the barcode of all employee using `get_all_employee()`, we do a rpc call to query the employee the barcode belong to. opw-4905206 Forward-Port-Of: odoo/enterprise#89436
Rejecting an UrbanPiper order in Point of Sale now works without causing an error screen. This keeps staff workflows smooth when declining test or real incoming orders and ensures the POS returns to a usable state afterward.
Original PR description
Steps to reproduce: --- - Configure UrbanPiper in any POS configuration. - Open this POS and place a test order. - Attempt to reject the order. Issue: --- - A traceback occurs when rejecting the order. Cause: --- - The `removeOrder` function was being called unnecessarily, even though it is already handled by `deleteOrders`. Fix: --- - Removed the redundant call to `removeOrder`. - Additionally, called `afterOrderValidation` and `setSelectedOrder` to properly reset the state after rejection. task-4965076 Forward-Port-Of: odoo/enterprise#91525 Forward-Port-Of: odoo/enterprise#91116
French VAT XML filings now place grid 26 refund requests in the correct field. This prevents reimbursement amounts from being omitted or sent in the wrong place when businesses submit VAT returns.
Original PR description
The French VAT report line for grid 26 ("Repayment of credit requested on form n°3519") uses code `box_26_external`, but the XML generator only mapped `box_26` to the `JB` tag.
As a result, the reimbursement amount was missing or incorrectly placed in the XML file.
This commit maps `box_26_external` to `JB` to ensure the correct tag is used when the user fills in grid 26.
opw-4931275
Forward-Port-Of: odoo/enterprise#90940This update improves the accounting audit workflow by making new working files easier to create and audit checks easier to follow. It also fixes status changes so validated checks remain usable when an audit is moved between ongoing and done.
Original PR description
Task https://www.odoo.com/odoo/project/967/tasks/4840028 was requested to merged very quickly and not everything could be done on time. This PR fixes/adds several things.
POS orders invoiced after session closing are now included correctly in GSTR1 HSN reporting. This helps ensure Indian tax return data remains complete after certain database migrations or session closing scenarios.
Original PR description
The issue occurs when a POS session closing entry is generated without grouping by HSN + UOM, which can happen after a database migration from an older version. Before this PR: POS orders were included only if they were **not invoiced** and had no **reversed_move_ids** (which is set when the invoice is created after closing the session). After this PR: POS orders are included if they are **not invoiced** **or** if they have **reversed_move_ids** (invoiced after session close). This ensures that reversed POS orders are properly processed in the GSTR1 HSN computation. OPW: 4931360
Payment links for recurring sales orders now use the next invoice amount instead of factoring in past payments. This prevents customers from seeing incorrect payment amounts on already-invoiced subscriptions.
Original PR description
Before this commit,when a payment link was generated for a recurring SO already invoiced, the default values of amount and amiunt_max would take into account all previous transactions. As a result, the amount would be badly computed as recurring order have many transactions (at least once or each period). This commit ensure to use the next invoice amount. taskid: 4352396 Forward-Port-Of: odoo/enterprise#83934
Audit report PDFs now prepare currency data before calculating figures like revenue and net accounting result. This prevents an internal error when users print audit reports and helps ensure the report values are generated correctly.
Original PR description
The method for generating the PDF of an audit report currently crashes when computing the template variables "revenue" and "net accounting result". This issue arises because the underlying method…
The method for generating the PDF of an audit report currently crashes when computing the template variables "revenue" and "net accounting result".
This issue arises because the underlying method used to compute these values runs raw SQL queries that perform a JOIN operation on the `account_currency_table`. However, this table is not created automatically by the system: It must be explicitly initialized by calling the method `_init_currency_table`.
This commit updates the code to ensure that `_init_currency_table` is called before invoking the methods that compute the total revenue, the net accounting result, etc. This should prevent the crash and allow the template variables to be computed correctly.
Steps to reproduce the issue on the runbot:
1. Open the Accounting App
2. In the navbar, click on "Accounting" > "Audit Reports"
3. Create a new audit report
4. Fill the form and save
5. Click on the "Print" button of the kanban card.
=> A new page should open displaying an internal error.
In the log of the runbot, we have the following log:
```
File "/data/build/enterprise/account_reports/models/account_report.py",
line 3899, in _compute_formula_batch_with_engine_domain
self.env.cr.execute(query)
File "/data/build/odoo/odoo/sql_db.py", line 426, in execute
self._obj.execute(query, params)
psycopg2.errors.UndefinedTable: relation "account_currency_table" does not exist
LINE 10: LEFT JOIN account_currency_table
```
Task-4840940