Daily updates from Odoo
Monday, November 3, 2025
26 changes · master
Enhancements to existing features
This update removes use of an outdated page rendering instruction from the system. It helps keep the platform aligned with current standards and reduces the risk of future compatibility issues, with little expected day-to-day impact for users.
Original PR description
task-4461090
Payroll CSV payment reports now include payment lines for partners linked to company contribution salary rules. This helps ensure employer-side contributions are visible in payment exports, reducing missed or incomplete payroll-related payments.
Original PR description
- For CSV payment reports, add lines for partners defined as company contributions in salary rule configurations. - Ensures that company-side contributions are properly reflected in generated payment reports. Task: 5114655
Demo employee payroll data for India now uses the correct employee pay category and regular pay structure. Two sample payslips are also marked as paid, making the demo data better reflect realistic payroll workflows.
Original PR description
-Update the Pay Category of all demo data employees to "India: Employee Pay". -Update "India: Regular" Pay Structure on all the Demo Payslip Records. -Mark two payslips in the demo data as "Paid".
The POS booking screen no longer automatically opens the search field on tablets and phones. This prevents the on-screen keyboard from appearing unexpectedly, making booking navigation smoother for mobile users.
Original PR description
Task: [#5016943](https://www.odoo.com/odoo/project/1737/tasks/5016943) --- On tablets and phones, the search bar was autofocus when opening the booking screen in the POS frontend. This was causing the keyboard to open automatically, which was not a good user experience. Now the search bar is not autofocus on touch devices for the booking screen by creating a new controller to manage this. Forward-Port-Of: odoo/enterprise#96873
Belgian payroll settings now start benefit fields at 0 instead of pre-filled maximum values, helping users make more deliberate choices. Added placeholders and help tips make the settings easier to understand and reduce configuration mistakes.
Original PR description
* Updated the default values of Belgian benefits to 0 instead of the previous maximum. * Added placeholders and tooltips to several fields to improve user guidance. * Adapted the tests by manually adding benefits so that the calculated salary values match the expected results (the previous expected results were based on the old default values). Task-5135523 (https://www.odoo.com/odoo/project/1251/tasks/5135523)
Resolved issues and error corrections
Lithuanian payslips no longer apply the employee pension contribution twice when the pension accumulation option is enabled. This helps ensure payroll deductions match expected contribution rules and reduces the risk of overcharging employees.
Original PR description
**Issue**
When generating a payslip for an employee with the `l10n_lt_pension` setting enabled on the contract ("Participate to pension accumulation system"):
- the SSC is raised from 19.5% to 22.5%
- a 3% pension contribution ("Pension Scheme") is added This effectively doubles the expected contribution.
Various sources (e.g. https://taxsummaries.pwc.com/lithuania/individual/other-taxes) seem to show this is not correct.
opw-5067664
Forward-Port-Of: odoo/enterprise#98276
Forward-Port-Of: odoo/enterprise#95880This fix ensures payroll runs only check payslips that actually have issues before listing those issues. It prevents incorrect issue handling when a pay run contains a mix of problematic and normal payslips, helping payroll teams review exceptions accurately.
Original PR description
Commit e4e573e1219f38561ae74e2086cee6d54cda6f46 introduced a bug. Steps to reproduce: - Generate a payrun with at least two payslips: one with an issue and another without any issue This commit fixes the issue by filtering the issues payslips before getting their issues. task-5230921
The Planning shift recurrence banner no longer appears immediately after recurrence is enabled. It now shows only after recurring shifts have actually been created, avoiding misleading guidance for users.
Original PR description
**Steps to reproduce:** --------- 1. Create a shift. 2. Save the shift. 3. Open the shift and enable the recurrence. 4. Observe that the recurrence banner is immediately displayed. **Issue:** ----- The recurrence banner is shown as soon as a shift is marked recurring, even though no recurring shifts have been generated yet. This is misleading since the banner has no effect until the actual recurrence slots exist. **Cause:** ------- The banner visibility was based on repeat and id, so it appeared too early, before any recurring shifts were actually created. **Fix:** -------- Update the banner visibility condition to check for both repeat and recurrency. Now, the recurrence banner only appears once the recurrence record exists and recurring shifts are generated: task-5163851 Forward-Port-Of: odoo/enterprise#97245
This change restores the Documents integration for Recruitment because the action to create job applicants from documents is still needed. It prevents users from losing an existing recruitment workflow while allowing future cleanup to be handled separately.
Original PR description
As create applicant action is still needed. Further development could be done to clean the module in a more proper way later if needed. This reverts commit dd38c92a337661b30731ed32f4ae0c0e146a7e8c. Task-5090259
Barcode scans are now ignored when a batch transfer is still being created or is not in a state where scanning should apply. This prevents confusing errors and incorrect messages for warehouse users who open draft, cancelled, or completed batches in the barcode app.
Original PR description
### Issue: Scans processed during picking batch creation in the barcode app are interpreted as scans related to the BarcodePickingBatchModel edition (that is product, lot, package,... scans) which…
### Issue: Scans processed during picking batch creation in the barcode app are interpreted as scans related to the BarcodePickingBatchModel edition (that is product, lot, package,... scans) which does not make sense and raises multiple errors. ### Steps to reproduce: - In the settings enable "Batch Transfers" - Inventory/Operations/Transfers/Batch Transfers - Create a new batch and do not confirm it - Go to the barcode app > Batch Transfers > Clear filters - Select your draft batch - Scan anything #### > Traceback #### Other issues: The same flow with a cancelled batch triggers the same tracebacks and, with a done batch triggers the message: "This picking is already done". ### Cause of the issue: Since `this.state.view === "barcodeLines"`, scans are processed as if we were processing an existing `BarcodePickingBatchModel` with lines: https://github.com/odoo/enterprise/blob/ce7460b27028d4133c4689afd2e8f303268494a0/stock_barcode/static/src/components/main.js#L204-L209 In particular, if the scan corresponds to a product, and error will be raised because the scan can not process a `createNewLine` for the scanned product in the current view and if the scan does not correspond to anything valid, it will raise an error because `this.picking` is undefined and `this.picking.use_existing_lots` raises an error: https://github.com/odoo/enterprise/blob/ce7460b27028d4133c4689afd2e8f303268494a0/stock_barcode/static/src/models/barcode_model.js#L1115 https://github.com/odoo/enterprise/blob/ce7460b27028d4133c4689afd2e8f303268494a0/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L177-L179 opw-5162164 Forward-Port-Of: odoo/enterprise#98022 Forward-Port-Of: odoo/enterprise#97526
A failing test setup was corrected so spreadsheet edition tests pass when that module is installed on its own. This helps keep automated validation reliable and reduces false failures during quality checks.
Original PR description
tests `test_image_attachment_copy_access_rights` and `test_image_attachment_deleted_access_rights` are failing when only `test_spreadsheet_edition` is installed. Runbot error: 233711
Fixed an error that could block French companies from sending a VAT report when launching the EDI VAT action from the tax return report menu. The wizard now keeps the related tax return context, so users can submit the VAT report without encountering a crash.
Original PR description
Steps to reproduce: - With a FR Company Setup - Create a bill with tax in past month - Create Tax return for past month, validate - Click "Submit", fill the required vals in wizard and 'Send VAT report' - Everything works as expected - From Accounting / Accounting / Closing / Tax Returns click Cog > EDI VAT - Fill the required vals in wizard and again 'Send VAT report' Issue: Traceback will raise `ValueError: Expected singleton: account.return()` Analysis: When opening the VAT Return wizard from Accounting / Accounting / Closing / Tax Returns the value of return record is not passed on opw-5107549 Forward-Port-Of: odoo/enterprise#98544
Point-of-sale records created locally are now preserved when syncing with the server, even if the server response does not yet include them. This reduces the risk of losing pending sales, refunds, or settlement information during connectivity or timing issues.
Original PR description
*: l10n_br_edi_pos, pos_settle_due, pos_urban_piper Before this commit, when syncing records from the server, local records that were not yet synced (isSynced=false) could be lost if they were not present in the server response. This could happen for example when a record was created locally and the server response did not include it. This commit fixes this issue by ensuring that local records are always kept when syncing, even if they are not present in the server response. This is done by merging the local records with the server records based on their keys. --- This commit also replace all checks of the form typeof id === "number" with isSynced checks. This is because the id of a record can be a temporary string id before it is synced with the server. Forward-Port-Of: odoo/enterprise#94568
New salary offers created from an existing offer now receive a proper secure link with a generated token. This prevents broken offer links showing "False" instead of a valid token, helping recruiters share salary configurator offers reliably.
Original PR description
_______________________________________ ## Short functional explanation of the error When creating an offer on the page of another offer, the salary configurator url doesn't contain a token, but instead, contains token = false. ## Reproduction Steps 1. Open the recruitment module. If there's no job position nor application, create some. 2. Open an existing application and click on Generate Offer. 3. Click on New on the top left of the screen. 4. Fill the new application and click on save. ### Expected behavior The field 'Link' contains an URL with, at the end, &token=x, with x a randomly generated token. ### Unexpected behavior The field 'Link' contains an URL with, at the end, &token=False. ## Origin of the issue The token generation code wasn't called when creating a new offer the way described in reproduction steps. _________________________________________ opw-4885796 --- Forward-Port-Of: odoo/enterprise#98503 Forward-Port-Of: odoo/enterprise#89546
Belgian accounting now assigns the correct VAT-related receivable and payable accounts to FPS and Collection Center partners. Bank transactions for VAT payments can be matched more automatically, reducing manual reconciliation work and payment-closing errors.
Original PR description
This commit sets AR and AP accounts of "FPS" and "Collection Center" partners with the 2 new added VAT accounts. Additionally, a new reconciliation rules that detects the partner and the communication and creates a counter entry. The partner "FPS" have been added to the VAT closing line for auto-reconciliation with bank transaction. task-5148985
This fix prevents salary rule forms from incorrectly requiring a percentage base field after certain condition changes. Payroll users can now save salary rules without unnecessary validation errors, reducing friction when configuring payroll rules.
Original PR description
**Steps to reproduce:** - Install the hr_payroll module. - Open a salary rule form view. - Change amount_select to Percentage and try to save → validation error occurs because amount_percentage_base is required. - Keep amount_select the same and change condition_select to Salary Input → the same validation error occurs. **Issue:** The amount_percentage_base field is incorrectly made required even when condition_select changes. The requirement should depend solely on amount_select, not condition_select. **Cause:** The field amount_percentage_base remains mandatory when condition_select is updated, leading to validation errors. **Fix:** This PR adjusts the logic so that the amount_percentage_base field is required only when appropriate, based on both condition_select and amount_select. task-5090125 Forward-Port-Of: odoo/enterprise#95419
On very small screens, the empty-list illustration no longer covers the barcode scan button. This ensures warehouse users on handheld scanners or small phones can continue scanning items even when a filtered list has no results.
Original PR description
On small screens (e.g., Zebra scanner, iPhone 4), the image overlaps the barcode scan button, making it impossible to click and scan new items. ### Steps to reproduce: On a small screen size (Zebra…
On small screens (e.g., Zebra scanner, iPhone 4), the image overlaps the barcode scan button, making it impossible to click and scan new items. ### Steps to reproduce: On a small screen size (Zebra scanner, Iphone 4,..) * Open barcode app * Go on Operations -> Receipts * Apply a filter so that the list becomes empty. -> the image is over the barcode button and the text. ### Observation: Our image (in div .o_view_nocontent) has position absolute, anchoring it to the top part of the screen where the search bar is located (in div .o_control_panel). The issue is that in barcode there is another element where the button to scan is located (o_kanban_tip_filter), and since the image is absolutely positioned relative to the top rather than this element, it ends up overlapping the button and the text, preventing interaction. ### Why the fix: The solution we chose is to change the position of the image to relative, for the image to not hide the text. Another possible solution was to make the image (more specifically .o_view_nocontent .o_nocontent_help) ignore all input, allowing them to go through the image and reach the button below. opw-5123880 Forward-Port-Of: odoo/enterprise#98243
This change fixes an intermittent issue that could occur when closing AI-related chat windows. It makes the close process happen in the expected order, reducing unpredictable failures and improving reliability for users.
Original PR description
Attempt to fix runbot error 233689 by refactoring `_onClose` across patches. The problem occurs because of the async nature and the many side effects that occur. `_onClose` is not supposed to be async. PR community https://github.com/odoo/odoo/pull/233597
Point of Sale cash session names now keep a continuous sequence when cash posting fails. This prevents missing session numbers, making records easier to follow and reducing confusion during audits or daily reconciliation.
Original PR description
Before this commit, if an issue occurred while posting the cash details, the session sequence would still increment even though the operation failed, leading to gaps in session names. With this commit, the sequence only increments when the operation succeeds, ensuring continuous session naming without gaps. related: https://github.com/odoo/odoo/pull/233183 opw-5180712 Forward-Port-Of: odoo/enterprise#98468 Forward-Port-Of: odoo/enterprise#98157
This update makes closing AI-related chat windows more dependable by preventing timing issues that could cause inconsistent behavior. It helps reduce errors in automated checks and improves stability for users interacting with chat features.
Point of Sale preparation displays now include any free-text details entered for custom product attributes. This helps kitchen or preparation staff see the full customer request, matching the information already shown on receipts.
Original PR description
Steps to reproduce: ------------------- 1. Create a PoS product with an attribute of type "Radio", name it "X", and add a value to it, name it "Y", with the "Free text" option selected. 2. From PoS, click the product, for the attribute "X", select the value "Y", and enter some text in the text input area "blabla". 3. Order the product. Observation: On the preparation display, only the attribute name and value are display, but not the entered text, i.e. "X: Y" instead of "X: Y: blabla". Fix: ---- We now show the custom value (free text) if any. This matches what's been shown on the receipt in PoS. opw-5111768 Forward-Port-Of: odoo/enterprise#95874
The salary contract test setup was corrected to rely only on permission groups from modules it already depends on. This prevents avoidable test failures and helps keep quality checks stable without changing employee-facing functionality.
Original PR description
Before this commit: Running `hr_contract_salary` tests were failing, due to groups used from the module `hr_payroll`, which is not part of the dependencies. After this commit: Use groups from the dependencies. runbot-233547 Forward-Port-Of: odoo/enterprise#98286
Code cleanup and technical improvements
The IoT Box now includes its device handlers by default instead of downloading them from the database during startup. This should make startup faster and reduce setup or connection issues for payment terminals, black boxes, cameras, and quality devices.
Original PR description
To speed up the IoT Box startup process and reduce the amount of potential issues, we now avoid downloading handlers from the database by providing them all by default on the IoT Box. odoo/odoo#233991
This update modernizes internal messaging-related code by using the current shared model reference path instead of an older compatibility path. It should not change day-to-day behavior for users, but it helps keep maintenance simpler across AI, approvals, VoIP, live chat helpdesk, and WhatsApp features.
Original PR description
Imports of `@mail/src/model` should be made through `@mail/model/export`. In the past the source code of JS models was also in `@mail/core/common` but was moved in its `model/` folder. `@mail/core/common/record` was kept for backward compatibility.
The appointment calendar was adjusted to stay compatible with recent calendar display changes. This keeps appointment scheduling working smoothly as the interface evolves to support viewing multiple months.
Original PR description
This commit makes some changes to the appointment calendar renderer, since the renderer from /web has been changed to support the display of multiple months at once in the ActionSwiper.
This update cleans and standardizes website-related JavaScript files across several website modules. It helps keep the codebase easier to maintain without introducing expected changes for end users.
Original PR description
[LINT] website_documents, *: lint website related files *: website_enterprise, website_generator, website_product_barcodelookup, website_studio The goal of this commit is to lint the website related js files. task-5110180