Daily updates from Odoo
Tuesday, March 24, 2026
256 changes
12 changes
Resolved issues and error corrections
This update fixes a bug where right-clicking on keypad buttons incorrectly triggered a long-press action. This issue stemmed from the way the context menu was handled, leading to unintended behavior. The fix ensures that only left-button actions are recognized, improving the overall user experience.
Original PR description
Since [1], some keypad buttons have a long-press value/action and, at worst, they enter the normal key value after the long-press duration. It was later improved by [2] (19.2) and other actions were…
Since [1], some keypad buttons have a long-press value/action and, at worst, they enter the normal key value after the long-press duration. It was later improved by [2] (19.2) and other actions were added such as long-pressing backspace at [3] (19.2) and more recently [4] (19.3) which allows calling the voicemail with long-pressing "1". In all those versions and features, there is the same bug: right-clicking the key triggers the long-press action as the context menu opens over the cursor, then our implementation ends up believing a long-press was performed. Solution: we should never have considered anything else than left-button actions anyways. [1]: https://github.com/odoo/enterprise/commit/82b4c4327fc722f55a0c14b14a916a5cddafa0eb [2]: https://github.com/odoo/enterprise/commit/b9dd0d6fc1fee479e9c8cd4c89dc0a9147891185 [3]: https://github.com/odoo/enterprise/commit/2723ef65622bb206d64e08482f3acd6594c03d28 [4]: https://github.com/odoo/enterprise/commit/dea0baa0dfd76962865717173807e4c945414cd3 task-6055182 Forward-Port-Of: odoo/enterprise#111490
This update fixes a technical error that occurred when users tried to take pictures without an IoT device connected to a quality control point. The fix adds a check to ensure a device is set, preventing a system error and guiding the user to properly configure the control point.
Original PR description
Currently, an error occurs when the user clicks the Take Picture button without an IoT box set on the quality control point. ## Steps to replicate: - Install Quality, Purchase, IoT - Quality >…
Currently, an error occurs when the user clicks the Take Picture button without an IoT box set on the quality control point. ## Steps to replicate: - Install Quality, Purchase, IoT - Quality > Quality Control > Control points - Create a new Control point with - Type: Take A Picture - Operations: My Company: Receipts - Create and confirm a purchase order for a test product - Receipts > Quality Checks > Take A picture ## Observed behavior: TypeError: Cannot read properties of undefined (reading '0') ## Root cause: This error occurs because no device has been set on the control point. When the user clicks the **Take a Picture** button, the `onClick` method [1] is triggered. Since `this.iotDevice` is false, both `iotBoxId` and `deviceIdentifier` are undefined. These undefined values are then passed to the action function [2], which in turn passes them to the `_attemptFallbacks` function. At [3], a type error occurs because the system tries to index `iotBoxId` even though it is undefined. [1]: https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/quality_iot/static/src/iot_picture_button.js#L7-L17 [2]: https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/iot/static/src/network_utils/iot_http_service.js#L213-L236 [3]: https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/iot/static/src/network_utils/iot_http_service.js#L149-L152 [4]: https://github.com/odoo/enterprise/blob/1d25675de808521dc8ad8c56bc9fbd320a0ae56b/quality_iot/static/src/iot_measure_button.js#L27-L32 ## Solution: Add a check for an unset device and notify the user to add a device to the quality point. This prevents a traceback and clearly informs the user about the issue. Similar to how it was done in [4] opw-6010095 Forward-Port-Of: odoo/enterprise#110615
This update fixes a discrepancy in test data related to tax reporting for foreign customers in Ecuador. The system now correctly identifies company partners ('02' tipoCliente) based on a new internal field, ensuring accurate tax calculations and compliance with Ecuadorian regulations. This change improves the reliability of reports generated for international sales.
Original PR description
Since `tipoCliente` is now determined using the computed `is_company` field, the test data must reflect this logic. `partner_ext` represents a foreign partner and is considered a company, therefore its `tipoCliente` should be set to '02'. See: https://github.com/odoo/enterprise/commit/a779badac35cf4a8f483f490e8ae29eb6bf3d2c5 `l10n_ar_edi`: For foreign partners, AFIP requires the CUIT pais based on the partner’s country and document type, not on partner.is_company. In multi-localization databases, is_company may be influenced by local heuristics and lead to picking the wrong foreign tax identifier. Use the identification type instead: VAT documents map to the legal-entity CUIT pais, while non-VAT documents map to the natural-person one. See: https://github.com/odoo/enterprise/pull/86089#discussion_r2128977870 runbot-241126 Forward-Port-Of: odoo/enterprise#110055
This update fixes an issue where the 281.50 PDF report occasionally generated an extra page due to formatting. The change optimizes the report layout to ensure it consistently uses only one page for standard reports, improving readability and reducing unnecessary PDF sizes. This primarily impacts reports for Belgian companies.
Original PR description
**Behavior:** Currently when generating the 281.50 report the pdf ends up taking an extra page filled only with header and footer, the page appears when creating the report for a natural person and…
**Behavior:** Currently when generating the 281.50 report the pdf ends up taking an extra page filled only with header and footer, the page appears when creating the report for a natural person and adding a national number. The solution is not to fully prevent the report form being more than 1 page long, as some informations could span over more than one line which would make the pdf need an extra page. But to shave a few milimeters so that by default when filled with standard informations the pdf appears cleaner. **Steps to reproduce:** - Log to a Belgian company - Create a contact that is a person - Add the 281.50 tag to them - Create a credit note for any positive amount for that person and set the date to the previous year - Make sure the account used in the credit note has any 281.50 x tag assigned - Go to Accounting/Reporting/Open 325 forms and create a new form for the year indicated in the credit note - When generating the 281.50 PDF you'll seee it span over 2 pages if you have filled the national number of the contact opw-5930339 Forward-Port-Of: odoo/enterprise#111310
This update fixes a critical issue where signature deadlines weren't updating correctly, leading to outdated task reminders. It also ensures that 'Signature Request' activities are automatically removed when a request is canceled, preventing clutter and improving the user experience. The change includes a safeguard to prevent errors when canceling directly from the activity widget.
Original PR description
1. **Date Sync: mail.activity & sign.request** **Before Fix:** When the validity_date on a sign.request was updated, the linked mail.activity (the "Please Sign" task) did not update its deadline.…
1. **Date Sync: mail.activity & sign.request**
**Before Fix:** When the validity_date on a sign.request was updated, the linked mail.activity (the "Please Sign" task) did not update its deadline. This led to a discrepancy where a document might expire in 2 days, but the user's to-do list still showed a deadline from a week ago.
**Expected Behavior:** The activity deadline should always reflect the current validity of the document to ensure signers are aware of the actual remaining time.
**Fix:** Overrode the write method on sign.request. When the validity_date is modified, the system now automatically updates the date_deadline of all associated records in sign_activity_ids.
2. **Activity Cleanup on Cancel**
**Before Fix:** Canceling a sign.request changed the document state but left "Signature Request" activities sitting in users' to-do lists. This resulted in "orphan" activities that pointed to canceled documents, cluttering the chatter and the activity bin.
**Expected Behavior:** Canceling a request should globally clean up any pending tasks related to that specific request.
**Fix:** Updated the cancel method to unlink associated activities.
**Note on Conflict Prevention:** To avoid a UserError/MissingRecord when canceling directly from the activity widget (where the interface attempts to delete the activity immediately after calling the cancel method), a context flag skip_sign_activity_unlink was introduced. This ensures that if the activity is already handling its own deletion, the backend doesn't "double-delete" it.
Task: 5989542This update ensures the 'Mark as Complete' button is always visible when a return flow has been started, regardless of the user's connection preferences or temporary API issues. This resolves a previous issue where the button was hidden, preventing users from finalizing returns, particularly in localized versions or during API downtime.
Original PR description
When a flow is already started, the button "mark as complete" on returns was invisible. This is an issue for some localizations that don't handle the flow when the API connection is not desired by the user. Another use case, for example, is the API connection is down temporarily, the user manually uploads it on the website, then wants to close the started return. Forward-Port-Of: odoo/enterprise#111600
This update corrects a technical issue impacting UK customer top-ups. The system previously relied on outdated data location information, causing processing errors. This change ensures accurate top-up payments for UK accounts by aligning with the current payment structure.
Original PR description
Fix the UK top-up logic as UK accounts payload structure shifts from the EU where the country data is located in the EU payload it could be found under bank_transfer[financial_adresses][0][iban][country] and bank_transfer[country] but in the uk payload it can only be found in the second As we used the first one, we are now switching it to the second as it's the only common ground Forward-Port-Of: odoo/enterprise#111588
This update fixes an issue where linked records were lost when importing spreadsheets from CSV or XLSX files. The change ensures that newly created spreadsheet documents maintain the original linked record, improving data consistency and simplifying workflows. This resolves a bug impacting how spreadsheets are created and linked to other Odoo records.
Original PR description
When importing an XLSX or CSV document into a spreadsheet, the linked record is lost on the newly created spreadsheet document. This happens because the conversion creates a new document through `copy()`, while `res_model` and `res_id` are computed fields and are not copied by default. This commit explicitly forwards the linked record values during the conversion so the created spreadsheet keeps the same linked record as the source document. Task: [6008920](https://www.odoo.com/odoo/project/2328/tasks/6008920) Forward-Port-Of: odoo/enterprise#111532 Forward-Port-Of: odoo/enterprise#110047
This update fixes an issue where salary deductions weren't being accurately calculated for certain types of salaries (like 'ATTACH_SALARY') in the Kenyan payroll system. The changes ensure that these deductions are now correctly applied, leading to more precise net pay calculations for employees. This resolves a previous error impacting payroll accuracy.
Original PR description
**Behavior before this commit** Some salary rules (e.g. `ATTACH_SALARY`) were ignored in the NET calculation. **Behavior after this commit** - Four rules are now added to the "Total deductions" line: their sequence and category has been changed. - The sign of these lines has also been switched: an attachment of salary of a positive amount should be added to the amount of total deductions, which is then deducted from the net.  opw-5894647 Forward-Port-Of: odoo/enterprise#110579 Forward-Port-Of: odoo/enterprise#107033
A recent change has resolved an error that occurred when updating payroll data in the Saudi Arabian company setup. This fix prevents a data mismatch issue that arose when users deleted salary rule categories, ensuring the 'Payroll: Update Data' process runs smoothly. This improves the reliability of payroll processing for Saudi Arabian companies.
Original PR description
Currently, an error occurs when the "Payroll: Update Data" scheduled action is executed. **Steps to Reproduce:** - Install `l10n_sa_hr_payroll` with demo data. - Switch to `Saudi Arabian` company. -…
Currently, an error occurs when the "Payroll: Update Data" scheduled action is executed. **Steps to Reproduce:** - Install `l10n_sa_hr_payroll` with demo data. - Switch to `Saudi Arabian` company. - Go to `Payroll` > `Configuration` > `Salary` > `Rule Categories`. - Delete all records related to the Saudi Arabian company. - Go to `Scheduled Actions` and run `"Payroll: Update Data"`. `ValueError: External ID not found in the system: l10n_sa_hr_payroll.l10n_sa_category_provision` After [this commit], the category_id field becomes non-required, allowing users to delete a rule category record even if it is linked to a salary rule. When updating the data file [1], this causes an error due to the missing rule category [2]. This commit ensures that, when updating the salary rule data, the rule category data is updated beforehand, as shown here [3]. [this commit]: https://github.com/odoo/enterprise/commit/c663fd2a81b7f6b34f8199fdbdc4a75c4f21379e [1]- https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_sa_hr_payroll/models/hr_payslip.py#L157-L165 [2]: https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_sa_hr_payroll/data/hr_salary_rule_saudi_data.xml#L249 [3]: https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_ke_hr_payroll/models/hr_payslip.py#L9-L18 sentry-7349905716 Forward-Port-Of: odoo/enterprise#111438
This update fixes an issue where DATEV reports generated from Odoo were sometimes inaccurate due to incorrect account assignments. Now, when a move line's account is changed, the DATEV export automatically updates to reflect the new account, preventing duplicate lines in the export. This ensures accurate financial reporting to DATEV.
Original PR description
Description of the issue this commit addresses: When the account of a move line is updated (e.g. replacing the suspense account with the actual one), l10n_de_datev_main_account_id was not recomputed which leads to an incorrect DATEV export with duplicate lines. Desired behavior after this commit is merged: Changing the account_id of a move line recomputes l10n_de_datev_main_account_id so that the exported DATEV data reflects the current accounts of the move. Forward-Port-Of: odoo/enterprise#111493
This update fixes an issue where payroll moves with analytic distribution rules weren't properly anonymized, potentially exposing employee data. The change ensures that payroll moves are correctly aggregated and anonymized, maintaining privacy and compliance. A new test has been added to verify the fix.
Original PR description
The Batch Account Move Lines option in the settings is used to aggregate together the different payslips of a payrun and to create only one move with aggregated lines, per account. This is done to…
The Batch Account Move Lines option in the settings is used to aggregate together the different payslips of a payrun and to create only one move with aggregated lines, per account. This is done to enforce privacy and avoid having lines for each employee in the payrun. If salary rules with analytic distributions are involved, though, the lines are not merged and we lose the anonimity.
This happens because in the _get_existing_lines funciton, that should return the lines to be merged with the input line (line), the condition for the rules that have an analytic distribution is wrong.
In particular, the condition is wrong because the
distribution_analytic_account_ids field is a recordset of the accounts, while line_id['analytic_distribution'] is a dictionary with keys that are comma separated strings of the ids of the accounts, with values reflecting the percentage.
For example, if a rule has one analytic distribution for 40% and involving accounts 13,7 and 12 + another analytic distribution for 60% involving accounts 3 and 5, line_id['analytic_distribution'] will be {'13,7,12': 40.0, '3,5': 60.0} while distribution_analytic_etc will be a recordset containing (13,7,12,3,5). To fix the problem and keep everything inline, we extract the logic to a new function, where we first unravel the ids from the keys of the dictionary and only then try to match them to the values in the recordset.
Task: 6043957
Forward-Port-Of: odoo/enterprise#1111409 changes
Resolved issues and error corrections
This update fixes an issue where users weren't receiving email notifications for signature requests, even when they preferred to receive notifications in their inbox. Now, all signature requests will trigger an email, ensuring signers are promptly informed and can respond. This improves the efficiency of the signature process.
Original PR description
When a user's notification preference is set to "inbox", no email is sent, which may prevent signers from being notified of signature requests. This commit enforces sending email notifications for signature requests regardless of user notification settings. Notifications are still created in Odoo, preserving in-app visibility for users who rely on it. task-6041834 Forward-Port-Of: odoo/enterprise#111094
This update fixes a technical error that occurred when users tried to take a picture without an IoT device connected to a quality control point. The fix prevents a system crash and now guides users to add a device before attempting to capture an image, ensuring a smoother user experience.
Original PR description
Currently, an error occurs when the user clicks the Take Picture button without an IoT box set on the quality control point. ## Steps to replicate: - Install Quality, Purchase, IoT - Quality >…
Currently, an error occurs when the user clicks the Take Picture button without an IoT box set on the quality control point. ## Steps to replicate: - Install Quality, Purchase, IoT - Quality > Quality Control > Control points - Create a new Control point with - Type: Take A Picture - Operations: My Company: Receipts - Create and confirm a purchase order for a test product - Receipts > Quality Checks > Take A picture ## Observed behavior: TypeError: Cannot read properties of undefined (reading '0') ## Root cause: This error occurs because no device has been set on the control point. When the user clicks the **Take a Picture** button, the `onClick` method [1] is triggered. Since `this.iotDevice` is false, both `iotBoxId` and `deviceIdentifier` are undefined. These undefined values are then passed to the action function [2], which in turn passes them to the `_attemptFallbacks` function. At [3], a type error occurs because the system tries to index `iotBoxId` even though it is undefined. [1]: https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/quality_iot/static/src/iot_picture_button.js#L7-L17 [2]: https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/iot/static/src/network_utils/iot_http_service.js#L213-L236 [3]: https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/iot/static/src/network_utils/iot_http_service.js#L149-L152 [4]: https://github.com/odoo/enterprise/blob/1d25675de808521dc8ad8c56bc9fbd320a0ae56b/quality_iot/static/src/iot_measure_button.js#L27-L32 ## Solution: Add a check for an unset device and notify the user to add a device to the quality point. This prevents a traceback and clearly informs the user about the issue. Similar to how it was done in [4] opw-6010095 Forward-Port-Of: odoo/enterprise#110615
This update fixes an issue where the 281.50 PDF report occasionally generated an extra page due to formatting. The change optimizes the report layout to ensure it consistently appears on a single page for standard reports, improving readability and reducing unnecessary printing.
Original PR description
**Behavior:** Currently when generating the 281.50 report the pdf ends up taking an extra page filled only with header and footer, the page appears when creating the report for a natural person and…
**Behavior:** Currently when generating the 281.50 report the pdf ends up taking an extra page filled only with header and footer, the page appears when creating the report for a natural person and adding a national number. The solution is not to fully prevent the report form being more than 1 page long, as some informations could span over more than one line which would make the pdf need an extra page. But to shave a few milimeters so that by default when filled with standard informations the pdf appears cleaner. **Steps to reproduce:** - Log to a Belgian company - Create a contact that is a person - Add the 281.50 tag to them - Create a credit note for any positive amount for that person and set the date to the previous year - Make sure the account used in the credit note has any 281.50 x tag assigned - Go to Accounting/Reporting/Open 325 forms and create a new form for the year indicated in the credit note - When generating the 281.50 PDF you'll seee it span over 2 pages if you have filled the national number of the contact opw-5930339 Forward-Port-Of: odoo/enterprise#111310
This update ensures the 'Mark as Complete' button is always visible when closing a return flow in Odoo, regardless of whether the API connection is active. This resolves an issue where the button was hidden for users relying on manual uploads, improving usability for all return processes.
Original PR description
When a flow is already started, the button "mark as complete" on returns was invisible. This is an issue for some localizations that don't handle the flow when the API connection is not desired by the user. Another use case, for example, is the API connection is down temporarily, the user manually uploads it on the website, then wants to close the started return. Forward-Port-Of: odoo/enterprise#111600
This update corrects a technical issue impacting UK users' top-up payments via Stripe. The system previously relied on outdated data location information, which has now been updated to align with the current UK account payload structure. This ensures accurate processing of UK top-up transactions.
Original PR description
Fix the UK top-up logic as UK accounts payload structure shifts from the EU where the country data is located in the EU payload it could be found under bank_transfer[financial_adresses][0][iban][country] and bank_transfer[country] but in the uk payload it can only be found in the second As we used the first one, we are now switching it to the second as it's the only common ground Forward-Port-Of: odoo/enterprise#111588
This update corrects a bug where text fields in Odoo Sign PDFs were incorrectly displayed as checkmarks instead of the entered text. The issue stemmed from an incorrect interpretation of Appearance State tags within standard text fields. This change ensures text fields accurately reflect the user's input when generating signable PDFs.
Original PR description
Create an interactive PDF form in Adobe Acrobat containing a standard Text Field (/FT /Tx). - Fill the text field with a value (e.g., "John Doe") and save the PDF. - (Note: Adobe Acrobat will often…
Create an interactive PDF form in Adobe Acrobat containing a standard Text Field (/FT /Tx). - Fill the text field with a value (e.g., "John Doe") and save the PDF. - (Note: Adobe Acrobat will often automatically assign an Appearance State (/AS /N) to this text field). - Upload this PDF to the Sign app. **Current behavior:** The text field's string value is ignored and replaced with a checkmark (✓). **Expected behavior:** The text field should correctly render the string value that the user entered. **Cause of the issue:** In the _draw_field_value function, the parser checks if an /AS (Appearance State) tag exists and is not set to /Off. If true, it assumes the field is a checked box and draws a chr(0x2713). However, it fails to check the Field Type (/FT) first. Because Adobe Acrobat sometimes assigns /AS tags to standard Text Fields (/FT /Tx), we misinterprets these populated text fields as checked buttons. **Solution:** This PR fixes the issue safely for stable versions across two commits: [REF]: Extracts the value extraction logic into a dedicated _get_field_value helper method to allow isolated unit testing without requiring a canvas or physical PDF files. No behavioral changes in this commit. [FIX]: Wraps the /AS check within an if field_type == "/Btn": condition. This ensures only actual Checkboxes and Radio Buttons render as checkmarks, allowing Text Fields to fall through and properly return their /V string values. Task: 6018260 Forward-Port-Of: odoo/enterprise#110292
This update corrects a minor typo in the industry_fsm_report module's view definitions. The change ensures accurate reporting functionality related to project tasks. This fix prevents potential inconsistencies in data displayed within the reporting system.
Original PR description
the view name is incorrect and already used for this view https://github.com/odoo/enterprise/blob/60e9e0f3232c9cd1e9675cb2e5c4b054dc57bbda/industry_fsm_sale/views/project_task_views.xml#L358 Forward-Port-Of: odoo/enterprise#108862
This update fixes an issue where DATEV exports were inaccurate when a move line's account was changed. Now, updating a line's account automatically recalculates the DATEV main account, ensuring the exported data correctly reflects the current financial accounts. This prevents duplicate lines in DATEV reports.
Original PR description
Description of the issue this commit addresses: When the account of a move line is updated (e.g. replacing the suspense account with the actual one), l10n_de_datev_main_account_id was not recomputed which leads to an incorrect DATEV export with duplicate lines. Desired behavior after this commit is merged: Changing the account_id of a move line recomputes l10n_de_datev_main_account_id so that the exported DATEV data reflects the current accounts of the move. Forward-Port-Of: odoo/enterprise#111493
This update resolves a bug where users accessing the Enterprise version of Odoo through a specific domain were incorrectly redirected to another domain, preventing them from viewing their documents. This change ensures that the documents smart button correctly directs users to the appropriate domain for accessing their files, improving usability for all users.
Original PR description
Steps to reproduce:
- Have two domains for your database (".odoo.com" and ".example.com")
- set the ".example.com" domain as your web base url
- login on the ".odoo.com" domain, go on an employee and click the documents smart button
-> you cannot see any documents because you are redirected on the ".example.com" domain on which you are not connected
opw-5857914
Forward-Port-Of: odoo/enterprise#1073845 changes
Resolved issues and error corrections
This update prevents the entire report export cron job from stopping if an error occurs during a single report generation. Previously, a single failure would halt the entire process. Now, the cron will continue to attempt to export other reports, improving reliability and ensuring timely report delivery.
Original PR description
If an error is raised during the export of reports cron execution, the whole cron stops due to the fact that the error is never catched This commit will ensure that even if there is an error with one of the report export, the cron won't top and will try to send to other documents task-5469038 Forward-Port-Of: odoo/enterprise#111602 Forward-Port-Of: odoo/enterprise#105191
This update resolves two issues preventing new employee creation in the Belgian payroll module. The first prevented saving with a start date, and the second caused errors when adding wages. The fix ensures proper record creation and avoids duplicate activity triggers, improving employee onboarding.
Original PR description
First bug: Steps: - Switch to belgian company - Create new employee - Set contract start date - Click save manually -> boom Cause: in _trigger_l10n_be_next_activities, we create a new mail activity for the created employee which is already created in the default create function leading to duplicate follower records. Fix: in the super.create, pass the context variable mail_create_nosubscribe=True to disable adding the current user as a follower again to the same record Second bug: Steps: - Switch to belgian company - Create new employee - Set contract date - Add a wage then click anywhere -> boom Cause: _trigger_l10n_be_next_activities is called before the record is saved, hence trying to link to a null object Fix: check if the record is created before working on the activities
This update resolves an issue where the XML generated for Swiss payments (iso20022_ch) was using an outdated payment schema. The fix ensures the XML adheres to current banking standards, specifically the pain.001.001.09 format required by Swiss financial institutions. This improves payment processing accuracy and compliance.
Original PR description
**PROBLEM** According to documentation (https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps-2025-en.pdf) PstlAdr must be structured. This isn't the case when generating a xml for the payment method iso20022_ch. **STEP TO REPRODUCE** 1. install l10n_ch and account_iso20022. 2. Create a swiss contact with a full address. And activate payment on the bank account of this contact. 3. Select the Company CH, and set a bank account in the bank journal configuration. 4. Create a vendor payment to the swiss contact. 5. Create a batch payment with it, and validate to get the xml. 6. Open the xml, and notice the PstlAdr isn't structured. Ticket [link](https://www.odoo.com/odoo/project.task/5880247) opw-5880247 Forward-Port-Of: odoo/enterprise#111158 Forward-Port-Of: odoo/enterprise#107025
This update fixes an issue where currency rates for Bulgaria were incorrectly calculated after the country switched to the Euro. The system was using reversed rates from the XML data, leading to inaccurate unit conversions. This change ensures correct currency calculations for Bulgarian transactions.
Original PR description
Issue: after Bulgaria switched to EUR, currency rate fetching from BNB was incorrectly set to still use reversed currency rates from the fetched XML, resulting in unit-to-EUR and EUR-to-unit rates being flipped in the database. Solution: adjusting the parser to get rate from 'RATE' rather than 'REVERSERATE', as the XML provides both. task-6050519 Forward-Port-Of: odoo/enterprise#111275
This update resolves a problem where invoices with discounts and decimal values (over 2 decimals) were failing to send to ARCA. The fix uses a simplified unit price to calculate discounts, ensuring accurate decimal calculations for EDI invoice generation. This prevents errors and ensures proper invoice transmission.
Original PR description
After changes made in Odoo of how the decimal precision works some of the code we use to prepare the data to create EDI invoices now fails. We already adapt the code to fix the data depending of the expected webserive format but we miss a case related to when invovice has discounts. The problem is that any invoice with lines that has more than 2 decimals and also have a discount will fail when trying send it to ARCA because the computed amount has differences in the decimals. Now we use the truncated unit price to compute the discount instead of the full amount with decimal of the `line.price_unit` value. Forward-Port-Of: odoo/enterprise#110706
11 changes
Resolved issues and error corrections
This update corrects an issue where a partner's identification type was incorrectly set based on its country. Previously, the system didn't consistently update the ID type when a partner's country was changed. This fix ensures that a partner's ID type always matches the country they are associated with, preventing data inconsistencies.
Original PR description
**PROBLEM** PR: https://github.com/odoo/odoo/pull/179078 Removed _onchange_country_id() which was used to set the identification type according to the country of the partner. This PR reintroduce it, so id type and country remains consistent. **STEP TO REPRODUCE** 1. install l10n_ar and l10n_co. 2. create a new partner. 3. set its country to Argentina, and select an argentinian id type. 4. set the country to Colombia and save. You end up with a partner from Colombia, with a id type that is used for Argentinian partners which shouldn't be possible. opw-5801824
This update ensures the sale dashboard accurately displays all orders, including those fulfilled through the POS system. Previously, orders marked as 'done' in the POS were not visible in the dashboard. This fix updates the dashboard to recognize and display all order statuses, providing a more complete view of sales data.
Original PR description
Step to reproduce: - install spreadsheet_dashboard_sale and pos_sale - create a order in pos , invoice it too - open sale dashboard Observation: - the order fulfilled in pos, does not reflect in…
Step to reproduce: - install spreadsheet_dashboard_sale and pos_sale - create a order in pos , invoice it too - open sale dashboard Observation: - the order fulfilled in pos, does not reflect in dashboard Cause: - sale has 4 status i.e ["draft", "sent", "sale", "cancel"] - when pos_sale is installed, new status oders are added i.e ['paid', 'invoiced', 'done'] - sale dashboard pivot relies on sale defined status only, which so not consider orders that have status in ['paid', 'invoiced', 'done'] Fix: - fix the domain of pivots such that, it will now accept other orders too **Before:** <img width="1058" height="277" alt="image" src="https://github.com/user-attachments/assets/e58c88fa-5ad3-4194-9f9c-ddf41f2f73de" /> <img width="1116" height="190" alt="image" src="https://github.com/user-attachments/assets/259e0347-5d5b-4d5c-9aeb-74102aa4becd" /> <br/> **After** <br/> <img width="1137" height="232" alt="image" src="https://github.com/user-attachments/assets/406b71a5-1dd8-4164-9d4e-4f0bca34c9e8" /> <img width="1125" height="235" alt="image" src="https://github.com/user-attachments/assets/fded3203-7d72-45ea-b5aa-142ebcd52136" /> opw-5487654 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248142
This update resolves a validation error that occurred when creating invoices from POS orders with cash rounding enabled. Previously, non-cash payment methods triggered an error due to rounding logic being applied. Now, the system correctly avoids applying rounding rules for non-cash payments, ensuring invoices are created without errors.
Original PR description
## Issue before this commit: Creating an invoice from a POS order with **Cash Rounding enabled only for cash payment methods** raised an unexpected validation error: > *"The operation cannot be…
## Issue before this commit: Creating an invoice from a POS order with **Cash Rounding enabled only for cash payment methods** raised an unexpected validation error: > *"The operation cannot be completed: Missing required account on accountable line."* This happened when the order was paid using a **non-cash payment method**, but rounding logic was still applied. ## Steps to Reproduce: 1. Install the `point_of_sale` module. 2. Go to POS Configuration → Settings: * Enable **Cash Rounding** * Set a **Rounding Method** * Enable **Only on cash methods** 3. Create a product: * Sale Price: 260 * Tax: 6% 4. Open a POS session. 5. Add the product to an order. 6. Apply a discount (e.g., 1.123). 7. Pay using a **non-cash payment method** (journal not marked as cash). 8. Enable **Invoice** and validate the order *(or create the invoice later from the Orders menu)* ## Cause of the Issue: While `_prepare_invoice_vals` correctly avoids setting `invoice_cash_rounding_id` for non-cash payments, `_create_invoice` still executes rounding logic whenever cash rounding is enabled on the POS configuration. This leads to a mismatch where: * No rounding configuration is set on the invoice * Rounding logic still attempts to create/update rounding lines * Required accounts (profit/loss) cannot be determined * A validation error is raised due to missing account on the generated line ## With This Commit: The rounding logic in `_create_invoice` is now guarded by checking the presence of `invoice_cash_rounding_id`. This ensures rounding is only applied when properly configured and avoids unexpected validation errors for non-cash payment invoices. Steps To Reporduce: [Video Link](https://drive.google.com/file/d/10ticlUW5i5pbu_oDDPqR-jg0hVcNWf3Z/view?usp=sharing) opw-6005320 opw-5951991 opw-6036870 Forward-Port-Of: odoo/odoo#254844
This update prevents the entire reports cron job from stopping if an individual report export fails. Previously, a single error would halt the entire process. Now, the cron will continue to attempt exporting other reports, improving reliability and ensuring all reports are eventually generated.
Original PR description
If an error is raised during the export of reports cron execution, the whole cron stops due to the fact that the error is never catched This commit will ensure that even if there is an error with one of the report export, the cron won't top and will try to send to other documents task-5469038 Forward-Port-Of: odoo/enterprise#111602 Forward-Port-Of: odoo/enterprise#105191
This update corrects a bug that prevented invoices with recupel taxes applied to negative lines from passing XML validation. The fix ensures that negative fixed taxes are correctly identified as allowances, resolving a validation issue related to PEPPOL invoice generation. This ensures accurate invoice processing and compliance.
Original PR description
**PROBLEM** If you set a recupel tax (fixed tax affecting base) and use it on a negative line, the generate xml will not pass validation. **STEP TO REPRODUCE** 1. Setup Peppol. 2. Create a recupel tax (fixed tax of 1€, affecting the base). 3. Create an invoice with a negative line, with a VAT and the recupel tax. 4. Send the invoice using peppol, and validate the xml. 5. Notice the xml doesn't pass validation. **CAUSES** 1. The negative fixed tax should be an allowance, but is marked as a charge in the xml. 2. Only fixed taxes that are charges influences the line_extension_amount, but it should also be the case with negative fixed taxes. 3. Negative fixed taxes should have a ChargeAllowanceReasonCode that is in the AllowanceReasonCode list. opw-5955289 Forward-Port-Of: odoo/odoo#255259 Forward-Port-Of: odoo/odoo#252716
This update resolves an issue where the XML generated for Swiss payments (iso20022_ch) was using an outdated payment schema. The fix ensures the XML conforms to the required standards, improving payment processing accuracy and compliance with Swiss banking regulations. It also includes enhancements for validator schema and QR-IBAN handling.
Original PR description
**PROBLEM** According to documentation (https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps-2025-en.pdf) PstlAdr must be structured. This isn't the case when generating a xml for the payment method iso20022_ch. **STEP TO REPRODUCE** 1. install l10n_ch and account_iso20022. 2. Create a swiss contact with a full address. And activate payment on the bank account of this contact. 3. Select the Company CH, and set a bank account in the bank journal configuration. 4. Create a vendor payment to the swiss contact. 5. Create a batch payment with it, and validate to get the xml. 6. Open the xml, and notice the PstlAdr isn't structured. Ticket [link](https://www.odoo.com/odoo/project.task/5880247) opw-5880247 Forward-Port-Of: odoo/enterprise#111158 Forward-Port-Of: odoo/enterprise#107025
This update resolves an issue where removed fields from the website contact form were still appearing in the associated project tasks. The change ensures that unset data is no longer displayed, providing a cleaner and more consistent task view for users. This was caused by a recent update to how partner data was added to task descriptions.
Original PR description
# How to reproduce - Add a contact form to your website - Make it so the contact form creates a task on submit - Remove some field from the contact form, but no the email (ex: Phone) - Fill in the contact form; the email must be from one of the existing partners - Submit the form and go look at the task in the project application # The problem The fields removed from the form are still present in the task's description (ex: partner_phone: False) # Why This commit (https://github.com/odoo/odoo/commit/7d0660e034f3be1b92869c266dc2cfb0bc6b6941) changed the way the partner's data was added to the description. When adding that data, it does not check if it exists before hand and instead adds a default value if not found. opw-5920816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252848
This update fixes an issue where configuring PEPPOL document syncing incorrectly directed users to a document form instead of the intended Kanban view. The change ensures users are presented with the correct Kanban view when setting up PEPPOL document synchronization, streamlining the configuration process. This improves usability and efficiency.
Original PR description
Before this commit: clicking through on the setting of configuring the folder to sync peppol documents would lead to the document form view instead of the kanban view. Task-6040802 Forward-Port-Of: odoo/enterprise#111712 Forward-Port-Of: odoo/enterprise#111341
This update fixes an issue where currency rates for Bulgaria were incorrectly calculated after the country switched to the Euro. The system was using reversed rates from the XML data, leading to inaccurate unit conversions. This change ensures correct currency calculations for Bulgarian transactions.
Original PR description
Issue: after Bulgaria switched to EUR, currency rate fetching from BNB was incorrectly set to still use reversed currency rates from the fetched XML, resulting in unit-to-EUR and EUR-to-unit rates being flipped in the database. Solution: adjusting the parser to get rate from 'RATE' rather than 'REVERSERATE', as the XML provides both. task-6050519 Forward-Port-Of: odoo/enterprise#111275
This update resolves an issue where users without sales permissions were encountering an error when viewing product information. The fix allows all users to access product subscription pricing data by bypassing access restrictions within the product view calculation. This ensures a smoother experience for all users.
Original PR description
Steps to reproduce: - Install sale_subscription. - Create a user with access to products but no access to Sales (e.g., base.group_user). - Log in as that user and open the Products Kanban or Form view. Observation: An Access Error is raised preventing the user from viewing the products. Cause: The UI evaluates fields and view modifiers (like invisible attributes) referencing restricted data. Since product_subscription_pricing_ids is restricted to Sales groups, non-sales users trigger an Access Error when the view or the compute method attempts to read it. Solution: n the _compute_display_subscription_pricing method, use .sudo() when accessing product_subscription_pricing_ids. This ensures that the display string can be computed for all users (including those without Sales access) by bypassing the access restrictions on the underlying pricing records. opw-5934036 Forward-Port-Of: odoo/enterprise#108265
This update resolves a problem where invoices with discounts and decimal values (over 2 decimals) were failing to send to ARCA. The fix uses a truncated unit price for discount calculations, ensuring accurate decimal handling and successful invoice transmission. This prevents errors related to discrepancies in decimal precision.
Original PR description
After changes made in Odoo of how the decimal precision works some of the code we use to prepare the data to create EDI invoices now fails. We already adapt the code to fix the data depending of the expected webserive format but we miss a case related to when invovice has discounts. The problem is that any invoice with lines that has more than 2 decimals and also have a discount will fail when trying send it to ARCA because the computed amount has differences in the decimals. Now we use the truncated unit price to compute the discount instead of the full amount with decimal of the `line.price_unit` value. Forward-Port-Of: odoo/enterprise#110706
14 changes
Resolved issues and error corrections
This update fixes an issue where the SDWorx payroll report wasn't correctly accounting for public holidays. The change ensures that employee attendance is accurately calculated, including days when the company is closed for public holidays, leading to more precise payroll reporting.
Original PR description
### Steps to reproduce: - Setup a public holiday in a month January for example - Add a leave for an employee for the whole Month of January - Export the SDworx report - Notice for the day of the public holiday, it is shown as a normal attendance ### Cause: When checking leaves for the SDWorx report we only check hr.leave we don't check resource.calendar.leaves ### Fix: We take resource.calendar.leaves now into account to make sure we add public holidays to the report when exporting it opw-5500070 Forward-Port-Of: odoo/enterprise#106065
This update fixes a problem where Mexican CFDI invoices generated by our system were missing a crucial piece of information – the ‘numero pediemento’ (import document number). The fix ensures that all CFDI invoices comply with Mexican tax regulations, preventing potential issues with tax authorities. This improves the accuracy and reliability of our invoicing process for Mexican businesses.
Original PR description
The numero pediemento is missing in invoices CFDI Step to reproduce: - in MX company with l10n_mx_edi_landing - create an invoice - add product with a custom number (with 2 spaces between number ranges) - Confirm and send The generated CFDI is missing the `InformacionAduanera` node and its `NumeroPedimento` attribute. Cause: Node and attribute are filled in the CFDI from the 'complementos_list'. Which is a copy of each base_line 'l10n_mx_cfdi_values'. The list was missing the `informacion_aduanera_list`. opw-5949684 Forward-Port-Of: odoo/enterprise#110347
This update fixes an issue where currency rates from the Bulgarian National Bank (BNB) were incorrectly processed, leading to reversed unit-to-EUR and EUR-to-unit calculations. The change adjusts the data parsing process to accurately use the standard 'RATE' value from the XML feed, ensuring correct currency conversions for Bulgarian operations.
Original PR description
Issue: after Bulgaria switched to EUR, currency rate fetching from BNB was incorrectly set to still use reversed currency rates from the fetched XML, resulting in unit-to-EUR and EUR-to-unit rates being flipped in the database. Solution: adjusting the parser to get rate from 'RATE' rather than 'REVERSERATE', as the XML provides both. task-6050519 Forward-Port-Of: odoo/enterprise#111275
This update fixes an issue where configuring PEPPOL document sync settings incorrectly directed users to a document form instead of the intended Kanban view. Now, users will correctly see the document Kanban view when setting up PEPPOL document synchronization, streamlining the configuration process. This ensures a smoother and more intuitive experience for managing PEPPOL documents.
Original PR description
Before this commit: clicking through on the setting of configuring the folder to sync peppol documents would lead to the document form view instead of the kanban view. Task-6040802 Forward-Port-Of: odoo/enterprise#111341
This update corrects a validation error in the Romanian SAFT reports generated by Odoo. The team restored a key data element and used a sanitized bank account number to ensure compliance with Romanian tax regulations and prevent report rejection.
Original PR description
Problem --------- In odoo/odoo#184131 and odoo/enterprise#72206, UOM's categories where removed. Along side the removal, the Description tag in the Romanian SAFT UOM table tag. However, without this node, the SAFT is flagged as invalid by validator in Romanian. Furthermore, in the RO SAF-T, we use the bank account number and not the sanitized one, which may lead to some spaces in the document. Spaces that are not accepted either. Solution --------- Add back the Description node and use the UOM name instead of category. Use the sanitized account number. opw-5956277
This update fixes a misunderstanding regarding the W4 form filing date in the US payroll system. The change clarifies that the field represents the date the W4 is submitted to the employer, not the date it's initially completed by the employee. This ensures accurate payroll calculations and compliance.
Original PR description
This field is about when the W4 is filed with the employer, not when it's filled in. opw-5096780 Forward-Port-Of: odoo/enterprise#111213
This update fixes an issue in Web Studio where invisible fields weren't consistently hidden based on user access. Previously, toggling the 'Show Invisible Elements' checkbox didn't always retain the intended invisibility settings. The fix ensures that invisible fields remain hidden when the user lacks access, improving the user experience and data consistency within the studio.
Original PR description
Steps to reproduce ================== - Install contacts,web_studio - Login as admin - Go to contacts - Open any record - Open studio - Click on any field - Add the "Role / Portal" group - Toggle the…
Steps to reproduce ================== - Install contacts,web_studio - Login as admin - Go to contacts - Open any record - Open studio - Click on any field - Add the "Role / Portal" group - Toggle the "Show invisible Elements" checkbox - Click on the same field => The field is marked as invisible - Add an invisible condition => The invisible condition is lost (but still applied on the view) Cause of the issue ================== In studio, when fetching the view, the invisible attribute is set to True when the user does not have access to the field (when he is not part of the groups). The goal is to make the field invisible in studio unless the "Show invisible Elements" is toggled. But this causes the actual value of the invisible attribute to be lost. Note that this also applies to the column_invisible attribute. Solution ======== If an invisible/column_invisible attribute is present on the nodes with missing access, we copy the actual value to the `actual_invisible` attribute. We then use that value in the editor, when present. opw-6026971 Forward-Port-Of: odoo/enterprise#111299
This update loosens restrictions on creating leave for employees with Swiss payroll, allowing for more flexible leave management. Specifically, it now permits leave creation even when payroll impacts are present, provided certain percentage conditions are met, ensuring accurate leave tracking within the Swiss payroll system. This change improves usability and reduces potential disruptions for HR teams.
Original PR description
Currently we block leave creation if the employee has a validated payslip in that period. In this commit we relax the constraint in the following way, we will allow to put the leave if: - `l10n_ch_swissdec_payroll_impact` is False - `l10n_ch_continued_pay_percentage` and `l10n_ch_disability_percentage` are BOTH 100% if `l10n_ch_swissdec_payroll_impact` is True - `l10n_ch_swissdec_work_interruption` cannot be True in both cases task-5948505 Forward-Port-Of: odoo/enterprise#107847
This update fixes a reporting issue where the KMD INF report incorrectly included partners with low turnover. Now, the report accurately filters partners based on a €1,000 turnover threshold, considering both invoices and credit notes. This ensures more reliable financial reporting.
Original PR description
The KMD INF report should only include partners whose total turnover for the period reaches 1,000 EUR. Before this PR: - The report did not check this threshold, so partners below €1,000 were still shown. After this PR: - The threshold is now calculated correctly based on specific rules: - The threshold is calculated separately for invoices and credit notes per partner. - If invoices total base amount >= €1,000 OR credit notes total base amount >= €1,000, both invoices and credit notes are included in the report - The same logic applies to bills and refunds in Part B. task-5373606 Forward-Port-Of: odoo/enterprise#111503 Forward-Port-Of: odoo/enterprise#101333
This update ensures that document creation times are displayed accurately for users, regardless of their location. Previously, times were inconsistent due to a failure to convert dates from UTC to the user's local timezone. Now, all times are correctly formatted for each user, improving data accuracy and user experience.
Original PR description
Step to reproduce: 1. Install `documents` 2. Upload a document and open the tree view 3. Compare the field `Created On` and the time from the `Manage Versions` action Issue: - The displayed time is inconsistent between the tree view and the dialog Cause: - The datetime used in Manage Versions is formatted without converting it from UTC to the user’s timezone Solution: - Use timezone-aware datetime helpers so values are converted from UTC to the user’s timezone. Before: <img width="1328" height="81" alt="image" src="https://github.com/user-attachments/assets/2a02f03c-714d-417d-a805-fd0dd7c52753" /> <img width="636" height="297" alt="image" src="https://github.com/user-attachments/assets/c4514469-2f51-493f-8991-32371fb7f338" /> After: <img width="641" height="312" alt="image" src="https://github.com/user-attachments/assets/3979ece8-635a-4b54-9b53-d8b28b3336ec" /> opw-5467782 Forward-Port-Of: odoo/enterprise#104443
This update prevents the entire reporting cron process from stopping if a single report export fails. Previously, an error would halt all subsequent exports. Now, the cron will continue to attempt sending other reports, improving reliability and ensuring timely report delivery.
Original PR description
If an error is raised during the export of reports cron execution, the whole cron stops due to the fact that the error is never catched This commit will ensure that even if there is an error with one of the report export, the cron won't top and will try to send to other documents task-5469038 Forward-Port-Of: odoo/enterprise#111602 Forward-Port-Of: odoo/enterprise#105191
This update resolves an issue where users without sales permissions were encountering errors when viewing product information within the Odoo interface. The fix allows all users to access product subscription pricing data by bypassing access restrictions, ensuring a smoother experience for all users regardless of their role.
Original PR description
Steps to reproduce: - Install sale_subscription. - Create a user with access to products but no access to Sales (e.g., base.group_user). - Log in as that user and open the Products Kanban or Form view. Observation: An Access Error is raised preventing the user from viewing the products. Cause: The UI evaluates fields and view modifiers (like invisible attributes) referencing restricted data. Since product_subscription_pricing_ids is restricted to Sales groups, non-sales users trigger an Access Error when the view or the compute method attempts to read it. Solution: n the _compute_display_subscription_pricing method, use .sudo() when accessing product_subscription_pricing_ids. This ensures that the display string can be computed for all users (including those without Sales access) by bypassing the access restrictions on the underlying pricing records. opw-5934036 Forward-Port-Of: odoo/enterprise#108265
This update resolves an issue preventing invoices with discounts and decimal values (over 2 decimals) from being correctly generated for ARCA. The fix uses a truncated unit price for discount calculations, ensuring accurate decimal handling and successful EDI invoice creation.
Original PR description
After changes made in Odoo of how the decimal precision works some of the code we use to prepare the data to create EDI invoices now fails. We already adapt the code to fix the data depending of the expected webserive format but we miss a case related to when invovice has discounts. The problem is that any invoice with lines that has more than 2 decimals and also have a discount will fail when trying send it to ARCA because the computed amount has differences in the decimals. Now we use the truncated unit price to compute the discount instead of the full amount with decimal of the `line.price_unit` value. Forward-Port-Of: odoo/enterprise#110706
This update corrects a small, technical issue with a message displayed within the documents generated for employee payroll. The fix ensures consistent and accurate reporting of payroll information. This change improves the overall quality and reliability of the payroll documentation.
Original PR description
Task#5980045 Forward-Port-Of: odoo/enterprise#109063
42 changes
Resolved issues and error corrections
This update resolves a technical issue related to how geographic data (specifically topoJSON) is processed within the Enterprise edition of Odoo. The fix ensures that charts displaying location-based information are now rendered correctly, improving the accuracy and reliability of these reports. This primarily impacts users relying on charts that visualize data by region or location.
Original PR description
test adaptation Counterpart of github.com/odoo/odoo/pull/248847 Task-5224009 Forward-Port-Of: odoo/enterprise#107912
This update disables the automatic refresh of GST tokens for the Russian localization (l10n_in_reports) module. Previously, tokens refreshed every 5 hours, but now they are permanently disabled. Manual triggering of the refresh process is now required, ensuring compliance with current regulations.
Original PR description
With this PR, the GST token refresh cron interval is updated from 5 hours to 9999 months to effectively disable automatic execution. The cron will instead be triggered manually from `validate_otp` and `_cron_refresh_gst_token` based on the token expiration time. Forward-Port-Of: odoo/enterprise#109937
This update resolves an issue where default values weren't consistently applied to VoIP call records. By reverting to a method that triggers Odoo's retry mechanism on unique constraint violations, the system now reliably handles potential errors and ensures data integrity. This improves the overall stability of the VoIP functionality.
Original PR description
Since 2d406b71cf17d91baa30070899515f22f5ec3222, voip.call records are created using a raw SQL query rather than the ORM. This has the side effect of not applying the default values. The main reason it was done with a raw SQL query was to be able to leverage Odoo default retry mechanism on unique constraint violation, since `UniqueViolation` exception doesn't normally trigger a retry. This commit reverts the approach to using the ORM, and raises a `ConcurrencyError` on `UniqueViolation`. The `ConcurrencyError` triggers the retry mechanism, allowing for the same behavior as the raw SQL query, while keeping the ORM features (e.g. default values). [Task-6036473](https://www.odoo.com/odoo/project/5778/tasks/6036473) Forward-Port-Of: odoo/enterprise#111104
This update resolves a visual issue where the map view in the "My Dashboard" sometimes collapsed. The fix removes conflicting height settings and adds a minimum height to the map, ensuring it always displays correctly regardless of the number of records shown.
Original PR description
This commit fixes rendering height issues when the map view is displayed inside "My Dashboard". * Removed `height: 100%` from the map and pin list containers. This conflicting rule interfered with the flexbox layout, often causing the map to collapse entirely since it couldn't compute its own height. * Added a `min-height` to the map renderer. This ensures the map always occupies a reasonable amount of space in the dashboard, even when there are few or no records to display. task-6022958 Forward-Port-Of: odoo/enterprise#111195 Forward-Port-Of: odoo/enterprise#110790
This update resolves a problem where tours on the website sale subscription pages weren't loading translations correctly, particularly with newer Chrome versions. The fix introduces a temporary step to ensure translations start loading promptly, preventing delays and interruptions in the tour experience. This ensures consistent and accurate tour guidance for users.
Original PR description
This commit adds an intermediary step ensuring the proper page has been reached before actually doing the checks and avoiding to let startup requests (like the loading of the translations) pending at the end of the tour (and the eventual stop of the runner browser). Note: this is most likely due to a timing (indeterministic by nature) change, emphasised by recent Chrome versions (like v145). runbot-239128 Forward-Port-Of: odoo/enterprise#111013 Forward-Port-Of: odoo/enterprise#110648
This update corrects an issue where incorrect folio numbering occurred when a Customer Fiscal Account (CAF) wasn't set up. The fix ensures that folios are generated correctly, avoiding negative numbering and preventing performance issues related to repeated sequence searches. This improves data accuracy and stability for Chilean accounting.
Original PR description
`l10n_cl_edi` overrides `account.move._get_last_sequence()` to ensure the folio belongs to an available in-use CAF. When no CAF exists at all, `l10n_latam.document.type._get_start_number()` returns 0 and the fallback builds a previous sequence using start_nb - 1. Formatting -1 as `:06d` yields “-00001”, which then propagates to “FAC -00002”, “-00003” and corrupts the sequence chain. In addition, returning an invalid “last sequence” may force `sequence.mixin` to search for a free number under the UNIQUE constraint by retrying increments inside a savepoint and rolling back on UniqueViolation, which is costly when many values are already taken see [ _locked_increment()](https://github.com/odoo/odoo/blob/18.0/addons/account/models/sequence_mixin.py#L352). Now we only reset to the CAF start when an in-use CAF actually exists (start_nb > 0). opw-5918758 Forward-Port-Of: odoo/enterprise#108909
This update allows superuser administrators to unlink existing salary rules and parameters within the HR Payroll module. This provides greater flexibility for managing payroll configurations and resolving potential conflicts. Previously, this action was restricted, creating a bottleneck for administrators needing to adjust payroll settings.
This update corrects a visual discrepancy between the AI live chat snippet editor and its actual display on the website. The fix ensures that the AI snippet appears correctly across different devices and configurations, resolving a rendering issue. This improves the user experience and consistency of the AI live chat feature.
Original PR description
Scenario: - add ai livechat snippet block - switch to mobile - enable "Fallback Button" - save Result: the rendering is different between edition and real usage of AI livechat snippet. Cause: structure and classes don't match Fix: make the structure and classes match. opw-5458575 pr note: I copied `ai_website_livechat.AILivechatComponent` in `ai_website_livechat.s_ai_livechat_edit` but it might make more sense to just render the owl widget with a class that neuter the AI (this way we don't need to update both template at each change) Forward-Port-Of: odoo/enterprise#109569
This update resolves a common error (code 9004) users experience when using the Instagram integration in Odoo. The changes provide clear guidance to help users quickly identify and troubleshoot network or file-related issues, reducing support requests. This improves the overall stability and usability of the Instagram module.
Original PR description
Purpose ======= Explain the possible errors for the code 9004, to help users debugging their Odoo servers without creating a ticket. Task-5972197 Forward-Port-Of: odoo/enterprise#110571 Forward-Port-Of: odoo/enterprise#109319
This update fixes an issue where project timesheets didn't accurately reflect changes in employee assignments on manufacturing orders. The fix automatically updates the AAL (analytic accounting line) associated with the work center when an employee is switched, ensuring accurate time tracking and reporting. This improves the reliability of project cost data.
Original PR description
### Steps to reproduce: - Create an MTO product and another Service product that create a project and task - Create a quotation with both products - Create two employees with different hourly cost - Go to Manufacturing order - Configure an employee to manufacture the product at a work station. - Observe the project dashboard - Go back to the MO and change the employee on the work station - Notice the project dashboard Timesheets section doesn't have any change on the amount ### Cause: This is happening because when changing the employee we don't modify anything in the AAL linked to the work station. As we only modify the AAL when the duration change. ### Fix: We call _create_analytic_entry when we change the employee on the work station to change the amount and the employee_id for the AAL. opw-5939321 Forward-Port-Of: odoo/enterprise#111040 Forward-Port-Of: odoo/enterprise#109695
This update fixes an issue where portal users weren't able to view timesheets linked to projects with 'Invited internal and portal users' visibility. The change expanded the timesheet domain to include both 'portal' and 'invited_users' visibility options, ensuring portal users can access timesheets as intended.
Original PR description
Steps to reproduce: - Create Project A with visibility set to `Invited internal and portal users.` - Create a Helpdesk Team and assign Project A to it. - Create a helpdesk ticket. - Log a timesheet…
Steps to reproduce:
- Create Project A with visibility set to `Invited internal and portal users.`
- Create a Helpdesk Team and assign Project A to it.
- Create a helpdesk ticket.
- Log a timesheet on the ticket and share the ticket with the portal user.
- Log in as the portal user and check the timesheet.
- Observe that the timesheet is not visible to the portal user.
Cause:
- After introducing the `invited_users` option in `privacy_visibility`, the portal domain in `_timesheet_in_helpdesk_get_portal_domain` was not updated.
- The domain was still defined as: `('project_id.privacy_visibility', '=', 'portal')`
- As a result, timesheets linked to projects with visibility set to “Invited internal and portal users” were excluded from the portal user’s view.
Solution
Update the domain to include both visibility options: `('project_id.privacy_visibility', 'in', ['portal', 'invited_users'])`
- This ensures timesheets are visible to portal users when the project visibility is either portal or invited_users.
task-5924243
Forward-Port-Of: odoo/enterprise#111548
Forward-Port-Of: odoo/enterprise#107800This update resolves a potential error in the bank statement import process for Odoo Enterprise when handling multiple journals with different currencies. The fix prevents a 'singleton error' by streamlining the data retrieval process, focusing only on the necessary IBAN and currency information.
Original PR description
When having multiple journals with the same IBAN, but different currencies, we could have a singleton error if they are not all configured the same (besides the currency). This happens in the cron that fetches new CODAs as we first fetch all CODAs. Then, for each, we have to dispatch it in the right journal. To do so, we rely on `_parse_bank_statement_file` which is called on `self`, which itself calls `_get_coda_final_statements` that triggers the singleton error. However, at this point, we don't care about calling `_get_coda_final_statements` since we only want to retrieve the IBAN and the currency of the CODA, we don't care about the other details. Thus, the solution here is to ignore this call if we don't need it while just retrieveing the necessary info to match a journal before even creating the statements. opw-5723017 opw-6036909 Forward-Port-Of: odoo/enterprise#111560 Forward-Port-Of: odoo/enterprise#111101
This update corrects a problem where the calculation of employee appraisal dates was unreliable. The fix ensures appraisal dates are correctly determined based on company settings related to appraisal plans. This improves the accuracy of appraisal scheduling within the system.
Original PR description
Issue: The computation of the next appraisal date for employees depends on setting the appraisal plan for a company or changing the company's settings for `duration_after_recruitment`, `duration_first_appraisal`, `duration_next_appraisal`. Fix: Moving the test employee creation after configuration of the company settings for the appraisal plan. task-6050719 Forward-Port-Of: odoo/enterprise#111345 Forward-Port-Of: odoo/enterprise#111265
This update ensures the 'To-Do' feature within the project management system functions reliably. Previously, uninstalling the 'To-Do' module could cause issues, but this change guarantees the necessary components are installed, preventing unexpected problems and improving user experience.
Original PR description
This commit backports the `project_enterprise_hr_todo` bridge module that ensures that `project-todo` is correctly installed in order to use the todo mail alias feature. Before, this requirement was not enforced so anyone uninstalling To-Do could experience some issue, as the feature would still be part the `project_enterprise_hr` module, even without `project_todo` installed. Forward-Port-Of: odoo/enterprise#110593 Forward-Port-Of: odoo/enterprise#109194
This update fixes a technical error that occurred when users tried to take pictures without an IoT device connected to a quality control point. The fix prevents a system crash and guides users to properly set up the IoT device before proceeding, ensuring a smoother workflow.
Original PR description
Currently, an error occurs when the user clicks the Take Picture button without an IoT box set on the quality control point. ## Steps to replicate: - Install Quality, Purchase, IoT - Quality >…
Currently, an error occurs when the user clicks the Take Picture button without an IoT box set on the quality control point. ## Steps to replicate: - Install Quality, Purchase, IoT - Quality > Quality Control > Control points - Create a new Control point with - Type: Take A Picture - Operations: My Company: Receipts - Create and confirm a purchase order for a test product - Receipts > Quality Checks > Take A picture ## Observed behavior: TypeError: Cannot read properties of undefined (reading '0') ## Root cause: This error occurs because no device has been set on the control point. When the user clicks the **Take a Picture** button, the `onClick` method [1] is triggered. Since `this.iotDevice` is false, both `iotBoxId` and `deviceIdentifier` are undefined. These undefined values are then passed to the action function [2], which in turn passes them to the `_attemptFallbacks` function. At [3], a type error occurs because the system tries to index `iotBoxId` even though it is undefined. [1]: https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/quality_iot/static/src/iot_picture_button.js#L7-L17 [2]: https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/iot/static/src/network_utils/iot_http_service.js#L213-L236 [3]: https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/iot/static/src/network_utils/iot_http_service.js#L149-L152 [4]: https://github.com/odoo/enterprise/blob/1d25675de808521dc8ad8c56bc9fbd320a0ae56b/quality_iot/static/src/iot_measure_button.js#L27-L32 ## Solution: Add a check for an unset device and notify the user to add a device to the quality point. This prevents a traceback and clearly informs the user about the issue. Similar to how it was done in [4] opw-6010095 Forward-Port-Of: odoo/enterprise#110615
This update resolves an error that prevented users from filtering products by date on the rental shop page. The fix adjusts how the system handles related resources to correctly process date-based searches. This ensures accurate product listings and a smoother user experience for rental bookings.
Original PR description
Currently, an error occurs when searching by date on the shop page. **Steps to Reproduce:** - Install the `website_sale_renting_planning` module. - Go to `Products` and create a product with the…
Currently, an error occurs when searching by date on the shop page. **Steps to Reproduce:** - Install the `website_sale_renting_planning` module. - Go to `Products` and create a product with the following configuration: - `Type`: `Service` - Under the `Sales` tab, set the `Periodicity` value. - Go to `Planning` > `Configuration` > `Roles` and switch to `Kanban` view. - Create a record by adding a `Resource` and the `service` product. - Enable `Sync Shifts and Rental Orders` in this role. - Go to `Website` > `Shop`. - Click `Edit` > `Style` > enable `Rental` by selecting it in the `toolbar`, then `save`. - Set the `start date` and `end date` and `apply` the filter. **Error1:** `ValueError: Invalid field 'resource_id' on model 'planning.slot' for 'resource_id:recordset'.` **Error2:** ` File "/home/odoo/odoo18/community/addons/resource/models/resource_calendar.py", line 455, in _leave_intervals_batch for _, resources in resources_per_tz.items():` `AttributeError: 'resource.resource' object has no attribute 'items'` This error occurs because after this [recent commit], the field `resource_id` was replaced by `resource_ids` with a M2M relation. When the user searches by date, the system attempts to group planning slots by `resource_id`, which raises the error[1]. After this [new commit], _leave_intervals_batch expects resources grouped by timezone, but here only resources are passed [2], which raises the error [3]. This commit ensures that `search_fetch` is used to retrieve `resource_ids`, since `read_group` cannot group records by M2M fields. It also ensures that resources with their timezone are correctly passed to _leave_intervals_batch. [recent commit]: https://github.com/odoo/enterprise/commit/fbf8b2ac67c71ca0abfc75df543069696bd2d29b [new commit]: https://github.com/odoo/odoo/commit/2dff65ab8b5a9db21d5b476065a72755cc4625be#diff-11ecbc9f00711187e60b88f84c618046bb24ada8c39cb29037568c1aa46f06a5 [1]: https://github.com/odoo/enterprise/blob/288c7d9c1f29746e0abe0338801621c033a2280c/website_sale_renting_planning/models/product_template.py#L30 [2]: https://github.com/odoo/enterprise/blob/288c7d9c1f29746e0abe0338801621c033a2280c/website_sale_renting_planning/models/product_template.py#L50 [3]: https://github.com/odoo/odoo/blob/9e41753a14c7398927445d8dc8f69dc57047b0b6/addons/resource/models/resource_calendar.py#L453 sentry-7325252044 Forward-Port-Of: odoo/enterprise#110306
This update automatically adds missing rows to pivot tables when a group by field causes the layout to shift, preventing errors. Previously, users would encounter confusing '#SPILL' errors and revert changes. Now, the system intelligently adjusts the layout and displays a clear error message if needed, improving usability.
Original PR description
When you update a pivot and you add a group by such that the pivot no longer fits in the available space, the formula becomes a #SPILL error. Users tend to think they messed up something and revert the change. They probably don't know they can hover the cell to see the error message. With this commit, missing headers are automatically added up to a reasonable amount. If it's above the threshold, it opens the error message to make it obvious. task-6023969
This update resolves a warning message appearing during time off processing. The fix removes a redundant check for blocked payslips related to leave, preventing the warning from triggering. This ensures smoother and more reliable time off calculations.
Original PR description
. Remove the check for blocked payslips corresponding to the leave to avoid triggering the warning. task-6044925
This update resolves an issue preventing the successful installation of the Helpdesk Stock module when auto-installation is skipped. The fix ensures that the necessary Sale Stock module is installed, allowing users to correctly utilize Helpdesk Stock's features. This improves the overall stability and usability of the Enterprise suite.
Original PR description
This commit fixes the error when installing helpdesk_stock with auto_install skipped which prevents the module `sale_stock` from being installed. The error is introduced by this PR: https://github.com/odoo/enterprise/pull/103051 To reproduce: install the module with `--skip-auto-install`. The fix: Change the module dependencies to include `sale_stock` to be able to access `sale_order.picking_ids` Runbot error links: https://runbot.odoo.com/odoo/error/242083
This update fixes an error in the reports generated for sales in Ecuador (l10n_ec_reports_ats). The system now correctly identifies foreign partners ('partner_ext') using the appropriate tax identifier ('02') based on their company status, aligning with AFIP requirements. This ensures accurate reporting and compliance for export sales transactions.
Original PR description
Since `tipoCliente` is now determined using the computed `is_company` field, the test data must reflect this logic. `partner_ext` represents a foreign partner and is considered a company, therefore its `tipoCliente` should be set to '02'. See: https://github.com/odoo/enterprise/commit/a779badac35cf4a8f483f490e8ae29eb6bf3d2c5 `l10n_ar_edi`: For foreign partners, AFIP requires the CUIT pais based on the partner’s country and document type, not on partner.is_company. In multi-localization databases, is_company may be influenced by local heuristics and lead to picking the wrong foreign tax identifier. Use the identification type instead: VAT documents map to the legal-entity CUIT pais, while non-VAT documents map to the natural-person one. See: https://github.com/odoo/enterprise/pull/86089#discussion_r2128977870 runbot-241126 Forward-Port-Of: odoo/enterprise#110055
This update fixes an issue where the 281.50 PDF report occasionally generated an extra page due to formatting. The change optimizes the report layout to ensure it consistently uses only one page for standard reports, improving readability and reducing unnecessary PDF file sizes. This primarily impacts reports for Belgian companies.
Original PR description
**Behavior:** Currently when generating the 281.50 report the pdf ends up taking an extra page filled only with header and footer, the page appears when creating the report for a natural person and…
**Behavior:** Currently when generating the 281.50 report the pdf ends up taking an extra page filled only with header and footer, the page appears when creating the report for a natural person and adding a national number. The solution is not to fully prevent the report form being more than 1 page long, as some informations could span over more than one line which would make the pdf need an extra page. But to shave a few milimeters so that by default when filled with standard informations the pdf appears cleaner. **Steps to reproduce:** - Log to a Belgian company - Create a contact that is a person - Add the 281.50 tag to them - Create a credit note for any positive amount for that person and set the date to the previous year - Make sure the account used in the credit note has any 281.50 x tag assigned - Go to Accounting/Reporting/Open 325 forms and create a new form for the year indicated in the credit note - When generating the 281.50 PDF you'll seee it span over 2 pages if you have filled the national number of the contact opw-5930339 Forward-Port-Of: odoo/enterprise#111310
This update fixes a potential issue where the Gemini AI feature would sometimes return empty responses to users, creating a confusing 'no reply' experience. The fix automatically retries the request with a slightly increased budget and, after three failed attempts, gracefully informs the user of the failure. This ensures a more reliable and consistent AI experience.
Original PR description
It often occurs that gemini responses come back empty without anything to show to the users. Specifically, the response object has content but the "parts" are empty - the place were you either get a…
It often occurs that gemini responses come back empty without anything to show to the users. Specifically, the response object has content but the "parts" are empty - the place were you either get a function call or a message to the user by the LLM. Prior to this commit, when this occured, we didn't perform any explicit handling. We would always just return what the LLM responded with, which when empty would be nothing. UX wise, it would seem like something broke because the user would basically get no reply. In this commit, we add a retry mechanism in `_request_llm_google` of `llm_api_service.py`, where if we get no response, we increase the thinking budget of the next request to 512 and try again. 512 tokens were chosen completely arbitrarily - anecdotally, the model should use around 300 thinking tokens for its tasks so 512 should be enough. After 3 unsuccessful tries, we send a failure response to the user. Task-5959805 Forward-Port-Of: odoo/enterprise#111228 Forward-Port-Of: odoo/enterprise#108755
This update resolves an issue where the 'Appraisal' survey type was not appearing as an option when creating a new survey. The fix replaces a technical code change to ensure the correct survey type selection is available, improving the user experience for creating appraisal surveys.
Original PR description
How to reproduce: - install hr_appraisal_survey - log in as admin and create a new survey The selection for "Appraisal" survey type is missing in the survey form. We solve the issue by replacing the "append" in the compute method by an affectation. Task-6009719
This update resolves a performance issue related to reading large spreadsheets in Odoo. Previously, Odoo used base64 encoding/decoding, which slowed down processing. Now, the system can directly read the spreadsheet data, resulting in a significant performance improvement.
Original PR description
We used to read from the attachment linked to the `spreadsheet_snapshot` binary field to avoid useless base64 encode/decode. On large spreadsheets, it would have a significant impact on performance. However, since odoo/odoo@41fe2ebdb9cc37341362d7af829c087a5f72f9f1, the orm no longer use base64 internally. We can now directly read the field. Task-6055190
This pull request addresses a minor typo and improves the user interface of the Odoo Enterprise payroll module. Specifically, a corrected spelling and updated styling (using `<label>` instead of `<span>`) were implemented to ensure consistency and a better user experience. The changes also included alignment adjustments for a distance input field.
Original PR description
- Correct typo "reimboursed" -> "reimbursed" - Replace `<span>` labels by `<label>` to match style (bold, arrow cursor) - Add narrow field class to distance input so that it is aligned with the field bellow Task: 5952495
This update simplifies the calendar event interface by removing a redundant button and optimizing its layout. The change addresses a recent update to the calendar event form, streamlining the user experience and improving efficiency. This ensures a cleaner and more intuitive way to manage calendar events.
Original PR description
Removing smart button as new field: `res_record` is added in the form view of calendar event. Also, changing the location of `action_view_sale_order` Task-5106718
This update resolves an issue where only administrators could delete salary rules within the payroll module. Now, superusers (with appropriate permissions) have the ability to remove outdated or incorrect salary rules, improving payroll management flexibility. This change enhances administrative control over payroll configurations.
This update ensures invoices accurately reflect subscription end dates, especially when they fall mid-period. It automatically prorates charges for products with prorated pricing, preventing overbilling and improving customer billing accuracy. This resolves a previous issue where subscriptions were billed for the full period regardless of the end date.
Original PR description
Before: - Invoicing ignored the subscription end date when it occurred within an invoiced period. Customers were billed for the full period even if the subscription ended earlier. After: - Invoicing period now ends at the subscription end date when it falls within the billing cycle. Invoice amounts are prorated when the product is configured for prorated pricing. Task-5870935
This update fixes an issue where the PayRun interface wasn't displaying correctly on resized windows, causing information to disappear from the user interface. The changes ensure that all PayRun details are consistently visible and accessible, regardless of screen size, improving usability.
Original PR description
**Description:** In the new payrun flow (https://www.odoo.com/odoo/project/1251/tasks/5362147) If you resize the window, the title is not well displayed and depending on the size, some information disapear event for the kanban cards without informations: Title issue Status bubble invisible: First button invisible (all in the dropdown): **Iplementation:** . Update payrun_card & payrun_button_box views to adapt window resizing task-5955169
This update optimizes the calculation of payroll figures by limiting the scope of certain computations to currently active payslips. This change prevents unnecessary processing of older, closed payslips, improving system performance and reducing potential data inconsistencies. It addresses a previous issue that could have impacted a large number of records.
Original PR description
Before this commit, `_compute_basic_net` was not limited to specific payslips, potentially affecting thousands of records and even more of `hr.payslip.line` records. This commit restricts the compute to ongoing payslips. task-6022499 Forward-Port-Of: odoo/enterprise#111437 Forward-Port-Of: odoo/enterprise#110069
This update corrects a technical issue impacting UK top-up payments. The system previously used incorrect country data due to a change in the UK account payload structure. This change ensures accurate top-up processing for UK customers, resolving a potential payment disruption.
Original PR description
Fix the UK top-up logic as UK accounts payload structure shifts from the EU where the country data is located in the EU payload it could be found under bank_transfer[financial_adresses][0][iban][country] and bank_transfer[country] but in the uk payload it can only be found in the second As we used the first one, we are now switching it to the second as it's the only common ground Forward-Port-Of: odoo/enterprise#111588
This update resolves an issue where employee document filenames were incorrectly displayed as file sizes instead of the actual document names. The fix ensures that the correct document filename is shown when uploading files to the employee's personal information, improving data accuracy and usability. This was a minor bug fix related to the Payroll module.
Original PR description
Steps to reproduce: ---------------------------------- 1. Install Payroll module 2. Go to any Employee > Personal Tab 3. In the Documents section, upload any file in the Sim Card Copy field 4. Save the record Observation: ---------------------------------- File name changed to file size Issue: ---------------------------------- The `filename` attribute was missing in the view, preventing the proper computation of the document filename. Solution: ---------------------------------- Add computed fields for the document filenames and Set these fields in the `filename` attribute of the corresponding binary fields in the view Related Community PR: https://github.com/odoo/odoo/pull/249024 opw-5905408
This update resolves an issue where a payslip would fail to generate correctly when an employee's contract started mid-period. The fix ensures the system handles contract start dates accurately, preventing errors and guaranteeing proper payroll processing for new hires. This improves the reliability of payroll calculations.
Original PR description
An error is thrown when an employee's contract starts mid-period. ```py Invalid Operation Wrong python code defined for: - Employee: Cesar Osbaldo Cruz Solorzano - Version: False - Payslip: Payslip -…
An error is thrown when an employee's contract starts mid-period.
```py
Invalid Operation
Wrong python code defined for:
- Employee: Cesar Osbaldo Cruz Solorzano
- Version: False
- Payslip: Payslip - Cesar Osbaldo Cruz Solorzano - 01/16/2026 - 01/31/2026
- Salary rule: Integrated Daily Wage (Base) (INT_DAY_WAGE_BASE)
- Error: AttributeError("'bool' object has no attribute 'year'") while evaluating
'\nresult = round(payslip.l10n_mx_integration_factor * payslip.l10n_mx_daily_salary, 4)\n
```
Steps to reproduce:
1. Install `l10n_mx_hr_payroll` modules
2. Switch to ESCUELA KEMPER URGATE company
3. Go to Employees and open Cesar Osbaldo Cruz Solorzano
4. Go to Payroll tab, change the start date of contract to 01/10/2026 and save
5. Go to Payroll > Payslips > Payslips and create a new pay run
6. Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Monthly' and Period '01/01/2026 -> 01/31/2026'
7. Click on Continue, select Cesar and click on Select
8. An error is thrown
Problem:
In `_compute_integration_factor` method, `_get_first_contract_date` is called with context `before_date`, it returns `False` as the contract starts after the payslip period. This causes an error when trying to access the `year` field of `start_date`.
Solution:
Add a fallback to call `_get_first_contract_date` without context in case the first call returns `False`.
target: saas-18.4
task-6034836
Forward-Port-Of: odoo/enterprise#111417
Forward-Port-Of: odoo/enterprise#110568This update fixes an issue where DATEV exports were inaccurate when a move line's account was changed. Now, updating an account on a move line automatically updates the DATEV account, ensuring the exported data reflects the correct financial information. This prevents duplicate lines in DATEV reports.
Original PR description
Description of the issue this commit addresses: When the account of a move line is updated (e.g. replacing the suspense account with the actual one), l10n_de_datev_main_account_id was not recomputed which leads to an incorrect DATEV export with duplicate lines. Desired behavior after this commit is merged: Changing the account_id of a move line recomputes l10n_de_datev_main_account_id so that the exported DATEV data reflects the current accounts of the move. Forward-Port-Of: odoo/enterprise#111493
This update fixes a bug where right-clicking on keypad buttons incorrectly triggered a long-press action. This issue stemmed from the system misinterpreting the context menu opening as a long-press. The fix ensures that only left-button actions are recognized, improving the user experience.
Original PR description
Since [1], some keypad buttons have a long-press value/action and, at worst, they enter the normal key value after the long-press duration. It was later improved by [2] (19.2) and other actions were…
Since [1], some keypad buttons have a long-press value/action and, at worst, they enter the normal key value after the long-press duration. It was later improved by [2] (19.2) and other actions were added such as long-pressing backspace at [3] (19.2) and more recently [4] (19.3) which allows calling the voicemail with long-pressing "1". In all those versions and features, there is the same bug: right-clicking the key triggers the long-press action as the context menu opens over the cursor, then our implementation ends up believing a long-press was performed. Solution: we should never have considered anything else than left-button actions anyways. [1]: https://github.com/odoo/enterprise/commit/82b4c4327fc722f55a0c14b14a916a5cddafa0eb [2]: https://github.com/odoo/enterprise/commit/b9dd0d6fc1fee479e9c8cd4c89dc0a9147891185 [3]: https://github.com/odoo/enterprise/commit/2723ef65622bb206d64e08482f3acd6594c03d28 [4]: https://github.com/odoo/enterprise/commit/dea0baa0dfd76962865717173807e4c945414cd3 task-6055182 Forward-Port-Of: odoo/enterprise#111528 Forward-Port-Of: odoo/enterprise#111490
This update enhances the accuracy of worker code searches within the Odoo Enterprise system. Previously, searches relied solely on display names, leading to potential mismatches. Now, the system incorporates DMFA and egov3 codes for a more reliable and comprehensive search experience.
Original PR description
before when searching for worker code it only used display name. now it uses dmfa, egov3 codes. Task#6020172 Forward-Port-Of: odoo/enterprise#110100
This update corrects a bug in the Social Media Clicks digest KPI calculation. A recent change removed tracking data previously used, and this fix adapts the KPI computation to the new UTM reference logic. This ensures the digest KPI accurately reflects social media click data, even with the updated tracking system.
Original PR description
Steps to reproduce the error : ============== 1. Go to Settings -> Technical -> Digest Emails 2. Open any Digest record 3. Click `Send Now` or `Test` -> A traceback occurs. Issue ============= A…
Steps to reproduce the error : ============== 1. Go to Settings -> Technical -> Digest Emails 2. Open any Digest record 3. Click `Send Now` or `Test` -> A traceback occurs. Issue ============= A previous refactor of Social UTM tracking: - removed `source_id` from social.post and now stores post reference directly in link.tracker (utm_reference) - removed `utm_medium_id` from social.account The "Social Media Clicks" digest KPI computation still relied on `social.post.source_id` and `social.account.utm_medium_id`. Since these fields were removed, the SQL query fails with a “column does not exist” error. Fix ============= Update the KPI computation to adapt to the new utm_reference logic Note ============ If a post is posted across all companies, its clicks are visible to all companies. This is an expected limitation of the new utm_reference logic See https://github.com/odoo/enterprise/commit/0058e409cd9ae4868bc8ed974f34f29d26c1f7df for more details task-5960183 Forward-Port-Of: odoo/enterprise#108728
This fix prevents a data error that occurred when updating payroll information for Saudi Arabian companies. The issue stemmed from a missing category reference during the data update process. The change ensures that related category data is updated first, resolving the error and allowing the scheduled 'Payroll: Update Data' action to run successfully.
Original PR description
Currently, an error occurs when the "Payroll: Update Data" scheduled action is executed. **Steps to Reproduce:** - Install `l10n_sa_hr_payroll` with demo data. - Switch to `Saudi Arabian` company. -…
Currently, an error occurs when the "Payroll: Update Data" scheduled action is executed. **Steps to Reproduce:** - Install `l10n_sa_hr_payroll` with demo data. - Switch to `Saudi Arabian` company. - Go to `Payroll` > `Configuration` > `Salary` > `Rule Categories`. - Delete all records related to the Saudi Arabian company. - Go to `Scheduled Actions` and run `"Payroll: Update Data"`. `ValueError: External ID not found in the system: l10n_sa_hr_payroll.l10n_sa_category_provision` After [this commit], the category_id field becomes non-required, allowing users to delete a rule category record even if it is linked to a salary rule. When updating the data file [1], this causes an error due to the missing rule category [2]. This commit ensures that, when updating the salary rule data, the rule category data is updated beforehand, as shown here [3]. [this commit]: https://github.com/odoo/enterprise/commit/c663fd2a81b7f6b34f8199fdbdc4a75c4f21379e [1]- https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_sa_hr_payroll/models/hr_payslip.py#L157-L165 [2]: https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_sa_hr_payroll/data/hr_salary_rule_saudi_data.xml#L249 [3]: https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_ke_hr_payroll/models/hr_payslip.py#L9-L18 sentry-7349905716 Forward-Port-Of: odoo/enterprise#111438
This update ensures the 'mark as complete' button is always visible when closing returns, regardless of whether the API connection is active. This resolves an issue where the button was hidden for users relying on manual uploads, improving usability for all return closure workflows.
Original PR description
When a flow is already started, the button "mark as complete" on returns was invisible. This is an issue for some localizations that don't handle the flow when the API connection is not desired by the user. Another use case, for example, is the API connection is down temporarily, the user manually uploads it on the website, then wants to close the started return. Forward-Port-Of: odoo/enterprise#111600
This update fixes an issue where multi-select rectangles on scaled PDF signatures were inaccurately drawn, leading to incorrect selections. Additionally, the update resolves a potential error when dropping elements and ensures helper lines align correctly during dragging, improving the overall signature experience. This enhances the reliability and usability of our digital signature process.
Original PR description
When drawing the multi-select rectangle on scaled PDF pages, the rectangle corner was not properly synchronized with the mouse pointer, leading to inaccurate selection. Additional fixes: - An uncaught error could be triggered when dropping elements on the page. - Helper lines during dragging were not accurately aligned around sign items. task-6049004 Forward-Port-Of: odoo/enterprise#111156
This update fixes an issue where repositioning PDF signs caused multiple resize events, leading to unpredictable behavior. The change ensures only one resize listener is attached per sign, resulting in a more reliable and consistent resizing experience for users. This improves the overall usability of the PDF sign feature.
Original PR description
Previously, repositioning a sign item inside the PDF iframe would attach multiple resize event listeners. This led to inconsistent and unintuitive resizing behavior. This commit ensures that only a single resize listener is registered per item, avoiding duplicated handlers and restoring stable interaction. task-6048759 Forward-Port-Of: odoo/enterprise#111520 Forward-Port-Of: odoo/enterprise#111146
This update ensures that sign document deadlines are always accurate and automatically adjusts when a document's validity date changes. It also removes orphaned 'Signature Request' activities when a document is canceled, preventing clutter and improving the user experience.
Original PR description
1. **Date Sync: mail.activity & sign.request** **Before Fix:** When the validity_date on a sign.request was updated, the linked mail.activity (the "Please Sign" task) did not update its deadline.…
1. **Date Sync: mail.activity & sign.request**
**Before Fix:** When the validity_date on a sign.request was updated, the linked mail.activity (the "Please Sign" task) did not update its deadline. This led to a discrepancy where a document might expire in 2 days, but the user's to-do list still showed a deadline from a week ago.
**Expected Behavior:** The activity deadline should always reflect the current validity of the document to ensure signers are aware of the actual remaining time.
**Fix:** Overrode the write method on sign.request. When the validity_date is modified, the system now automatically updates the date_deadline of all associated records in sign_activity_ids.
2. **Activity Cleanup on Cancel**
**Before Fix:** Canceling a sign.request changed the document state but left "Signature Request" activities sitting in users' to-do lists. This resulted in "orphan" activities that pointed to canceled documents, cluttering the chatter and the activity bin.
**Expected Behavior:** Canceling a request should globally clean up any pending tasks related to that specific request.
**Fix:** Updated the cancel method to unlink associated activities.
**Note on Conflict Prevention:** To avoid a UserError/MissingRecord when canceling directly from the activity widget (where the interface attempts to delete the activity immediately after calling the cancel method), a context flag skip_sign_activity_unlink was introduced. This ensures that if the activity is already handling its own deletion, the backend doesn't "double-delete" it.
Task: 5989542
Forward-Port-Of: odoo/enterprise#1115925 changes
Resolved issues and error corrections
This update corrects a rounding error in the US payslip PDF that was causing incorrect overtime rates to be displayed, particularly for very small overtime durations. The fix changes how the rate is calculated directly on the work entry, ensuring accurate overtime pay is reflected in the PDF. This improves the reliability of payroll reporting.
Original PR description
The Rate column on the US payslip PDF is computed as amount / hours, but amount is a Monetary field rounded to 2 decimals. For small hour values (e.g. seconds from the attendance app), the rounding error causes us to compute the wrong rate. For example, working 6 seconds of overtime at an hourly rate of $26 with a 1.5x overtime multiplier results in this calculation: $26/hour * 1.5 * 0.00166667 hour = $0.065 ≈ $0.06 We then attempted to calculate the rate in reverse for the PDF: $0.06 / 0.00166667 hour = $35.9999 ≈ $36.00 Because of the rounding that happened, it doesn't show the expected $39/hour rate ($26 * 1.5). We now compute the rate directly from hourly_wage * multiplier on the work entry type instead. This is a manual forward-port of the work in Odoo 18 [1], to instead use the new amount_rate field on hr.work.entry.type instead. task-6052711 [1] https://github.com/odoo/enterprise/pull/111540
This update resolves an issue where repositioning signs within PDF documents caused erratic resizing behavior. The fix ensures only one resize listener is attached to each sign, resulting in a more reliable and predictable resizing experience for users. This enhances the overall usability of the sign request process.
Original PR description
Previously, repositioning a sign item inside the PDF iframe would attach multiple resize event listeners. This led to inconsistent and unintuitive resizing behavior. This commit ensures that only a single resize listener is registered per item, avoiding duplicated handlers and restoring stable interaction. task-6048759 Forward-Port-Of: odoo/enterprise#111520 Forward-Port-Of: odoo/enterprise#111146
This update fixes an issue where multi-select rectangles on scaled PDF signature pages were inaccurately drawn, leading to incorrect selections. Additionally, the fix resolves a potential error when dropping elements and ensures helper lines align correctly during dragging. This improves the reliability and usability of the signature process.
Original PR description
When drawing the multi-select rectangle on scaled PDF pages, the rectangle corner was not properly synchronized with the mouse pointer, leading to inaccurate selection. Additional fixes: - An uncaught error could be triggered when dropping elements on the page. - Helper lines during dragging were not accurately aligned around sign items. task-6049004 Forward-Port-Of: odoo/enterprise#111156
This update fixes an issue where currency rates for Bulgaria were incorrectly calculated after the country switched to the Euro. The system was using reversed rates from the data source, leading to inaccurate unit conversions. The change ensures correct rate calculations by using the primary 'RATE' value from the XML data.
Original PR description
Issue: after Bulgaria switched to EUR, currency rate fetching from BNB was incorrectly set to still use reversed currency rates from the fetched XML, resulting in unit-to-EUR and EUR-to-unit rates being flipped in the database. Solution: adjusting the parser to get rate from 'RATE' rather than 'REVERSERATE', as the XML provides both. task-6050519 Forward-Port-Of: odoo/enterprise#111275
This update resolves a problem where invoices with discounts and decimal values (over 2 decimals) were failing to send to ARCA. The fix uses a simplified unit price for discount calculations, ensuring accurate decimal handling and successful invoice transmission.
Original PR description
After changes made in Odoo of how the decimal precision works some of the code we use to prepare the data to create EDI invoices now fails. We already adapt the code to fix the data depending of the expected webserive format but we miss a case related to when invovice has discounts. The problem is that any invoice with lines that has more than 2 decimals and also have a discount will fail when trying send it to ARCA because the computed amount has differences in the decimals. Now we use the truncated unit price to compute the discount instead of the full amount with decimal of the `line.price_unit` value. Forward-Port-Of: odoo/enterprise#110706
1 change
Resolved issues and error corrections
This update corrects a small, unintended message appearing in the documents generated for employee payroll. This ensures a cleaner and more professional presentation of payroll information for employees and managers. The change improves the overall user experience.
Original PR description
Task#5980045 Forward-Port-Of: odoo/enterprise#109063
1 change
Resolved issues and error corrections
This update resolves an issue where the AEAT tax report file was being rejected due to an incorrect date format. The fix ensures the file includes a default numeric date ('00000000') when a legal person's procuration date is not specified, meeting AEAT's requirements and allowing successful file uploads.
Original PR description
**Steps to reproduce:** - Install the `l10n_es_reports` module and switch to the `ES company`. - Go to Invoices and create an invoice with taxes, then confirm it. - Navigate to Accounting > Reporting…
**Steps to reproduce:** - Install the `l10n_es_reports` module and switch to the `ES company`. - Go to Invoices and create an invoice with taxes, then confirm it. - Navigate to Accounting > Reporting > Tax Report. - From the smart button, select `Report: Tax Report (Mod 390) (ES)` and choose the year as `This Financial Year`. - Download the `BOE` file using the dropdown and fill the wizard fields (e.g., Natural Person – Name: Test, Principal activity: Test, Activity Code: 12345). - Upload the generated .txt file to the AEAT portal. (AEAT credentials are required) **Observation:** AEAT rejects the file with: `Caracteres no válidos '4. Representante - Personas Jurídicas - Represent. 1 - Fecha Poder (DDMMAAAA)'` **Root cause:** At [1], when `judicial_person_procuration_date` is `false`, an empty string is written to the BOE file, resulting in blank spaces in the exported file. This does not comply with AEAT’s required numeric format and causes the file to be rejected. **Fix:** This commit ensures the file contains '00000000' when `judicial_person_procuration_date` is false, complying with AEAT numeric format requirements. [1]: https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/l10n_es_reports/models/aeat_tax_reports.py#L1696 opw-5995290