Daily updates from Odoo
Friday, July 3, 2026
48 changes · master
New functionality added to Odoo
Odoo can now use official daily exchange rates from the Central Bank of Azerbaijan for automatic currency updates. This helps businesses using AZN keep multi-currency accounting and tax transactions aligned with official rates, including currencies quoted in larger nominal units.
Original PR description
This commit adds the Central Bank of Azerbaijan (CBA) as a supported service provider for automatic currency rate updates. Purpose: To ensure multi-currency accounting entries and taxable transactions are accurately translated into the national currency (AZN) using the official exchange rate defined by the CBA for the transaction day. Functionality: -Enables fetching official daily exchange rates directly from CBA via XML. -Automatically handles rates defined for different nominal quantities (e.g., rates quoted per 100 units instead of 1 unit). task-6112867
Enhancements to existing features
Senders using Sign Now for documents with multiple signers can now choose whether each remaining person signs immediately or receives their signing link by email. This makes in-person signing sessions more flexible and clearly confirms that the request will finish once emailed recipients complete their part.
Original PR description
When signing locally for multiple signers, the sender can now choose, for each remaining signer, to sign on the spot or send them the link by email. Once every signer has been handled, a confirmation dialog lets the sender know the request will complete as the emailed signers sign on their side. task-6234594
VoIP demo mode now only allows administrators to place demo calls, helping prevent unintended use by regular users. The VoIP dashboard is also simplified by removing a production filter that was not useful in live environments.
Original PR description
1. Only allow voip admin to make demo calls in demo mode 2. remove the default is_producion filter in dashboard since it's useless in production. Task-6304061
French fiscal declaration exports now run additional validation before submission. This helps ensure required company, debtor, writer, and partner information is complete and that ambiguous report choices are resolved before the file is sent.
Original PR description
while exporting liasse fiscale, no chceks were done before the export and there were no account returns checks before sending it, this commit add account return checks to the liasse fiscale: -writer and debtor have the necessary informations on their record -partners mentionned in the reports have the necessary fields completed on their records -for some line, we have to choose between some values task-6127270 Forward-Port-Of: odoo/enterprise#115812
This update improves Japanese tax reporting within Odoo Enterprise by incorporating the two distinct types of Japanese Consumption Tax Returns (JCT) – Accumulation and Deduction. This change aligns Odoo with updated Japanese tax regulations, ensuring accurate reporting and compliance.
Original PR description
Replace the single generic Japanese return type with the two JCT return types, Accumulation and Deduction, pointing at the new sectioned reports in l10n_jp. task-4490922
This update enhances the visual clarity of the attendance Gantt chart by addressing issues with negative overtime values and adjusting the color scheme. The changes improve the user experience and make it easier to understand employee attendance data.
Original PR description
Improve the readability of the progress bar: - no negative values for overtimes - adapt colors task-6341209
This update enhances the report editor by introducing tabs, similar to the website editor, for easier switching between different report creation modes. The changes also incorporate new Owl 3 features, streamlining the report editor's functionality and improving the overall user experience. This simplifies report design and development workflows.
Original PR description
This commit introduces tabs (like in the website editor) for switching between different modes in the report editor. It also updates and improves part of the report_editor codebase to take advantage of new Owl 3 features.
This update enhances how event names are displayed in the Calendar and Gantt views within the Appointment app. When managing capacity, the display name now includes the number of reserved or attending participants, providing clearer event information. This change improves the user experience by making it easier to understand event details.
Original PR description
- Removed the default_name of the event.
- The following display name will be shown in the Calendar and
Gantt views when an event is opened through the Appointment app.
Case 1: Manage capacity is on: EventTitle - total_capacity_reserved 🪑.
e.g., EventTitle = demo, total_capacity_reserved = 4, then display_name
will be "demo - 4🪑".
Case 2: Manage capacity is off: EventTitle - totalAttendees 👤.
e.g., EventTitle = demo, totalAttendees = 4 then display_name
will be "demo - 4👤".
Task-6194877This update simplifies the initial setup of Point of Sale sessions by requiring users to select tax inclusion options immediately. Previously, users overlooked this step, leading to later adjustments and frustration. This change ensures accurate tax calculations from the start, improving the user experience.
Original PR description
..., l10n_mx_edi_pos During onboarding, users weren't paying attention to the tax inclusion question, which caused some frustration when they had to change it later on. We now ask the user to choose the tax inclusion when they first open a session. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6171257
Resolved issues and error corrections
Payroll run creation now keeps the selected branch company instead of falling back to the main company. This prevents blocking warnings and supports accurate payroll processing for branch employees, including Hong Kong payroll flows.
Original PR description
[FIX] hr_payroll: fix correct company selection in payrun (branch case) Bug reproduc: 1 - Select 19.3 or master -> Open a branch to belgium company -> create an employee in that branch 2 - In your…
[FIX] hr_payroll: fix correct company selection in payrun (branch case)
Bug reproduc:
1 - Select 19.3 or master -> Open a branch to belgium company -> create an employee in that branch
2 - In your env, select both belgium and its branch, payroll->payrun->select branch as a company.
3 - Continue till the end of payrun creation, you will get warning (blocked) due to wrong company selection, main belg company is selected instead of branch
Bug cause:
1 - In selectEmployees function of hr_payslip_run_form, in the raw_record the company_id is passed as integer.
2 - In buildRawRecord function of hr_version_list_controller, we are assigning company_id as raw_record's company_ids id, but company id was already integer, company_id.id is undefined
3 - Since undefined is passed to the company_id, it uses the self.env.company_id as a default in the creation of hr payrun that cause to the error.
Bug fix:
1 - In the buildRawRecord function of hr_version_list_controller, I just assigned the company_id because it is already integer and all problem is solved.
task - 6326117
Forward-Port-Of: odoo/enterprise#122538
Forward-Port-Of: odoo/enterprise#121505Belgian payroll now handles cases where a student minimum wage salary scale cannot be found without causing the calculation to fail. This helps payroll teams avoid unexpected errors and keeps wage checks running reliably.
Original PR description
When computing _get_student_min_wage and the specific salary scale is not found, it returns None and then fails in the tuple compression as None is not an interable. task-6318004 Forward-Port-Of: odoo/enterprise#122500 Forward-Port-Of: odoo/enterprise#121392
Fixes a point of sale issue where deleting an order line with a custom product attribute could make the kitchen preparation display go blank. The display now stays available and continues showing the order information it can safely resolve, reducing disruption for kitchen staff.
Original PR description
When an order is sent to the preparation display and one of its products has an attribute with a custom (free text) value, completely deleting that line in the PoS makes the whole preparation display…
When an order is sent to the preparation display and one of its products has an attribute with a custom (free text) value, completely deleting that line in the PoS makes the whole preparation display crash and show a blank white screen, so the kitchen can no longer see any order. Steps to reproduce: ------------------- * Configure a PoS product with an attribute whose variant that has a custom (free text) value. * In the PoS, add the product, select that attribute value and send the order to the preparation display. * Back in the PoS, completely delete that order line (do not just set its quantity to 0) and send the order to the preparation display again. > Observation: The preparation display crashes and only a white screen is shown. The browser console reports "TypeError: Cannot read properties of undefined (reading 'id')". Why the fix: ------------ Completely deleting the line deletes the source pos.order.line, so the preparation line that is still displayed no longer resolves its `pos_order_line_id`. While building the attributes to display, the orderline component dereferenced `.id` on that (now undefined) relation, as well as on the related custom value records, which threw and brought down the whole preparation display instead of only that line. We now guard those relations: when the originating order line is gone, the unresolvable custom value is simply dropped and the attribute is still shown, keeping the preparation display alive. opw-6282607 Forward-Port-Of: odoo/enterprise#122691 Forward-Port-Of: odoo/enterprise#121194
This update fixes an internal test setup issue in the Urban Piper point-of-sale integration. It keeps test-only changes properly contained, helping maintain code quality checks without affecting day-to-day users.
Original PR description
Avoid polluting the Odoo model registry and failing `test_lint_override_signature` by using `patch.object` instead of manual assignment. This ensures the injected method is properly torn down after the test block, keeping the registry clean and bypassing static analysis failure as the patched method is only used for tests. runbot-939298 Forward-Port-Of: odoo/enterprise#122446 Forward-Port-Of: odoo/enterprise#122283
This update corrects automated test coverage for Swedish SEPA payment files when related payment modules are installed together. It helps ensure Sweden-specific bank payment exports remain validated without false test failures.
Original PR description
Here https://github.com/odoo/enterprise/pull/114662 we changed the way the CdtrAgt node is used in the SEPA XML file for Sweden. But this change broke a test when both account_iso20022 & l10n_se_bban are installed, leading to a Non-expected child error. This commit skip the failling test if l10n_se_bban is installed, and add a new one to replace it. runbot-938366 runbot-938367 Forward-Port-Of: odoo/enterprise#122599 Forward-Port-Of: odoo/enterprise#121485
This update resolves issues with knowledge tours and web_studio's Powerbox functionality. By inserting a forward slash into the DOM and adjusting event handling, the system now correctly simulates Powerbox opening, ensuring tours function as expected and web_studio's editing features are reliable.
Original PR description
#### Description of the issue: - Since the search powerbox plugin now checks for the actual existence of `/` in the DOM, some knowledge tours were failing because only the input event was dispatched without inserting `/`. - In web_studio, `insertText` was not positioning the selection correctly after insertion and was not dispatching beforeinput event before the DOM insertion. #### After this commit: - Adapt the `openPowerbox` utility in knowledge to insert `/` in the DOM before opening the powerbox. - Dispatch `beforeinput` before DOM insertion and `input` after it in web_studio, and move the selection after the inserted text. Community PR-https://github.com/odoo/odoo/pull/266284 task-6243724 Forward-Port-Of: odoo/enterprise#118310
This update fixes an issue where customer names weren't being correctly displayed in Odoo bookings created through Reserve with Google. Now, when booking through Google, the customer's full name (first and last) is used instead of just their email address, improving the user experience and contact information accuracy.
Original PR description
When a customer books through Reserve with Google, the createBooking payload carries the booker given_name and family_name next to the email, but the handler passed only the normalized email to…
When a customer books through Reserve with Google, the createBooking payload carries the booker given_name and family_name next to the email, but the handler passed only the normalized email to _mail_find_partner_from_emails. The new res.partner was therefore created with its name falling back to the email, see https://github.com/odoo/odoo/blob/aa7b5921191a0ff53ef1cc32af99fe458c45c0da/addons/mail/models/res_partner.py#L177 That name then flows into the calendar.event name, the attendee common_name and the contact details, all showing the email instead of the customer name. The module has read neither field since it was added in https://github.com/odoo/enterprise/commit/2e855b910173b56e8501d0ebe9ee6f83ac5845bc. Build the booker name from given_name and family_name and pass it with the email through formataddr in google_reserve_booking_create, so a newly created partner is named after the customer. A partner matched on an existing email keeps its current name. Steps to reproduce: 1. Enable Reserve with Google on an appointment type. 2. Book a slot from Google Maps with given name John and family name Doe. 3. Open the created booking and its contact in Odoo. => the contact name is the email instead of John Doe Ticket [link](https://www.odoo.com/odoo/project/49/tasks/6232318) opw-6232318 Forward-Port-Of: odoo/enterprise#120604
This update fixes an issue where the withholding tax return was incorrectly combining balances with regular tax returns. The change ensures the withholding tax return accurately calculates the independent balance due, resolving a discrepancy in reported tax liabilities for Italian companies. This improves the accuracy of tax reporting.
Original PR description
Steps to reproduce: - setup an Italian company - make an invoice (for example in May) with a withholding tax and make a transaction to pay it - generate tax returns (opening date in June so that it generates from May) - validate regular tax return for May - validate withholding tax return for May -> The withholding tax return shows an amount to pay with a balance that is a combination of both the regular tax return and the withholding one, while it should be independent of the regular one. task-6116304 Forward-Port-Of: odoo/enterprise#121254 Forward-Port-Of: odoo/enterprise#119375
A recent update removed a dependency and added a new project field to improve data accuracy. This change resolved a test failure (test_fsm_flow) that indicated missing project information. The update ensures correct project data is fetched within the planning module.
Original PR description
Currently, running test `test_fsm_flow` leads to a Attribute Error: `planning.slot' object has no attribute 'project_id'`. This happens because project_id field removed in this PR: https://github.com/odoo/enterprise/pull/113153 This field is removed to remove `project_timesheet_forecast_sale` module in the dependencies of `planning_field_service_sale_timesheet` module and add a project field in settings of planning when Billing feature of field service is enabled. Related PR: https://github.com/odoo/enterprise/pull/83012 runbot-[941219](https://runbot.odoo.com/odoo/error/941219) Forward-Port-Of: odoo/enterprise#122442
This update ensures that only complete and accurate address data is sent to Fiskaly when creating POS certificates. Previously, placeholder values like 'N/A' were included, which is now corrected to omit fields when data isn't available, streamlining the process and improving data quality. This change enhances integration with Fiskaly and reduces potential errors.
Original PR description
In this commit: ------------------- - Buyer address fields are optional and should only be sent to Fiskaly when they are actually available. - Avoid sending placeholder values like "N/A". If the data is not present, the fields should simply be omitted from the request. task: 6113133 Forward-Port-Of: odoo/enterprise#122188 Forward-Port-Of: odoo/enterprise#113621
This update resolves an issue where downloading the ETA payroll form generated an error due to incorrect file formatting. Additionally, a warning about missing employee data (like Social Insurance Number) was fixed by adding a dependency to automatically recompute warnings when the data changes. These improvements ensure accurate payroll reporting and data integrity.
Original PR description
Issue 1: Steps to Reproduce: -> Create Payslip for Employee -> Once payslip is validated, Click Pay, and for Mode Choose ETA Form 2 -> Download and open the File it throws Formatting error Cause: The Excel workbook was base64-encoded before being written to the binary field, which expects raw bytes. Fix: Save raw binary data directly and update the test case to load it using `io.BytesIO` on binary field content Issue 2: Steps to Reproduce: -> Create a payslip for an employee missing (like EG Social Insurance Number) -> A warning is raised that field is missing. -> Even if the field is filled, the warning does not disappear. Cause: There is no compute dependency to recompute warnings when value changed. Fix: Added dependency in `_issues_dependencies` so it recomputes when value changes. task-**6292194** Forward-Port-Of: odoo/enterprise#122474 Forward-Port-Of: odoo/enterprise#120544
This update fixes an issue where sales from European companies to Northern Ireland (XI) were incorrectly calculating intra-community taxes. The change adds a check to ensure these transactions are treated as third-country sales, aligning with tax regulations. This ensures accurate financial reporting.
Original PR description
…stomers The services sales done from a European company to a Northern Ireland (XI) company should not contain intra-community taxes but should be treated as third country (non-EU) transactions. We solve it by adding a check in the EC Sales List return that is only visible when a wrong record occurs. task-6007931 Forward-Port-Of: odoo/enterprise#122535 Forward-Port-Of: odoo/enterprise#121487
This update fixes an issue where the payrun chatter window would disappear unexpectedly during certain actions, disrupting the payroll process. The change ensures the chatter window stays open and functional, improving the user experience when continuing pay runs. The fix was triggered by a bug in how the system refreshed messages related to pay runs.
Original PR description
The payslip run aside chatter was keyed on a revId counter that _updatePayRun bumps on every payrun update (view button actions, the HR_PAYROLL:UPDATE_PAYRUN bus, the step bubble refresh). Changing a t-key makes Owl destroy and recreate the whole chatter, which resets composerType to false. When a refresh landed while the log note composer was open, the composer input disappeared. In the payrun tour this happens right after continuing a pay run, so posting the third note timed out waiting for .o-mail-Composer-input. Remove the t-key and refresh its messages through the MAIL:RELOAD-THREAD bus that the Thread already listens to. The server posted status messages still show up without throwing away the composer. https://runbot.odoo.com/odoo/error/941272 Forward-Port-Of: odoo/enterprise#122518
This update fixes an issue where GS1-compliant barcodes were not correctly interpreted as product scans. When enabled, the system now accurately processes these barcodes, ensuring correct quantity updates during scanning, improving inventory accuracy.
Original PR description
In certain cases the barcode of a product could be a valid standalone GS1 sequence. In that case it needs to be be correctly interpreted as a product scan. ### Steps to reproduce: - In the settings…
In certain cases the barcode of a product could be a valid standalone GS1 sequence. In that case it needs to be be correctly interpreted as a product scan. ### Steps to reproduce: - In the settings enable "Default GS1 Nomenclature" - Create a storable product P with the barcode 3701762412212 - Create and confirm a delivery for 2 units of P and set the qty to 2 - Go to the barcode app and open your delivery - Scan 3701762412212 > The line of P is now selected with a quantity of 1/2 - Scan 3701762412212 #### > A new line is created for 1762411 units ### Cause of the issue: According to the GS1 nomenclature, the barcode 3701762412212 matches the scan of a quantity of "1762412" units of the lot name "2". As the scan of the of the product match a pattern for the GS1 nomenclature before matching a product, its barcode data is expected to be reset by these lines: https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1320-L1324 In order to bypass the GS1 parser and to add 1 unit of the product. This is what happen on the first scan. However, performing the first scan also selects the associated line and, hence on the second scan the lines just above this check do set the product to match the product of the current line: https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1294-L1320 In particular, we do not bypass the result provided by the GS1 parser and add `1762412` units of the product. opw-6175621 Forward-Port-Of: odoo/enterprise#122256 Forward-Port-Of: odoo/enterprise#120035
This update fixes an issue where bank reconciliation calculations were incorrect when dealing with foreign currencies. The system now properly converts amounts from the journal currency to the company currency, ensuring accurate balance calculations and preventing constraint errors. This improves the reliability of bank reconciliation processes.
Original PR description
### Issue: When a bank journal uses a foreign currency, reconciliation model lines with `Amount Type: From Label` (regex) could raise a constraint error or produce incorrect balances on the journal…
### Issue: When a bank journal uses a foreign currency, reconciliation model lines with `Amount Type: From Label` (regex) could raise a constraint error or produce incorrect balances on the journal entry ### Cause: The `balance` of the generated move line was set to the raw value extracted by the regex, without converting it from the journal currency to the company currency This violated the sign constraint between `balance` and `amount_currency` when the exchange rate caused a mismatch, raising a `_check_amount_currency_balance_sign` error The `amount_currency` was already correctly set Only the `balance` conversion was missing ### Steps to reproduce: - Install `accountant` - Enable a foreign currency (e.g. EUR) with two rates: yesterday: ratio < 1 (e.g. 0.5), today: ratio > 1 (e.g. 2.0) - Create a Bank journal in EUR - Open Bank Reconciliation for that journal - Add two transactions (one dated yesterday, one today) (Ref: "test BANK:0001690,00EUR EXP:00033,80", amount: 1656.20) - Create a reconciliation model (3 dots > Manage Models) (name: From Label): -- Account: 101401 Bank, Amount: BANK:0*(\d+),(\d+) -- Account: 600000 Expenses, Amount: EXP:0*(\d+),(\d+) - Apply the model on both transactions Before the fix, one raised an error due to the constraint violation - From the list view, open the Journal Entry for the other transaction Before the fix, `balance` was not converted to company currency opw-6292839 Forward-Port-Of: odoo/enterprise#121114
This update fixes an issue where group payments weren't correctly updated when invoices were modified, leading to reconciliation problems. The change ensures that all payments, including group payments, transition to 'In Process' state when a statement line is unreconciled, resolving a discrepancy in payment status.
Original PR description
**Steps to reproduce:** - Install Accounting - Create an invoice: * Customer: Partner A * Total: 30.00 - Confirm the invoice - Create a second invoice for the same customer: * Customer: Partner A *…
**Steps to reproduce:** - Install Accounting - Create an invoice: * Customer: Partner A * Total: 30.00 - Confirm the invoice - Create a second invoice for the same customer: * Customer: Partner A * Total; 10.00 - Confirm the invoice - From the invoice list, select both invoice - Create payment: * Journal: Bank * Group Payments: [checked] * Group Payments: [checked] * Amount: 40.00 - Create a third invoice for another customer: * Customer: Partner B * Total: 25.00 - Confirm the invoice - Register payment from the invoice - Create a fourth invoice for another customer: * Customer: Partner C * Total; 40.00 - Confirm the invoice - Register payment from the invoice - From the payment list, select all 3 payments and create batch payment - Validate the batch payment - From Accounting dashboard, open Bank journal - Create a new bank statement line of 105.00 - Match it with the batch payment At that point, the statement line is reconciled with the 4 invoices and the 3 payments are marked as paid. - Go to the fourth invoice - Reset it to draft - Change the price - Save When the amount of the invoice is changed, the statement line is unreconciled and all the payments should change state from "Paid" to "In Process". **Issue:** All the single payments have their state correctly changed to "In Process", except for the group payment for the 2 first invoices, which leads to undesired values when trying to reconcile the statement line with the batch payment again. **Cause:** When the statement is unreconciled, all the partial reconcile records are deleted and the state of the linked payments are updated to "In Process". The payments are retrieved by checking if there are linked to an account move present in the partial reconcile record and if the amount of the payment matches the amount of the partial reconcile record. In case of a group payment, there are 2 partial reconcile records for each invoice linked to the payment. Therefore, in that case, the amount doesn't match the amount of the payment because it matches the amount of one of the invoice. opw-6141089 Forward-Port-Of: odoo/enterprise#122585 Forward-Port-Of: odoo/enterprise#120210
This update fixes a display issue in the Intrastat report where bill names were being cut off before hyphens. The change adjusts a regular expression to correctly handle hyphen characters in bill names, ensuring complete and accurate reporting. This improves the clarity and usability of Intrastat reports.
Original PR description
**Steps to reproduce:** - Install Accounting - In Accounting settings, activate "Intrastat" - Create a product with Intrastat info - Create a bill: * Product: [the created Intrastat product] *…
**Steps to reproduce:** - Install Accounting - In Accounting settings, activate "Intrastat" - Create a product with Intrastat info - Create a bill: * Product: [the created Intrastat product] * Intrastat Country: [any] * Intrastat Transport Mode: [any] - Confirm the bill - Make sure that the bill name contains a hyphen character (i.e. "-") For example, "BILL/2026-06/0001". Use the "Resequence" action from the bills list view if needed. - Go to "Accounting / Reporting / Audit Reports / Intrastat Report" - Expand the line to display the bill name **Issue:** The bill name is not fully displayed. It is cropped right before the hyphen character (i.e. BILL/2026). **Cause:** A regex is used to retrieve the bill name from the report line name, but it is only allowing "/" character. **Solution:** Just allow "-" character in addition. No other character is allowed to limit the risk of matching something that should not. opw-6299854 Forward-Port-Of: odoo/enterprise#120979
This update fixes an issue where users would lose the project, description, and task information they entered in the Timesheets systray when closing it. The previous fix was an unnecessary precaution, and this update removes it, ensuring data is saved correctly.
Original PR description
## Issue When using the Timesheets systray, if we set a project after clicking the *Save* or *Reset* button, the project is not saved after closing the systray. ## Steps to reproduce 1. Install…
## Issue When using the Timesheets systray, if we set a project after clicking the *Save* or *Reset* button, the project is not saved after closing the systray. ## Steps to reproduce 1. Install *Timesheets* (`timesheet_grid`) 2. Open the Timesheets systray 3. Click *Reset* and set a description, a project and/or a task, then close the systray 4. Open the systray again 5. **The description/project/task set in step 3 do(es) not appear anymore.** ## Cause Commit https://github.com/odoo/enterprise/commit/b9b7f8a0acf7a1c545c6613cf8bbc29871632e26 introduced the `preventUnmountSave` attribute. The attribute is set to `true` after saving and discarding an entry. When the systray is unMounted, the manual values (e.g., description, project and task) are not saved if the attribute is set to `true`: https://github.com/odoo/enterprise/blob/7cd8dd008eb88d6c12f3e65fb8d311058290a301/timesheet_grid/static/src/components/timesheet_timer_inline_form/timesheet_timer_inline_form.js#L171-L174 ## Fix After discussing with the author of the previous commit, it appears this was done to prevent an issue with values stored in cache, but that issue does not seem to occur anymore, which leads to believe that the attribute is not required anymore. opw-6284016 Forward-Port-Of: odoo/enterprise#122332 Forward-Port-Of: odoo/enterprise#121605
This update reverts a recent change that allowed employees to directly edit personal information within Odoo. Management requested this change to prevent potential inaccuracies in payroll calculations and ensure compliance with tax regulations. HR team oversight will now be required for any updates to this sensitive data.
Original PR description
This reverts the recent changes that exposed the "Family" and "Personal Info" sections (such as Marital Status) in the employee's "My Preferences" menu. While the initial addition was intended to improve employee self-service, management requested this revert because allowing employees to directly edit these fields poses a risk to payroll accuracy and compliance. Data points like marital status or family dependents directly impact tax deductions and benefit enrollments. To ensure data integrity, any modifications to payroll-affecting information must remain the exclusive duty of the HR team, who can require and verify the proper legal documentation before updating the system. task-6304031
This update resolves an issue where signed documents were incorrectly placed in separate folders, leading to duplicate entries and confusion. Now, signed documents from both the Documents and HR apps appear only in their respective folders (Employee/Payroll), and no extra documents are created upon completion. This ensures data consistency and simplifies document management.
Original PR description
Before: - Documents flow: after signing, the signed copy was placed in the Sign folder instead of the same folder as the original document. - HR flow: after signing a sign.request linked to an HR…
Before: - Documents flow: after signing, the signed copy was placed in the Sign folder instead of the same folder as the original document. - HR flow: after signing a sign.request linked to an HR record (e.g. hr.employee, hr.version), the signed document appeared twice, once in the Employee/Payroll folder and again in the Sign folder. - [_sign()](https://github.com/odoo/enterprise/blob/19.0/sign/models/sign_request.py#L505) attaches a copy of the signed document to the linked record, but the missing `no_document=True` was mistakenly creating an extra document - Import from Documents flow: after signing via "Import from Documents" in the Sign app, the signed copy was placed in the original document folder instead of the Sign folder. After: - Documents flow: the signed document is now placed in the same folder as the original document. - HR flow: the signed document is created only once, in the Employee/Payroll folder. No copy is made in the Sign folder. - No extra documents are created in the background when a sign request linked to a record is completed. - Import from Documents flow: the signed document is now placed in the Sign folder. Impact: - Signed documents from the Documents app stay in the same folder. - Signed HR contracts appear only in the Employee/Payroll folder. - No duplicate documents are created on completion. Task: 6176315
This update resolves a tour test failure in the Belgian HR contract salary module. The issue stemmed from a configuration that incorrectly expected an identification number or NISS when the core payroll module was not installed. The fix ensures the necessary fields are displayed correctly when the Belgian payroll module is active, improving test reliability.
Original PR description
[FIX] l10n_be_hr_contract_salary: fix NISS runbot error in salary config Bug reproduction: 1 - Get 19.4, only install hr_contract_salary and execute tour test hr_contract_salary_employee_flow_tour 2…
[FIX] l10n_be_hr_contract_salary: fix NISS runbot error in salary config
Bug reproduction:
1 - Get 19.4, only install hr_contract_salary and execute tour test hr_contract_salary_employee_flow_tour
2 - When only single app is installed without installing l10n_be_hr_contract_salary, the tour test fails
Bug cause:
1 - When the employee's company's country is belgium we were showing NISS instead of identification number.
2 - But NISS field is appended in l10n_be_hr_contract_salary and if you do not install, there is no identification number and NISS.
3 - That's why the test fails (it looks for identification number or NISS but none of them is there)
Bug solution:
1 - I moved the code of hiding identification number or hiding NISS to the l10n_be_hr_contract_salary. So, when only hr_contract_salary is installed, identification number field won't get hided.
task - 6333129
runbot error link: https://runbot.odoo.com/odoo/error/941044
Forward-Port-Of: odoo/enterprise#121800This update removes the ability to quickly create new journals from the POS payment method form. The accounting team requested this change to ensure users only create journals within the dedicated accounting application, improving process control and data accuracy. This change applies locally and can be extended where needed.
Original PR description
Currently on the pos payment method form, if you click "Select more" on the journal field, you will see two buttons 'New' & 'Create New'. Steps to reproduce: ------------------- * Open any pos…
Currently on the pos payment method form, if you click "Select more" on the journal field, you will see two buttons 'New' & 'Create New'. Steps to reproduce: ------------------- * Open any pos payment method * Select the journal field * Select "Search more" > See two creation buttons Why the fix: ------------ One button is the standard "On search more" button which can be hidden using options such as no_create, no_create_edit, ... The second button is defined on the list view for journals and since the search more uses the list view it shows the button as well. Currently we can do that with a context key to ensure that on the "real" list view it's still visible. Why do we want to hide those buttons? Asked the R&D accounting team, it should not be allowed to create journals on the fly. You should only be able to create them inside accounting app. This behavior is not limited to this view but will only be applied locally. The fix can however be applied everywhere where needed. Before the fix: ------------------- <img width="700" height="417" alt="image" src="https://github.com/user-attachments/assets/ca11ea13-c38e-40a1-9848-cbc5edc6226e" /> <img width="1507" height="887" alt="image" src="https://github.com/user-attachments/assets/1cde5d3b-3372-4aca-b5d0-2319bd82c1de" /> After the fix: ---------------- <img width="707" height="474" alt="image" src="https://github.com/user-attachments/assets/01dc7b42-43d6-4b18-a12d-54330d51b92b" /> <img width="1457" height="870" alt="image" src="https://github.com/user-attachments/assets/ff387d3f-f59c-47ad-abfe-a2003669db1a" /> opw-6131231 Forward-Port-Of: odoo/enterprise#120379
This update fixes an error in calculating holiday attest annual taxable income for employees on long-term sick leave (over 30 days). Previously, the calculation was incorrect due to a reliance on zero-valued payslips. Now, the system uses the employee's monthly wage to ensure accurate taxable income calculations, aligning with Belgian tax regulations.
Original PR description
Problem ---------------------- When an employee takes a long sick leave (more than 30 days), the basic wage on the payslip is set to 0, leading to the holiday attest annual taxable income to be…
Problem ---------------------- When an employee takes a long sick leave (more than 30 days), the basic wage on the payslip is set to 0, leading to the holiday attest annual taxable income to be calculated as 0 * 12, which is incorrect. Reason ------------------- The calculation for the holiday attest uses the last payslip for the employee, and if the employee had leave type LEAVE214, the last payslip has the basic wage set to zero, so the taxable wage that is used in the annual taxable wage calculation is wrong. The monthly wage should be used as the basic wage in the payslip to get the correct computation. Solution ------------------- The GROSS (taxable income) line that is used is computed as (basic wage - ONSS total + BIK), but the basic wage was 0. This commit checks whether the basic wage is 0 and if the time off type was longterm sick leave, and simulates a payslip using the monthly wage from the contract as basic wage to get the accurate computation for the taxable income. task-6237717 Forward-Port-Of: odoo/enterprise#120180
This update resolves a technical issue that caused build failures in certain testing modes. The team moved assertions to their correct locations, ensuring consistent build behavior across all environments. This improves the reliability of our software development process.
Original PR description
Oversight of: https://github.com/odoo/enterprise/pull/98569 Some assertions were put in the wrong module, making the builds work in "all apps" mode but fail in "single app" mode. This commit moves assertions where they belong. Task-6353709 Forward-Port-Of: odoo/enterprise#122486
This update fixes an issue where CFDI documents generated after payment updates incorrectly displayed rates, particularly when payments were made in foreign currencies (like USD). The fix ensures the correct payment amount and rate are reflected in the CFDI document, improving accuracy and compliance for Mexican tax reporting.
Original PR description
The rate and payment amount shown on the CFDI document generated after updating payments was wrong when the payment was made in a foreign currency. Steps to reproduce: ------------------- * Create a journal that use USD as currency and set the rate to 20 MXN for 1 USD * Create an invoice in MXN and make sure it is set to PPD * Add any product to the invoice for 300$ and post it * Send the invoice to CFDI (a first document should be generated) * Create a payment of 15 USD in the new journal and reconcile it with the invoice * Go back to the invoice and click on "Update payments" to generate the second CFDI document > Observation: The payment document shows an amount of 300 USD with a rate of 1 instead of 15 USD with a rate of 20. Why the fix: ------------ We make sure to use the amount from the statement line when there is one. opw-5974519 Forward-Port-Of: odoo/enterprise#122117 Forward-Port-Of: odoo/enterprise#115779
This update fixes a vulnerability in the Odoo test for Brazilian Electronic Invoice (BR-EDI) processing. The previous test was overly reliant on a specific message format, making it prone to failure due to minor changes in invoice data. The fix now searches for the key information across all invoice messages, ensuring more reliable test results.
Original PR description
The test was relying on a fixed chatter message position. Another tracking message can be inserted before the informative taxes message, so the assertion may read the wrong body. Search the expected informative taxes content among all invoice messages instead. Broke the runbot of : https://github.com/odoo/odoo/pull/273569
This update resolves a technical problem where web studio's technical names were incorrectly generating `x_studio_<type>_NaN` values. The fix ensures these names are generated correctly, preventing potential errors and improving the stability of the web studio functionality. This change ensures consistent and reliable technical naming conventions.
Original PR description
The PR #119993 introduced a bug leading to technical names being named `x_studio_<type>_NaN`. This commit fixes the issue. A `_NaN` increment is only possible if the increment reach int max size. task-6353814 Forward-Port-Of: odoo/enterprise#122594
This update corrects a warning in the planning module that occurred when trying to modify certain settings. The change ensures data restrictions are applied correctly, preventing potential issues with data integrity. This improves the stability and reliability of the system.
Original PR description
The `@api.constrains` decorator was listening to `company_id`, which is a readonly related field. This triggers an ORM warning ("parameter 'company_id' is not writeable").
Swapped the constraint trigger from `company_id` to `warehouse_id`. Since the company is fully dependent on the warehouse, this safely achieves the exact same trigger logic.
build: [940408](https://runbot.odoo.com/odoo/runbot.build.error/940408)
Forward-Port-Of: odoo/enterprise#121584Features or functions removed from Odoo
This update removes a previously deleted file that was causing a 'dead' module in the Odoo Enterprise system. The change ensures the system is cleaner and more stable, addressing a minor technical issue. This improves overall system performance.
Original PR description
The contents of this file were previously deleted, but the file itself was missed, leaving a dead l10n_hk_hsbcnet module in 19.4. This commit removes the file entirely to clean it up. Forward-Port-Of: odoo/enterprise#122573
This update removes outdated code related to 'onWillRender' hooks, a component of the older Owl 3 system. This change is part of a larger migration to Owl 3, ensuring the system continues to function correctly and efficiently. It's a routine maintenance update.
Original PR description
As part of the Owl 3 migration, replace deprecated onWillRender hooks with the appropriate Owl 3 alternatives.
This update removes an outdated feature ('useComponent') from several Odoo modules. This change improves the system's efficiency and stability by aligning with newer development practices. It ensures the continued smooth operation of key functionalities within Odoo.
Original PR description
- Community: https://github.com/odoo/odoo/pull/272185 See commit messages for details.
Code cleanup and technical improvements
This update aligns several Enterprise apps with the latest underlying Odoo web interface changes. It helps keep features such as Gantt views, Studio, Documents, Sign, Social, Planning, and related workflows working reliably after the platform upgrade.
Original PR description
## `t-ref` → Owl 3 signals — enterprise companion Enterprise side of the codebase-wide Owl 2 → Owl 3 ref-semantics migration. Pairs with the consolidated community PR. Single squashed commit (16 files): xpath rewrites for removed `t-custom-ref` attributes, ref reads converted to the signal call form, and patch/subclass reusers adapted across `web_gantt`, `web_studio`, `documents`, `ai`, `sign`, `social`, `l10n_ke_edi_oscu_pos`, `planning`, `hr_holidays_gantt`. ### Notes - Rebased onto current enterprise `master` (2026-06-10). - Community PR: odoo/odoo#269265
This update removes outdated code related to a previous Gantt chart progress bar redesign. The progress bar component is no longer needed in the current layout, so these files have been deleted to streamline the system and improve efficiency. This is a routine maintenance task.
Original PR description
Cleans up residual dead code left over from the progress bar redesign in https://github.com/odoo/enterprise/pull/118045. Since the `GanttRowProgressBar` component is no longer referenced anywhere in the new layout architecture, its corresponding files have been deleted. Forward-Port-Of: odoo/enterprise#122142
This update removes an outdated technique for autofocusing elements within the View Editor component. The change utilizes a more modern, reactive approach to ensure the element correctly focuses when needed, improving the user experience. Comprehensive testing confirms this update resolves a previous issue.
Original PR description
Replaced `useLayoutEffect` with `signal.ref(HTMLDivElement)` + `useEffect` because `useLayoutEffect` is deprecated in OWL3. The effect drove autofocus on the Property component's root element,…
Replaced `useLayoutEffect` with `signal.ref(HTMLDivElement)` + `useEffect` because `useLayoutEffect` is deprecated in OWL3.
The effect drove autofocus on the Property component's root element, triggered both when the DOM element became available and when `env.viewEditorModel.activeNodeXpath` changed. This matches the canonical `signal.ref()` + `useEffect` pattern: converting `useRef('root')` (from `@web/owl2/utils`) to a `signal.ref(HTMLDivElement)` class field makes the element a reactive signal, so `useEffect` auto-subscribes to it and re-runs whenever the element appears. The second dependency is read via `void` inside the callback to force subscription without changing the logic.
The useLayoutEffect refactored in this PR has test coverage — below are some tests that failed when the effect was commented out, and are now passing:
- @web_studio/view_editors/interactive_editor_sidebar/autofocus field label in the sidebar
- @web_studio/view_editors/interactive_editor_sidebar/update sidebar after edition
- WebSuite.test_unit_desktop
see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2602195/build/115250521This update replaces outdated `useLayoutEffect` code with modern, native React event handling (`onMounted` and `onWillUnmount`) across several Odoo modules. This improves stability and performance, aligning with the latest OWL3 compatibility standards. The changes address potential bugs and simplify the codebase for easier maintenance.
Original PR description
## Summary Part of the incremental OWL3 migration removing `useLayoutEffect` from `@web/owl2/utils`, which relies on the OWL2 compatibility shim and is deprecated in OWL3. The pattern replaced is…
## Summary Part of the incremental OWL3 migration removing `useLayoutEffect` from `@web/owl2/utils`, which relies on the OWL2 compatibility shim and is deprecated in OWL3. The pattern replaced is always the same: `useLayoutEffect` with a static or stable-ref dependency was used solely to attach DOM event listeners after mount and clean them up before unmount. In all cases, `onMounted` + `onWillUnmount` from `@odoo/owl` is the correct native replacement — the effect runs once, the ref is stable, and no reactive re-run is needed. ## Commits - **web_gantt**: `useMultiHover` — replaces per-element `pointerenter`/ `pointerleave` listeners (re-queried on every patch) with a single event delegation pair (`pointerover`/`pointerout`) on the container. Simpler and handles dynamic DOM children for free. - **hr_referral**: Bootstrap carousel `slide.bs.carousel` listener — also migrates `carouselRef` from `useRef` to a signal (`t-ref`) and `reachedEnd` from a proxy state to a signal. Fixes a latent bug where `bind(this)` was called twice (once in `addEventListener`, once in `removeEventListener`), making the removal a silent no-op. - **social_facebook/instagram/linkedin**: Click listeners on comment and like buttons queried via `querySelector` — identical structure across the three social kanban patches, straightforward one-to-one swap.
This update replaces an outdated coding technique (`useLayoutEffect`) with a more modern approach (`useListener`) for handling the AI chat feature. This change ensures compatibility with the latest Odoo version (OWL3) and improves the stability of the codebase. The update includes thorough testing to guarantee continued functionality.
Original PR description
Replaced `useLayoutEffect` with `useListener` because `useLayoutEffect` is deprecated in OWL3. The commented-out effect was a pure event-subscription pattern: its body only called…
Replaced `useLayoutEffect` with `useListener` because `useLayoutEffect` is deprecated in OWL3.
The commented-out effect was a pure event-subscription pattern: its body only called `this.env.bus.addEventListener('AI:OPEN_AI_CHAT', openAiChat)` with a cleanup returning `this.env.bus.removeEventListener`, and its dependency function returned an empty array (register once on mount, unregister on destroy). `useListener(this.env.bus, 'AI:OPEN_AI_CHAT', openAiChat)` is an exact 1:1 replacement — it internally wraps `useEffect` with a null-guard and a `removeEventListener` cleanup, preserving the exact add/remove lifecycle without any dep-array bookkeeping.
The `useLayoutEffect` refactored in this PR has test coverage — below are some tests that failed when the effect was commented out, and are now passing:
- TestAIDraftUI.test_ai_draft_chatter_button (Post install test_ai)
- TestAIDraftUI.test_ai_draft_chatter_button (test_discuss_full_enterprise)
- TestAIDraftUI.test_ai_draft_chatter_button (test_mail_enterprise)
see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2604770/build/115379831This update removes outdated code (`useLayoutEffect`) that was causing issues with the sign process. The changes replaced these calls with more modern React hooks, ensuring better performance and stability. Additionally, a related refactoring addressed compatibility issues with older Odoo versions.
Original PR description
Replaced 4 `useLayoutEffect` calls with `onMounted` (3 cases) and `useEffect` (1 case) because `useLayoutEffect` is deprecated in OWL3. 3 of the 4 effects run once at mount with an empty dependency…
Replaced 4 `useLayoutEffect` calls with `onMounted` (3 cases) and `useEffect` (1 case) because `useLayoutEffect` is deprecated in OWL3. 3 of the 4 effects run once at mount with an empty dependency array, making `onMounted` the natural fit. The remaining effect tracked `this.state.documentsWithUnsignedItems` and `this.state.openedDocumentIndex` — the state is a reactive proxy mutated via Set in-place, which would break with signals. `useEffect` auto-tracks reactive reads and preserves the exact same reactive behaviour. Note: `usePublicRefuseButton` was refactored to accept a `component` parameter instead of calling `useComponent()`, which only exists in the OWL2 compat layer `@web/owl2/utils` and is not available in OWL3. The useLayoutEffect refactored in this PR has test coverage — below are some tests that failed when the effect was commented out, and are now passing: - `@sign/document_backend/simple rendering`: getDataFromHTML step not received - `@sign/signable_sign_request/simple rendering`: getDataFromHTML step not received - `TestPortalSignFlow.test_portal_sign_document`: .o_sign_sign_item_navigator not found see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2596833/build/114857629
This update streamlines the process of setting up test environments for Odoo modules. By separating environment configuration from app creation, it simplifies future updates and makes it easier to remove test environments. This change improves the reliability and maintainability of our automated testing.
Original PR description
* account_reports,documents,documents_spreadsheet,knowledge,obox,room, sign,sign_itsme,spreadsheet_dashboard_edition,spreadsheet_edition, test_spreadsheet_edition,web_studio This commit splits the app/component creation and the env creation at user pov by changing how we populate the env in tests. Now, we have to configure the env before creating the app. This will make the env removal easier in the future.
This update adjusts the Point of Sale (POS) modules and related components to align with the new OWL 3 properties syntax. This change ensures compatibility with evolving standards and improves the system's ability to handle data related to POS transactions.
Original PR description
In this commit: =============== - Update `point_of_sale` and related modules to use the OWL 3 props syntax. Task-6260271 Related Community PR: https://github.com/odoo/odoo/pull/270730