Daily updates from Odoo
Friday, February 27, 2026
39 changes · master
New functionality added to Odoo
This update enhances payment advice reports by including the beneficiary account used for salary adjustments. This provides greater transparency and clarity for payroll reporting, ensuring accurate record-keeping and compliance with In-country regulations. This change improves the reporting accuracy for employee compensation details.
Original PR description
-The beneficiary account details for the salary adjustment has been added to the payment advice report.
This update introduces a new Fixed Asset Listing (FAL) report for the Book of Accounts, specifically designed to meet BIR reporting requirements in the Philippines. The report allows exporting data in both CSV and PDF formats and includes custom filters for asset status and model, ensuring accurate reporting of assets, including historical and indefinite-life assets.
Original PR description
Todo: - [x] complete the 2 custom filters (finish up the WIP js) - [x] PDF export (aims the GL for some reason, should be simple targeting the selected_section_id or smth) - [x] CSV export (simple)…
Todo: - [x] complete the 2 custom filters (finish up the WIP js) - [x] PDF export (aims the GL for some reason, should be simple targeting the selected_section_id or smth) - [x] CSV export (simple) ~~- [ ] make `_build_custom_columns()` into a parent helper (and give it a better name) with GJ~~ - [x] handle the changes in https://github.com/odoo/enterprise/pull/102950 if merged before - [x] ^ stuff like the updated `method_number` - [ ] https://github.com/odoo/enterprise/pull/102808 --- ## [ADD] l10n_ph_reports_asset: Subsidiary BOA - Fixed Asset Listing This commit adds the Fixed Asset Listing (FAL) subsidiary report to the Book of Accounts. It, like all other BoA reports, supports export in .csv and .pdf formats as required by the BIR. This report introduces 2 custom filters for Asset Status and Asset Models that are fully-supported in the PDF export. --- Technical Choices: - **Entity-First Strategy:** Unlike standard transaction-based reports (GL), this report uses a registry-based query (`FROM account_asset`). This ensures visibility for historical assets with no current depreciation), indefinite-life assets (e.g., Land), and simulated assets. - **Date Overlap Logic:** The date range filtering will show assset lines that are running or projected to run. We determine asset end of life by disposal date (if applicable) or useful life. We also handle infinite life assets (method_number = 0). - **Custom Filters**: They are designed as dropdown selects with UI behavior mimicing filter_journal. Supports multi-company. Asset Model filter will be hidden if there are no Asset Models created. - We deduplicate column values across colgroups for ease of reading. - Accumulated Depreciation column will only show depreciation AMLs. This excludes modifications to depreciations such as selling and disposal. Changes summary: - Add `l10n_ph.boa.fal.report.handler` abstract model. - Add `L10nPhBoaFalReportFilters` and it's PDF export display - Add CSV and PDF export templates. Testing/Verification: Includes snapshot testing of the web view and csv export data and some extra tests to check for these features: - Indefinite life assets (e.g., Land with 0 duration) - Historical assets (acquired years ago, still running) - Future/Simulated assets (Draft state with analytic distribution) - Custom filters work as intended task-[5419877](https://www.odoo.com/odoo/action-4043/5419877) Forward-Port-Of: odoo/enterprise#103209
This pull request enhances Odoo's data cleaning capabilities with new models and views designed to improve data quality and consistency. The changes focus on unifying and merging data from different sources within the system, ultimately leading to more reliable reporting and business insights.
This update allows users to directly link materials to specific employees within planning schedules. When an employee is assigned to a planning slot, the associated material is automatically added to the resources, streamlining resource allocation and shift assignments. This improves planning efficiency and accuracy.
Original PR description
In this commit, we add a field "Assigned To" to materials. This allow users to assign one employee to the material. With that, when adding an employee to a planning slot, its assigned material will automatically added to the resources, and a shift will be assigned to it. task-5259038
Enhancements to existing features
This update allows users to easily negotiate salaries based on net amounts, making it simpler to understand employer costs and employee compensation. Previously, users had to manually calculate net figures, which is now streamlined for a better user experience. This change improves employee engagement and simplifies payroll simulations.
Original PR description
For users it is often easier to negotiate/talk with employee based on a net amount and simulate what will be the employer cost but currently the user has to do a simualtion base on monthly gross and search until he finds the net he wants. task-5925813
This update ensures that employee names are displayed in their full, correct length on pay run reports. Previously, names were truncated, which could lead to confusion and errors when reviewing payroll data. This change improves clarity and accuracy for HR and finance teams.
Original PR description
. Display Employee name in ful length on pay run listview task-5916582
This update standardizes timesheet data storage to always use hours in the database, simplifying calculations and improving accuracy. Previously, inconsistencies with day-based storage led to frontend errors. This change impacts several key modules related to timesheet management.
Original PR description
Impacted modules: - helpdesk_timesheet - timesheet_grid After this commit, timesheets will always be stored in hours in database, the field project_time_mode is therefore not needed anymore. task-3508445 related-https://github.com/odoo/odoo/pull/143171
This update simplifies the Hong Kong payroll module by fully integrating eMPF (employee MPF) support. Previously a temporary workaround, this change removes redundant code and aligns the module with current Hong Kong payroll standards. This improves the system's efficiency and reduces complexity.
Original PR description
Previously, `l10n_hk_hr_payroll_empf` was introduced in version 19 as a temporary solution for stable releases. Its purpose was to support the new system while hiding deprecated views and ensuring new users received the correct version via auto-installation. Now that the feature is fully supported, the separation is no longer necessary in master. This commit merges the `l10n_hk_hr_payroll_empf` logic directly into `l10n_hk_hr_payroll`. This simplifies the codebase and aligns the module with standard Hong Kong payroll requirements. The legacy provider-specific feature for Manulife is also removed. Task-5437968
This update enhances the Swiss payroll module's functionality within organizations with multiple companies. It restricts modifications to Swiss company settings and restores access to related features while ensuring appropriate error handling when accessed from the Swiss context. This improves the stability and usability of the module for businesses operating across different regions.
Original PR description
- Restrict all form modifications to Swiss companies. - Restore visibility of the related menu items, but raise appropriate errors when accessed from Swiss companies. Task: 5130161
This update streamlines the restaurant order process by automatically sending pending changes to the kitchen when an order is validated on the payment screen. Previously, a confirmation pop-up was required, but this change removes that step and simplifies the workflow for staff. This improves efficiency and reduces potential errors.
Original PR description
pos_*: pos_restaurant_preparation_display, l10n_de_pos_res_cert Before this commit: ========== - In restaurant mode, when navigating to the payment screen, if the order still had unsent changes for the kitchen, a confirmation pop-up was displayed before sending them. After this commit: ========== - Any pending changes are automatically sent to the kitchen upon validation on the payment screen, removing the need for the confirmation pop-up and streamlining the workflow. Related PR: - https://github.com/odoo/odoo/pull/237731 Task-5321557
Resolved issues and error corrections
This update resolves an issue where the 'account_iso20022' module was generating invalid XML for Swiss payment files (pain.001). The fix ensures that only one of BIC or ClrSysMmbId is included, aligning with Swiss banking standards. This prevents payment processing errors and ensures compliance.
Original PR description
**Steps to reproduce:** - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor…
**Steps to reproduce:** - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor bill for a Swiss partner or payrun report - Pay with "Swiss ISO20022" > generate xml pain001 - Validate against xsd or any swiss pain001 test plateform > Incorrect rules usage ! not valid xml ! **Cause:** In the XML the field BIC and ClrSysMmbId are present. Only one of them can be present. See the [documentation (page 27 and 33)](https://www.six-group.com/dam/download/banking-services/interbank-clearing/fr/standardization/iso/swiss-recommendations/archives/implementation-guidelines-ct/implementation-guidelines-ct_v1_6_1.pdf). **Solution:** Create the method `_get_ClrSysMmbId()` which will only return for Swiss if there is no BIC number. This is a partial unrevert of [this commit](https://github.com/odoo/enterprise/commit/177c7bbc890c3d142010de2cb7d0d9d6752c7fd9#diff-282e44e861d61542f3bc6d40e61b73fd1556f659d53ecd8bf9430dcec79c2fd6). opw-4872507 Forward-Port-Of: odoo/enterprise#108796 Forward-Port-Of: odoo/enterprise#108461
This update streamlines the process of finding or creating bank accounts within Odoo Enterprise. The changes consolidate how bank accounts are handled across multiple modules, reducing potential errors and improving data consistency. This enhancement ensures more reliable financial transactions and reporting.
Original PR description
*: account_invoice_extract,hr_constract_salary,payment_sepa_direct_debit Forward-Port-Of: odoo/enterprise#108238
This update resolves an issue where a specific configuration of salary inputs on employee records would cause a calculation error during payslip generation. The fix prevents the system from incorrectly interpreting a hidden input field as a valid number, ensuring accurate payroll processing. This improves the reliability of payslip calculations.
Original PR description
**Steps to reproduce** - Have a salary rule - Condition based on: Salary Input - Input on: Employee - On the employee form, click on "Add inputs" in the Payroll tab - Add an input - Enter a value - Click on "Inputs" to fold the section and hide the input - Try to compute a new payslip for this employee, error: `ValueError: invalid literal for int() with base 10: 'separator_1'` **Cause** By default, the separator doesn't have a `value` key, but after the first interaction to hide its elements, it is added to keep track of the folded state (see `_toggleSeparators` in `web`). **Solution** Ensure separators are ignored. opw-5928247 Forward-Port-Of: odoo/enterprise#108731 Forward-Port-Of: odoo/enterprise#107326
This update fixes the XML templates used for generating Dutch SBR and ICP tax reports, aligning them with the latest 2026 version of the Dutch taxonomy. This ensures accurate reporting for our Dutch customers, complying with regulatory requirements and improving the reliability of financial data.
Original PR description
Fix the xml SBR and SBR ICP file template for the 2026 version of dutch taxonomy Documentation: https://www.sbr-nl.nl/werken-met-sbr/taxonomie/documentatie-nederlandse-taxonomie task-5974129
This update fixes an issue where the payroll update process would fail when a common working schedule was deleted. The fix ensures that the system correctly handles situations where a referenced schedule is no longer present, preventing errors and maintaining accurate payroll calculations. This impacts all localized payroll modules.
Original PR description
*:ae,au,bd,be,ch,eg,id,jo,ke,lt,lu,ma,my,nl,pk,pl,ro,sk,tr,us When the ``Standard 40 hours/week`` working schedule is deleted and the ``Payroll: Update data`` cron runs, a traceback is raised. For…
*:ae,au,bd,be,ch,eg,id,jo,ke,lt,lu,ma,my,nl,pk,pl,ro,sk,tr,us
When the ``Standard 40 hours/week`` working schedule is deleted
and the ``Payroll: Update data`` cron runs, a traceback is raised.
For ``l10n_us_hr_payroll`` module
Steps to reproduce the error:
- Install ``l10n_us_hr_payroll`` module with demo data
- Go to Employees > Configuration > Settings > Change Company Working Hours
- Go to Working Schedules > Delete ``Standard 40 hours/week`` working schedule
- Run the ``Payroll: Update data`` cron
Traceback:
```py
ValueError: External ID not found in the system: resource.resource_calendar_std
ParseError: while parsing /home/odoo/src/enterprise/l10n_us_hr_payroll/data/hr_payroll_structure_type_data.xml:3, somewhere inside <record id="structure_type_employee_us" model="hr.payroll.structure.type">
<field name="name">United States: Employee</field>
<field name="default_resource_calendar_id" ref="resource.resource_calendar_std"/>
<field name="country_id" ref="base.us"/>
</record>
```
The ``Payroll: Update data`` cron updates payroll data that references
the ``Standard 40 hours/week`` working schedule.
If the user has deleted this working schedule, the external ID no longer exists,
leading to the above traceback.
sentry-7166574553
Forward-Port-Of: odoo/enterprise#108730
Forward-Port-Of: odoo/enterprise#106950This update resolves a technical issue preventing the account reports annotation tour from functioning correctly. The change adjusts the confirmation button used in the tour to align with recent styling updates, ensuring the tour operates as intended. This improves the user experience for accessing and utilizing the account reports feature.
Original PR description
This PR updates the account reports annotation tour to use the correct confirmation button after the dialog styling change, fixing the failing test trigger. community: https://github.com/odoo/odoo/pull/247708 task-5873845 Forward-Port-Of: odoo/enterprise#108806
This update resolves an issue where the tax report export button wouldn't work correctly when companies had different VAT numbers and branches. The fix ensures the button correctly considers the entire branch hierarchy, allowing users to export reports for all relevant companies. This improves the accuracy and usability of the tax reporting feature.
Original PR description
To reproduce the issue: - Create a company with a branch - Give the company and its branch different VAT numbers - Make both companies active in the company selector - Open the tax report - Click on gear icon - Click on the XML(l10n_lu_reports)/Export SAWT & QAP(l10n_ph_reports) button ===> The following error is raised: "Please select the main company and its branches in the company selector to proceed." This is because the tax report's options only consider one of the two companies (because they have different VAT numbers). The button is not declared as branch_allowed, so when clicked, it checks whether all the companies of the branch hierarchy are in the options => they're not => error. We can fix this by simply making the buttons branch_allowed. Followup on: https://github.com/odoo/enterprise/commit/34ba0609e984496f0dcc862f0d7a46c6721beab9 task-5416330 Forward-Port-Of: odoo/enterprise#105961
This update fixes an issue where the system incorrectly identified companies in certain localization modules (Brazil and Ecuador). Now, Brazilian partners with a CNPJ and Ecuadorian partners with a RUC are correctly recognized as companies. For other countries, a partner is considered a company if a VAT is provided.
Original PR description
`is_company` was not correctly computed in some localization modules. This commit adds a compute method for: - l10n_br*: Company if identification type is CNPJ - l10n_ec*: Company if identification type is RUC For foreign partners (country ≠ BR/EC), a partner is considered a company if a VAT is provided. Follow-up of: https://github.com/odoo/enterprise/pull/86089 Task-5947797 Forward-Port-Of: odoo/enterprise#108599 Forward-Port-Of: odoo/enterprise#107674
This update corrects a potential data issue where OCR processing of CVs could incorrectly overwrite existing contact information (like company or user details) within the system. The fix adds safeguards to ensure OCR data is only applied when appropriate, preventing inaccurate data propagation. This ensures data integrity for applicant records.
Original PR description
When OCR processes a CV, it writes extracted name/email/phone onto the applicant, which then propagates to the linked res.partner via the email_from inverse. This causes data corruption in two cases: - The CV was forwarded: the OCR email belongs to the candidate but email_from is the forwarder's address. Writing OCR data would overwrite the forwarder's partner with the candidate's details. - The existing partner is a company contact (parent_id set) or is linked to a user account (user_ids set). Writing OCR data would overwrite user/business partner with the candidate's details. Both guards are applied and added tests that check the flows. task-5949635 Forward-Port-Of: odoo/enterprise#108128
This update fixes an issue where rental accessories added from the cart's suggested products wouldn't consistently apply the correct rental period. Now, when adding accessories from the cart, the system uses the existing cart's rental period, ensuring accessories are added correctly and preventing errors. This improves the user experience for rental product purchases.
Original PR description
Why this commit --- When adding a rental accessory product from the cart page suggested products, the…
Why this commit --- When adding a rental accessory product from the cart page suggested products, the [add_to_cart](https://github.com/odoo/enterprise/blob/19.0/website_sale_renting/controllers/cart.py#L52-L58) was triggered without the rental start and end dates(None was taken by default). As a result, the system uses [default rental duration](https://github.com/odoo/enterprise/blob/19.0/website_sale_renting/models/sale_order.py#L95-L99) for comparison and considers the accessory as having a different rental period then on the sale order and raised an error preventing it from being added to the cart. This issue did not occur when adding the same product from its product page, as the rental context was correctly provided there. After this Commit --- The rental start and end dates from the current sale order are passed when adding accessory products from the cart page suggested products. This ensures that rental period consistency checks succeed and the accessory can be added without raising an invalid operation error. Steps to Reproduce --- 1. Create two rental products A and B. 2. Configure product B as an accessory of product A. 3. Add product A to the cart with any rental period(except default). 4. From the cart page, attempt to add product B from suggested products. 5.Observe the error about mixing different rental periods. Here is the video demonstrating on how the error is reproduced : https://github.com/user-attachments/assets/3d5e6f96-cebd-4221-8592-1bdb6ae40ec7 Expected Result The accessory product is added to the cart using the same rental period as the existing cart's rental period. OPW: 5823691 Forward-Port-Of: odoo/enterprise#107343 Forward-Port-Of: odoo/enterprise#106426
This update corrects a discrepancy in payslip calculations for the private car daily allowance. The daily amount is now rounded to two decimal places to precisely match the 'Quantity × Amount' displayed on payslips. This ensures accurate and consistent payroll reporting for employees.
Original PR description
Round the computed daily private-car salary rule amount to 2 decimals so the displayed per-day value matches Quantity × Amount on payslips. References task-5917569 Forward-Port-Of: odoo/enterprise#108606 Forward-Port-Of: odoo/enterprise#106753
This update resolves an issue where the 'Publish & Send' button was inadvertently removed from the scheduling interface. The fix removes a previous change that added a context variable, which caused the button to disappear. This ensures users can correctly send their scheduled shifts.
Original PR description
## Issue Since commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2, `planning_test_tour_no_email` is failing when trying to click on the (missing) `Publish & Send` button. ## Cause The…
## Issue
Since commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2, `planning_test_tour_no_email` is failing when trying to click on the (missing) `Publish & Send` button.
## Cause
The commits adds the `my_planning_action` attribute to the context when opening the `Schedule by Resource`. This allowed to display the `I Take It!` button when opening an open shift, but it also removed the `Publish & Send` button, as its condition to be invisible consistently contains `context.get('my_planning_action')` [[1](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L11), [2](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L78-L79), [3](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L273-L274)].
## Fix
The objective is to fix the bug from previous commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2 differently. Instead of adding the `my_planning_action` to the context, we remove the conditions on the `I Take It!` button.
runbot-241028
Forward-Port-Of: odoo/enterprise#108753
Forward-Port-Of: odoo/enterprise#108333This update fixes a bug that prevented the accurate calculation of employer costs in Switzerland. The change ensures that employer contributions are now correctly included in payroll calculations, aligning with Swiss regulations. This improves payroll accuracy and reporting.
Original PR description
The computation of the employer cost in Switzerland was wrong (always 0) because the rules didn't have the appears_on_employee_cost_dashboard flag set and were therefore not counted in the computation of the fiels. Furthermore we modify the override of the function used to compute the values of some fields, to add the correct computation of the employer cost. Task: 5354103 Forward-Port-Of: odoo/enterprise#106839
This update fixes a technical issue related to how numeric values are handled in the web_studio interface and ensures consistent use of the new badge widget across the appointment module. It improves the reliability of data entry and aligns with recent changes to the core widget system, enhancing overall system stability.
Original PR description
### **This PR addresses:** Updating the `appointment` module to reflect the removal of the `selection_badge_icons` widget in core `web` and fixing property parsing in `web_studio`. This is a…
### **This PR addresses:** Updating the `appointment` module to reflect the removal of the `selection_badge_icons` widget in core `web` and fixing property parsing in `web_studio`. This is a mandatory follow-up to the migration of icon support and dropdown fallbacks into the standard `selection_badge` widget. ### **Key Changes:** * **Widget Migration:** Replaced all occurrences of `widget="selection_badge_icons"` with `widget="selection_badge"` in appointment question views. * **Studio Property Fix:** Updated `web_studio` property parsing to use `Number()` instead of `JSON.parse` for numeric values. This prevents errors when handling numeric strings with leading zeros (e.g., "032"). * **Test Alignment:** Updated the OWL tests to use the new `.o_field_selection_badge` class name for waiting and selectors, ensuring the test suite remains green. * **Compatibility:** Maintained the existing `icon_mapping` and `size` options, which are now natively supported by the core widget. **Task-5270283** **Related Community PR:** odoo/odoo#243855
This update fixes a technical error preventing managers without appraisal rights from scheduling meetings. The issue stemmed from access restrictions related to employee data. The fix simplifies the process by directly using the employee's work contact information instead of the problematic related partner ID.
Original PR description
Steps to reproduce: - Create two employees: one as a manager and the other as a subordinate. - Ensure that the manager does not have any officer or appraisal rights. - Create an appraisal for the subordinate through the manager. - Confirm the appraisal and then click the Schedule Meeting button Issue: - The manager should schedule a meeting even though he does not have the rights, but a traceback error occurs due to access rights issues when trying to schedule a meeting. Reason: - The manager is unable to access the related_partner_id due to restrictions set by the officer/manager group, which results in a traceback error. Fix: - Replace the related_partner_id with the work_contact_id of the employee. Since related_partner_id is computed from work_contact_id, we can directly use work_contact_id task-5881127 Forward-Port-Of: odoo/enterprise#106106
This update fixes an issue where accounts without a code in the primary company were being excluded from report consolidation, leading to inaccurate totals. Now, the system will automatically find the correct code for these accounts in other companies, ensuring accurate report generation and financial data consistency.
Original PR description
Description of the issue this commit addresses: When consolidating reports, any account that doesn't have a code on the consolidating company is filtered out of the consolidation. This will lead to amounts that do not match which should not happen. --- Desired behavior after this commit is merged: When an account should be used but is filtered out because of not having a code in the per company mapping, we try to find its code on any of the other companies he is and use that one as anchor in the consolidation. --- task-5911409 Forward-Port-Of: odoo/enterprise#107651
A bug was preventing users from correctly saving approval rules with specific domain filters in the web studio. This was caused by a mismatch in how data was represented between Python and JavaScript. The fix ensures that domain filters are saved accurately, allowing users to properly configure email approvals.
Original PR description
Steps to reproduce ================== - Install web_studio,sale_management - Open a form view in sale - Open studio - Click on the "Send by email" button - Add an approval rule - Add a domain by clicking on the filter icon - Use the not set operator - Confirm - Click on the filter icon again - Confirm => ValueError: malformed node or string on line 1: <ast.Name object at 0x79ff4c7b7f50> Cause of the issue ================== JSON.stringify was used to pass the domain as a string to the DomainSelectorDialog. This doesn't work for boolean as they don't have the same representation in JavaScript as opposed to Python. Solution ======== Use the Domain().toString function opw-5923585 Forward-Port-Of: odoo/enterprise#108595 Forward-Port-Of: odoo/enterprise#107432
This update resolves an issue where payment reference data from the Codabox integration was incorrectly formatted, often with leading or trailing spaces. The change automatically removes these spaces before creating reco models, ensuring accurate data processing and preventing potential errors in financial reporting. This improves the reliability of bank statement imports.
Original PR description
Before this commit, when we do the creation of the automatic reco models, it was possible that the payment ref ended with a lot of empty spaces. To avoid that, we now strip the payment ref before the creation of the reco model. Data coming from codabox where wrongly formatted since the payment ref could have space at the end or the start and even in the middle. By using a split join we solve that issue. task-5926548 Forward-Port-Of: odoo/enterprise#107421
This update corrects a problem in how Odoo handles extended sick leave in Belgium. Previously, different work entry types for consecutive days of absence caused matching issues. The change reverts a previous fix and isolates the Belgium-specific logic, ensuring accurate calculations for sick leave durations.
Original PR description
In Belgium, when more than a month of consecutive sick time of is taken, every day over the month is of a different type of work entry (sick time of without pay). This means that work entries relative to the same leave have different work entry types which was causing problems when checking the matching of the types. To fix this, a previous PR (https://github.com/odoo/odoo/pull/237829) made it so that if the internal_leaves computation returned empty, every leave was considered. Because of this some problems in the HK localization arose so we go back to the original code (see related Community PR) and we move the BE specific changes to the BE localization module. Here we override the check function to allow for the specific case described above, where LEAVE110 is the code for sick time off and LEAVE214 is the code for sick time of without pay. Task: 5472538 Community PR: https://github.com/odoo/odoo/pull/246116 Forward-Port-Of: odoo/enterprise#105776
This update resolves an issue where test applications for new hires were failing due to missing applicant name information. The team has added required partner_name values to the test cases, ensuring data integrity and preventing errors during application creation. This improves the reliability of our recruitment testing process.
Original PR description
In the related community PR, we are making the partner_name as required. So need to give the partner_name values in the test cases while creating the `hr.applicant` to resolve the not null violations Community PR:- https://github.com/odoo/odoo/pull/203222 sentry-6409185730
This update streamlines the process of generating salary simulations by introducing a standardized context manager. This ensures consistent setup and teardown of necessary operations, reducing potential errors and improving the reliability of the simulation process. It also enforces the correct context setup for related methods.
Original PR description
Description ----------- Getting an `hr.version` from an `offer` during simulation is done in a savepoint, preceded and followed with flushing of the environment and some post-cleanup. This is verbose…
Description ----------- Getting an `hr.version` from an `offer` during simulation is done in a savepoint, preceded and followed with flushing of the environment and some post-cleanup. This is verbose and error-prone, as it's done at each call site of `hr.contract.salary.offer._get_version` and `hr.version._generate_salary_simulation_payslip` (or any other future method that may require such a savepoint). These methods have a comment that mentions *requiring* a savepoint to be called, but nothing is enforcing it, so a bug due to oversight is bound to happen. Context keys are also injected a bit everywhere like `salary_simulation` and `tracking_disable`, without much consistency, and adding to the visual clutter. This commit introduces a little context manager called `hr_version_context` that manages the creation of the savepoint, the setup and teardown necessary, and the setting of the keys in the context. It's accompanied by a decorator `@requires_hr_version_context` that will fail if the caller didn't use `hr_version_context` before invoking the marked method. This ensures: - Correct creation of the savepoint and its related pre-/post-operations - Apply context keys consistently - Ensure methods that require such setup *cannot* be called without it. Forward-Port-Of: odoo/enterprise#107743 Forward-Port-Of: odoo/enterprise#103187
This update corrects a display issue in the chat window where the agent's subtitle was not appearing correctly when the agent description was blank. The fix adds a default message to ensure the subtitle is always visible, improving the user experience. This resolves a previous display problem.
Original PR description
The chat subtitle is false, if the agent description is not set. This commit fixes the issues by adding a default message if subtitle is missing. Task-5916227 Forward-Port-Of: odoo/enterprise#108948 Forward-Port-Of: odoo/enterprise#106949
This update fixes an issue where social security numbers were incorrectly displayed across different company views in Odoo. The change restricts SSN visibility to only appear within the specific country's company records, ensuring data privacy and compliance. This improves data accuracy and reduces potential reporting errors.
Original PR description
[FIX] l10n_hr_payroll: limit l10n_xx_ssn to appear only in xx companies Bug reproduction: Select version >= saas-19.2 -> select your company -> payroll->employee->personal->you will see social security number even though that can belong to SA, MX, EG. Bug cause: added ssn fields are not restricted to their own l18n, then they are appearing in each employee form views. Bug solution: add country restrictions for MX, EG, SA to not appear in other country's company. task - 5974006 Forward-Port-Of: odoo/enterprise#108903
This update fixes a bug that prevented accurate payment advice reports when employees had multiple bank accounts. The team verified all bank accounts and BIC codes to ensure the system correctly generates reports, even with secondary bank information. This ensures accurate financial reporting for our users.
Original PR description
steps to reproduce: - install `l10n_in_hr_payroll` - create an employee, with multiple bank accounts - add invalid BIC in one of the bank accounts with isn't primary - notice that you will still be able create the advice report with invalid data. issue: - after the support of multiple bank accounts, the payment advice methods were not adapted with it. fix: - checked all the banks and their BIC. task-5890497 Forward-Port-Of: odoo/enterprise#109002 Forward-Port-Of: odoo/enterprise#107283
This update fixes a warning generated during testing of document attachments. The team replaced artificial PDF content with a standard, minimal PDF file used for testing, ensuring consistent and reliable test results. This resolves a technical issue that could have impacted the stability of the document processing features.
Original PR description
While creating attachments/documents for testing, using a "fake PDF content" generates warning from PyPDF 5.4.0 (even with `strict=False`) when the said PDF is eventually parsed. This commit replaces those "fake PDF content" by reading the "minimal" PDF file provided for testing purposes in `base`. runbot-231278 Forward-Port-Of: odoo/enterprise#108779
This update fixes an issue where the VAT Book download was limited to only the primary company. Now, when multiple branches with the same CUIT are selected, the VAT Book will download for all of them, ensuring accurate reporting for multi-branch businesses in Argentina. This improves the reliability of tax reporting.
Original PR description
#### Issues: VAT Book should download for all selected companies with same CUIT as the current one. #### Step to reproduce: - In a company in Argentina ("Parent Company") - Create a branch "Child…
#### Issues:
VAT Book should download for all selected companies with same CUIT as the current one.
#### Step to reproduce:
- In a company in Argentina ("Parent Company")
- Create a branch "Child Company A" with no CUID
- Create a branch "Child Company B" with a different CUID than parent
- Go to "Child Company A"
- Either:
- i. Select both "Parent Company" and "Child Company A" but not "Child Company B"
- ii. Select all 3 "Parent Company", "Child Company A" and "Child Company B"
- In Accounting > Report > Tax Return :
- Download the VAT Book (wheel > "VAT book(ZIP)")
#### Current behavior:
i. Get Invalid Operation
ii. Download the VAT Book for "Parent Company" only
#### Expected behavior:
- Download the VAT Book for both "Parent Company" and "Child Company A"
A previous call to get_options provide the client with the info about which selected companies have the same CUIT as the current company. Therefore companies in the options are the correct ones.
opw-5385585
Forward-Port-Of: odoo/enterprise#108466
Forward-Port-Of: odoo/enterprise#101898This update resolves an issue where a required SRI payment method wasn't being applied to invoices for POS orders paid entirely with gift cards in Ecuador. The fix automatically assigns the '01' SRI payment code when no other payments are associated with the order, ensuring accurate invoice generation and compliance. This prevents errors and streamlines the POS process for Ecuadorian businesses.
Original PR description
When a POS order has no payment associated (e.g. when the order is fully paid with a gift card), the SRI payment method was not set on the invoice Steps to reproduce: ------------------- * Create a PoS in Ecuador with the l10n_ec_edi_pos module installed * Create a gift card program and some gift cards * Create a PoS order and pay it fully with a gift card and invoice it > Observation: You get an error saying that the SRI payment method is required Why the fix: ------------ When setting the SRI payment method on the invoice, we check if there are more than 1 payment associated with the order, and if not we fallback on the SRI payment with code "01" opw-5432004 Forward-Port-Of: odoo/enterprise#108798 Forward-Port-Of: odoo/enterprise#107966
Code cleanup and technical improvements
This update prepares for a change to improve how the portal communicates with the Odoo server. It now allows the server to recognize requests originating from the portal, enabling targeted limitations and better performance. This refactoring enhances the overall system's responsiveness and integration.
This update clarifies the event triggered when the website builder prepares to save a complete document. The change ensures the system correctly handles saving the entire website design, rather than individual snippets. This improves the reliability and efficiency of the website building process.
Original PR description
This commit renames the resource `on_will_reset_history_after_saving_handlers` (formerly `save_handlers`) to `on_ready_to_save_document_handlers`. To convey that: - the event is "the builder is ready to save the document" - this is about saving the whole document (and not a custom snippet)