Daily updates from Odoo
Navigate
Branch
Friday, July 11, 2025
31 changes
New functionality added to Odoo
This change introduces AI-assisted document handling in the Documents app, including tools to automatically classify or sort files. It helps businesses reduce manual filing work and keep document workspaces more organized.
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.
Quality checks for registering consumed materials now show the lot or serial information only once. This reduces confusion for users by removing duplicate information without changing the underlying tracking data.
Original PR description
- For quality checks of type Register Consumed Materials , Component lot id is saved in: 'Component Lot/Serial' Additionally, we also set the same id on the field above: 'Lot/Serial' and it is the same exact field `lot_id` . There is no reason to duplicate that information. Task: 4894434
This update prevents records in several Odoo apps from using names reserved for system communication. It reduces the risk of confusing errors or broken integrations in invoicing, manufacturing, sales timesheets, and timesheet grids.
Original PR description
odoo/odoo#218355
Payroll can now identify extra hours and apply a configurable payment rate directly from work entry types. This gives HR teams a clearer, more consistent way to pay overtime or additional hours on top of regular salary across multiple country payroll setups.
Original PR description
- The goal of this change is to improve the payroll system by providing clearer and more efficient way to manage extra hours and overtime. - This update introduces the ability to track extra hours worked and apply an adjustable payment rate for those extra hours. **This PR includes the following changes:** - Added new options to track extra hours and set a rate for extra hours worked. - Updated the UI to make it easier to configure extra hours and rates. - Improved the logic behind calculating extra hours, ensuring that extra hours are compensated correctly based on the set rate. - Ensured that extra hours are paid in addition to the regular monthly salary in payslip when applicable. Task - 4420535
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
The spreadsheet document tests now reflect the latest chart side panel behavior, including sticky tabs, preserved scroll position, and retained expanded or collapsed sections. This helps ensure the updated interface remains reliable for users working with charts in documents.
Original PR description
Update test cases to reflect recent UI changes in the chart side panel: - Tabs are now sticky while scrolling - Scroll position is preserved when switching tabs - Expanded/collapsed section state is retained Task: [4752564](https://www.odoo.com/odoo/2328/tasks/4752564)
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
Employee contract version lists now show the yearly cost next to the wage by default. This gives HR teams a clearer view of total compensation costs without opening each contract record.
Original PR description
In this PR, we added the yearly cost field to the version list to the right to the wage and will be visible by default. Related task: 4901173.
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
VoIP error messages now show line breaks and formatting as intended instead of displaying HTML tags as plain text. This makes error information easier for users to read and understand when using the softphone.
Original PR description
`<br>` tags in VoIP error messages are rendered as text. This is because the code uses t-esc instead of t-out, and t-esc never renders inner HTML. This commit just replace t-esc with the proper t-out directive. |Before|After| |-|-| ||| Forward-Port-Of: odoo/enterprise#88431 Forward-Port-Of: odoo/enterprise#88355
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 an issue where payment references ending with a backslash could break bank statement reconciliation matching. The change helps accounting users process such payments without unexpected errors.
Original PR description
If a payment ref end with '\\', this '\\' will be interpreted as an escape operator in the query, which leads to an error. This commit add the '\\' to the list of char to escape. no-task Forward-Port-Of: odoo/enterprise#89659
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
This fix stops Point of Sale IoT setup from automatically assigning a newly connected device as a weighing scale when it may be misidentified on first startup. It prevents businesses from ending up with the wrong device configured in their PoS settings after the IoT box restarts and correctly recognizes the device.
Original PR description
If on first boot after flashing the iot box a blackbox is connected the iot box doesn't have the blackbox driver so it's identified as Adam scale With the pos_iot auto configuration we would first send it as a scale to the database and it would be set as a scale to the selected pos config. After odoo restart on the iot box it gets detected as blackbox correctly and its name changes. Now after it's sent to the db the user ends up with a blackbox in the scale field in PoS config. This PR removes the automatic scale configuration so that doesn't happen Forward-Port-Of: odoo/enterprise#89888
The VoIP softphone interface now works better on smaller screens by adding scrolling where content was previously cut off and improving spacing and alignment. This helps users access call controls and transfer options more reliably on compact displays.
Original PR description
This commits fixes minor layout issues: - It adapts some views that had no scroll bar when the viewport was small. This prevented access to part of content. - It revises some spacing and alignment on…
This commits fixes minor layout issues: - It adapts some views that had no scroll bar when the viewport was small. This prevented access to part of content. - It revises some spacing and alignment on small screens. - It defines small transfer buttons in "outline" style to maintain consistency with the others tabs. task-4908502 | Before | After | |--------|--------| |  |  | |  |  | |  |  | |  |  | |  |  | |  |  | |  |  | Forward-Port-Of: odoo/enterprise#89679 Forward-Port-Of: odoo/enterprise#89005
Indian reports now use the official state name "Odisha" instead of the outdated "Orissa". This keeps report labels aligned with Government of India terminology and avoids confusion for users reviewing tax reporting information.
Original PR description
Issue: As per Government of India guidelines, the state name was officially changed from "Orissa" to "Odisha" in 2011. However, Odoo still uses the outdated name in report. Solution: Updated the records from "Orissa" to "Odisha". opw-4935633 Forward-Port-Of: odoo/enterprise#89947
Users can now share shortcut folders from the cog menu next to the breadcrumbs, matching the behavior available for regular folders. This removes a small usability gap in Documents and includes cleanup of unused code.
Original PR description
Before this commit, the share action in the cog menu (next to the breadcrumbs) wasn't available for shortcut folders. This commit fix this issue. This commit also removes some dead code. Task-4897840 Forward-Port-Of: odoo/enterprise#89161 Forward-Port-Of: odoo/enterprise#88512
This fix prevents HR jobs from being linked to contract templates belonging to a different company. It also updates Belgian salary package demo data so examples follow the same company-alignment rule, reducing setup errors in multi-company environments.
Original PR description
task-4885755
Features or functions removed from Odoo
Unused data and demo files were removed from several Odoo Enterprise modules after a new automated check identified files that were not loaded by the system. This reduces clutter and helps prevent outdated or incompatible files from causing confusion in future maintenance.
Original PR description
In the OCA we have added the following lint: - https://github.com/OCA/odoo-pre-commit-hooks/pull/127 For Odoo I have created the following new LINT: - https://github.com/odoo/odoo/pull/211259 It…
In the OCA we have added the following lint:
- https://github.com/OCA/odoo-pre-commit-hooks/pull/127
For Odoo I have created the following new LINT:
- https://github.com/odoo/odoo/pull/211259
It detects the data files not used
It means, csv or xml files in data/ or demo/ folders
but not referenced in the __manifest__.py
- `"data": [...]` or `"demo": [...]` sections
Then I have ran this new check:
find . -type f -name "__manifest__.py" -exec bash -c 'oca-checks-odoo-module --enable file-not-used "$(dirname "$0")"' {} \;
And it detects a few cases
We could add them to manifest file or delete them
but they were not used before maybe it is a better idea to delete them
since that they could be not needed or incompatibles
Related to enterprise PR:
- https://github.com/odoo/odoo/pull/211150
# UPDATED
Data files called from hooks:
https://github.com/odoo/enterprise/blob/a9a2a972d96665bdb4068427555ba40ddffc0325/product_unspsc/hooks.py#L28
https://github.com/odoo/enterprise/blob/a9a2a972d96665bdb4068427555ba40ddffc0325/pos_restaurant_preparation_display/models/pos_config.py#L18
https://github.com/odoo/enterprise/blob/a9a2a972d96665bdb4068427555ba40ddffc0325/stock_barcode/models/epc_encoder.py#L283
https://github.com/odoo/enterprise/blob/f0b2cb72529acaec3cff5edc6cdb8bb3c712bed9/l10n_uk_reports_cis/models/hmrc_transaction.py#L170Code cleanup and technical improvements
This update streamlines how action buttons are displayed across several Odoo screens by removing unnecessary layout wrappers. The change should make the interface structure cleaner and easier to maintain, with little to no visible change for end users.
Original PR description
This commit cleans up and simplifies the structure of the buttons provided by the views/actions and displayed in the ControlPanel (or modal's footer for the FormView). The point is to avoid unnecessary wrapper around them, reducing the DOM and also the rules necessary to handle the buttons' layout, gap... task-4277543
This change refactors how the system handles domain logic used to filter and organize records. It should not change day-to-day behavior, but it helps keep project and field service sales features easier to maintain and improve over time.
Original PR description
Refactor of the API for Domain.
This update cleans up unused code left behind after a user experience refactor in the time-off area. It helps keep the system easier to maintain without changing day-to-day functionality for users.
Original PR description
task-4893623
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