Monday, March 23, 2026
33 changes · 19.0
New functionality added to Odoo
The README now includes a gitcgr badge that links to interactive code graph statistics for the repository. This makes it easier for visitors to discover a visual overview of the codebase, with no effect on Odoo functionality.
Original PR description
Adds a [gitcgr](https://gitcgr.com) badge to the README showing code graph statistics for this repository. **Badge preview:** [](https://gitcgr.com/odoo/odoo) --- [gitcgr.com](https://gitcgr.com) visualizes any GitHub repo as an interactive code graph — just change `hub` to `cgr` in the URL. Generated automatically by [gitcgr](https://gitcgr.com).
Enhancements to existing features
The IoT setup now generates the proxy token needed for Egypt-specific requirements again, but sends it directly to the database instead of showing it in a user-facing pop-up. This keeps the required compliance flow working while avoiding unnecessary prompts for most users.
Original PR description
Proxy token generation was removed to avoid showing a modal with a token nobody cares about except Egypt. We reintroduce token generation, but send it to the database instead of showing a modal. see odoo/enterprise#111496
Resolved issues and error corrections
This update removes outdated short date and time formatting options that are no longer supported in Odoo 19.0. It helps prevent formatting errors in calendars, HR records, point of sale emails, and event SMS messages.
Original PR description
modules: calendar, event_sms, hr, point_of_sale, pos_self_order From this [commit], the methods `format_datetime` and `format_time` no longer handle `short` because the fields `short_time_format` and `short_date_format` are no longer available in 19.0. [commit]: https://github.com/odoo/odoo/commit/062b14097033afc19252cf3b8bb1fc541f8c868d#diff-61162ac65633a1c7b054fc83ce1813f1a7984e3169ff36021713ef441f62a208 opw-6030342 ---
Features or functions removed from Odoo
This commit cleans up the codebase by removing a previously merged module that contained a dead file. This ensures our system remains efficient and free of outdated components. The removal addresses a technical issue identified during the integration process.
Original PR description
Description of the issue this commit addresses: When Faulty PR¹ was merged, one file was not removed resulting in a dead module staying in the codebase with a single dead file. ¹: [Faulty PR](https://github.com/odoo/enterprise/pull/92769) --- Desired behavior after this commit is merged: This commit removes said module and therefore dead files. --- task-[none](https://github.com/odoo/enterprise/pull/92769#issuecomment-4097703654)
Miscellaneous changes
In `ThreadedServer,` the http daemon will create threads to handle incoming requests. The creation of these threads doesn't wait until the registry is loaded because the request could be serving static files. In the WSGI application entry point `__call__`, the threads will be going into `self.get_static_file` and up until this point, there's no locking whatsoever on these threads. Inside `get_static_file`, the `self.statics` lazy_property is evaluated which will walk the addons path. Before t
Original PR description
In `ThreadedServer,` the http daemon will create threads to handle incoming requests. The creation of these threads doesn't wait until the registry is loaded because the request could be serving…
In `ThreadedServer,` the http daemon will create threads to handle incoming requests. The creation of these threads doesn't wait until the registry is loaded because the request could be serving static files. In the WSGI application entry point `__call__`, the threads will be going into `self.get_static_file` and up until this point, there's no locking whatsoever on these threads. Inside `get_static_file`, the `self.statics` lazy_property is evaluated which will walk the addons path. Before this PR, the order of the conditions in the or statement will always evaluate the lazy property regardless of the other parts of the condition. This means that every single request that comes in will do an unnecessary `os.listdir` on all addons paths. For customers with a very large and deeply nested addons path like in opw-5877522 (they had over 93K dirs), this is a tremendous load on the system when there are multiple threads doing that due to the amount of syscalls involved for no reason whatsoever. This is especially worse on SH because disks are not local, so an individual syscall is more expensive. This is slowing down all requests as well as the registry loading time which is a prerequisite for any non-static request. This PR simply reorders this check to only evaluate the self.statics property if all other parts of the condition are False. This means it'll only have to do this expensive `os.list` for a fewer number of requests which are much more unlikely to coincide at the startup of a worker. On top of that it's a better optimization to avoid doing this expensive check for every request. Benchmarks |No. files in addons path| No. concurrent threads | Registry loading time Before PR | Registry loading time After PR | |--------|--------|--------|--------| | 93447 | 5 | 53.23 s | 4 s | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254660
This fix prevents new accounts from being assigned a code that already belongs to an archived account. It helps avoid validation failures during account creation and upgrades, improving reliability for accounting data management.
Original PR description
The logic of `code_is_available` should match that of `_ensure_code_is_unique`. However the latter was modified by https://github.com/odoo/odoo/commit/cd8d9718427e48aaa79be21f9a08e89b79b573f9 to also search archived accounts without matching the former. With the current logic, new accounts could generate a code used by an archived account and fail the validation. Found in failing upgrades.
Credit notes now show the appropriate partner bank accounts in the Recipient Bank field instead of only listing the company's accounts. This helps users restore or select the correct recipient bank account when processing refunds or credit notes.
Original PR description
Description of the issue this commit addresses: The Recipient Bank field in the Other Info tab of the Account Move form view refilters accounts to only show you company's ones. This is expected for invoices but is blocking when doing a credit note. You can't find a partner's bank account to fill that field. --- Steps to reproduce: 1. Install account. 2. Create an Invoice to a partner which has a bank account setup. 3. Create a Credit Note for that Invoice. 4. In the "Other Info" tab, remove the partner's bank account. 5. Try to search for his bank account to add it back. It won't show up. --- Desired behavior after this commit is merged: The Recipient Bank field prefilters bank accounts based on who is expected to be the recipient of the move. --- task-5976951 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254850 Forward-Port-Of: odoo/odoo#252961
Fixes an issue where users might see a technical crash instead of a clear error message when PDF merging fails, such as with a malformed PDF. This helps users understand document problems and avoids confusing internal errors during report generation.
Original PR description
When merging pdfs, if there is an error when meging those pdfs (due to a malformed PDF for example), the UserError that should be shown to the user is not due to an error in the arguments given to the handle_error function.
The aim here is to keep the same function signature and edit the signature of the local function used when a custom_handle_error was defined and edit the function itself.
The error message appeared when I was working on a task to change a
test and tested it on master and got the following stacktrace:
```
...
File "/home/odoo/Desktop/src/odoo/odoo/addons/base/models/ir_actions_report.py", line 788, in _merge_pdfs
handle_error(error=e, error_stream=stream)
TypeError: IrActionsReport._handle_merge_pdfs_error() missing 1 required positional argument: 'self'
```
Discovered during : task-3603619
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#211611The Discuss call controls now show the muted microphone button in the same clear red style as other critical call actions. This removes a confusing lighter pink shade and makes the call interface more visually consistent.
Original PR description
Before this commit, when in discuss call and current user has microphone muted, the icon has light red / pink background color on muted instead of red. The color should be the same as the one from…
Before this commit, when in discuss call and current user has microphone muted, the icon has light red / pink background color on muted instead of red. The color should be the same as the one from "disconnect", but the difference comes from `btn-danger` with or without `.active` that has different shade of red for background: the `.active` version is lighter like in the mute button when active. `.active` classname is preferred to keep so that the visual is consistent for most discuss actions, including the ones without success / danger which a majority of these buttons have. However, the buttons with danger / success style are intended to preserve their color unchanged as the `.active` aspect is meant to tell whether the button is active or not and the slight change of color shade is not desirable in the context of discuss action list. This commit uses the same background color for danger / success / primary inline button. Other styles line dropdown and inline buttons without background had already the same colors, so this commit fixes the only case that was missing. Task-5436990 Before / After <img width="283" height="38" alt="Screenshot 2026-03-13 at 15 21 22" src="https://github.com/user-attachments/assets/3ebba48c-5b22-43e9-a915-e18a5531e660" /> <img width="270" height="41" alt="Screenshot 2026-03-13 at 15 21 45" src="https://github.com/user-attachments/assets/586d05a4-2a6c-48e0-89c6-bffa85a86e59" />
Fixes an issue where a livechat conversation with oneself could show a duplicated name. This keeps chat labels clearer for users and avoids confusion in self-chat scenarios.
Original PR description
Since PR #212150 when getting the livechat channel values, the `visitor_user` value is set to the current visitor user even when the visitor user is the same as the agent (self chat). The code is guarded in the next step and so this visitor is not added to the channel members but the already set value affects the livechat channel name. The bug becomes visible when the `displayName` computation is changed later by the PR #227240. This change ensures that the visitor user remains falsy throughout the process when the visitor and agent are the same. task-6015652
Website menu group labels now follow the selected alignment in the editor, including centered and right-aligned mobile menus. This makes navigation layouts look consistent for visitors and avoids mismatched menu styling on mobile and sidebar headers.
Original PR description
Steps to reproduce: =================== 1- Enter the website editor 2- Enable mobile view 3- Edit the alignment of the mobile menu to be center or right aligned The group labels (e.g. "Shop",…
Steps to reproduce: =================== 1- Enter the website editor 2- Enable mobile view 3- Edit the alignment of the mobile menu to be center or right aligned The group labels (e.g. "Shop", "Forum") stay left-aligned regardless of the chosen alignment. This can also be seen on desktop by switching to the sidebar header template. Cause: ====== The class .accordion-button uses `display:flex` and `text-align:left` and that class is used for the menu groups labels. this prevents the alignment from working. Solution: ========= When right-aligned (`text-end`), reverse the flex direction so the arrow moves to the left and the text stays on the right. When centered (`text-center`), let the text span fill the remaining space and center its content via `text-align: center`, keeping the arrow on its position. The default left-aligned case is unchanged. opw-5494765 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244565
This fix prevents the meeting sidebar from crashing when participant avatar information is not yet available. It improves reliability for online meeting views and helps avoid intermittent test and user interface failures.
Original PR description
Before this commit, test `test_04_meeting_view_tour` could crash non-deterministically with the following error:
```
OwlError: An error occured in the owl lifecycle (see this Error's "cause" property)
Caused by: TypeError: Cannot read properties of undefined (reading 'avatarUrl')
at DiscussSidebarCallParticipants.template
```
This happens because the template was reading a deep field in a JS relation without guard in `rtc_session.channel_member_id.avatarUrl`.
When a rtc_session is known in client code, the `channel_member_id` is not necessarily known, therefore code should guard it unless context is explicit that this is known.
This commit adds optional guarding in the template to take into account possibility to know rtc session without the related channel member id.
Fixes runbot-error-242142
Backport of https://github.com/odoo/odoo/pull/233232This fix ensures Danish Nemhandel CVR identifiers in OIOUBL e-invoices include the required 'DK' country prefix. This helps keep generated invoices compliant with the expected Danish electronic invoicing format and reduces the risk of rejected documents.
Original PR description
In this commit af94099c4d74e9c48251a1c1656e3ad11b9f8a70, we made a fix regarding OIOUBL21 XML files, but we forgot to add the 'DK' prefix for CVR nemhandel identifier. The format should be 'DK' + nemhandel_identifier_value. no-task Forward-Port-Of: odoo/odoo#254430
Odoo now allows approved cross-origin requests to include the Range header, preventing these requests from failing during browser checks. This helps external apps or services retrieve partial content when a route already permits cross-origin access.
Original PR description
Previously, specifying the Range header in a CORS request would result in a preflight failure even if cors was enabled on the route. It is sometimes desirable to allow querying ranges even in a CORS context. It may be desirable at some point in the future to allow controllers to customize their preflight responses more thoroughly, but considering this hasn't really be an issue before, it seems premature. Instead, this commit just adds the Range header to the Allow-Control-Allow-Headers response header to allow such requests to succeed. Forward-Port-Of: odoo/odoo#254805
Product names from website catalog blocks no longer appear as entries in a page table of contents. This prevents long product lists from cluttering page navigation and makes website editing output cleaner for visitors.
Original PR description
# How to reproduce - Have atleast one product published on the website. The more products published, the more noticable the issue is - Edit the website - Add a table block to a page (Search for table…
# How to reproduce
- Have atleast one product published on the website. The more products published, the more noticable the issue is
- Edit the website
- Add a table block to a page (Search for table in the "Insert block" popup and pick the first one)
- Add a catalog block to the table. This catalog block needs to be the one with the title "Our latest content".
- Add any other block in the table block to update the table of content
# The problem
The table of contents display the names of the different products. If there are a lot of products, it fills the whole table of content
# Why
The TableOfContentPlugin scans for ```<h2>``` tags to use them in the table of content.
```js
updateTableOfContentNavbar(tableOfContentMain) {
const tableOfContent = tableOfContentMain.closest(".s_table_of_content");
const tableOfContentNavbar = tableOfContent.querySelector(".s_table_of_content_navbar");
const currentNavbarItems = [...tableOfContentNavbar.children].map((el) => ({
title: el.textContent,
href: el.getAttribute("href"),
}));
if (tableOfContentMain.children.length === 0) {
// Remove the table of content if empty content.
this.dependencies.remove.removeElement(tableOfContent);
return;
}
const targetedElements = "h1, h2";
const currentHeadingItems = [...tableOfContentMain.querySelectorAll(targetedElements)]
.filter((el) => !el.closest(".o_snippet_desktop_invisible"))
.map((el) => ({ title: el.textContent, id: `#${el.id}`, el }));
```
The product snippet template uses ```<h2>``` for their product title dispite having the h6 CSS class.
Note that the reason you need to add another block to the table to see the issue is that the table of content is updated before the products are loaded in the catalog.
opw-5992937
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prViettel e-invoices now include the seller’s full address, including additional street, city, postal code, state, and country details. This helps businesses meet Viettel EDI requirements and reduces the risk of incomplete invoice information.
Original PR description
The seller address on e-invoices was missing some fields. This commit updates the logic to include street2, city, zip, state, and country when generating the seller address, ensuring full address details are provided in compliance with Viettel EDI requirements. task-6040875 Forward-Port-Of: odoo/odoo#254564
Creating a project task from a template now sends the expected email notifications to project followers. This helps ensure stakeholders are informed when new templated tasks are created, matching the behavior users expect from copied tasks.
Original PR description
Steps to reproduce: - Open form view project that has task templates. - Add a partner to follow project when task is created. - From `New` button click on any available task templates . Issue: - Mail is not sent when task is created from template. Fix: - Now we are treating creating task from template same as we do copy. Solution: - Make sure we send a mail and stop the normal logging which happens when copying the task. Forward-Port-Of: odoo/odoo#250306
Italian delivery document details are now shown on dropship operations, matching the behavior already available for standard deliveries. This helps Italian companies manage required transport document information consistently across delivery workflows.
Original PR description
Steps to reproduce the bug: - Create a company with country = Italy and select it - Install the module “l10n_it_stock_ddt” - Activate “Dropshipping” in the inventory settings - Create a delivery → the group "DDT Information" is visible - Create a dropship → the group "DDT Information" is not visible Problem: The DDT information should also be visible for dropship operations. The compute used for “l10n_it_show_print_ddt_button” correctly takes dropship operations into account, but it cannot be reused to control the visibility of the DDT Information group because this compute is True only when the picking state is done and locked: https://github.com/odoo/odoo/blob/e6d4ab62e950c8b88ac54fecbf2682cba846c7c3/addons/l10n_it_stock_ddt/models/stock_picking.py#L34-L35 opw-5190251
This fixes an internal accounting test so it still works when Indian or Argentinian localization modules are installed. It improves reliability of automated checks without changing day-to-day user behavior.
Original PR description
Create the invoice line through the `invoice_line_ids` o2m write command instead of a standalone `account.move.line` create with move_id. The mock server's `inverse_fname_by_model_name` mapping only keeps one o2m per co-model; when extra modules add another o2m with the same inverse (`l10n_in_withholding_line_ids` from l10n_in, `l10n_ar_withholding_ids` from l10n_ar_withholding), it shadows `invoice_line_ids` and the list renders empty. runbot-233670 Forward-Port-Of: odoo/odoo#255188
This fixes a visual issue in the online shop where the product grid could lose its left border on smaller screens when the sidebar is hidden. The change improves the storefront's appearance and layout consistency for mobile and narrow-window shoppers.
Original PR description
On smaller viewports the sidebar is hidden and the grid misses a left border. It's because of a selector typo. task-6059942 <img width="845" height="925" alt="image" src="https://github.com/user-attachments/assets/9ebb8a04-c3ce-40fd-acfa-8a17fbc31e3a" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a visual inconsistency in accounting reports. Previously, the company header was grayed out only in light mode. Now, it uses a standard muted color, ensuring a consistent and professional appearance across both light and dark modes.
Original PR description
Before this pr: - The company header in the accounting reports is grayed out in the light mode only, not in the dark mode. Reason: - Until now, we have been using the hard-coded 'lightgrey' color for the company header. After this pr: - In this pr, we are changing the color of the company header from hard-coded 'lightgrey' color to the standard variable color '--AccountReport-muted-data-color' used for muted data in account reports. Task-5960592 Forward-Port-Of: odoo/enterprise#111353 Forward-Port-Of: odoo/enterprise#110108
This update removes the outdated 'short' option from the `format_datetime` and `format_time` functions. This change is necessary for the Odoo 19.0 release as the `short_time_format` and `short_date_format` fields have been deprecated. It ensures consistent date and time formatting across the appointment, data cleaning, planning, and sale-renting modules.
Original PR description
modules: appointment, data_cleaning, planning, sale_renting From this [commit], the methods `format_datetime` and `format_time` no longer handle `short` because the fields `short_time_format` and `short_date_format` are no longer available in 19.0. [commit]: https://github.com/odoo/odoo/commit/062b14097033afc19252cf3b8bb1fc541f8c868d#diff-61162ac65633a1c7b054fc83ce1813f1a7984e3169ff36021713ef441f62a208 opw-6030342
This update resolves a technical issue related to how geographic data (specifically topoJSON) is processed within the Enterprise edition's spreadsheet functionality. The fix ensures accurate display of maps and charts generated from spreadsheet data, improving the user experience for business reporting. This change primarily impacts users relying on geographic visualizations within the Enterprise module.
Original PR description
test adaptation Counterpart of github.com/odoo/odoo/pull/248847 Task-5224009 Forward-Port-Of: odoo/enterprise#107912
This update fixes an issue where the 281.50 PDF report occasionally generated an extra page with header and footer content. The change optimizes the report layout to ensure it consistently appears on a single page for standard reports, improving readability and reducing unnecessary PDF sizes.
Original PR description
**Behavior:** Currently when generating the 281.50 report the pdf ends up taking an extra page filled only with header and footer, the page appears when creating the report for a natural person and…
**Behavior:** Currently when generating the 281.50 report the pdf ends up taking an extra page filled only with header and footer, the page appears when creating the report for a natural person and adding a national number. The solution is not to fully prevent the report form being more than 1 page long, as some informations could span over more than one line which would make the pdf need an extra page. But to shave a few milimeters so that by default when filled with standard informations the pdf appears cleaner. **Steps to reproduce:** - Log to a Belgian company - Create a contact that is a person - Add the 281.50 tag to them - Create a credit note for any positive amount for that person and set the date to the previous year - Make sure the account used in the credit note has any 281.50 x tag assigned - Go to Accounting/Reporting/Open 325 forms and create a new form for the year indicated in the credit note - When generating the 281.50 PDF you'll seee it span over 2 pages if you have filled the national number of the contact opw-5930339
This update fixes a technical error that occurred when users tried to take a picture without an IoT device connected to a quality control point. The fix prevents a system error and guides users to properly set up the device, ensuring a smoother workflow for quality checks.
Original PR description
Currently, an error occurs when the user clicks the Take Picture button without an IoT box set on the quality control point. ## Steps to replicate: - Install Quality, Purchase, IoT - Quality >…
Currently, an error occurs when the user clicks the Take Picture button without an IoT box set on the quality control point. ## Steps to replicate: - Install Quality, Purchase, IoT - Quality > Quality Control > Control points - Create a new Control point with - Type: Take A Picture - Operations: My Company: Receipts - Create and confirm a purchase order for a test product - Receipts > Quality Checks > Take A picture ## Observed behavior: TypeError: Cannot read properties of undefined (reading '0') ## Root cause: This error occurs because no device has been set on the control point. When the user clicks the **Take a Picture** button, the `onClick` method [1] is triggered. Since `this.iotDevice` is false, both `iotBoxId` and `deviceIdentifier` are undefined. These undefined values are then passed to the action function [2], which in turn passes them to the `_attemptFallbacks` function. At [3], a type error occurs because the system tries to index `iotBoxId` even though it is undefined. [1]: https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/quality_iot/static/src/iot_picture_button.js#L7-L17 [2]: https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/iot/static/src/network_utils/iot_http_service.js#L213-L236 [3]: https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/iot/static/src/network_utils/iot_http_service.js#L149-L152 [4]: https://github.com/odoo/enterprise/blob/1d25675de808521dc8ad8c56bc9fbd320a0ae56b/quality_iot/static/src/iot_measure_button.js#L27-L32 ## Solution: Add a check for an unset device and notify the user to add a device to the quality point. This prevents a traceback and clearly informs the user about the issue. Similar to how it was done in [4] opw-6010095
This update resolves an issue where the CFDI payment method '99' incorrectly displayed as '99 - False' on reports. The fix ensures that '99 - Por definir' is shown accurately, aligning with Mexican tax regulations. This improves report accuracy for invoices with payment method 99.
Original PR description
**PROBLEM** PR https://github.com/odoo/enterprise/commit/843d57b25f925a5d4f1848b85717adb4d1a9d388 Archives payment method 99, but because it's archived `_l10n_mx_edi_get_extra_invoice_report_values()` doesn't retrieve it. This leads the pdf report to display '99 - False' instead of '99 - Por definir'. **STEP TO REPRODUCE** 1. Create an invoice with the mx company. 2. Set the due date sometime in the month later. (To have the PPD payment policy on the invoice). 3. Send and generate the invoice using cfdi. opw-5927655 Forward-Port-Of: odoo/enterprise#111051 Forward-Port-Of: odoo/enterprise#107267
This update resolves a test issue caused by simultaneous requests for order tax details, which previously triggered errors. The fix ensures that backend processes complete before subsequent test steps are executed, improving the reliability of the POS tax test. This enhances the overall stability of the Odoo Enterprise Point of Sale module.
Original PR description
In the test test_pos_avatax_flow, two calls are made to get_order_tax_details almost simultaneously, which causes the second call to raise an error due to both call trying to sync the same order at the same time. This commit fixes the test by waiting for the backend calls to be done before proceeding with the test next steps. runbot-error: 238871, 238872 Forward-Port-Of: odoo/enterprise#110341
This update corrects a bug where changes to view order within the Odoo Studio interface weren't consistently applied. The fix involved updating the code to properly set the default order for views using the designated attribute on the relational model. This ensures that view order changes made through the Studio are now correctly reflected.
Original PR description
Bug === When changing the order of the views using studio, it wasn't applied. The reason is that we add a default order at the wrong place in JS, it should be done with the attribute made for that, `defaultOrderBy` on the relational model. Task-6047024 Forward-Port-Of: odoo/enterprise#111395 Forward-Port-Of: odoo/enterprise#111091
This update resolves an issue where long tax amounts in Ke EDI reports were causing display problems. The fix ensures that tax totals are accurately and clearly presented, regardless of the numerical size. This improves the readability and usability of invoices generated using the l10n_ke_edi_oscu module.
Original PR description
This commit aims to: Fix Display issue when the amount is long. task-5162891 Forward-Port-Of: odoo/enterprise#111003 Forward-Port-Of: odoo/enterprise#100319
This update resolves an issue where the calculation of employee appraisal dates was inconsistent. The fix ensures test employees are created *after* company appraisal settings are configured, leading to accurate appraisal date calculations. This improves the reliability of appraisal scheduling within the system.
Original PR description
Issue: The computation of the next appraisal date for employees depends on setting the appraisal plan for a company or changing the company's settings for `duration_after_recruitment`, `duration_first_appraisal`, `duration_next_appraisal`. Fix: Moving the test employee creation after configuration of the company settings for the appraisal plan. task-6050719 Forward-Port-Of: odoo/enterprise#111265
This update corrects a technical issue in how Odoo processes top-up payments for UK accounts. The data structure for UK accounts differs from the EU, requiring a change to the system's location data retrieval. This ensures accurate payment processing for UK customers.
Original PR description
Fix the UK top-up logic as UK accounts payload structure shifts from the EU where the country data is located in the EU payload it could be found under bank_transfer[financial_adresses][0][iban][country] and bank_transfer[country] but in the uk payload it can only be found in the second As we used the first one, we are now switching it to the second as it's the only common ground
This update ensures the 'mark as complete' button is always visible when closing a return flow, regardless of whether the user is using the API or a manual upload. This resolves an issue where the button was hidden for certain localization setups and temporary API connection problems, allowing users to consistently finalize return processes.
Original PR description
When a flow is already started, the button "mark as complete" on returns was invisible. This is an issue for some localizations that don't handle the flow when the API connection is not desired by the user. Another use case, for example, is the API connection is down temporarily, the user manually uploads it on the website, then wants to close the started return.
This update relaxes a restriction that previously prevented leave creation when payroll data was active for an employee. Now, leave can be created under specific conditions – primarily when payroll impact is false, or when continued and disability payments are both 100% if payroll impact is true. This improves flexibility in managing employee time off.
Original PR description
Currently we block leave creation if the employee has a validated payslip in that period. In this commit we relax the constraint in the following way, we will allow to put the leave if: - `l10n_ch_swissdec_payroll_impact` is False - `l10n_ch_continued_pay_percentage` and `l10n_ch_disability_percentage` are BOTH 100% if `l10n_ch_swissdec_payroll_impact` is True - `l10n_ch_swissdec_work_interruption` cannot be True in both cases task-5948505 Forward-Port-Of: odoo/enterprise#107847