Daily updates from Odoo
Navigate
Branch
Wednesday, March 25, 2026
294 changes
8 changes
Enhancements to existing features
This update enhances the Project Side Panel by allowing more detailed budget information to be displayed. By enabling inheritance of a key method, the system now includes a broader range of budget items, providing project managers with a more complete financial overview. This improves decision-making related to project costs.
Original PR description
Enabling the inheritance of the method _get_budget_items to include more budget information, by adding a method for the budget items domain. Forward-Port-Of: odoo/enterprise#107466
Resolved issues and error corrections
This update resolves an issue where the Modelo 390 BOE file generated for Spanish tax reports was being rejected by the AEAT portal. The fix ensures a default date format ('00000000') is used when a legal entity's procuration date is not specified, aligning with 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 Forward-Port-Of: odoo/enterprise#109652
This update replaces an older method for accessing configuration settings within the currency rate module. Using the recommended `get_str` method ensures consistent and reliable retrieval of settings, improving the stability and performance of the system. This change is a routine maintenance update.
Original PR description
https://github.com/odoo/odoo/pull/223180 removes the `get_param` method from `res.config_parameter`, which was used in the `currency_rate_live` module. This commit replaces it with the `get_str` method, which is the recommended way to retrieve configuration parameters in Odoo. No task ID Forward-Port-Of: odoo/enterprise#110975
This update fixes an issue where payroll attendance calculations were incorrectly high when public holidays were present. The change ensures accurate attendance line amounts by properly accounting for public holiday hours during the calculation process. This improves payroll accuracy and reporting.
Original PR description
Fixes the calculation of the worked day lines amount, in cases where a public holiday is set. The current computation doesn't account for hours of public holiday when calculating the attendance amount; causing it to be higher than expected. This is caused by the calculation of work_time, which comes from the calendar data from _work_intervals_batch. If there is a public holiday, the work interval for that day is being removed from the result, causing it to wrongly calculate a lower work_time than expected and increasing the attendance line amount. task-5979501 Forward-Port-Of: odoo/enterprise#111741
This update resolves two issues preventing new employee creation in the Belgian payroll module. The first prevented saving a new employee with a start date, while the second caused errors when adding a wage. The fix ensures that employee records are created correctly and reliably.
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 Forward-Port-Of: odoo/enterprise#111780 Forward-Port-Of: odoo/enterprise#109799
This update enhances payroll processing, particularly for employees with changing contracts during a pay period. By layering payslip calculations and introducing new tools for tracking totals, the system now accurately handles contract adjustments, preventing overpayments and ensuring correct contribution calculations, especially in Hong Kong.
Original PR description
This commit aims to provide better support for contract changes that happen in the middle of a pay period. It has a few impacting changes, notably: 1) Payslip calculation sequencing As of now, all…
This commit aims to provide better support for contract changes that happen in the middle of a pay period. It has a few impacting changes, notably: 1) Payslip calculation sequencing As of now, all payslips of a same payrun have their line calculated all at once. While this is better for performances, it has a negative effect when a single employee has multiple payslips in the same payrun. In such cases, we may want or need for the payslips to know what was already calculated in the same payrun to avoid overpaying contributions or allowances that have caps. To solve this issue, we now group payslips by employee, sort them chronologically, and evaluate them in horizontal "layers": - Layer 1: Computes the 1st payslip for ALL employees simultaneously. - Layer 2: Computes the 2nd payslip for the subset of employees who have one, etc 2) More tools in HK payroll to support these cases The payslip rules now have a `l10n_hk_payrun_totals` dict that contains the total amount already reported in previous payslips of a same payruns for a selection of rules that needs it. We also provides a `worked_days_prorata_rate` which gives the ratio of worked days vs unworked days in a month for cases where we need to adjust amounts based on that ratio. 3) Rule updates The last part of the fix requires some updates in a few rules that are fixed amounts/not based on the wage and ends up being counted double in our use case. These rules will now take into account already computed amounts as said above to avoid going over the limit. In most cases it will only affect that specific use case, with a small exception for fixed mpf voluntary contributions, which have been updated to be prorated based on the worked days in the month. Forward-Port-Of: odoo/enterprise#111814 Forward-Port-Of: odoo/enterprise#111570
This update resolves a bug that prevented users accessing documents linked to their employees when using a secondary Odoo domain. The fix ensures that users are correctly directed to the appropriate domain based on their login location, improving document access 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#110390
Forward-Port-Of: odoo/enterprise#107384This update fixes an issue where currency rates for businesses in Bulgaria were incorrectly calculated due to a misinterpretation of data from the Bulgarian National Bank (BNB). The change ensures accurate EUR-to-unit and unit-to-EUR conversions, resolving a potential discrepancy in financial reporting. This update improves the reliability of currency calculations for our Bulgarian customers.
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#111753 Forward-Port-Of: odoo/enterprise#111275
17 changes
Enhancements to existing features
This update improves the Project Side Panel by allowing more budget details to be displayed. Specifically, it enables inheritance to include additional budget information, enhancing the visibility of project financial data. This change provides greater insight into project spending.
Original PR description
Enabling the inheritance of the method _get_budget_items to include more budget information, by adding a method for the budget items domain. Forward-Port-Of: odoo/enterprise#107466
Resolved issues and error corrections
This update enhances payroll calculations, particularly for employees with changing contracts during a pay period. By grouping payslips and considering previously calculated amounts, the system now accurately avoids overpaying contributions and allowances, especially in Hong Kong. This ensures greater payroll precision and compliance.
Original PR description
This commit aims to provide better support for contract changes that happen in the middle of a pay period. It has a few impacting changes, notably: 1) Payslip calculation sequencing As of now, all…
This commit aims to provide better support for contract changes that happen in the middle of a pay period. It has a few impacting changes, notably: 1) Payslip calculation sequencing As of now, all payslips of a same payrun have their line calculated all at once. While this is better for performances, it has a negative effect when a single employee has multiple payslips in the same payrun. In such cases, we may want or need for the payslips to know what was already calculated in the same payrun to avoid overpaying contributions or allowances that have caps. To solve this issue, we now group payslips by employee, sort them chronologically, and evaluate them in horizontal "layers": - Layer 1: Computes the 1st payslip for ALL employees simultaneously. - Layer 2: Computes the 2nd payslip for the subset of employees who have one, etc 2) More tools in HK payroll to support these cases The payslip rules now have a `l10n_hk_payrun_totals` dict that contains the total amount already reported in previous payslips of a same payruns for a selection of rules that needs it. We also provides a `worked_days_prorata_rate` which gives the ratio of worked days vs unworked days in a month for cases where we need to adjust amounts based on that ratio. 3) Rule updates The last part of the fix requires some updates in a few rules that are fixed amounts/not based on the wage and ends up being counted double in our use case. These rules will now take into account already computed amounts as said above to avoid going over the limit. In most cases it will only affect that specific use case, with a small exception for fixed mpf voluntary contributions, which have been updated to be prorated based on the worked days in the month. Forward-Port-Of: odoo/enterprise#111570
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 the 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 Forward-Port-Of: odoo/enterprise#109652
This update resolves two bugs preventing new employee creation in the Belgian payroll module. The first issue involved duplicate record creation due to a mail activity trigger. The second addressed a problem where activities were attempted before the employee record was fully saved. These fixes ensure reliable employee onboarding within the Belgian company setup.
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 Forward-Port-Of: odoo/enterprise#111780 Forward-Port-Of: odoo/enterprise#109799
This update fixes a potential issue where a user could indirectly change an employee's work email through contract settings. Previously, linking an employee to a user allowed for unintended email modifications. Now, the system ensures the work_email remains consistent if the employee is associated with a user, improving data integrity.
Original PR description
Due to https://github.com/odoo/enterprise/pull/106974,the employee's work_email may be reset to False when creating or updating an offer. This behavior is acceptable if the employee does not have a linked user. However, if the employee is linked to a user, resetting work_email can allow a user to indirectly modify their own work_email through salary confi. To prevent this, we now ensure that work_email never changes if employee has a user linked to it. Steps to reproduce: - Hire an applicant from Recruitment (the employee has no work_email). - Set a random work_email and create a user for the employee. - Open the hired applicant and create a new offer to update the contract. - work_email should not be modified, even after new contract. task: 6033382 Forward-Port-Of: odoo/enterprise#110810
A technical issue causing a tour to fail has been resolved. This change adjusted the company referenced within the tour, addressing a previously unreplicable access rights problem. The fix ensures the tour now runs correctly, improving the user experience.
Original PR description
Before this commit, the tour `hr_referral_utm_campaign_tour` was failing because of some weird access rights issues. The issue did not seem to be reproducible in local with similar condition. This commit changes the company used in that tour runbot issue 239152
This update significantly speeds up the bank reconciliation view, particularly when dealing with large volumes of financial data. The previous freezing issue was caused by redundant calculations, which has now been resolved by optimizing the system's performance. This results in a much faster and more responsive user experience.
Original PR description
The bank reconciliation view was freezing on large databases (50k+ invoices, 90k+ journal entries), making it impossible to expand lines, filter, or interact with the view in any way. Attempting to…
The bank reconciliation view was freezing on large databases (50k+ invoices, 90k+ journal entries), making it impossible to expand lines, filter, or interact with the view in any way. Attempting to open a line would sometimes result in a timeout. **Root cause:** The `reconciledLineName` getter was called multiple times per render cycle — once in `t-foreach` and again in the `t-if` condition. Since OWL re-evaluates the template on every reactive state change, this created an O(n×m) computation loop (n renders × m statement lines) that overwhelmed the browser. **Fix:** Cache the result in OWL reactive state via a dedicated `_computeReconciledLineName()` method, called once on setup and reactively via `useEffect` when `line_ids.records` changes. The template is updated to store `Object.entries(reconciledLineName)` in a `t-set` variable to avoid rebuilding the array on every iteration. | Metric | Before | After | |---|---|---| | Longest blocking task | 15 091 ms | 5 118 ms | | Total blocking time | 74 147 ms | 22 481 ms | | Avg. click response | 2 163 ms | 28 ms | | Max click response | 14 305 ms | 222 ms | | Total microtasks executed | 9 917 | 32 484 | opw-5879798 Forward-Port-Of: odoo/enterprise#107135
This update corrects an issue preventing Romanian SAFT reports from passing validation. The team restored a key data element and used a sanitized bank account number, ensuring compliance with Romanian tax regulations. This resolves a technical problem impacting report accuracy and preventing errors.
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 Forward-Port-Of: odoo/enterprise#111664
This update resolves an issue where users could inadvertently create 'Requested Documents' instead of folders when syncing Peppol documents through the accounting settings. To avoid a confusing 'My Drive' folder creation, the ability to create or edit documents within the settings has been disabled, aligning with a previous fix.
Original PR description
Before this commit a user could create or edit a folder in the accounting settings to sync peppol documents to. The issue was that this created a 'Requested Document' instead of a folder. This commit removes the possibility to create or edit documents through the settings. An alternative would have been to add the contex to create a Folder instead of a Requested Document, however another problem then arises: the folder is created in My Drive, which does not make any functional sense. Therefore we are disabling creation and edit. This is the same logic applied in 8ada2a4f. Task-6063736 Forward-Port-Of: odoo/enterprise#111761
This update resolves a problem where invoices with discounts and decimal values (over 2 decimals) were failing to send to ARCA for electronic invoicing. The fix uses a simplified unit price to calculate discounts, ensuring accurate decimal calculations and successful invoice transmission. This improves the reliability of our ARCA integration.
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 rounding error in the US payslip PDF that was causing incorrect overtime rates for very small work durations (like seconds). The fix now calculates the rate directly from the work entry, ensuring accurate overtime pay is displayed. This improves the precision of US 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 Forward-Port-Of: odoo/enterprise#111733
A recent update to Odoo Enterprise prevented the deletion of newly created approval rules within the Studio interface. This was caused by the way the system managed updates to these rules, leading to data inconsistencies. This fix ensures that these rules are properly managed, preventing data loss during updates.
Original PR description
Server and automated actions created by the ORM for the purpose of revoking approval rights are created without `noupdate=True` which leads to said records being removed by the ORM becuase of not being found in the source. Such records created on the fly should have `noupdate=True` to prevent that from happening. This bug can be reproduced by going to Settings > Technical > User Interface > Studio Approval Rules and creating a new record from there and updating `web_studio`. The update will drop the record from the database. Issue originally detected in the upgrade process from 18.0 to 19.0. This fix will be complemented by an upgrade script that fixes erronous records. Forward-Port-Of: odoo/enterprise#110065
This update fixes a technical issue that caused a traceback error when generating the 281.10 report for Belgian payroll. The fix ensures the report correctly identifies payslips without the Fleet module, preventing errors and improving report generation reliability. This resolves a disruption in generating key financial reports.
Original PR description
[FIX] l10n_be_payroll: fix traceback in 281.10 sheets
Bug reproduction: Go to any version>=17.0 -> select belgium company -> install only belgium payroll (don't install fleet one) -> fill in niss, certification level, address, Time in R&D -> generate payslip and confirm it -> try to generate 281.10 report -> traceback
Bug cause:
1 - In traceback it was saying payslip doesn't have vehicle_id, in 281.10 sheet preparation (in function _get_atn_nature), there is a term like that
2 - Payslip doesn't have it because fleet module is not there.
Bug solution:
1 - Instead of checking the payslip has vehicle like that, we calculated it by using paylsip line_ids
2 - If the code ATN.CAR is there and the total of it is not zero, which means this payslip has a vehicle indeed.
task - 6037206
Forward-Port-Of: odoo/enterprise#111506
Forward-Port-Of: odoo/enterprise#110860This update fixes a bug preventing the proper synchronization of XML documents (like e-invoices) related to accounting moves. Previously, invoices created from various sources didn't consistently attach the original XML files to the Documents app. This change ensures all XML files are now correctly linked, improving document management and compliance.
Original PR description
[FIX] documents_account: sync all XML documents for account moves Before this commit, the synchronization between accounting attachments and the Documents app was incomplete regarding XML files…
[FIX] documents_account: sync all XML documents for account moves Before this commit, the synchronization between accounting attachments and the Documents app was incomplete regarding XML files (e.g., e-invoices, Peppol). This caused several specific issues: 1. When creating an invoice via the Accounting upload interface, only the generated PDF was synced to the correct Documents folder, leaving the original XML file unsynced. 2. When creating an invoice from an existing file in the Documents app (via server action), the system correctly synced the generated PDF, but failed to move or sync the original XML source file to the target folder. 3. When receiving vendor bills via Peppol or other EDI networks, the proxy attaches the fetched XML to the `account.move` via an `ir.attachment` write. Because this bypassed the existing sync filters, the Peppol XMLs were never pushed to the Documents app. This commit updates the `ir.attachment` logic in both `create` and `write`. It ensures that whenever an XML file (mimetype `application/xml` or `text/xml`) is attached to an `account.move`—regardless of the move type or whether it was uploaded manually or fetched via EDI—the document synchronization logic is triggered, properly linking and filing the XML alongside the PDF. Task-5909245 Task-5917535 Forward-Port-Of: odoo/enterprise#106574
This update fixes an issue where project budget totals were incorrectly summing expenses and revenue. The code was adjusted to properly differentiate between expense and revenue budgets when calculating totals, ensuring accurate reporting of project financial status. This improves the reliability of project cost tracking.
Original PR description
### Steps to reproduce: - Create a billable project - Create two budgets one expense and the other revenue or both each for 100$ - Create a vendor bill with the analytic account of the created project - Notice in the project dashboard the two budgets are summed up in the total ### Cause: When calculating the total spent and total allocated we add up the amount whether it is an expense or revenue. https://github.com/odoo/enterprise/blob/1dccb87a48ac44735da4c78594e37d4783789cd6/project_account_budget/models/project.py#L120-L121 ### Fix: Set the expense budget to -ve and the revenue/both to +ve amount when calculating the total spent and total allocated opw-5488131 Forward-Port-Of: odoo/enterprise#106504
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
Features or functions removed from Odoo
This change removes the automatic assignment of a VoIP provider to new users. Previously, users were linked to the first available provider, which created issues for systems with multiple providers. Now, users will not be linked to a VoIP provider by default, aligning with best practices for multi-provider environments.
Original PR description
Following this Pull Request, users will not be linked to any VoIP provider by default. Prior to this Pull Request, users were linked to the first `voip.provider` record found. The rationale behind this behavior has been forgotten, but it was likely implemented to spare admins with a single provider from having to assign one. However, for databases with more than one provider, "nothing" is usually the relevant default. See also: [task-6023412](https://www.odoo.com/odoo/project.task/6023412)
6 changes
Resolved issues and error corrections
This update resolves an issue where fields weren't being created correctly within Odoo. The fix ensures that fields are properly populated during the creation process, improving data accuracy and reliability. This primarily impacts HR and reporting modules.
Original PR description
See https://github.com/odoo/odoo/pull/199647. Forward-Port-Of: odoo/enterprise#109725
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 date ('00000000') when the procuration date is not specified, aligning with 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 Forward-Port-Of: odoo/enterprise#109652
This update resolves an issue where users couldn't add reactions to messages within the Discuss module, specifically when using the mail_group model. The fix ensures that the 'add reaction' button isn't displayed for message types that don't properly support reactions, improving the overall stability and usability of the Discuss feature.
Original PR description
Steps to reproduce: - Install the mail_group module - Open Discuss - Go to the History tab - Add a reaction on a message that has model mail.group - Throws an error The error occurs because the mail.group model does not implement the `_get_allowed_access_params()` method, which is invoked during the process here. Actually, the "add reaction" button should not be shown on messages whose model does not inherit from mail.thread. This commit fixes the issue by hiding the "add reaction" button on messages with models that don’t inherit from mail.thread, such as `mail.group`. community: https://github.com/odoo/odoo/pull/218615 Task-5098050 Forward-Port-Of: odoo/enterprise#111673 Forward-Port-Of: odoo/enterprise#111271
This update ensures that all contract sign-off and validation steps are completed before the applicant's process ends. This prevents inconsistencies in the system's state and improves the reliability of our HR processes. It’s a small fix to enhance data accuracy and process repeatability.
Original PR description
This commit adds final steps after the applicant contract being signed to let the actual sign & validate fully finish before ending the tour to avoid unconsistent state and be more reproducible. runbot-241162
This update resolves an issue in Odoo's Web Studio where field visibility settings (based on user groups) were not consistently applied. Previously, toggling the 'Show invisible Elements' checkbox didn't always retain the intended hidden state. This fix ensures that fields remain invisible when a user lacks the necessary access permissions, improving the consistency and usability of the Web Studio interface.
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#111751 Forward-Port-Of: odoo/enterprise#111299
This update corrects an issue preventing Romanian SAFT reports from passing validation. The team restored a key data element and used the correct, sanitized bank account number, ensuring compliance with Romanian tax regulations. This resolves a technical problem impacting report accuracy and usability.
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 Forward-Port-Of: odoo/enterprise#111664
10 changes
Resolved issues and error corrections
This update resolves an issue where fields weren't being populated correctly during Odoo record creation. The fix ensures that fields are properly filled in when new records are generated, improving data accuracy and reliability. This impacts several core Odoo modules.
Original PR description
See https://github.com/odoo/odoo/pull/199647. Forward-Port-Of: odoo/enterprise#109725
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 date ('00000000') when the 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 Forward-Port-Of: odoo/enterprise#109652
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 threshold of €1,000 in total turnover (from invoices and credit notes), ensuring 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 corrects a technical issue preventing users from accessing public website content (like blog posts) without logging in. The fix ensures that website access rules are correctly evaluated, resolving a 404 error. This improves the overall user experience for browsing public content on the website.
Original PR description
\* = test_website_modules ### Issue: When accessing a record from the website without logging in, a `404` error occurs if a public record rule filters records by website related domain, for example…
\* = test_website_modules
### Issue:
When accessing a record from the website without logging in, a `404`
error occurs if a public record rule filters records by website related
domain, for example `[('website_id', '=', website.id)]`.
### Steps to reproduce:
- Install the 'website_blog' module and create at least one website.
- Enable debug mode.
- Go to Settings > Technical > Database Structure > Models.
- Open the `blog.post` model.
- Go to the 'Record Rules' tab.
- For the record 'Blog Post: public: published only', change the domain
from `[('website_published', '=', True)]` to
`[('website_id', '=', website.id)]`.
- Go to Website > Configuration > Blogs.
- Open a blog (e.g., Travel).
- Select 'My Website' in its 'Website' field.
- Open 'My Website' without logging in.
- Click on the 'Blog' menu and the blog listing will appear correctly.
- Try opening a blog post and a `404` error occurs.
### Reason:
<pre>
┌─────────────────────────────────────────────────────────┐
│ Request Lifecycle │
├─────────────────────────────────────────────────────────┤
│ │
│ User Request (not logged in) │
│ ↓ │
│ ┌──────────────────────────────────────┐ │
│ │ 1. _pre_dispatch │ │
│ │ ↓ │ │
│ │ check_access_rule │ │
│ │ ↓ │ │
│ │ _eval_context (compute domain) │ │
│ │ ↓ │ │
│ │ get_request_website() │ │
│ │ ↓ │ │
│ │ request.website = None │ ← Issue │
│ │ ↓ │ │
│ │ Domain evaluation FAILS │ │
│ │ ↓ │ │
│ │ Access DENIED → 404 Error │ │
│ └──────────────────────────────────────┘ │
│ ↓ │
│ ┌──────────────────────────────────────┐ │
│ │ 2. _frontend_pre_dispatch │ │
│ │ (NEVER REACHED) │ │
│ │ ↓ │ │
│ │ request.website initialized ✓ │ ← Too Late │
│ └──────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
</pre>
Because `request.website` is initialized later in
`_frontend_pre_dispatch`, access rules evaluated earlier in
`_pre_dispatch` cannot rely on website context. As a result, record
rules depending on `website_id` are evaluated before `request.website`
is available, incorrectly denying access to public records.
### Fix:
Avoid totally relying on `get_request_website` during access rule
evaluation. Use the `request.is_frontend` attribute as a fallback, which
is set earlier, to detect frontend requests and ensure correct access
handling.
task-[4758311](https://www.odoo.com/odoo/project/974/tasks/4758311)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#213143This update corrects a problem where printed POS receipts were displaying incorrect QR codes for subsequent orders. The issue stemmed from how the system cached QR code images, leading to the reuse of outdated information. This fix ensures that each order generates a unique QR code for accurate scanning and tracking.
Original PR description
**Step to reproduce:** - install "l10n_es_edi_verifactu_pos" - setup "ePOS printer" for a pos - open pos and settle a order below 400$ - notice we get l10n_es_edi_verifactu_qr_code in our receipt -…
**Step to reproduce:** - install "l10n_es_edi_verifactu_pos" - setup "ePOS printer" for a pos - open pos and settle a order below 400$ - notice we get l10n_es_edi_verifactu_qr_code in our receipt - click on "Print receipt" - repeat above steps for one more order **Observation:** - when we print the second order receipt, the QR still points to 1 order invoice **Issue:** - [getCacheKey](https://github.com/odoo/odoo/blob/0cee3350df09b06af77c879f0eba74bf6a8dd2c9/addons/point_of_sale/static/src/app/utils/html-to-image.js#L351C10-L355 ) was trimming query strings when generating cache keys. URLs like: ` http://localhost:9000/report/barcode/?barcode_type=QR&value=... ` were reduced to: ` http://localhost:9000/report/barcode/` - As a result, different QR code requests shared the same cache key. Subsequent requests reused the previously cached image instead of fetching a new one, producing incorrect QR codes for different orders. **Solution:** Add an `includeQueryParams` flag to `resourceToDataURL` so the full URL, including query parameters, is used as the cache key when needed. This ensures unique QR code URLs are cached and fetched correctly. opw-5455807 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251139
This update resolves an issue where employees with extra hours weren't showing up on their time off dashboard. The fix adjusts how extra hours are calculated and displayed, ensuring accurate reporting of available time off allocations. This improves the visibility of employee overtime for better workforce management.
Original PR description
### Issue: When an employee has Extra Hours, they are not shown in the dashboard. ### Steps to reproduce: - Install Attendance and Time off apps - Create some attendance with extra hours for the employee - Go to the employee's time off dashboard - Notice Extra Hours allocation is not shown ## Cause: The extra hours are added in [`get_allocation_data()`](https://github.com/odoo/odoo/blob/5c3deb11627f4d6762c4994207bd582afb96f064/addons/hr_holidays_attendance/models/hr_leave_type.py#L35-L66), but then they are removed in [`get_allocation_data_request()`](https://github.com/odoo/odoo/blob/5c3deb11627f4d6762c4994207bd582afb96f064/addons/hr_holidays/models/hr_leave_type.py#L489) just before returning because `max_leaves` is zero. ### Solution: We also set `max_leaves` to `employee.total_overtime`. If the employee doesn't have any extra hours, then it will not display. opw-5925258 Forward-Port-Of: odoo/odoo#255504 Forward-Port-Of: odoo/odoo#253655
This update resolves an issue where attachment updates for invoices were sometimes failing, leading to inconsistencies in the system. By updating the attachment within the same transaction as the move update, we ensure both changes are reliably committed, maintaining data integrity. This prevents data discrepancies and improves the reliability of invoice processing.
Original PR description
Was committing the move fields update, then updating the attachment. This might create an issue were the move update commits successfully, but setting the attachment fails and we end up with an inconsistency. Set attachment in the same transaction as the move update. task-6035727 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255440 Forward-Port-Of: odoo/odoo#255262
This update resolves a restriction that previously limited access to KSeF functionality for users without administrative privileges. By adding necessary permissions, non-admin users can now perform actions related to KSeF compliance, ensuring broader usability of the l10n_pl_edi module. This change enhances efficiency and simplifies processes for a wider range of users.
Original PR description
Fields on `res_company` related to KSeF are marked only for group `base.group_system`, as are the `certificate.certificate` and `certificate.key` models. Adding `compute_sudo` and `sudo()` calls where it's needed in actions that can be performed by non-admin users. task-6018713 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253336
This update ensures Odoo uses the latest, pre-built wheel version of the cbor2 library, aligning it with Debian Bookworm and Ubuntu Jammy. This improves stability and performance by utilizing optimized pre-compiled code.
Original PR description
This commit sets the cbor2 library's version to match more closely the Debian Bookworm/Ubuntu Jammy packaged versions and to match the ones with a prebuild wheel. Note: while the 5.4.2 already matched the one from Jammy, it didn't provided a corresponding wheel, which the 5.4.2.post1 did fix (cf. https://github.com/agronholm/cbor2/releases/tag/5.4.2.post1). runbot-238903 Forward-Port-Of: odoo/odoo#254638
This update fixes a potential issue where users could inadvertently create incorrect group assignments to inherited views, leading to upgrade errors. The change adds a validation rule to prevent this, ensuring groups are defined directly within the view's XML configuration for stability and easier management.
Original PR description
**Steps to Reproduce:** - Create a new database. - Install any module (for example, Payroll). - Go to Settings → Technical → Security → Groups. - Open any group and assign an inherited view in the…
**Steps to Reproduce:** - Create a new database. - Install any module (for example, Payroll). - Go to Settings → Technical → Security → Groups. - Open any group and assign an inherited view in the Views section. - Upgrade the module. **Issue:** - Odoo already prevents assigning groups directly on inherited view records in ir.ui.view. However, it is still possible to indirectly assign groups to inherited views through res.groups via the view_access relation. - This creates entries in ir_ui_view_group_rel and can trigger a ValidationError during module upgrades. As a result, users may unknowingly create invalid group-view relations, leading to errors and confusion. **Solution:** - Add a validation constraint on res.groups to prevent linking groups to inherited views via the view_access relation. - Raise a ValidationError when such an assignment is attempted, with the message: "Groups should instead be defined using the 'groups' attribute inside the view XML definition." This ensures that inherited views cannot be assigned to groups, avoiding invalid configurations and preventing errors during module upgrades. **opw-6015526** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255411 Forward-Port-Of: odoo/odoo#254849
4 changes
Resolved issues and error corrections
This update corrects a technical issue related to how fields are populated during the creation process within Odoo. Specifically, it ensures that the correct model is used when creating certain fields, improving data accuracy and reliability. This change primarily impacts the HR and Payroll modules.
Original PR description
See https://github.com/odoo/odoo/pull/199647. Forward-Port-Of: odoo/enterprise#109725
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 the 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 Forward-Port-Of: odoo/enterprise#109652
This update fixes a potential issue where a user could indirectly change an employee's work email through salary contract settings. The change ensures that an employee's work_email remains consistent, regardless of whether they are linked to a user, improving data integrity. This resolves a bug identified in a previous pull request.
Original PR description
Due to https://github.com/odoo/enterprise/pull/106974 employee's work_email may be reset to False when creating or updating an offer. This behavior is acceptable if the employee does not have a linked user. However, if the employee is linked to a user, resetting work_email can allow a user to indirectly modify their own work_email through salary confi. To prevent this, we now ensure that work_email never changes if employee has a user linked to it. ### Steps to reproduce: - Hire an applicant from Recruitment (the employee has no work_email). - Set a random work_email and create a user for the employee. - Open the hired applicant and create a new offer to update the contract. - work_email should not be modified, even after new contract. task: 6033382 Forward-Port-Of: odoo/enterprise#111243
This update fixes an issue where barcode scanning with a different serial number than the reserved one didn't create a new lot in stock. The fix ensures that the correct lot is always used when scanning a batch, preventing incorrect inventory tracking. This improves the reliability of the barcode scanning process.
Original PR description
Issue ----- When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken…
Issue
-----
When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken regardless of setting.
Steps to reproduce
-----
- Enable GS1 nomenclature, lots & batches
- Go to Inventory > Configuration > Operation Types > Delivery Orders
- Enable Lots/Serial Numbers > Create New
- Create a product
- Barcode 23456789012344
- Tracked by SN
- 1 in stock (SN 1234)
- Create a delivery for the product and add it to a batch
- Open the batch in barcode
- Scan 012345678901234410BATCHSN1
- Confirm the delviery
- Go back to the picking and see the lines' details
> The line used the reserved SN
Cause
-----
The existing line gets matched in `_findLine`
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1085
because none of the conditions before
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1402
get matched. This is unexpected but necessary for batches, as it ensures barcode correctly swaps to the correct picking in the batch. If the line was not matched we would be creating a new line in the same picking than the last scanned line, regardless of which picking the reservation is made in.
Because a line is matched, we have to force its' `lot_id` to `false` so that the new one gets created (`lot_name` is used for display but `lot_id` takes precedence).
-----
Ticket:
opw-5216921
Forward-Port-Of: odoo/enterprise#111696
Forward-Port-Of: odoo/enterprise#10967140 changes
New functionality added to Odoo
This update introduces a new module to support the processing of e-Resguardos documents, a key requirement for businesses operating in Uruguay. The changes address a previous bug related to automatic addenda calculation and include new unit tests for improved reliability. This ensures accurate accounting and compliance with local regulations.
This update enables businesses to formally cancel previously sent DTEs (Digital Tax Evasion) by sending an XML file to Infile. Users can initiate the cancellation process through a wizard, specifying the reason for the cancellation, which is then transmitted to the SAT (Mexican tax authority). This improves compliance and reduces potential penalties.
Original PR description
Allow users to void a sent DTE by sending an AnulacionDTE XML to Infile. Clicking "Request Cancel" on a sent invoice opens a wizard asking for the cancellation reason, which is then sent to SAT. task-5994798
Enhancements to existing features
This update adds a new system for calculating and managing professional tax deductions for employees in Russia. The change combines existing logic for LWF deductions and introduces flexible payment cycles (monthly, quarterly, etc.) to simplify tax processing and improve accuracy. This enhancement ensures compliance with Russian tax regulations.
Original PR description
[IMP] l10n_in_hr_payroll: professional tax deduction cycle
1 - New deduction cycle field is added for professional tax (monthly, quarterly, half_yearly, yearly)
1.1 - It is added form view of employee just below of Professional Tax in Tax Deductions
2 - There was a written logic for LWF deductions in the code already _l10n_in_apply_lwf.
2.1 - Since the logic was almost same, I combined both professional tax deduction and lwf tax deduction and made a small refactor.
task - 4978408This update improves the speed and reliability of refreshing social media data (Facebook and Instagram) by using batch API requests. It also ensures consistent engagement trend calculations across platforms, leading to more accurate reporting and a better user experience. The changes focus on efficiency and data accuracy.
Original PR description
Purpose ======= The Meta API supports batch requests: > https://developers.facebook.com/docs/graph-api/batch-requests This can reduce a lot the HTTP calls we make, and makes the module faster to…
Purpose ======= The Meta API supports batch requests: > https://developers.facebook.com/docs/graph-api/batch-requests This can reduce a lot the HTTP calls we make, and makes the module faster to refresh. We could have been way more aggressive in the optimization (eg, fetch the stats and the posts at the same time), but it will deteriorate the readability, so we just batched API calls in loop, and stuff like that. Time of a refresh for 6 Facebook pages and 1 Instagram page: <img width="881" height="71" alt="a" src="https://github.com/user-attachments/assets/ec319c4a-c51d-49b8-a6ab-3ee879cf63b4" /> After: <img width="886" height="103" alt="b" src="https://github.com/user-attachments/assets/0b707b72-f30f-4e00-a38c-614feea6e204" /> Use `total_interactions` instead of `reach` for the engagement trend of Instagram. Show the view and saved statistic for Instagram. Do misc UI improvement. Fix an inconsistency for the engagement trend computation between Facebook and Instagram. Task-4865381
This update simplifies the tracking of materials within MRP components by removing unnecessary packaging fields from the SML form. These fields were previously visible but are not used when components are consumed unpacked, preventing user confusion and ensuring data accuracy. This change improves the user experience and data integrity.
Original PR description
Hide the `Destination Package` and `Destination Container Package` fields in the SML form for MO components in the Barcode app, as they are always consumed unpacked. Keeping these fields visible can mislead users into entering information with no functional meaning. Community PR:- odoo/odoo#243072 TaskID-4068485
Resolved issues and error corrections
This update enhances the testing process for WhatsApp features within Odoo Enterprise. Specifically, it improves how the system verifies notifications sent through the bus, ensuring more reliable test results. This change contributes to overall product stability and quality.
Original PR description
Enterprise counter-part. task-4715511 https://github.com/odoo/odoo/pull/253083/
This update fixes an issue where users weren't receiving email notifications for signature requests, even when their notification preferences were set to 'inbox'. Now, all signature requests will trigger email alerts, ensuring signers are promptly informed. The change preserves in-app notifications for users who rely on them.
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 resolves a small, technical issue with a message displayed within the documents generated for employee payroll. The fix ensures consistent and accurate document formatting, improving the overall user experience. This change does not impact business processes or functionality.
Original PR description
Task#5980045 Forward-Port-Of: odoo/enterprise#109063
This update ensures that payroll moves with analytic distribution rules are correctly anonymized, protecting employee privacy. The fix addresses a previous issue where lines weren't merged properly, leading to unnecessary detail in financial reports. This enhancement improves data security and compliance.
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#111705
Forward-Port-Of: odoo/enterprise#111140This update fixes an issue where salary deductions weren't being accurately calculated for certain payroll rules, specifically 'ATTACH_SALARY'. The changes ensure that these deductions are now correctly processed, leading to more precise net salary figures. This improves payroll accuracy and reporting.
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#111080 Forward-Port-Of: odoo/enterprise#107033
This update enhances the performance of Odoo's email functionality by utilizing record rules for access control, leading to more efficient database queries. The changes also address a security improvement by replacing a custom access check method with a more robust record rule approach. This results in a more stable and secure email experience for enterprise users.
Original PR description
Update of query count. odoo/odoo#254381
This update resolves an issue where users were directed to the wrong document form view when configuring PEPPOL document syncing settings. The change adds a dedicated Kanban view for PEPPOL documents within the settings, ensuring users access the correct document management interface. This improves the user experience and streamlines the process of 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#111765 Forward-Port-Of: odoo/enterprise#111341
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 date ('00000000') when a procuration date isn't 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 Forward-Port-Of: odoo/enterprise#109652
This update updates how Odoo retrieves configuration settings within the currency rate module. The change replaces an older method with the recommended approach, ensuring greater stability and compatibility with future Odoo versions. This improves the reliability of the currency rate calculations.
Original PR description
https://github.com/odoo/odoo/pull/223180 removes the `get_param` method from `res.config_parameter`, which was used in the `currency_rate_live` module. This commit replaces it with the `get_str` method, which is the recommended way to retrieve configuration parameters in Odoo. No task ID Forward-Port-Of: odoo/enterprise#110975
This update fixes an issue where subscription quotations weren't displaying correctly in the customer portal. Recent changes caused orders to be incorrectly directed to a general subscription page. Now, draft and sent subscription orders will correctly redirect users to their specific order details page, ensuring a smoother user experience.
Original PR description
Version: - saas~19.2 Steps to reproduce: - Create a subscription quotation. - Open it from the portal. Issue: - The portal view of the subscription quotation is not displayed correctly. Cause: - After recent changes, subscription orders were always redirected to `/my/subscriptions/` route. - This route renders the `subscription_portal_template`, which is not suitable when the order is still in draft or sent state. Solution: - If the subscription order is in draft or sent state, redirect the user to `/my/orders/<order_id>` instead. task-5966871 Forward-Port-Of: odoo/enterprise#108509
This update resolves issues where overtime calculations were incorrect due to timezone discrepancies, specifically impacting employees in UTC+ timezones. The fix ensures accurate overtime interval determination and prevents crashes related to overlapping attendances, while also correctly deleting stale overtime lines.
Original PR description
Steps to reproduce (singleton crash): Create an employee in a UTC+ timezone (e.g. Asia/Shanghai or Australia/Adelaide) with an overtime ruleset containing a paid rule. Generate work entries for a…
Steps to reproduce (singleton crash): Create an employee in a UTC+ timezone (e.g. Asia/Shanghai or Australia/Adelaide) with an overtime ruleset containing a paid rule. Generate work entries for a period, then create two consecutive midnight-to-midnight attendances in the employee's local timezone. Creating the second attendance crashes with: "ValueError: Expected singleton: hr.attendance.overtime.line(...)". Steps to reproduce (stale overtime lines): With the same setup, delete the attendance after it generated overtime lines. The overtime lines remain in the database instead of being removed. The singleton crash occurred because `end_of_day` in `_get_overtime_intervals` was computed as a naive datetime, implicitly treated as UTC. For UTC+ timezones, the actual local end of day is earlier than UTC midnight. As a result, overtime intervals were computed with a stop time extending past the real local midnight into UTC time. When consecutive attendances were processed together, these extended intervals overlapped. The `Intervals` class (`keep_distinct=True`) merges overlapping intervals into a single entry with a multi-record recordset as payload. The subsequent `overtime.rule_ids.work_entry_type_id` and `overtime.status` calls expected a singleton but received a multi-record set, causing the crash. The same multi-record issue also affected the iteration in `_set_real_overtime_intervals` and the overtime work entry loop in `_get_attendance_intervals`. The stale overtime lines issue occurred because `_get_overtimes_to_update_domain` (hr_attendance) built its search date range from raw UTC `.date()` values instead of the employee's local timezone. For UTC+ employees whose attendance spans local midnight, the overtime line is dated in the next local calendar day. Since the domain was derived from UTC dates, that next local day fell outside the search range, so the overtime line was never found and deleted when the attendance was removed. Solution: - In `_get_overtime_intervals`, localize `end_of_day` to the employee's timezone before converting to UTC, so overtime intervals are correctly bounded by the local end of day. - In `_set_real_overtime_intervals` and the overtime loop in `_get_attendance_intervals`, iterate over individual records from potentially multi-record `Intervals` payloads to avoid singleton errors. - In `_get_overtimes_to_update_domain` (hr_attendance), localize check_in/check_out to the employee's timezone before computing the date range so overtime lines for dates that only exist in local time are correctly included in the delete-and-recreate cycle. opw-5931665 Forward-Port-Of: odoo/enterprise#111684 Forward-Port-Of: odoo/enterprise#109419
This update resolves a bug where the 'documents' button on employee records incorrectly redirected users to the wrong domain, preventing them from accessing their documents. The fix ensures users are directed to the correct domain based on their login location, improving document access 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#110390
Forward-Port-Of: odoo/enterprise#107384This update resolves an issue where documents uploaded to the 'All' folder in the Documents app were not viewable through the bridge interface. The fix ensures that uploads to 'All' now default to the standard bridge folder, restoring full accessibility for users.
Original PR description
Problem: When a user uploads a document through a bridge to the Documents app, if the destination is set to the `All` folder, the file becomes unviewable from the bridge. It can only be accessed directly via the Documents app. Cause: This occurs because `All` is not an actual folder. Uploads directed to it default to the `My Drive` folder instead. Because `My Drive` is restricted and inaccessible via the bridge, the uploaded documents remain hidden. Solution: To solve this problem, this PR ensures that uploads directed to the `All` folder default to the default bridge folder rather than to `My Drive`. task-6023290 Forward-Port-Of: odoo/enterprise#111715 Forward-Port-Of: odoo/enterprise#111290
This update resolves two critical bugs preventing new employee creation in the Belgian payroll module. The first issue involved duplicate record creation due to a mail activity trigger. The second bug occurred when the payroll system attempted to link to a non-existent record before it was fully saved. These fixes ensure proper employee setup and data integrity.
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 Forward-Port-Of: odoo/enterprise#111780 Forward-Port-Of: odoo/enterprise#109799
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 are used 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#111753 Forward-Port-Of: odoo/enterprise#111275
This update resolves a technical error that prevented users from completing the checkout process within the Enterprise module. The issue stemmed from an outdated reference to a property name, which has now been corrected. This ensures a smoother and more reliable user experience.
Original PR description
Steps to reproduce: - In the home menu of a database, click on the ActivityMenu at top of page (red dot) - Click check in - Click ActivityMenu (green dot) again and click check out Current behavior: - Traceback saying this.displayAllowBillable is not a function Expected behavior: - No error Note: displayAllowBillable was renamed to displayIsBillable in this commit https://github.com/odoo/enterprise/pull/110708 opw-6061392 Forward-Port-Of: odoo/enterprise#111850
This update resolves a warning appearing in the Time Off popup within the Odoo Enterprise demo payroll module. The change removes unnecessary data dependencies, allowing the system to automatically calculate time off balances correctly. This ensures accurate reporting and a smoother user experience for payroll administrators.
Original PR description
. Remove payslip_state for hr.leave(178) to be automatically computed . Add corresponding tests task-6044925
This update resolves a technical issue that was preventing updates to the AI module. The fix ensures the system correctly verifies changes to the AI model, preventing crashes and allowing updates to proceed smoothly. This improves the stability and reliability of the AI functionality.
Original PR description
Prior to this commit one could not run the update of `ai` module because of a constraint on the write method which would cause it to crash. The constraint checked for modification to the `llm_model` without checking that the model was actually different from the original model assigned to the image generation agent. With this commit, we add a condition to check that the `llm_model` in the values is different form the one currently assigned to the image generation agent.
This update removes a specific exception (JC 999) from minimum wage checks within the Odoo Enterprise Belgian payroll module. This change ensures more accurate compliance with Belgian labor laws and avoids potential warnings for employees classified as JC 999. Associated tests have been added to verify the updated functionality.
Original PR description
. Exclude JC 999 from minimum wage checks in both versions and offer versions . Add corresponding tests task-6055486
This update restores the appointment synchronization onboarding banners, which guide staff users to connect their Google and Microsoft calendars. These banners also display a warning for users with Google Meet set up on appointments, ensuring correct meeting links are added.
Original PR description
: appointment{_google,_microsoft}_calendar This is a revert commit of [1] reintroducing the appointment_microsoft_calendar module, as we bring back the synchronization onboarding banners on the…
: appointment{_google,_microsoft}_calendar
This is a revert commit of [1] reintroducing the
appointment_microsoft_calendar module, as we bring back the
synchronization onboarding banners on the appointment.type
form view that were removed in [1]
- A banner includes a shorcut to setup / connect google /
outlook external calendars as well as an informative message.
- A banner is a warning banner on staff users without
active synchronization in the case of google_meet set up
on the appointment, as those will not have a google_meet
link correctly added to their meetings.
Note: as the original commit removed the whole module
appointment_microsoft_calendar, the revert would also
reintroduce i18n files. To allow a clean module reintroduction,
we do not keep them in this revert commit.
In a separate commit, reintroduce the helper for the field
event_videocall_location.
[1] https://github.com/odoo/enterprise/commit/c64e3435db792508ecec0b25dd25dc6e9360fc63.
Task-5969306This update prevents partner address changes from erasing previously stored location coordinates. This ensures automatic lead assignments continue to function correctly and avoids disruptions for partners relying on their existing geolocation data. Users can still manually update coordinates if needed.
Original PR description
Previously, updating a partner address reset latitude and longitude to 0.0. This removed existing coordinates and could prevent automatic lead assignment. With this change, coordinates are preserved when the address is modified. This avoids losing existing coordinates and allows partners to continue receiving leads based on their stored geolocation. Users can still manually refresh the geolocation if updated coordinates are required. Task-4812621
This update fixes an issue where payroll attendance calculations were incorrectly high when public holidays were present. The change ensures accurate attendance amounts by properly accounting for public holiday hours, preventing inflated attendance figures.
Original PR description
Fixes the calculation of the worked day lines amount, in cases where a public holiday is set. The current computation doesn't account for hours of public holiday when calculating the attendance amount; causing it to be higher than expected. This is caused by the calculation of work_time, which comes from the calendar data from _work_intervals_batch. If there is a public holiday, the work interval for that day is being removed from the result, causing it to wrongly calculate a lower work_time than expected and increasing the attendance line amount. task-5979501 Forward-Port-Of: odoo/enterprise#111819 Forward-Port-Of: odoo/enterprise#111741
A recent update to Odoo Enterprise prevented the deletion of automatically created approval rules within the Studio module. This issue arose during an upgrade from version 18.0 to 19.0 and resulted in data inconsistencies. The fix ensures these rules are created with a safeguard to prevent accidental deletion.
Original PR description
Server and automated actions created by the ORM for the purpose of revoking approval rights are created without `noupdate=True` which leads to said records being removed by the ORM becuase of not being found in the source. Such records created on the fly should have `noupdate=True` to prevent that from happening. This bug can be reproduced by going to Settings > Technical > User Interface > Studio Approval Rules and creating a new record from there and updating `web_studio`. The update will drop the record from the database. Issue originally detected in the upgrade process from 18.0 to 19.0. This fix will be complemented by an upgrade script that fixes erronous records. Forward-Port-Of: odoo/enterprise#110065
This update removes a previous restriction that prevented users from adjusting production quantities on work orders when quality checks were marked as complete. Now, changes to the work order quantity automatically update related quality checks, streamlining the production process and eliminating a potential bottleneck. This improves efficiency and accuracy in managing work orders.
Original PR description
Initially users were blocked from splitting or updating quantity to produce if we have quality check points marked as complete as an old limitation in odoo/enterprise#5193, That doesn't exist anymore. Now when the quantity is updated in MO its also updated for quality checks in shopfloor. Task: 5438445
This update fixes an issue where project budget totals were incorrectly summing expenses and revenue. The fix adjusts how the system calculates totals, ensuring accurate reporting of project spending and allocated funds. This improves the reliability of project financial data.
Original PR description
### Steps to reproduce: - Create a billable project - Create two budgets one expense and the other revenue or both each for 100$ - Create a vendor bill with the analytic account of the created project - Notice in the project dashboard the two budgets are summed up in the total ### Cause: When calculating the total spent and total allocated we add up the amount whether it is an expense or revenue. https://github.com/odoo/enterprise/blob/1dccb87a48ac44735da4c78594e37d4783789cd6/project_account_budget/models/project.py#L120-L121 ### Fix: Set the expense budget to -ve and the revenue/both to +ve amount when calculating the total spent and total allocated opw-5488131 Forward-Port-Of: odoo/enterprise#106504
This update enhances payroll processing, particularly for employees with changing contracts during a pay period. The system now intelligently adjusts calculations to prevent overpayment of contributions and allowances, ensuring accurate payroll processing, especially in Hong Kong.
Original PR description
This commit aims to provide better support for contract changes that happen in the middle of a pay period. It has a few impacting changes, notably: 1) Payslip calculation sequencing As of now, all…
This commit aims to provide better support for contract changes that happen in the middle of a pay period. It has a few impacting changes, notably: 1) Payslip calculation sequencing As of now, all payslips of a same payrun have their line calculated all at once. While this is better for performances, it has a negative effect when a single employee has multiple payslips in the same payrun. In such cases, we may want or need for the payslips to know what was already calculated in the same payrun to avoid overpaying contributions or allowances that have caps. To solve this issue, we now group payslips by employee, sort them chronologically, and evaluate them in horizontal "layers": - Layer 1: Computes the 1st payslip for ALL employees simultaneously. - Layer 2: Computes the 2nd payslip for the subset of employees who have one, etc 2) More tools in HK payroll to support these cases The payslip rules now have a `l10n_hk_payrun_totals` dict that contains the total amount already reported in previous payslips of a same payruns for a selection of rules that needs it. We also provides a `worked_days_prorata_rate` which gives the ratio of worked days vs unworked days in a month for cases where we need to adjust amounts based on that ratio. 3) Rule updates The last part of the fix requires some updates in a few rules that are fixed amounts/not based on the wage and ends up being counted double in our use case. These rules will now take into account already computed amounts as said above to avoid going over the limit. In most cases it will only affect that specific use case, with a small exception for fixed mpf voluntary contributions, which have been updated to be prorated based on the worked days in the month. Forward-Port-Of: odoo/enterprise#111814 Forward-Port-Of: odoo/enterprise#111570
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 automatically link to the same source document, maintaining data relationships. This improves data integrity and simplifies spreadsheet workflows.
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#111569 Forward-Port-Of: odoo/enterprise#110047
This update corrects a rounding error in the US payslip PDF that was causing incorrect overtime rates, particularly for very small overtime durations. The fix changes how the rate is calculated directly on the work entry, ensuring accurate overtime pay is displayed. This improves the reliability of payroll reports.
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 Forward-Port-Of: odoo/enterprise#111733
This update resolves an issue where equity transactions couldn't be created in currencies other than the company's default (USD). Now, users can set the equity currency for the first transaction, ensuring flexibility in recording equity values. Subsequent transactions automatically use this chosen currency.
Original PR description
### Issue: When a company is set in USD, it was not possible to create equity transactions in another currency (e.g., EUR) ### Cause: The equity_currency_id is initialized with the company currency at partner creation (or module installation) However, there was no way to override this value when creating transactions ### Fix: It is now possible to set the equity currency on the first transaction Subsequent transactions reuse this currency and the field becomes read-only ### Steps to reproduce: - Install `equity` with demo data (currency and equity_currency default to USD) - Enable the EUR currency - Create an equity transaction for a company - You can now choose EUR on this transaction - Create another transaction for the same company, the selector is hidden and the currency remains EUR opw-5382255 Forward-Port-Of: odoo/enterprise#108248
This update resolves an issue where ISO20022 XML files generated for Swiss companies were being rejected by banks due to an outdated configuration. The fix ensures the correct 'PAIN 09' format is used, guaranteeing compatibility with Swiss banking standards after database migration. This prevents delays and errors in financial transactions.
Original PR description
To reproduce the issue:
- Create a database in 17.0, with a Swiss company, and install account_sepa. Make sure the bank journal uses the Swiss IS020022 PAIN version.
- Migrate this database to 18.0
- Generate an ISO20022 xml file for the Swiss company
==> The file is wrongly formatted, and will be rejected by the bank.
This happens because the sepa_pain_version field of the journal is still set to its old selection value ('pain.001.001.03.ch.02') after migration, which is not supported anymore. The ORM hence returns an empty value when accessing the selection field, and does not enter the proper conditions when generating the file.
An upgrade fix has been made here https://github.com/odoo/upgrade/pull/9771. This commit makes sure already-migrated databases dynamically fix the issue as well.
opw-6060612
Forward-Port-Of: odoo/enterprise#111949This update resolves a technical issue where reports were failing to load correctly on some migrated databases. The change adds a backup system to automatically identify and use account codes when the standard XMLIDs are missing, ensuring reports run smoothly without warnings. This improves the reliability of our financial reporting.
Original PR description
Description of the issue this commit addresses: On some migrated BE databases, account template refs a4121/a4521 are missing as XMLIDs. l10n_be_reports then fails to recover partner/reconcile account refs and logs warnings during post-init load. --- Desired behavior after this commit is merged: This commit adds a fallback in BE report chart template data to resolve a4121/a4521 by account code when XMLIDs are missing, preventing recovery warnings while keeping normal XMLID behavior unchanged. --- runbot-[233845](https://runbot.odoo.com/odoo/runbot.build.error/233845) Forward-Port-Of: odoo/enterprise#111325
This update fixes a potential issue where a user could indirectly change an employee's work email through contract settings. Previously, linking an employee to a user allowed for unintended email updates. Now, the system ensures the work_email remains consistent when an employee is associated with a user, improving data integrity.
Original PR description
Due to https://github.com/odoo/enterprise/pull/106974,the employee's work_email may be reset to False when creating or updating an offer. This behavior is acceptable if the employee does not have a linked user. However, if the employee is linked to a user, resetting work_email can allow a user to indirectly modify their own work_email through salary confi. To prevent this, we now ensure that work_email never changes if employee has a user linked to it. Steps to reproduce: - Hire an applicant from Recruitment (the employee has no work_email). - Set a random work_email and create a user for the employee. - Open the hired applicant and create a new offer to update the contract. - work_email should not be modified, even after new contract. task: 6033382 Forward-Port-Of: odoo/enterprise#111815 Forward-Port-Of: odoo/enterprise#110810
This update resolves a problem where reports with annotations were failing to export correctly. The previous filtering process was redundant, and the unnecessary date filters have been removed. This ensures reports with annotations now export reliably.
Original PR description
[FIX] account_report: Unable to export Report with Annotations Following changes to the date filter in https://github.com/odoo/enterprise/pull/98695, the date options can be missing a date_from (For example, when using period type: "today"). The date were used to filter on the annotations to display during the period of the report. However, we already filter on those date when generating the annotations so this was redondant and can be safely removed. To reproduce: - Open the Balance sheet - Open the chatter of any account and post a message - Click on the "PDF" button to export the report Forward-Port-Of: odoo/enterprise#109984
This update resolves an issue preventing superuser administrators from deleting work entry types within the Odoo payroll module. This change allows for greater flexibility in managing payroll configurations and correcting errors. It's a technical fix to improve administrative control.
Original PR description
Forward-Port-Of: odoo/enterprise#111967
Features or functions removed from Odoo
This change removes a redundant field related to tracking payslip documents with tags. The feature was no longer required and has been removed from the system configuration and associated files. This simplifies the system and reduces potential maintenance overhead.
Original PR description
According to the linked task, the documents_hr_payslip_tags field is no longer needed, therefore we can remove the override of the view adding it and the field on res_config_settings (we remove the whole file since it was the only thing that it was changing). Finally we also remove the documents_tag_payslips record, which was used as a default tag but is no longer needed. Task: 5936989
4 changes
Resolved issues and error corrections
This update fixes a minor issue where the Direct Deposit module's documentation link was incorrectly pointing to SEPA documentation. Now, the link accurately directs users to the correct documentation for US Direct Deposit setup. Future versions (19.1+) will have the documentation adjusted as well.
Original PR description
When the Direct Deposit module was merged there were no docs created yet, as such we linked to the SEPA documentation temporarily. Now that it has been merged, we update the link to point to the right documentation. Note that in 19.1+ there is no documentation linked in `l10n_us_account` and as such that will be adjusted in the forward port. task-none
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 date ('00000000') when the 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 Forward-Port-Of: odoo/enterprise#109652
This update resolves an issue where documents uploaded to the 'All' folder in the Documents app were inaccessible through the bridge interface. The fix ensures that 'All' folder uploads now correctly default to the standard bridge folder, restoring full accessibility for users.
Original PR description
Problem: When a user uploads a document through a bridge to the Documents app, if the destination is set to the `All` folder, the file becomes unviewable from the bridge. It can only be accessed directly via the Documents app. Cause: This occurs because `All` is not an actual folder. Uploads directed to it default to the `My Drive` folder instead. Because `My Drive` is restricted and inaccessible via the bridge, the uploaded documents remain hidden. Solution: To solve this problem, this PR ensures that uploads directed to the `All` folder default to the specific bridge folder rather than to `My Drive`.
This update addresses a compatibility error related to Python version 3.10 on Ubuntu Jammy. The change prevents a type-checking error that would have occurred when running the GoFood order platform. The fix ensures the system continues to function correctly without requiring a newer Python version.
Original PR description
NotRequired is only available starting with Python 3.11. While not blocking, this generates an error when running on Ubuntu Jammy, which provides Python 3.10. This commit gates the types import only during type checking. runbot-241253
8 changes
Resolved issues and error corrections
This update resolves an issue where fields weren't being populated correctly when new records were created in certain Odoo modules. The fix ensures that fields are properly filled in during the creation process, improving data accuracy and reliability. This primarily impacts HR and reporting functionality.
Original PR description
See https://github.com/odoo/odoo/pull/199647. Forward-Port-Of: odoo/enterprise#109725
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 the 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 Forward-Port-Of: odoo/enterprise#109652
This update fixes a discrepancy in how tax reports are tested within Odoo. The change ensures tests now correctly utilize the 'invoice_label' field for tax information, rather than the 'name' field. This improves the accuracy and reliability of tax report generation across various Odoo localization modules.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/236497 Forward-Port-Of: odoo/enterprise#103555
This update resolves a compatibility issue with the website knowledge editor's HTML migrations. The change utilizes a more widely supported selector (`selectorHas`) instead of `:has`, ensuring consistent functionality across different browsers. This improves the stability and reliability of the knowledge base feature.
Original PR description
The `:has` selector is not yet fully supported by `querySelectorAll` in all browsers. Public widgets have the `selectorHas` attribute to get arround this. opw-4658698
This update removes a confusing purple pill that appeared on mobile devices when using Web Studio. This prevented users from easily clicking action buttons, leading to a frustrating experience. The change ensures a cleaner and more intuitive interface for mobile users.
Original PR description
Steps: - Install `web_studio` - Add an approval rule to any action in any form view (example preview button) - Open this form view - You will have a purple info pill in every action button in the form view This can be confusing for people wanting to click on the button on mobile but instead, they click on the purple pill + we don't even want this opw-5911667
This update resolves an issue where saving a report with an empty XML format in Web Studio would generate an error. The fix prevents the system from attempting to process invalid XML data, ensuring reports can be saved correctly. This improves the user experience and prevents data corruption.
Original PR description
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External…
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External > Type Text in report - Save > Edit Sources > Remove full XML > Save Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)` This error occurs because line [1] in `web_editor` attempts to access nodes by using `etree.fromstring()` with an empty `view.arch`, which is empty, resulting in an error. In earlier versions, this error was already handled by the `_check_xml` constraint, which raised a validation error when an `etree.ParseError` occurred while parsing `etree.fromstring(view.arch)` with an empty `view.arch` (see code reference [2]). However, recent changes introduced in commit [3] allow `view.arch` to be empty. As a result, this error is no longer handled by the constraint. This commit fixes the issue by adding a condition to prevent calling `etree.fromstring()` when `view.arch` is empty, avoiding attempts to access nodes from invalid data. It also updates the logic in the `web_studio` module's `get_xml_editor_resources` method to ensure resources are processed only when a valid view architecture is available. [1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367 [2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377 [3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f sentry-6288795955
This update fixes a previous issue where the data merge process would fail silently if it timed out. Now, users will receive a warning notification, and the system suggests merging fewer records for a smoother experience. Reloading the model on successful completion ensures data accuracy.
Original PR description
Display a warning notification when the merge operation times out instead of failing silently. Suggest merging fewer records and reload the model on success. task-5912855 Forward-Port-Of: odoo/enterprise#110763
This update fixes an issue where the canteen cost was incorrectly calculated for Belgian employees, even when they had no attendance recorded. The fix ensures the canteen cost is only applied if the employee has earned money through attendance or working during the payslip period, preventing incorrect charges.
Original PR description
[FIX] l10n_be_payroll: fix canteen cost computation
Bug reproduction: belgium company -> create a new employee -> new contract (payroll wage > 0) -> canteen_cost = 50 -> create payslip -> allocate time off for full month (such that there will be no attendance) -> recompute payslip -> still canteen cost is calculated
Bug cause:
1 - If l10n_be_canteen_cost is > 0 it was computing the canteen cost line for sure
2 - If result_rules['BASIC']['total'] is > 0 then the canteen cost was 50.
Bug solution:
1 - I add worked_days['WORK100'].amount != 0 to the computation condition.
2 - If there is any earned money from attendance or working in that payslip duration, the canteen cost should be deducted completely
3 - If the employee is absent during the payslip, the employee should not pay the canteen cost.
task - 6045406
Forward-Port-Of: odoo/enterprise#1109913 changes
Resolved issues and error corrections
This update resolves a bug where portal users received blank or incomplete PDFs when printing knowledge articles. The fix ensures the necessary printing styles are loaded automatically, regardless of the print method (Ctrl+P or export), improving the user experience for all portal users. This change enhances the usability of our knowledge base.
Original PR description
Steps to reproduce ================== 1. Log in as an admin. 2. Go to any article and share with the portal. 3. Log in as a portal. 4. Open the shared article. 5. Press `Ctrl + P` or export from…
Steps to reproduce ================== 1. Log in as an admin. 2. Go to any article and share with the portal. 3. Log in as a portal. 4. Open the shared article. 5. Press `Ctrl + P` or export from topbar. Results showing `Export` and `Ctrl + P` works for which users: | Version | Export | Ctrl + P | | ------- | ------------- | ------------- | | 17.0 | Admin, Portal | None | | 18.0 | Admin | None | | 18.2 | Admin | Admin | | 18.3 | Admin | Admin, Public | | 18.4 | Admin | Admin, Public | | Master | Admin | Admin, Public | Technical ========= In 17.0, `Ctrl + P` printed blank PDF because the required style assets `knowledge.assets_knowledge_print` was loaded only on clicking `Export` button. From 18.0, this asset was moved to the bundle `web.assets_web_print` to use style for printing. Though this bundle is not loaded for portal and public users. Note: For all versions, public users got the incomplete PDF on pressing `Ctrl + P`. After this commit, we will load this asset bundle before printing. Task-4797552
This update ensures that reports display decimal numbers using the correct format based on the user's language settings (e.g., comma instead of a dot). Previously, the system always used a dot, which could lead to confusion for users in different regions. This change improves the user experience and data clarity.
Original PR description
Description of the issue this commit addresses: The external value pop up doesn't take into account the locale to chose which decimal separator to use. --- Desired behavior after this commit is merged: The decimal separator is the one determined by the language of the user rather than always a dot. --- task-6010533
This update resolves an issue preventing web push notifications from functioning correctly in Firefox. The fix involved switching to a compatible import method for Firebase libraries, addressing a technical incompatibility that was blocking notification delivery.
Original PR description
Currently, web push notifications do not work on Firefox. ### Steps to reproduce * Install `social_push_notifications`. * In the settings, enable and set up web push notifications. * Go to the website and wait a few seconds. A small window will open, asking if you want to allow notifications. * Click "Allow," and another window will open. * Click "Allow" again. You will be met with a traceback. ### Cause The service worker imports Firebase libraries using ECMAScript module imports, which Firefox does not support in service workers. Additionally, one of the Firebase modules itself contains an ECMAScript import, making it unusable in this context. ### Fix * Use `importScripts` instead of ECMAScript module imports. * Use the compatibility version of the Firebase libraries to avoid ECMAScript imports inside the libs themselves opw-4629623 opw-4551502