Daily updates from Odoo
Friday, July 11, 2025
14 changes
Enhancements to existing features
Spreadsheet users can now choose filter matching options such as including, excluding, or containing values depending on the type of filter. This makes spreadsheet analysis more precise and easier to tailor to business questions.
The India payroll payslip report has been improved to show more comprehensive information using the India payslip format. This helps employees and payroll teams review pay details more clearly and consistently.
Original PR description
- customized the standard payslip using the IN: Payslip task-4790769
Payroll payment report details are now cleared when a payslip or payslip batch is moved back to draft, helping avoid outdated payment information being reused by mistake. The update also removes obsolete payroll payment report references, making the process cleaner and less error-prone across supported local payroll modules.
Original PR description
this PR aims to - reset the `payment_report` related fields when the payslip is set to `draft` state. - remove the dead view ID (`hr_payslip_payment_report_view_form`) from the actions. task-4894688
This update changes how Point of Sale data is prepared for India GSTR-1 reporting, especially the product classification totals used in the filing JSON. It reduces unnecessary POS-specific calculation complexity and adds checks to help ensure the exported tax data stays accurate and compliant.
Original PR description
**Remove HSN Computation for POS**: The HSN computation logic for Point of Sale (POS) entries has been removed to streamline the processing and avoid unnecessary complexity in the calculations. Task Id: 4193554
Resolved issues and error corrections
This fix ensures WhatsApp messaging features load consistently across all relevant Odoo pages, including backend, public discussion pages, live chat, and portal chatter. It prevents message updates from failing when broadcasts are received in tabs outside the main backend interface.
Original PR description
`common` folder should be included in all bundles. This is especially necessary when broadcasting messages on the bus, because these messages will be received in all tabs, including those potentially not in the back-end, such the discuss public page, any page where a live chat is opened, or a portal page with a chatter. This is also necessary just to have all features properly working in all context, there is no reason that a whatsapp viewed in the public page should not have its features working as intended. runbot-223082 Forward-Port-Of: odoo/enterprise#89847
This fixes an issue that could prevent payslips from being created for Belgian employees when a work entry covered a long period, such as a full month. Payroll teams can now process these payslips without encountering the error.
Original PR description
There is a bug in the module that made the creation of payslip triggers an error. Steps to reproduce it :
1) Use a Belgian company and an employee with a contract;
2) Create a work entry for a whole month (from 05/01/2025 09:00:00 to 06/01/2025 17:00:00 for example);
3) Try to create a payslip for this employee.
Error :
File "/data/build/enterprise/l10n_be_hr_payroll/models/hr_contract.py", line 517, in _get_work_hours_split_half
work_data[('half', work_entry.work_entry_type_id.id)] += dt.days * 24 + dt.seconds / 3600 # Number of hours
TypeError: 'float' object is not iterable
[opw-4752109](www.odoo.com/odoo/project/49/tasks/4752109)
Forward-Port-Of: odoo/enterprise#89039
Forward-Port-Of: odoo/enterprise#84810This fixes an error that could block draft accounting entry creation when a payroll batch contained payslips from more than one company. Payslip company selection is now protected from manual changes, and older inconsistent records show a clear validation message instead of a system traceback.
Original PR description
Currently a traceback is occurring when the user tries to create a Draft Entry, in the batch that contains payslips of multiple companies. **To reproduce this issue:** 1) Install hr_payroll_account…
Currently a traceback is occurring when the user tries to create a Draft Entry, in the batch that contains payslips of multiple companies. **To reproduce this issue:** 1) Install hr_payroll_account and switch to multi-company environment 2) Create two employees with two running contracts respectively 3) Now create a Batch record from payroll/payslips/batches 4) Create two playslips with different companies with the created batch 5) Compute both the payslips and open the batch 6) Now, try to click on the Create Draft Entry **Error:** A traceback will occur. ``` ValueError: Expected singleton: res.company(1, 2) ``` **Cause:** When the user created multiple payslips with multiple companies containing the same batch and tries to create a Draft Entry, we filtered out the payslips based on the payslip state, and try to change the state to Done using the action_payslip_done method. https://github.com/odoo/enterprise/blob/1e5d7155466f80942f0b8fe2df7fdfb86cae7417/hr_payroll/models/hr_payslip_run.py#L70 So the self will contain multiple payslip recordsets with different company in each payslip. This leads to the above traceback when accessing company_id from self https://github.com/odoo/enterprise/blob/1e5d7155466f80942f0b8fe2df7fdfb86cae7417/hr_payroll_account/models/hr_payslip.py#L61 **Solution:** In payslips, the company_id field should be in readonly state, since the value of the company_id will computed from the employee_id which is a required field. Also raised a validation Error for the previously created record to handle the traceback. Related Upgrade PR:- https://github.com/odoo/upgrade/pull/7763 opw-4797089 Forward-Port-Of: odoo/enterprise#89085 Forward-Port-Of: odoo/enterprise#86628
Bank reconciliation now avoids matching statement lines when a reference or move name only appears as part of a longer value. This reduces incorrect automatic matches, especially for invoice or journal references that resemble dates or prefixes.
Original PR description
Actually, we are matching to blindly for full matches. We only check if aml.move_name or aml.ref is present in st_line label.
But this cause issues with move names like dates, where you could have :
- move_name = 2025/123
- label contains 2025/1234567
In this case, we don't want to match, as 2025/123 is not perfectly present in the label.
So this commit update the condition so we need now to have a perfect full match between st_line label and aml.ref or aml.move_name.
no-task
Forward-Port-Of: odoo/enterprise#89248This fixes a Point of Sale issue where employees with minimal permissions could enter negative quantities during refunds when the UrbanPiper integration was installed. The change helps ensure refund handling follows the intended permission controls and reduces the risk of incorrect order adjustments.
Original PR description
Fix issue where when `pos_urban_piper` was installed, minimal right employee were able to set negative orderline qty with a refund through the ticket screen. task-id: 4922318 community PR: https://github.com/odoo/odoo/pull/217774 Forward-Port-Of: odoo/enterprise#89669
Appointment requests now avoid linking a new opportunity to a customer record from a company the appointment staff cannot access. This prevents multi-company booking submissions from failing with company compatibility errors, making online appointment lead creation more reliable.
Original PR description
**Steps to reproduce:** - Set up CRM / Appointment / Website apps - Create new company (2) - Create partner contact with specific email and the new company - Create appointment type linked to a staff…
**Steps to reproduce:**
- Set up CRM / Appointment / Website apps
- Create new company (2)
- Create partner contact with specific email and the new company
- Create appointment type linked to a staff user of another company (1) who has no access to the new one
- Enable `Create Opportunities` on the new appointment type
- Go to the website as an anonymous user
- Submit an appointment request using the partner's email
- `Incompatible companies on records:` error
**Issue:**
Previous solution (17.0) was trying to use existing partner if the email was provided and existed in the database
`customer = request.env['res.partner'].sudo().search([('email_normalized', '=', email_normalized)], limit=1`
This means that, in a multi-company environment, the lead created by the new appointment for the appointment user of company 1 can be linked to the partner contact of company 2 and throw an error on validation.
**Fix:**
Restricted partner search domain using current allowed companies using the `staff_user` or the user which created the `appointement_type`.
opw-4713060
Forward-Port-Of: odoo/enterprise#89196
Forward-Port-Of: odoo/enterprise#84006Manufacturing orders created or opened in the barcode app now handle bill of materials lines that use units different from the product default. This prevents errors when unit settings are disabled and ensures component quantities use the intended units, reducing mistakes in production operations.
Original PR description
Previous behaviour: * Traceback if MO created with a BoM whose lines have UoMs that don't correspond to those of the products, then UoM setting disabled and MO viewed in the barcode app. * BoM line UoMs ignored in favour of product UoMs when creating MO in the barcode app. New behaviour: * No traceback. * Stock moves in MOs properly created with the corresponding BoM line UoMs. Task ID: [4674196](https://www.odoo.com/odoo/my-tasks/4674196)
This fixes how monthly payroll summary data is grouped for Swiss ELM transmissions. It helps ensure payroll reports sent through the Swiss payroll process contain complete and accurately aggregated information.
Original PR description
Forward-Port-Of: odoo/enterprise#89914 Forward-Port-Of: odoo/enterprise#89839
Fixes an issue where clicking “Close Production” from the Shop Floor did nothing after an operation was marked done. Manufacturing orders now close correctly from the Shop Floor, helping operators keep production status accurate without switching screens.
Original PR description
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the…
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the All MO tab > The operation was removed from the Assembly line - Click on "close production" #### > Nothing happends while the MO should be marked as done and disappear ### Cause of the issue: The issue has been introduced by commit [X](10ed12241365942914885dff953049303b9ed94f) To be more precise, clicking on the "Close production" button will launch a call of the `validate`. In case of `mrp.production` records, this call will first launch a call of the `pre_button_mark_done` and then (prior to the change) add the record to the validation Stack for real Validation: https://github.com/odoo/enterprise/pull/79918/commits/10ed12241365942914885dff953049303b9ed94f#diff-7695d0af56f8efc3200fc5a693b797de9314165f4754bb2054d25809381c0ccdL504 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L530 Prior to commit [X](10ed12241365942914885dff953049303b9ed94f), in our use case, the `pre_button_mark_done` would simply return `True` as no action need to be proceed prior to the `button_mark_done` and the porduction would be added and closed by the real validation. However, since commit [X](10ed12241365942914885dff953049303b9ed94f) the record is simply set to the validated state and not added to the validation stack... That satement is simply incorrect: https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L503-L505 In the most general usecase, our mrp record is in `to_close` state and is not expected to be validated by the `pre_button_mark_done` even if this call returns `True``. What is true however, is that in the exceptional use case treated in commit [X](10ed12241365942914885dff953049303b9ed94f) where you are in the `always` backorder setting and where you need to create a backorder, the MO will be entirely processed by the `pre_button_mark_done`: https://github.com/odoo/odoo/blob/6542b0a5a58324f532a4ae1e0c630ca4fe2f77d7/addons/mrp/models/mrp_production.py#L2142-L2145 and hence should not be marked as done once more (otherwise it would raise multiple errors such as sn uniqueness,... (as the mo has already been validated)). ### Fix: The double validation did not happen prior ot the change of commit [X](10ed12241365942914885dff953049303b9ed94f) because we did not skip redirection at the time: https://github.com/odoo/enterprise/commit/154eec919faac0725b90b830adf499df375e8e81 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L497-L502 returning the record before even adding it to the real validation stack. However, since we do not want to be redirected to the back end we propose to return the information that the record has been validated by the `pre_button_mark_done` and avoid the call of the real validation using the mechanism already in place: https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L524 Commit [X](10ed12241365942914885dff953049303b9ed94f): 10ed12241365942914885dff953049303b9ed94f Community: https://github.com/odoo/odoo/pull/212885 opw-4800147 Forward-Port-Of: odoo/enterprise#88525 Forward-Port-Of: odoo/enterprise#86905
Code cleanup and technical improvements
Messages no longer keep a separate stored record name, reducing outdated or inconsistent labels and simplifying how message context is displayed. Related areas such as Helpdesk, Appraisals, Sign, WhatsApp, Frontdesk, and mobile messaging now rely on the current record name or explicitly provide one when needed.
Original PR description
Reasons to remove record_name
* it is not synchronized, and synchronizing it would be very costly.
This makes searching on record_name / grouping / ... useless;
* some flows even set it to False to speedup sub records creation
and avoid calling display_name on a lot of records e.g. mass
mailing;
* it is unnecessary to store it in most cases;
* its main usage is in discuss / chatter where it is anyway based
on actualy display_name;
In conclusion: get rid of stored 'record_name' field, simplify message
model by making it a computed field displaying the related record
display_name, and let flows displaying / managing messages handle
record names as they want to.
Task-4690371