Daily updates from Odoo
Navigate
Branch
Thursday, July 10, 2025
53 changes
18 changes
Enhancements to existing features
Belgian accounting localization data was refreshed with updated chart of accounts details, translations, and disallowed expense rules. The change also adds default asset model support so eligible Belgian accounts can automatically create assets, reducing manual setup and improving accounting consistency.
Original PR description
1) Misc data modifications and corrections for l10n_be. * Updated the CoA (accounts, descriptions, translations) * Fixed and updated disallowed_expenses 2) Added default asset models module for l10n_be See task-4791757 for more details. Related :https://github.com/odoo/odoo/pull/210755 Forward-Port-Of: odoo/enterprise#89471 Forward-Port-Of: odoo/enterprise#87067
Payroll users no longer need to manually click the Compute button after changing information that affects a payslip. Payslip lines are recalculated dynamically when related payroll data changes, helping reduce missed updates and improve payroll accuracy.
Original PR description
make it so payslip lines are dynamically recomputed when dependencies are edited. task-4720287
Project update descriptions now better reflect the information shown in the project side panel. This makes profitability-related project information easier to understand even when the sales timesheet app is not installed.
Original PR description
_*: project_timesheet_forecast_sale Currently, profitability isn't displayed in the project update description form without the sale_timesheet module. In this commit, we have improved the project description according to the project side panel. task-3916169
The Website Studio form walkthrough has been updated to work with the redesigned website builder. This restores automated checks that help ensure the form-building experience remains reliable for users.
Original PR description
The `website_studio_website_form` tour was previously broken due to DOM structure changes introduced by the new website builder and was consequently disabled. This commit updates the tour steps to align with the new DOM and re-enables the associated test. Forward-Port-Of: odoo/enterprise#89389
The DHL delivery integration is now categorized under shipping connectors. This makes it easier for users to find the DHL connector in the appropriate section when browsing or managing apps.
Original PR description
DHL module should be in the shipping connectors section Task: 4903666
Resolved issues and error corrections
Users can now open and generate field service task reports from the customer portal without hitting an error when the optional reporting module is not installed. This keeps portal task details accessible and avoids disruption for Field Service workflows.
Original PR description
An error occurs when a user attempts to generate a report from the portal because the `industry_fsm_report` module is not installed. **Steps to reproduce:** * Install `industry_fsm` * Field Service>New Task>log time sheet using `start` button * open portal view( `/my/tasks` )> Your created task> `View details` `AttributeError: 'project.task' object has no attribute '_get_report_base_filename'` **Solution:** * Define `_get_report_base_filename` inside `industry_fsm` instead of `industry_fsm_report`. **Sentry-6685756279** Forward-Port-Of: odoo/enterprise#89615 Forward-Port-Of: odoo/enterprise#87949
Brazilian electronic invoices now automatically choose the appropriate invoice purpose in more common business cases instead of always using the standard purpose. This helps prevent EDI submission failures when the correct purpose depends on the product types, vendor, customer, or operation type.
Original PR description
We hardcoded the standard purpose (finNFe) and goal for invoices, credit notes and debit notes. In certain cases however, the purpose is must be different for EDI to succeed (based on the combination of sold product types, vendor and customer). In master we will likely add some fields on the operation type so the user can choose, but in stable we can already determine some other common cases based on the operation type. Using XML ids was considered but since users can create and edit operation types [1] it's better to use the technical names. [1] Since odoo/enterprise#73198 opw-4832447 Forward-Port-Of: odoo/enterprise#89782
This fixes an issue in the Belgian Intrastat reporting module where an empty view definition could cause errors when other report views depended on it. The change keeps report setup stable and prevents failures during upgrades or module loading.
Original PR description
In l10n_be_intrastat, we have vat_report_export.xml, which contains an empty arch (because it had to be removed in master). But as this view is inherited by other views, it raises an error, because we're trying to merge a string (the inherits) and a None (the empty arch). We will remove the empty arch in 18.4 (as we did in 18.3), and remove totally the view in master, with an upgrade script. Linked:https://github.com/odoo/upgrade/pull/7973 no-task Forward-Port-Of: odoo/enterprise#88647
PDF versions of stock reports now show table headers in bold as intended. This makes printed reports match the on-screen layout and improves readability for users reviewing inventory documents.
Original PR description
Problem: When printing the stock report, table headers are not bold in the generated PDF despite being styled that way in the HTML template. Cause: The bold styling is applied via CSS on the `thead` element, which doesn't render properly in the PDF output. Solution: Use `<strong>` tags inside table headers to apply bold formatting, as done in version 17.0. Also remove `font-weight` rules from CSS for `thead` to avoid conflicts and ensure consistent output. Steps to reproduce: 1. Go to Inventory > Inventory Overview. 2. Select any inventory record. 3. Print the report. → Table headers are not bold as expected, despite formatting. opw-4840380 Forward-Port-Of: odoo/enterprise#89836 Forward-Port-Of: odoo/enterprise#87852
The POS appointments screen now loads the missing illustration used when no bookings are available. This prevents an error when users remove grouping in the bookings Gantt view and keeps the empty state displaying correctly.
Original PR description
Steps to reproduce: ------------------------- - Open pos enabled with bookings. - Open booking tab and in gantt view remove groupby filter. Issue: ------- There will be a traceback. Cause: -------- When there are no bookings available it tries to load no booking svg template, which is not loaded in the assets. Fix --- We have loaded the missing asset file to ensure the SVG displays correctly when there are no bookings. task: 4912389 Forward-Port-Of: odoo/enterprise#89378
Bookkeepers can now open, close, and reset tax return flows without being blocked by administrator-only setup steps. This prevents unnecessary access errors and helps accounting teams complete return-related work more smoothly.
Original PR description
- Trying to open the returns form the dashboard failed for bookkeepers when no opening date was set, since the wizard used to set them is restricted to administrators only. - When closing a tax return, an access error was triggered when trying to set the lock date. - When resetting a tax return, an access error was triggered when trying to set the lock date. Forward-Port-Of: odoo/enterprise#89878 Forward-Port-Of: odoo/enterprise#89610
Odoo Studio can no longer be opened to customize the Bank Reconciliation view. This prevents users from making unsupported changes to a sensitive accounting workflow, reducing the risk of configuration issues.
Original PR description
- Install `web_studio` and `account_accountant` - Open Accounting -> Bank You can open studio on this view but this should not be possible opw-4859464 Forward-Port-Of: odoo/enterprise#89181 Forward-Port-Of: odoo/enterprise#89146
Amazon sales integrations now correctly recognize DPD, Hermes, and updated Royal Mail carrier names for Great Britain shipments. This helps avoid fulfillment or shipping confirmation issues caused by carrier name mismatches from Sendcloud.
Original PR description
For DPD and Hermes (not the others), Sendcloud adds an unnecessary ISO code. In order to keep it should it be necessary (e.g. rml_gb), we map them to the Amazon const instead of stripping the code. While testing, it was also found that royal mail seems to have been renamed and was thus not working. Forward-Port-Of: odoo/enterprise#87745
This fix makes manufacturing shop floor test checks more reliable by avoiding assumptions about exact record counts when demo data may add extra entries. It helps keep automated validation stable and reduces false build failures without changing user-facing behavior.
Original PR description
### Issue: Certain shopfloor tests make assert on the number of records present in the shopfloor: - test_shop_floor_my_wo_filter_with_pin_user - test_automatic_backorder_no_redirect These assert can not be reliable due to demo-data's adding unrelated records e.g. https://github.com/odoo/enterprise/blob/5bfadae317ee47ac34703d4cc222677ac677cc7d/purchase_mrp_workorder_quality/data/purchase_mrp_workorder_quality_demo.xml#L79-L84 runbot-build-error-226734 Forward-Port-Of: odoo/enterprise#89556 Forward-Port-Of: odoo/enterprise#88005
Code cleanup and technical improvements
This update refreshes internal automated tests for Facebook-related social features without changing the visible product experience. It helps the team keep the module easier to maintain and reduces the risk of future regressions in comment and preview behavior.
Original PR description
Part of task-4028356
The Sign document request dropdown has been rebuilt using Odoo's own interface component instead of relying on Bootstrap. This supports Odoo's broader effort to reduce external UI dependencies while keeping the signing workflow consistent for users.
Original PR description
As we try to remove as much as possible our dependency on Bootstrap components for the backend, this commit rewrites the Sign's document request dropdown by using our own implementation instead of the Bootstrap's one. task-4277543
This internal cleanup makes Odoo's IoT components use a shared system identifier instead of checking the operating system in multiple places. It helps keep hardware integrations more consistent and easier to maintain, with no expected change for day-to-day users.
Original PR description
Related odoo PR/ https://github.com/odoo/odoo/pull/216055
Miscellaneous changes
As for the blackbox, we now use the websocket as fallback to longpolling to print receipt. This commit also fixes an issue regarding the module `pos_blackbox_be`: if the module was installed, but no blackbox was configured, we could not print a receipt as no signature was provided. Task: 4824066 Forward-Port-Of: odoo/enterprise#87095
Original PR description
As for the blackbox, we now use the websocket as fallback to longpolling to print receipt. This commit also fixes an issue regarding the module `pos_blackbox_be`: if the module was installed, but no blackbox was configured, we could not print a receipt as no signature was provided. Task: 4824066 Forward-Port-Of: odoo/enterprise#87095
35 changes
New functionality added to Odoo
Adds a new financial summary tool that helps users generate and review financial summary information from within Odoo. This supports sales-related requirements by making key financial details easier to access and organize for business decision-making.
Original PR description
Description of the issue/feature this PR addresses: requerimientos de ventas Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
Expense receipt scanning now captures the actual merchant or place name, such as a restaurant or fuel station, instead of a broad category like food or gasoline. This makes automatically created expense records clearer and easier for employees and approvers to understand.
Original PR description
The detection of the description has been improved in the latest version of the expense OCR API. It now actually detects a description (restaurant name, fuel station name, etc) instead of predicting a category ('food', 'parking', 'gasoline', etc).
Task [link](https://www.odoo.com/odoo/project/2068/tasks/4623180)
task-4623180
Forward-Port-Of: odoo/enterprise#89448Odoo now better supports the updated mobile-first finance connection flow by handling bank accounts created directly inside the embedded iframe. This helps users continue setup when their searched institution is not already available in Odoo Finance, reducing friction during bank synchronization.
Original PR description
The aim of this commit is making sure that the odoo database code is handling properly the new feature introduced with the iframe revamp in mobile-first. This feature allows user to create a bank account from the iframe directly if Odoo Finance doesn't have the searched institution. task-4481880 Forward-Port-Of: odoo/enterprise#81894
Resolved issues and error corrections
Employees in Indian companies can now open their approved time off requests without running into an access error. The change prevents the system from trying to update leave details after approval, keeping approved records stable while preserving the existing time off calculation behavior.
Original PR description
**Steps to reproduce:** 1. Install l10n_in_hr_holidays and l10n_in 2. Switch to IN company 3. Create an employee related to Marc Demo in IN Company 4. Log in with Marc Demo and create a timeoff 5. Approve the timeoff by Mitchel admin 6. Open the form view of approved timeoff by Marc Demo **Issue:** - The _get_durations method in l10n_in_hr_holidays attempts to update the l10n_in_contains_sandwich_leaves field whenever it runs, including when opening the form view of an approved time off. This causes an access error, as updates are not allowed for Marc demo in the approved state. **Solution:** - Added a state check in the _get_durations method to prevent updating the field for approved records. opw-4741162
This fixes how Mexican DIOT tax report columns are calculated so they use the correct tax tags and tax values. Businesses should see more accurate DIOT reporting for paid VAT and import-related tax categories, reducing confusion from previously misleading column definitions.
Original PR description
Description of the issue/feature this PR addresses: The language used in the DIOT documentation was confusing and even though we had the exact same description for two columns it turns out they were different, so we need to change the logic of a few columns to make it work as needed. Current behavior before PR: In the DIOT, the columns Paid 8% N, Paid 8% s, Paid 16%, Importation 16% and Intangible imports 16% are sums of taxes paid with this type of tax. Desired behavior after PR is merged: Taxes now have a correction in their tags so that the columns in the DIOT report are calculated correctly. Likewise, the way of computing the columns Paid 8% N, Paid 8% s, Paid 16%, Importation 16% and Intangible imports 16% has been simplified. Now it no longer adds up different types of taxes, but only one type. opw-4920577 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217441
The Point of Sale product configuration popup now works even when multiple pricelists have the same name. This prevents checkout staff from encountering errors in setups where pricelist names are reused, improving reliability without changing normal workflows.
Original PR description
Before this commit, an error would occur when opening the product configuration popup if two pricelists shared the same name. This was due to the pricelist name being used as a key, which must be unique. This commit resolves the issue by switching to the pricelist ID as the key, ensuring uniqueness and preventing errors when duplicate pricelist names exist. opw-4882900 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where employees with flexible schedules could have incorrect timesheet entries for one-day leave. The system now records leave using the average daily hours, keeping timesheets aligned with time off calculations.
Original PR description
After https://github.com/odoo/odoo/pull/209570 , the way work intervals are computed might not reflect real working time for flexible employees, since the virtual schedule is based on a weekly span. In this PR we chose to allocate a timesheet for single day leaves corresponding to average hours per day to be consistent with hr_holidays calculation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Windows printer handling now sends documents to the printer one at a time when multiple jobs arrive simultaneously. This prevents print jobs from failing during busy periods and improves reliability for businesses using Odoo IoT printing on Windows.
Original PR description
Before this commit, if multiple documents were sent to print at exactly the same time, some of them could end up erroring because the Windows printing API requires us to send one document at a time. After this commit, we use a lock similar to the Linux driver, to ensure that only one document is sent to the printer at once. opw-4829908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218300
Turkish Nilvera e-invoice XML notes now include the remaining invoice amount written out in uppercase text. For invoices in a foreign currency, the note includes both the Turkish Lira amount and the foreign currency amount, helping recipients and compliance checks read the payable amount clearly.
Original PR description
This commit will add the amount residual in text in the note of the xml we sent to nilvera. If the invoice is in another currency than Turkish Lira, we have to add two notes one for the amount in turkish lira and one in the other currency task-4518269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195938
Odoo now shows a plus sign when a list selection may include more records than the displayed count, such as "10,000+". This helps users understand the true scope of bulk actions and reduces the risk of applying actions to more records than expected.
Original PR description
Previously, when selection was made in domain mode, the system used the global `web.active_ids_limit` config parameter instead of the actual number of records selected (based on session limit). This caused unintended behavior. For example: - Open a list view of a model with 25,000 records. - The pager limit is initially set to 10,000. - When selecting all 10,000 visible records and performing an action (e.g., archive), the system would incorrectly apply the action to 20,000 records (based on the default value of `web.active_ids_limit`), not the selected 10,000.
Automatic check-out now uses the employee schedule's local date instead of UTC when calculating expected and previous working hours. This prevents employees in time zones ahead of UTC from being checked out too early when they clock in before UTC midnight.
Original PR description
**Issue** The auto check out cron was using the check in time in UTC to determine the excepted working hours and the previous attendances. For example: - have an employee with a working schedule using a UTC+8 timezone. - check-in on a monday before 8am (0:00 UTC) in the employee's tz. - the auto check-out cron closes the attendance immediately because there are no working hours for the attendance's check in day in UTC (Sunday). **Change** Use the date of the check-in localized in the tz of the calendar used by the attendance's employee to determine the previous worked hours for that day and the expected worked hours. opw-4654847
This fix prevents an error when a cancelled sales order containing a kit is returned to quotation and confirmed again. It ensures cancelled delivery moves are ignored so users can proceed with the sales workflow normally, even when a kit uses the same component more than once.
Original PR description
Bug introduced in: https://github.com/odoo/odoo/pull/207955
Steps to reproduce the bug:
- Create a kit product:
- BoM:
- Components:
- 1 unit of C1
- 1 unit of C1 (same product)
- Create a SO with one unit of kit
- Confirm the SO
- The delivery is created
- Cancel the SO → the delivery is canceled.
- Set the SO back to quotation and confirm again
Problem:
A traceback is triggered:
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: mrp.bom.line(24, 25)
When a kit's BoM contains the same product multiple times, multiple bom_line_ids match a given move. Assigning them causes an error. Additionally, cancelled moves were incorrectly considered.
Solution:
Filter out cancelled stock moves before accessing the bom_line_id to ensure only active moves are considered.
opw-4919875Odoo now avoids trying to display raw binary file contents, such as PDF data, in the developer record data view. This prevents connection errors and keeps administrators' debugging tools usable when inspecting attachments.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable developer mode; 2. go to Settings / Technical / Database Structure / Attachments; 3. open a PDF attachement; 4. open developer tools; 5. click on Record / Data. Issue ----- > Connection lost. Trying to reconnect... Traceback in logger: > `UnicodeDecodeError: 'utf-8' codec can't decode byte ...` Cause ----- Commit 5ef4c07ada1b4 moved the `json_default` function from `date_utils` to `json`, with the purpose of letting it serialize objects besides `date` & `datetime`. When used for raw data of binary files like PDF, it encounters values that cannot be represented in UTF-8, and because `decode` defaults to strict error handling, an exception is thrown. Solution -------- When sending the `read` request to the ORM, only request fields of that aren't of type `binary` to ensure they're serializable. opw-4717657
Cash-rounded invoices now export and import correctly in UBL electronic invoice formats. This prevents validation failures and helps ensure totals, taxes, and payable amounts remain consistent when invoices are exchanged with customers or authorities.
Original PR description
Currently these problems can appear when an invoice is cash rounded. 1. In case we use the "Modify tax amount" (`biggest_tax`) cash rounding strategy: The rounding amount is added to the taxes in…
Currently these problems can appear when an invoice is cash rounded.
1. In case we use the "Modify tax amount" (`biggest_tax`) cash rounding strategy:
The rounding amount is added to the taxes in Odoo but not in the UBL XML
- This affects everything that uses `_prepare_invoice_aggregated_taxes`
(and not just UBL XML)
2. The generated UBL XML is invalid (for any rounding strategy).
See below for details.
3. The import of the exported UBL XML does not yield back the same invoice
(even after fixing the export / the previous 2 problems).
Also there are some problems with the correction of tax values
of imported UBL XML (`correct_invoice_tax_amount`).
(They probably do not cause issues in practice but would after this
fix. We adapt the correction as part of the fix for (3).)
#### Runbot: How to generate problematic XML
1. Select BE Company CoA
2. Enable Cash Rounding in the settings
3. Create a cash rounding method
(in the settings where cash rounding can be enabled):
- precision `1.00`
- strategy: any
- profit / loss account: any
4. Create an invoice
- Set a Belgian partner (e.g. "BE Company CoA" is okay)
- Set the the cash rounding method from step 2
- Single Line with price=70.00€ and a 21% tax
5. The total should be 85.00 € (84.70 € w/o the rounding)
In the journal items there should be the following
non payment term items:
- 70.00€ base
- 14.70€ tax
- 0.30€ rounding (depending on the cash rounding strategy the tax is set or not)
6. Confirm & Send (with BIS Billing 3.0)
7. Look at the UBL BIS 3 XML in the `Invoice` element
- `TaxTotal/TaxAmount`: 14.70€
- `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€
- `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€
- `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€
- `LegalMonetaryTotal/TaxInclusiveAmount`: 85.00€
- `LegalMonetaryTotal/PayableAmount`: 85.00€
8. This fails validation `BR-CO-15`:
```
Invoice total amount with VAT (BT-112)
= Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110).
```
(`LegalMonetaryTotal/TaxInclusiveAmount` = `LegalMonetaryTotal/TaxExclusiveAmount` + `TaxTotal/TaxAmount`)
Since the cash rounding is included in `LegalMonetaryTotal/TaxInclusiveAmount` but not in
`TaxTotal/TaxAmount` (or `LegalMonetaryTotal/TaxExclusiveAmount`)
#### Tax value correction details (with examples)
Currently we try to fix the tax amounts after importing an invoice.
The function we use for that (`_correct_invoice_tax_amount`) has the following issues:
- We look for `TaxTotal/TaxSubtotal` elements anywhere.
But i.e. such elements can also exist inside `InvoiceLine` elements.
Example:
- module `l10n_dk_oioubl` file `test_xml_oioubl_dk.py`
- function `test_oioubl_import_exemple_file_4` / XML file 'external/BASPRO_01_01_00_Invoice_v2p1.xml'
- The tax total parsed from the document may need to be inverted.
E.g. credit notes can be given as an invoice with negative amounts.
See function `_get_import_document_amount_sign`.
Example:
- module `l10n_account_edi_ubl_cii` file `test_xml_ubl_be.py`
- function `test_import_invoice_xml_open_peppol_examples` / XML file 'bis3_invoice_negative_amounts.xml'
- We compare the tax total from the document only with a single line of that tax.
But there can be multiple lines for a single tax. We have to use the sum of all those lines for the comparison.
Example:
- module `l10n_account_edi_ubl_cii` file `test_xml_ubl_au.py`
- function `test_export_import_invoice` / XML file 'from_odoo/a_nz_out_invoice.xml'
#### The fix
This commit does the following to fix that
1. We include cash rounding lines belonging to a tax in the tax computation for the UBL XML export
(or rather everything any tax computation done with `_prepare_invoice_aggregated_taxes`).
2. After fixing (1) we only have to fix the "Add a rounding line" (`add_invoice_line`) strategy.
This is as follows
- Subtract the cash rounding from the `LegalMonetaryTotal/TaxInclusiveAmount`
- Add node `LegalMonetaryTotal/PayableRoundingAmount` with the value of the cash rounding
3. Cases
- `add_invoice_line`: We create a dedicated invoice line with the amount found in node
`LegalMonetaryTotal/PayableRoundingAmount` (if it is present).
- `biggest_tax`: We update the amount on the tax line to match the value found in the XML.
(Currently we only do this if the difference is not greater than '0.05')
The fixes for the tax value correction on import are also needed for 3./`biggest_tax`.
#### Runbot: example XML after the fix
The export in the example then looks like this for the different cash rounding strategies
- `add_invoice_line`
- `TaxTotal/TaxAmount`: 14.70€
- `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€
- `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€
- `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€
- `LegalMonetaryTotal/TaxInclusiveAmount`: 84.70€
- `LegalMonetaryTotal/PayableRoundingAmount`: 0.30€
- `LegalMonetaryTotal/PayableAmount`: 85.00€
The validation for the `LegalMonetaryTotal/PayableAmount` is still
okay since (in the example) it is just `LegalMonetaryTotal/TaxInclusiveAmount` + `LegalMonetaryTotal/PayableRoundingAmount`.
- `biggest_tax`
- `TaxTotal/TaxAmount`: 15.00€
- `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€
- `TaxTotal/TaxSubtotal/TaxAmount`: 15.00€
- `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€
- `LegalMonetaryTotal/TaxInclusiveAmount`: 85.00€
- `LegalMonetaryTotal/PayableRoundingAmount`: (not exported)
- `LegalMonetaryTotal/PayableAmount`: 85.00€
#### References
Also see
- https://docs.peppol.eu/poacc/billing/3.0/bis/#_rounding
- https://docs.peppol.eu/poacc/billing/3.0/bis/#_calculation_of_totals
task-4854592
Forward-Port-Of: odoo/odoo#213378This fixes an issue where newly created, automatically validated attendance records could show zero extra hours even when an employee worked overtime. The correction ensures overtime is calculated immediately when the record is saved, improving accuracy for attendance and payroll-related reviews.
Original PR description
Introduced by cc81bb59f87540cf4dd8da65510417d8023ef65b **Steps to reproduce** 1. Create a new automatically validated attendance. 2. Set the employee, check in and check fields before saving the form. Issue: the "Extra hours" field is not computed. e.g.: if the employee has worked 1 hour more than expected, "Worked Extra Hours" equals 1:00 (ok), but "Extra hours" appears as 0:00. **Cause** The previous fix intended to avoid recomputation of the `validated_overtime_hours` field. No better way was found than to exclude records where the `overtime_hours` was different than the `validated_overtime_hours` (meaning it had been manually modified by the user). The problem comes from the fact that at creation, `validated_overtime_hours` was sent in the `vals_list` to the create with a value of 0. **Solution** Force the computation of the field at creation.
Odoo now hides star and mark-as-read options on chatbot messages while a live chat thread has not yet been saved. This prevents users from triggering errors by clicking actions that cannot work in that temporary state.
Original PR description
**Before this PR:** the toggle-star and mark-as-read actions were visible on chatbot messages in a non-persisted livechat thread. Clicking these actions caused errors. This PR hides these actions when the thread is in a non-persisted state, preventing such errors. task-[4743758](https://www.odoo.com/odoo/project/1519/tasks/4743758) Forward-Port-Of: odoo/odoo#214382
The hardware drivers module now skips certificate updates when the data received from Odoo.com is empty. This helps prevent web server restart issues that could disrupt connected hardware services.
Original PR description
We now ensure that the certificate data returned by odoo.com is not empty, to avoid nginx not restarting. Task: 492610
Products available for store pickup will now still show an out-of-stock message when relevant. This helps shoppers understand product availability more clearly and reduces confusion during checkout or pickup selection.
Original PR description
Before the commit, when a 'pick up in store' was published, the out-of-stock message was hidden to avoid confusion. However, customers want to benefit from it, and now we reintroduce it. opw-4791969
Users can now return to the expense list after opening an expense from dashboard filters such as "To Submit". This fixes a navigation issue that made reviewing filtered expenses less efficient.
Original PR description
**Steps to reproduce:**
- Install the `hr_expense` module.
- Go to the Expense menu and click on "To Submit" in the My Expense dashboard.
- Open any record from the list view.
**Observation:**
- You can't go back to the list view after opening a record.
**Cause:**
- A tag `menu` was added to the action to hide breadcrumbs, but it removed all breadcrumb navigation, unable to go back.
https://github.com/odoo/odoo/blob/92993d7790bb641e5822a5358db35c7fcc7bd091/addons/hr_expense/static/src/components/expense_dashboard.js#L44
**Solution:**
- Used a better way by passing `{ clearBreadcrumbs: true }` to stop the breadcrumb from changing when a filter is applied.
opw-4790643
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prCancelling accounting entries no longer removes their reference when the entry is not linked to an expense. This prevents unrelated records from losing important identifying information when the Expenses app is installed.
Original PR description
### Issue: On 18.0 and 18.1, cancelling an `account.move` will clear the `ref` value in all situations if `hr_expense` is installed. While clearing the `ref` is necessary if unlinking an expense, this isn't the case for unrelated records. ### Solution: Check to see if the `expense_sheet_id` is set on the `account.move` to determine if the `ref` should also be removed. ### Additional Note: This flow was reworked in 18.2 via #189701, so we only need to adjust this for the affected versions. opw-4853903
Manufacturing users can now create a new workcenter directly from the operations form even when no Bill of Materials has been selected. This removes an unnecessary company setting that caused an error and interrupted setup workflows.
Original PR description
**Current behavior:** Can't create a workcenter from the operations (workorder) form view without having a BoM filled in (due to company check issue). **Expected behavior:** Can **Steps to reproduce:** Open `Manufacturing / Configuration / Operations` -> create new -> type in a new workcenter name -> hit create -> error **Cause of the issue:** in `mrp_routing_workcenter_form_view` we get some context for a `default_company_id`- it's not only unnecessary because `Mrp.Workcenter` will get a default company just fine via its its `resource.mixin` inheritance. The currently provided company comes from the BoM, thus the issue happens when the BoM has not yet been filled in on the view. **Fix:** Remove the context in the view. opw-4836904
Mobile dialog headers no longer use backend-specific colors such as the community theme color. This keeps website dialogs visually consistent for visitors and prevents internal Odoo styling from appearing on the public front-end.
Original PR description
Before this PR: header color of `Dialog` on mobile was "community color" or white, depending on the version of Odoo the database is running. This was creating issues in in the front-end, where the user of the website would see back-end specific colors in different `Dialog`s. This PR removes the color customization of `Dialog`'header as it was fitting a design line we had before we introduced MILK. task-4001365 Example of the issue (mobile front-end): <img width="376" alt="Screenshot 2024-06-20 at 10 54 04" src="https://github.com/odoo/odoo/assets/110090660/dad6a4b2-6164-45dd-9e16-0160e2989607"> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170087
When a purchase order linked to a sales delivery is cancelled, Odoo now allows the delivery to use available inventory instead of continuing to wait for the cancelled purchase. This helps orders move forward when stock is later added or already available, reducing unnecessary delivery delays.
Original PR description
Steps to reproduce the bug:
- Unarchive the MTO route
- Create a product P1:
- Type: Storable
- Route: MTO
- Supplier: Vendor A
- Create a sales order for 1 unit of P1
- Confirm the SO
→ A purchase order is created for Vendor A with 1 unit of P1
- Cancel the PO
- Update the quantity on hand of P1 to 1
- Go to the delivery picking of the SO
- Check availability
Problem:
The quantity on hand is not taken into account, and the picking remains
in the "Waiting Availability" state.
When the purchase order is cancelled, the stock move should switch to
MTS instead of remaining in MTO.
opw-[4876611](https://www.odoo.com/web#id=4876611&view_type=form&model=project.task)
opw-[4874199](https://www.odoo.com/web#id=4874199&view_type=form&model=project.task)The Discuss message composer now keeps the send button's opacity behavior aligned with other composer buttons when the message field is empty or focused. This creates a more consistent and polished user experience without changing how messages are sent.
Original PR description
Before this commit, the paper-plane button to send a message was not changing opacity when the composer was empty and the user focused on the composer. Whereas the other buttons such as the emoji picker were changing it. Now the opacity of this button is changing like the other buttons while still changing when the composer is not empty (like before this commit) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Attendance reports now respect the employee’s weekly contracted hours when calculating expected hours for flexible schedules. This prevents reports from overstating expected time when an employee works more days than their contract allows.
Original PR description
### Issue: - When the attendance is flexible, the weekly expected hours shown in reports are incorrect. - This happens because the calculation is based only on the hours worked per day and doesn't…
### Issue:
- When the attendance is flexible, the weekly expected hours shown in reports are incorrect.
- This happens because the calculation is based only on the hours worked per day and doesn't
take into account the total hours worked during the week.
It ignores the weekly limit defined in the employee's working schedule.
- As a result, if an employee works more days than expected, the report may show more than the allowed weekly hours.
Example:
- An employee has a 32h/week contract and 8h/day.
- If they work 5 days, the system still counts 8h as expected for each day — totaling 40h instead of 32h.
### Steps To reporduce:
- Set up a flexible contract with 32 hours/week (8 hours/day) for an employee.
- Log 5 attendances in one week with 8 worked hours each.
- Go to report and filter by employee by week, notice the current behavior yields 5 x 8 = 40 hours in expected_hours.
### Solution:
- Check the weekly hours cap defined in `resource_calendar_id.full_time_required_hours`.
- If total `expected_hours` from earlier attendances this week exceeds that limit, set expected_hours = 0 for any excess.
OPW-4583064
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis change corrects how monthly payroll summaries are aggregated for Swiss ELM transmissions. It helps ensure payroll reporting totals are calculated accurately, reducing the risk of incorrect submissions or follow-up corrections.
Original PR description
Forward-Port-Of: odoo/enterprise#89839
The Italian point of sale flow now makes sure the invoice option is selected before validating an order. This prevents a validation error and helps sales complete correctly when an invoice is required.
Original PR description
## After this commit: - It ensure invoice checkbox is selected before validation, preventing the error and allowing the order to validate correctly. Runbot [link](https://runbot.odoo.com/odoo/runbot.build.error/159985) Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4916349) runbot-159985 task-4916349
Updates the Mexican DIOT report logic to use the correct reporting references after related column changes. This helps ensure DIOT tax report values are calculated from the intended categories and avoids confusion from outdated labels.
Original PR description
Description of the issue/feature this PR addresses: The language used in the DIOT documentation was confusing and even though we had the exact same description for two columns it turns out they were different, so we need to change the logic of a few columns to make it work as needed. This issue was addressed in PR: https://github.com/odoo/odoo/pull/217441, but a small adjustment still needs to be made in the l10n_mx_reports module. Current behavior before PR: The l10n_mx_diot_get_values function uses references to the old account.report.expression that were removed in the pr mentioned above. Desired behavior after PR is merged: The l10n_mx_diot_get_values function uses the new references to account.report.expression that were introduced in the pr of the community repo. opw-[4920577](https://www.odoo.com/odoo/my-tasks/4920577) "I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr" Forward-Port-Of: odoo/enterprise#89481
Shipping label printing now includes a unique print identifier when sending jobs to connected IoT printers. This prevents unnecessary printer-related error messages while keeping the label printing process working smoothly.
Original PR description
Before this commit, the shipping label printing would send documents to the printer without using a print_id, which would cause an error (but the document would still print). After this commit, we send a print_id using a UUID just like for report printing, ensuring no error occurs on the IoT. opw-4829908 Forward-Port-Of: odoo/enterprise#89930
Fixes Colombian electronic invoicing so cash rounding lines are included correctly in tax calculations and UBL invoice output. This helps ensure legally required invoice files match rounded invoice totals, reducing validation errors when submitting invoices.
Original PR description
#### [FIX] l10n_co_dian: UBL related cash rounding issues In the community PR the UBL XML generation was adjusted to support cash rounding. (See there for more details) This commit adjusts the code in `l10n_co_dian` to be compatible. #### [FIX] l10_co_edi: tax_amls include rounding lines Currently rounding lines (with taxes) are not included in the tax lines. This is fixed in this commit. See the community PR / commits for motivation. #### info task-4854592
The Spanish tax report now avoids adding rectification lines for bills and credit notes that fully cancel each other within the same reporting period. This prevents incorrect BOE 349 declarations while preserving expected rectifications for documents from previous periods.
Original PR description
# How to reproduce the issue On a **l10n_es** fiscal position: - Create a bill for the current period and then create a credit note for this bill. - In the tax report, under model 349, download the BOE report. Since the bill has been fully canceled within the same period, no rectification line should appear in the BOE report (correct behavior). - Create a bill from a previous period. - Create a credit note for this bill in the current period. - Download the BOE report from model 349. A rectification line appears for the previous period bill, which is expected. However, a rectification line also appears for the current period bill, which is incorrect, as the bill was canceled within the same period. This commit prevents moves from the current period from being included as rectification lines in the BOE report. opw-4895636 Forward-Port-Of: odoo/enterprise#89624 Forward-Port-Of: odoo/enterprise#89382
Fixed an issue where returning to a receipt in the Barcode app could incorrectly increase the requested quantity for lot-tracked products. This keeps warehouse receipts accurate when users partially process and later complete grouped barcode lines.
Original PR description
### Steps to reproduce: - Create a storable product tracked by lot - Create and confirm a receipt for 10 units of that product - Go to the barcode app and regiter 1 unit - Exit the picking - Go back…
### Steps to reproduce: - Create a storable product tracked by lot - Create and confirm a receipt for 10 units of that product - Go to the barcode app and regiter 1 unit - Exit the picking - Go back to the picking register the 9 remaining units - Exit the picking and comeback #### > The demand of the receipt has been updated from 10 to 19. ### Cause of the issue: Exiting the picking will launch a call of the `post_barcode_process` in order to keep track of the changes you made without changing the initial demand: https://github.com/odoo/enterprise/blob/c26c21cec14a234021bb13bbc2684334bc64b70b/stock_barcode/models/stock_move.py#L50-L53 THe first time you enter the picking you have a single move with a quantity of 10. The first time you exit, since you have set a qty_done of 1 (and hence have updated the quantity of the associated move to 1), the `split_uncompleted_moves` will then create a move for a quantity of 9 in order to keep 10 units assigned. The second time you enter the picking both moves are grouped in a single line since the product is tracked by lot, however, when you update the qty_done of that grouped line you will actually only update the quantity of the first move line and its related move. Since the `_truncate_overreserved_moves` was not designed to handle these grouped lines, it does not notice that the combined reservation overcomes the actual demand. opw-4731803
Amazon order shipping now better recognizes DPD, Hermes, and Royal Mail carrier names used in Great Britain. This helps prevent carrier mapping issues when Sendcloud provides country-specific carrier codes, improving fulfillment accuracy.
Original PR description
For DPD and Hermes (not the others), Sendcloud adds an unnecessary ISO code. In order to keep it should it be necessary (e.g. rml_gb), we map them to the Amazon const instead of stripping the code. While testing, it was also found that royal mail seems to have been renamed and was thus not working. Forward-Port-Of: odoo/enterprise#87745
The Belgian POS blackbox integration now acknowledges status messages properly, preventing repeated or misplaced responses. This reduces failed communications with the device and helps ensure sales certification requests receive the expected replies.
Original PR description
We did not send an `ACK` after asking for blackbox status, leading in BlackBox sending it again. This lead to situations where we sent requests to the BlackBox, and received the status instead of the actual response. In addition, the repeated status responses were missing the leading `ACK`, resulting in our log: `sent 1 NACKS without receiving response, giving up.` More, if we sent a command too soon to the BlackBox (before it finished instanciating), we were receiving its `certified ref` instead of the actual response, due to the `_push_status` method called from the `run` method of the BlackBox Driver parent class. This `run` method is now overridden by the BlackBox driver Task: 4750435 Backport of https://github.com/odoo/enterprise/pull/87659
Work permit fields have been restored in the Swiss payroll employee view. This helps Swiss payroll users access and maintain important employee permit information directly where they need it.
Original PR description
In this PR we reintroduce the work permit fields for the swiss localization, which is heavily used. Forward-Port-Of: odoo/enterprise#89864