Thursday, April 24, 2025
60 changes · saas-18.1
Resolved issues and error corrections
The Point of Sale debug tools now support importing paid orders, matching the existing export option. This completes the export/import workflow for support teams who need to investigate issues or move order data during troubleshooting.
Original PR description
Before this commit, it was possible to export paid orders from the debug window, but importing them was not possible. This commit allows importing orders, making the export/import flow complete and usable for debugging or data transfer purposes. opw-4688082 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Refreshing the Point of Sale screen no longer changes the order of product categories. Categories now keep the intended business-defined sequence, making navigation more predictable for cashiers.
Original PR description
Prior to this commit, refreshing the PoS caused the category order to default to ID-based sorting from IndexedDB. This commit fixes the issue by sorting categories based on their sequence. opw-4725408 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a timing issue in automated mail tests that could incorrectly fail when checking edited message labels. It helps keep validation stable without changing the user-facing mail experience.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/204922 PR above improved visual of (edited) label so that this is inline to the message content. Due to implementation details, it adds new test coverage when saving an edited message without changes, which may not have (edited) label with a simpler fix and this would be obviously a bug. The new steps to test may do `ctrl-ENTER` too soon, which would lead to not saving the message edition and instead the message is still being edited. As a result, this assertion would fail: ``` Failed to find 1 of ".o-mail-Message-content" with text "edited again (edited)" (Timeout of 3 seconds). Found 0 instead. ``` This commit fixes the issue by awaiting that the message being edited shows the input with message content in textarea, ensuring the user can actually edit the message and thus the ctrl-ENTER shortcut works and saves the message edition. runbot-1629170
Payroll users can now add a dated history line to salary rule parameters without triggering an error. This keeps payroll configuration workflows smooth when creating new rule parameter entries with initially empty values.
Original PR description
The error occurs when attempting to add a date in line in the Salary Rule Parameters Steps to Reproduce: --- - Install the `hr_payroll` module - Payroll > Configuration > Rule Parameters - Create New > History > Add a Line > Add Date Traceback: --- AttributeError: 'bool' object has no attribute 'replace' At [1], this error occurs because `value_id.parameter_value` is False. This happens because first we're adding a date, so `value_id.parameter_value` is initially empty. [1]- https://github.com/odoo/enterprise/blob/b52a93da7d680b60646cb08a9126cf6c12f5307d/hr_payroll/models/hr_rule_parameter.py#L101-L102 sentry-6531613276
Miscellaneous changes
This fix just add the error code and error message for IT language. Ref: odoo/odoo#184156 Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4728595) opw-4728595 Forward-Port-Of: odoo/odoo#207062 Forward-Port-Of: odoo/odoo#206985
Original PR description
This fix just add the error code and error message for IT language. Ref: odoo/odoo#184156 Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4728595) opw-4728595 Forward-Port-Of: odoo/odoo#207062 Forward-Port-Of: odoo/odoo#206985
To reproduce: - Install both `hr_contract_salary` and `project_timesheet_holidays` - Create a public holiday for the company (ex. on May 01) - Create a employee => This create leaves for employee's company public holidays - Create a contract for that employee - Send a signing request to both employee and HR responsible - The employee sign the document - The responsible sign the document => At that time, we're going to update the contract after both parties signed the contract and f
Original PR description
To reproduce: - Install both `hr_contract_salary` and `project_timesheet_holidays` - Create a public holiday for the company (ex. on May 01) - Create a employee => This create leaves for employee's company public holidays - Create a contract for that employee - Send a signing request to both employee and HR responsible - The employee sign the document - The responsible sign the document => At that time, we're going to update the contract after both parties signed the contract and force unarchiving the employee even if it's already active. This commit ensure that unarchiving an already active employee does not create duplicate *future* public holidays. opw-4134712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206997
Before this commit, validating an order that belonged to a different PoS configuration could result in an error if the selected payment method was not available in the current configuration. This prevented the order from being successfully validated. opw-4687658 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204809
Original PR description
Before this commit, validating an order that belonged to a different PoS configuration could result in an error if the selected payment method was not available in the current configuration. This prevented the order from being successfully validated. opw-4687658 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204809
steps to reproduce: 1. create an accrual plan that is accrued in hours (`added_value_type = 'hours'`) 2. create a time off type that can only be taken in days 3. create an accrual allocation with the plan and that time off type The calculation in the dashboard shows the amount of hours as days. The issue is that the amount of time off allocated is shown for the time off type request which is not true in this case. task: 4076800 --- I confirm I have signed the CLA and read the PR
Original PR description
steps to reproduce: 1. create an accrual plan that is accrued in hours (`added_value_type = 'hours'`) 2. create a time off type that can only be taken in days 3. create an accrual allocation with the plan and that time off type The calculation in the dashboard shows the amount of hours as days. The issue is that the amount of time off allocated is shown for the time off type request which is not true in this case. task: 4076800 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206532 Forward-Port-Of: odoo/odoo#176765
Steps: - Go to Time Off Overview. - Search for an employee using the Name field. Issues: - Searching by Name triggers an access error for users without Time Off rights. - Because, name is precomputed from Employee, Time Off Type, and Duration. - Search by Employee is already available so users can search by Employee. Fix: - Removed the Name search field from the Time Off Overview. - Eliminated the `_search_name` method, preventing access errors. - Removed the related test cases for
Original PR description
Steps: - Go to Time Off Overview. - Search for an employee using the Name field. Issues: - Searching by Name triggers an access error for users without Time Off rights. - Because, name is precomputed from Employee, Time Off Type, and Duration. - Search by Employee is already available so users can search by Employee. Fix: - Removed the Name search field from the Time Off Overview. - Eliminated the `_search_name` method, preventing access errors. - Removed the related test cases for searching by Name. Task - 4574162 Forward-Port-Of: odoo/odoo#207033 Forward-Port-Of: odoo/odoo#198461
In Hungary, when you fully reverse what is left to pay of an invoice with a Credit Note, it's usually called a "Storno" invoice, meaning an invoice that fully cancels what was previously sent. In the Hungarian EDI, invoices and credit notes are linked together, and they make a clear difference between a "modification" invoice (like a partial credit note, a debit note, etc) and a "cancellation" (Storno) invoice. We used to send it as a "modification" even when the residual amount was zero. Thi
Original PR description
In Hungary, when you fully reverse what is left to pay of an invoice with a Credit Note, it's usually called a "Storno" invoice, meaning an invoice that fully cancels what was previously sent. In the Hungarian EDI, invoices and credit notes are linked together, and they make a clear difference between a "modification" invoice (like a partial credit note, a debit note, etc) and a "cancellation" (Storno) invoice. We used to send it as a "modification" even when the residual amount was zero. This fix makes sure that it is sent as "cancellation" (Storno) in that case. task - 4707254 Forward-Port-Of: odoo/odoo#205390
When selling a physical gift card, and invoicing it. The code and partner id where not taken into account. Steps to reproduce: ------------------- * Open PoS * Add a gift card to the order * Click on selling a physical gift card * Enter any code * Validate the order and invoice it > Observation: If you check the gift card in the backend, you will see that the code and partner id are not set correctly. Why the fix: ------------ When updating the rewards, the code and partner id
Original PR description
When selling a physical gift card, and invoicing it. The code and partner id where not taken into account. Steps to reproduce: ------------------- * Open PoS * Add a gift card to the order * Click on selling a physical gift card * Enter any code * Validate the order and invoice it > Observation: If you check the gift card in the backend, you will see that the code and partner id are not set correctly. Why the fix: ------------ When updating the rewards, the code and partner id were never set. opw-4597330 Forward-Port-Of: odoo/odoo#206071
In https://github.com/odoo/odoo/pull/205403 I did some wrong changes to the totals of Modelo 390 section 1. This PR reverts these changes and fixes the section 2, which was the initial plan. Details: l10n_es tax has two main tax reports, modelo 303 (quarterly taxes) and modelo 390 (annual taxes). For both of these reports, for invoices, the taxes use positive tax tags corresponding the to tax line in the tax report. For refunds, the two reports work differently. Modelo 303 links all the
Original PR description
In https://github.com/odoo/odoo/pull/205403 I did some wrong changes to the totals of Modelo 390 section 1. This PR reverts these changes and fixes the section 2, which was the initial plan. Details:…
In https://github.com/odoo/odoo/pull/205403 I did some wrong changes to the totals of Modelo 390 section 1. This PR reverts these changes and fixes the section 2, which was the initial plan. Details: l10n_es tax has two main tax reports, modelo 303 (quarterly taxes) and modelo 390 (annual taxes). For both of these reports, for invoices, the taxes use positive tax tags corresponding the to tax line in the tax report. For refunds, the two reports work differently. Modelo 303 links all the refund amounts to some special report line (modification/correction of base/taxes), whereas the modelo 390 uses the negative tax tags corresponding to the tax line in the report. The issue lies in the multiple cross report references from modelo 303 to modelo 390. In section 1, some base and tax amounts are referrenced from modelo 303, as well as the modification amounts (the total of refunds mentionned above). When we compute the totals for that section, some refunds can be counted twice (once from the report using the negative tax tags, and a second time if we count the modification cross referenced from modelo 303). Since we have more taxes using the negative tags than cross-referenced in that section, it is better to omit the modification from the totals (i.e. we do not subtract [30] for the totals, as the negative amounts are already accounted for for the majority of the taxes). The totals will still be incorrect for that section, but less wrong. A future PR for master will fix the report by splitting all the tags used for the two reports. In section 2, we are in a similar case, so we remove the subtraction of [62] from the totals. In this case, the totals are correct after this modification. Forward-Port-Of: odoo/odoo#205860
Currently we block the push propagation when a move reach its final location. However it causes issue on some cases and it's not really helpful. E.g.of blocked flow - Special location in customer zone. - PO (set the final loc to stock). Arrived in stock don't push to wanted location Forward-Port-Of: odoo/odoo#206826
Original PR description
Currently we block the push propagation when a move reach its final location. However it causes issue on some cases and it's not really helpful. E.g.of blocked flow - Special location in customer zone. - PO (set the final loc to stock). Arrived in stock don't push to wanted location Forward-Port-Of: odoo/odoo#206826
this commit makes the validation of stock moves assign next stock move of same procurement group first. This will makes the MTSO moves reservation acts like hard MTO. Task: 4374225 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201846
Original PR description
this commit makes the validation of stock moves assign next stock move of same procurement group first. This will makes the MTSO moves reservation acts like hard MTO. Task: 4374225 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201846
Since 18.0, the taxes computation engine is managing the round globally. It means we have helpers and tools to manage features based on multiple base lines at a time. The hsn summary was using a custom representation of a base line with an explicit call to the low level _get_tax_details method. This commit removes this custom code to use the generic base lines instead. Also, this commit adds a test in POS to ensure the feature is working. --- I confirm I have signed the CLA and read the P
Original PR description
Since 18.0, the taxes computation engine is managing the round globally. It means we have helpers and tools to manage features based on multiple base lines at a time. The hsn summary was using a custom representation of a base line with an explicit call to the low level _get_tax_details method. This commit removes this custom code to use the generic base lines instead. Also, this commit adds a test in POS to ensure the feature is working. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201253
**Current behavior:** When receiving product after having billed it already, if: A) the product is valuated, B) the purchase is in a foreign currency, C) there is an underlying exchange diff between time of bill and receiption then the exchange difference account move will occur in the regular exchange account. **Expected behavior:** It should be for the stock valuation account. **Steps to reproduce:** *with anglo saxon accounting enabled* 1. Create a real-time valuated product in
Original PR description
**Current behavior:** When receiving product after having billed it already, if: A) the product is valuated, B) the purchase is in a foreign currency, C) there is an underlying exchange diff between…
**Current behavior:** When receiving product after having billed it already, if: A) the product is valuated, B) the purchase is in a foreign currency, C) there is an underlying exchange diff between time of bill and receiption then the exchange difference account move will occur in the regular exchange account. **Expected behavior:** It should be for the stock valuation account. **Steps to reproduce:** *with anglo saxon accounting enabled* 1. Create a real-time valuated product invoiced on ordered qty 2. Activate a foreign currency, set some exchange rate for today and tomorrow (unique) 3. Make a purchase for the product, invoice -> post 4. The next day, receive the product 5. Check the exchange journal to see the offending AMLs **Cause of the issue:** In this flow, when the receipt is validated, at this point: *from `_validate_accounting_entries()`* https://github.com/odoo/odoo/blob/7e7c1abeead0d4ef19ec15d50808ab33a642d25e/addons/stock_account/models/account_move.py#L185 the SVL linkage is somewhat broken because the bill's SVL was generated before the receiption's. It means the exchange diff reconciliation proceeds as "usual" (without the `stock_account` module impacting the process) so the regular journal and accounts are used to record the amounts. **Fix:** Add overrides for getting the relevant journal and account(s) inside `_prepare_exchange_difference_move_vals()` in order to prevent `real_time` valuated product moves from generating AMLs in the ordinary exchange account (instead, use the stock journal and stock valuation account resp.) opw-4655669 Forward-Port-Of: odoo/odoo#206095 Forward-Port-Of: odoo/odoo#204505
Description of the issue/feature this PR addresses: sale_pdf_quote_builder uses `//` for selection of the kanban and list views of the order lines rather than `/`. Current behavior before PR: However, in the upstream view the form view is declared first. If any extension, or studio change embeds a list or kanban view inside the form, the current selectors will pick that up instead of the list and kanban views associated with the order line. Desired behavior after PR is merged: More acc
Original PR description
Description of the issue/feature this PR addresses: sale_pdf_quote_builder uses `//` for selection of the kanban and list views of the order lines rather than `/`. Current behavior before PR: However, in the upstream view the form view is declared first. If any extension, or studio change embeds a list or kanban view inside the form, the current selectors will pick that up instead of the list and kanban views associated with the order line. Desired behavior after PR is merged: More accurately select the correct insertion point of the inherited view OPW-4716782 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205474
Purpose: ------- Following the changes in [1], discarding the changes in a form view when a properties field has a change does not reset the field to its initial value (UI only issue: the change is not applied when reloading the view). This issue arises because after the changes in [1], the properties are not deep copied anymore. Therefore, when a property is updated, the value inside the relational model's record data is updated. The issue is fixed by returning a copy of the properties
Original PR description
Purpose: ------- Following the changes in [1], discarding the changes in a form view when a properties field has a change does not reset the field to its initial value (UI only issue: the change is not applied when reloading the view). This issue arises because after the changes in [1], the properties are not deep copied anymore. Therefore, when a property is updated, the value inside the relational model's record data is updated. The issue is fixed by returning a copy of the properties values again. [1]: https://github.com/odoo/odoo/commit/8723f020c3587a900c811b8cc23f53fe34b98df3#diff-89ec9296feb48614f91829b8b732dca614359831967fa65a2126d6fe68c84450 Forward-Port-Of: odoo/odoo#207061 Forward-Port-Of: odoo/odoo#206824
the xmlid `hr_expense.mail_alias_expense` can be deleted by the user, don't raise error if xmlid is not found. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203152 Forward-Port-Of: odoo/odoo#203002
Original PR description
the xmlid `hr_expense.mail_alias_expense` can be deleted by the user, don't raise error if xmlid is not found. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203152 Forward-Port-Of: odoo/odoo#203002
task-4715664 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205388
Original PR description
task-4715664 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205388
Changing the syntax of the product code line in the invoice to not have a space before the colon. Example: `VTSZ : 8604000` -> `VTSZ: 8604000` task-4707459 Forward-Port-Of: odoo/odoo#206602
Original PR description
Changing the syntax of the product code line in the invoice to not have a space before the colon. Example: `VTSZ : 8604000` -> `VTSZ: 8604000` task-4707459 Forward-Port-Of: odoo/odoo#206602
Versions -------- - 17.4+ Steps ----- 1. Ensure that Mitchell Admin has a child delivery partner in the database with the following information: 'name': 'Mitchell Admin', 'email': 'admin@yourcompany.example.com', 'street': '215 Vine St', 'country': 'US', 'city':'Scranton', 'zip':'18503' 2. Log in to eCommerce as Mitchell Admin 3. Add any deliverable product to the cart 4. Pay using Express Checkout Issue ----- Express Checkout fails when customers use different billing and s
Original PR description
Versions -------- - 17.4+ Steps ----- 1. Ensure that Mitchell Admin has a child delivery partner in the database with the following information: 'name': 'Mitchell Admin', 'email': 'admin@yourcompany.example.com', 'street': '215 Vine St', 'country': 'US', 'city':'Scranton', 'zip':'18503' 2. Log in to eCommerce as Mitchell Admin 3. Add any deliverable product to the cart 4. Pay using Express Checkout Issue ----- Express Checkout fails when customers use different billing and shipping addresses. If the shipping address is unknown to the system, a validation error blocks payment. If known, the payment goes through but results in a generic shipping error with no further details or options for the user. Cause ----- `billing_address` was wrongly parsed as `shipping_address` in a5df1a7. Solution -------- Parse `shipping_address` correctly. opw-4710674 Forward-Port-Of: odoo/odoo#207010
Since Chrome 135, the "Keep scrollTop when loading records with load more" unit test fails with a scrolling value way higher than expected. In practice, the scroll in the test goes down to the "Load more" button after it has been clicked instead of keeping scroll to the same value as before the loading of the "more" items. Weirdly, it doesn't look to be an actual issue when performed by the user, but only in the test suite. This commit works around that issue by using `element.click()` f
Original PR description
Since Chrome 135, the "Keep scrollTop when loading records with load more" unit test fails with a scrolling value way higher than expected. In practice, the scroll in the test goes down to the "Load more" button after it has been clicked instead of keeping scroll to the same value as before the loading of the "more" items. Weirdly, it doesn't look to be an actual issue when performed by the user, but only in the test suite. This commit works around that issue by using `element.click()` followed by waiting for an animation frame instead of using `contains().click()`, because... well, the two helpers behave slightly differently. 🤷 Forward-Port-Of: odoo/odoo#206956
This commit remove the readonly on the tax_ids field, in the expense_split wizard. task-4703493 Forward-Port-Of: odoo/odoo#206957 Forward-Port-Of: odoo/odoo#205940
Original PR description
This commit remove the readonly on the tax_ids field, in the expense_split wizard. task-4703493 Forward-Port-Of: odoo/odoo#206957 Forward-Port-Of: odoo/odoo#205940
Unbuilding a returned product will break the stock valuations. To reproduce the issue: 1. Create a FIFO product 2. Produce 3. Deliver 4. Return 5. Unbuild Issue: Looking at the remaining qties of the SVL, we see that the layer of the unbuild didn't consume the quantity of the return. This may lead to more important issues in the stock valuation. When processing the unbuild, we `_run_fifo` to consume the existing SVLs. To do so, we first try to find the candidates. Here is the p
Original PR description
Unbuilding a returned product will break the stock valuations. To reproduce the issue: 1. Create a FIFO product 2. Produce 3. Deliver 4. Return 5. Unbuild Issue: Looking at the remaining qties of the…
Unbuilding a returned product will break the stock valuations. To reproduce the issue: 1. Create a FIFO product 2. Produce 3. Deliver 4. Return 5. Unbuild Issue: Looking at the remaining qties of the SVL, we see that the layer of the unbuild didn't consume the quantity of the return. This may lead to more important issues in the stock valuation. When processing the unbuild, we `_run_fifo` to consume the existing SVLs. To do so, we first try to find the candidates. Here is the problem: since [1], in case of an unbuild, we force to use the SVL of the MO only. This will not work with the above use case: the SVL of the MO has been consumed by the delivery. Therefore, we don't find any candidate. This is the reason why we have some inconsistencies on the layers. Instead of getting the SVL of the MO only, we should simply give it the priority and be able to find some other candidates. [1] https://github.com/odoo/odoo/commit/49565cdd9007ac66a3b835dc073777e2e6c48f2c OPW-4683083 Forward-Port-Of: odoo/odoo#206659 Forward-Port-Of: odoo/odoo#206450
Even though uploaded image was .png it gives such error, reason behind this was `DecompressionBombWarning` occurred in `PIL (Pillow)`  Before this PR: - When uploading an image that is too large, the error message notification was showing wrong message. After this PR: - The error message notification will show the correct message. task-4606136 --- I confirm I have signed the CLA and
Original PR description
Even though uploaded image was .png it gives such error, reason behind this was `DecompressionBombWarning` occurred in `PIL (Pillow)`  Before this PR: - When uploading an image that is too large, the error message notification was showing wrong message. After this PR: - The error message notification will show the correct message. task-4606136 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206059 Forward-Port-Of: odoo/odoo#199564
When changing the journal on a draft payment, the linked journal entry was not updated. This caused two issues: The journal entry kept the old journal. The sequence (move name) was not updated to match the new journal. Now, when the journal is changed on a draft payment, both the journal and its sequence are correctly updated. task-4688823 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I conf
Original PR description
When changing the journal on a draft payment, the linked journal entry was not updated. This caused two issues: The journal entry kept the old journal. The sequence (move name) was not updated to match the new journal. Now, when the journal is changed on a draft payment, both the journal and its sequence are correctly updated. task-4688823 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204507
We get an Access Error when trying to print check from a journal that is shared between branches. Steps: - Have a company X and a branch Y - Make a vendor payment with only X selected in company selector, set payment method as 'Checks' - Confirm and print check - Now select only branch Y in company selector - Create a vendor payment with same config as previous one - Condirm, and try to print check -> Access Error This is because we try to get the previous check number from the last payment
Original PR description
We get an Access Error when trying to print check from a journal that is shared between branches. Steps: - Have a company X and a branch Y - Make a vendor payment with only X selected in company selector, set payment method as 'Checks' - Confirm and print check - Now select only branch Y in company selector - Create a vendor payment with same config as previous one - Condirm, and try to print check -> Access Error This is because we try to get the previous check number from the last payment of the journal, but even if the record shares the same journal, we don't necessary have access to it. Fix: Get `check_number` directly from the SQL query instead of a record opw-4520708 Forward-Port-Of: odoo/odoo#206304
This corrects 9f96aa7648ed4320849c6736e85b9cb6c988232c that was impacting all xml files whereas it should only have had an impact on the invoice report. opw-4661577 Forward-Port-Of: odoo/odoo#206877 Forward-Port-Of: odoo/odoo#206811
Original PR description
This corrects 9f96aa7648ed4320849c6736e85b9cb6c988232c that was impacting all xml files whereas it should only have had an impact on the invoice report. opw-4661577 Forward-Port-Of: odoo/odoo#206877 Forward-Port-Of: odoo/odoo#206811
## Issue When an employee has a flexible (unset) working calendar, and another employee has the default calendar (`Standard 40 hours/week`), scheduling a meeting involving both results in a `KeyError`: ```python File "/home/odoo/src/odoo/18.0/addons/hr_calendar/models/res_partner.py", line 78, in _get_schedule calendar_interval = interval_by_calendar[calendar][employee.resource_id.id] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^ KeyError: <numbe
Original PR description
## Issue When an employee has a flexible (unset) working calendar, and another employee has the default calendar (`Standard 40 hours/week`), scheduling a meeting involving both results in a…
## Issue
When an employee has a flexible (unset) working calendar, and another employee has the default calendar (`Standard 40 hours/week`), scheduling a meeting involving both results in a `KeyError`:
```python
File "/home/odoo/src/odoo/18.0/addons/hr_calendar/models/res_partner.py", line 78, in _get_schedule
calendar_interval = interval_by_calendar[calendar][employee.resource_id.id]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: <number>
```
## Root Cause
Odoo uses the Standard 40 hours/week calendar (resource.resource_calendar_std) as a fallback for flexible (unset) calendars. However, when grouping resources by their calendars, resources without a calendar are included in a separate group.
Later, when Odoo computes work intervals per calendar, it assigns the default calendar to resource.resource(). If another user already uses the same calendar, the group duplication results in one being overwritten during iteration—causing the KeyError.
## Fix
Before grouping resources by calendar, explicitly assign the default calendar (resource.resource_calendar_std) to any resource that lacks a calendar. This ensures all resources are grouped correctly, avoiding duplication and key errors.
## Impacted versions:
18.0 and later
## Steps to Reproduce
### Pre-requisites:
- Install `hr_contract`, `calendar` apps.
### Steps:
1. Create **Employee 1**:
- Set **Working hours** to **Flexible** (unset)
- Create a **Contract**:
- Set **Working hours** to **Flexible** (unset)
2. Create **Employee 2**:
- Set **Working hours** to **Standard 40 hours/week**
- Create a **Contract**:
- Set **Working hours** to **Standard 40 hours/week**
- Ensure the XML ID is `resource.resource_calendar_std`
3. Open the **Calendar** app.
4. Create a **new Event**.
5. Add both employees as **attendees**.
## Current Behavior
The system raises a `KeyError` and does not allow the event to be saved.
## Expected Behavior
The event is saved successfully with both attendees.
### Task
OPW-[4699028](https://www.odoo.com/odoo/my-tasks/4699028)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#205266**Current behavior:** In the *Contacts* application, with a partner record open, you can view the lots associated with that customer (used in orders for that partner(?)). Lots that were delivered to that partner via dropship transfers do not appear here. **Expected behavior:** Dropship lots are there. **Steps to reproduce:** 1. Create a dropship product (route, vendor, ..) tracked by lot 2. Sell 1 of that product to some partner, confirm the ensuing purchase & dropship transfer
Original PR description
**Current behavior:** In the *Contacts* application, with a partner record open, you can view the lots associated with that customer (used in orders for that partner(?)). Lots that were delivered to that partner via dropship transfers do not appear here. **Expected behavior:** Dropship lots are there. **Steps to reproduce:** 1. Create a dropship product (route, vendor, ..) tracked by lot 2. Sell 1 of that product to some partner, confirm the ensuing purchase & dropship transfer 3. Go to *Contact* -> open the customer -> `Lot/Serial Numbers` smart button -> lot is not there **Cause of the issue:** `StockLotReport` only looks for `outgoing` (delivery) picking type pickings. **Fix:** Override the join on `PickingType` and `ResPartner` such that dropship pickings can also be collected here. opw-4559129 Forward-Port-Of: odoo/odoo#204250
Explanation: Includes previously missing supported payment methods for AsiaPay, such as Alipay (distinct from AlipayHK). Forward-Port-Of: odoo/odoo#206836
Original PR description
Explanation: Includes previously missing supported payment methods for AsiaPay, such as Alipay (distinct from AlipayHK). Forward-Port-Of: odoo/odoo#206836
Steps to reproduce: 1. Drag and drop a popup snippet. 2. Add a banner inside the popup snippet. 3. Set the banner to be invisible on desktop by selecting `no_desktop` visibility on the `Block` element. Issue: The popup remains open, but the element is incorrectly marked as hidden in the invisibility elements list. Solution: This PR ensures that the element's visibility is toggled correctly and triggers the snippet activation to false. task-4337481 Forward-Port-Of: odoo/odoo#206893
Original PR description
Steps to reproduce: 1. Drag and drop a popup snippet. 2. Add a banner inside the popup snippet. 3. Set the banner to be invisible on desktop by selecting `no_desktop` visibility on the `Block` element. Issue: The popup remains open, but the element is incorrectly marked as hidden in the invisibility elements list. Solution: This PR ensures that the element's visibility is toggled correctly and triggers the snippet activation to false. task-4337481 Forward-Port-Of: odoo/odoo#206893 Forward-Port-Of: odoo/odoo#187233
Issue Before This Commit: ------------------------------ The 'company' field was required but not validated in relevant triggers for scrap orders. This allowed operations to proceed even when the 'company' field was unset, leading to unexpected issues and inconsistent behavior. Steps to reproduce: ------------------------------ 1. Enable multi-step routes. 2. Create a new scrap order and add a product. 3. Remove the company from the company field. With This Commit: -----------------
Original PR description
Issue Before This Commit: ------------------------------ The 'company' field was required but not validated in relevant triggers for scrap orders. This allowed operations to proceed even when the 'company' field was unset, leading to unexpected issues and inconsistent behavior. Steps to reproduce: ------------------------------ 1. Enable multi-step routes. 2. Create a new scrap order and add a product. 3. Remove the company from the company field. With This Commit: ------------------------------ - Added a check for 'company' in relevant triggers to ensure that operations only proceed if a company is set. - This fix guarantees that the 'company' field is always set (required), preventing errors and maintaining consistent behavior in scrap orders. task-4497387 Forward-Port-Of: odoo/odoo#194702
<b>Steps to reproduce:</b> 1. Go to website > Shop > Scroll to tags filter (If tags aren't visible in the sidebar, go to Sales > Configuration > Product Tags > create tags) 2. Notice that Tags filter cannot be collapsed unlike other filters 3. Observe that margins and spacing don't match other filter components <b>Issue:</b> The "Tags" filter on the website shop sidebar lacked a collapsible header, unlike other filters such as "Price Range". This caused UI inconsistency. Additionally, t
Original PR description
<b>Steps to reproduce:</b> 1. Go to website > Shop > Scroll to tags filter (If tags aren't visible in the sidebar, go to Sales > Configuration > Product Tags > create tags) 2. Notice that Tags filter cannot be collapsed unlike other filters 3. Observe that margins and spacing don't match other filter components <b>Issue:</b> The "Tags" filter on the website shop sidebar lacked a collapsible header, unlike other filters such as "Price Range". This caused UI inconsistency. Additionally, the margin and spacing did not align visually with other filter components. <b>Solution:</b> Applied Bootstrap collapse classes to the Tags filter to enable accordion-style toggling. Adjusted margin and structure to match the layout of other sidebar filters for visual consistency. opw-4702463 Forward-Port-Of: odoo/odoo#205709
The view `digest.res_config_settings_view_form` uses the field `restrict_template_rendering_setting` from the [mail](https://github.com/odoo/odoo/blob/2987eea19f375191250ac9306f6b9d3b831ade08/addons/mail/views/res_config_settings_views.xml#L58) module in an xpath, while it inherits the view in `base_setup`. The order of the inheritence can load the digest view before the mail view and the field in the xpath will not be found. affects many upgrades --- I confirm I have signed the CLA and r
Original PR description
The view `digest.res_config_settings_view_form` uses the field `restrict_template_rendering_setting` from the [mail](https://github.com/odoo/odoo/blob/2987eea19f375191250ac9306f6b9d3b831ade08/addons/mail/views/res_config_settings_views.xml#L58) module in an xpath, while it inherits the view in `base_setup`. The order of the inheritence can load the digest view before the mail view and the field in the xpath will not be found. affects many upgrades --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206841
## Issue: Survey's PDF certifications no longer display the company logo when printed by other companies' users. ## Steps to reproduce: - Create a survey with certification and ensure `Require Login` is checked; - Share the survey (copy the `Survey Link`); - In a private navigator (to ensure no login data are saved): - Log in as Demo user; - Answer the survey (using the copied link above); - Go to Surveys / Participations; - Enter the record of your test (`Contact` field shoul
Original PR description
## Issue: Survey's PDF certifications no longer display the company logo when printed by other companies' users. ## Steps to reproduce: - Create a survey with certification and ensure `Require Login`…
## Issue:
Survey's PDF certifications no longer display the company logo when printed by other companies' users.
## Steps to reproduce:
- Create a survey with certification and ensure `Require Login` is checked;
- Share the survey (copy the `Survey Link`);
- In a private navigator (to ensure no login data are saved):
- Log in as Demo user;
- Answer the survey (using the copied link above);
- Go to Surveys / Participations;
- Enter the record of your test (`Contact` field should match Demo's data);
- Open the PDF certification in the chatter.
## Cause:
The company `logo` field is a Binary field related to the partner's `image_1920`.
The retrieval method was changed to access `partner_id.image_1920` directly with `sudo`, since `sudo` does not apply when accessing the related field (`logo`) directly.
However, this change broke the standard certification printing layout, likely due to rendering issues with the direct access method.
## Fix:
Reverts logo access back to the related field `company_id.logo` to restore compatibility with certification printing.
Partial revert of commit 9b4c4ad8d1a238c6f7f4bea52d3f64016a6ff325 as already applied by JKE on Odoo.
Ensures the certification printing is still allowed for other companies' users.
opw-4266445
opw-4657294
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#204262Some of the tests are not deterministic on the runbot. Avoid raising errors in these cases. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206669
Original PR description
Some of the tests are not deterministic on the runbot. Avoid raising errors in these cases. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206669
## Details: The function get_link_preview_from_html is a common tool used in many modules, one of them documents. When you add a link on a workspace that response with a content with a xml declaration (ex. "<!--?xml version="1.0" encoding="UTF-8"?-->"), this will raise the next ValueError: "Unicode strings with encoding declaration are not supported. Please use bytes input or XML fragments without declaration." At the moment that the string is being parsed as a html element, this str
Original PR description
## Details: The function get_link_preview_from_html is a common tool used in many modules, one of them documents. When you add a link on a workspace that response with a content with a xml…
## Details: The function get_link_preview_from_html is a common tool used in many modules, one of them documents. When you add a link on a workspace that response with a content with a xml declaration (ex. "<!--?xml version="1.0" encoding="UTF-8"?-->"), this will raise the next ValueError: "Unicode strings with encoding declaration are not supported. Please use bytes input or XML fragments without declaration." At the moment that the string is being parsed as a html element, this string has been cleaned, to avoid the issue, we can only remove this xml declaration because this element is only being used to extract information about the page. ## Impacted versions: 18.0 and later ## Steps to reproduce: 1. Go to Documents App 2. Add a link in any workspace with xml declaration (ex. https://www.buffalo.jp/s3/guide/crmm/userguide/99/en/pc_index.html) ## Current behavior: Raise Value Error "Unicode strings with encoding declaration are not supported. Please use bytes input or XML fragments without declaration." ## Expected behavior: Link should be saved. ### Task OPW-4675813 Forward-Port-Of: odoo/odoo#205049
Description: Adding a warning message when checking the option to enable the audit trail as this option can't be disabled if there are any existing move lines. opw-4596812 opw-4346608 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200072
Original PR description
Description: Adding a warning message when checking the option to enable the audit trail as this option can't be disabled if there are any existing move lines. opw-4596812 opw-4346608 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200072
In commit aca36072a8adcdc2263f5dcc12a3c9fb374a025e a new data file was created but not included in the manifest. So it is never loaded. This commit removes the file (since it is not used anyway). task: None Forward-Port-Of: odoo/odoo#206612
Original PR description
In commit aca36072a8adcdc2263f5dcc12a3c9fb374a025e a new data file was created but not included in the manifest. So it is never loaded. This commit removes the file (since it is not used anyway). task: None Forward-Port-Of: odoo/odoo#206612
The text color in the input is purple and not clearly visible with the dark input background. Steps to reproduce: ------------------- * Go to edit mode. * Drag and drop a "countdown" block. * Open the date picker by clicking the "Due Date" input in the options. * Click on a date. > Observation: Why the fix: ------------ Make it visible opw-4589158 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205040
Original PR description
The text color in the input is purple and not clearly visible with the dark input background. Steps to reproduce: ------------------- * Go to edit mode. * Drag and drop a "countdown" block. * Open the date picker by clicking the "Due Date" input in the options. * Click on a date. > Observation: Why the fix: ------------ Make it visible opw-4589158 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205040
**Issue** Menu items starting with helpdesk in their URL were not dispalyed to the public user in some cases. **Steps to reproduce** - Have `website_helpdesk` installed. - Activate the website form for a helpdesk team. - Create a menu item for the website, using a URL starting with helpdesk, e.g. `/helpdesk-123-test` - This menu is always invisible to the public user. **Cause** This issue was fixed in previous versions, but it appears the duplicated `_compute_visible` code present
Original PR description
**Issue** Menu items starting with helpdesk in their URL were not dispalyed to the public user in some cases. **Steps to reproduce** - Have `website_helpdesk` installed. - Activate the website form…
**Issue** Menu items starting with helpdesk in their URL were not dispalyed to the public user in some cases. **Steps to reproduce** - Have `website_helpdesk` installed. - Activate the website form for a helpdesk team. - Create a menu item for the website, using a URL starting with helpdesk, e.g. `/helpdesk-123-test` - This menu is always invisible to the public user. **Cause** This issue was fixed in previous versions, but it appears the duplicated `_compute_visible` code present in `website.py` was not deleted in forward ports of the fix (see enterprise PR 63105). https://github.com/odoo/enterprise/blob/b320390d23d3f009beb809e0334c8fa61c44d824/website_helpdesk/models/website.py#L24-L26 As a result, the menu item starting with `/helpdesk` is matched as a helpdesk menu, but will logically not be part of the helpdesk published menus: https://github.com/odoo/enterprise/blob/b320390d23d3f009beb809e0334c8fa61c44d824/website_helpdesk/models/website.py#L30-L32 opw-4560291 Forward-Port-Of: odoo/enterprise#82824
- Adding 'invoice_received' as an accepted state in account_move.py -> _compute_l10n_mx_edi_cfdi_state_and_attachment to enable SAT status display on vendor bills in 17.0, making SAT status no longer remain None. - Making adjustments to functions updating SAT status related fields for vendor bills. - Adding a test for SAT status for creating and cancelling vendor bills. The change necessary to display 'Update SAT' button was already implemented in 17.0 in https://github.com/odoo/enterpr
Original PR description
- Adding 'invoice_received' as an accepted state in account_move.py -> _compute_l10n_mx_edi_cfdi_state_and_attachment to enable SAT status display on vendor bills in 17.0, making SAT status no longer remain None. - Making adjustments to functions updating SAT status related fields for vendor bills. - Adding a test for SAT status for creating and cancelling vendor bills. The change necessary to display 'Update SAT' button was already implemented in 17.0 in https://github.com/odoo/enterprise/commit/931d7b199f1183acfbb42325025a6b62b2e73de1 but not forward ported yet. task-4368532 Forward-Port-Of: odoo/enterprise#83842 Forward-Port-Of: odoo/enterprise#80201
Forward-Port-Of: odoo/enterprise#81187
Original PR description
Forward-Port-Of: odoo/enterprise#81187
The miscellaneous were displayed in the VIES summary report (even if it was rare as it needs to have the field l10n_cz_transaction_code set). A common case would be to create deferred entries with this transaction field set. opw-4688616 Forward-Port-Of: odoo/enterprise#83112
Original PR description
The miscellaneous were displayed in the VIES summary report (even if it was rare as it needs to have the field l10n_cz_transaction_code set). A common case would be to create deferred entries with this transaction field set. opw-4688616 Forward-Port-Of: odoo/enterprise#83112
In this commit we fix the website_sale_renting_select_wrong_period tour that can cause undeterministic errors. Forward-Port-Of: odoo/enterprise#83568
Original PR description
In this commit we fix the website_sale_renting_select_wrong_period tour that can cause undeterministic errors. Forward-Port-Of: odoo/enterprise#83568
Adding a condition to match contry to CO when looking for NIT latam ID type. therwise, adding another ID type named 'NIT' for a different country causes the search to return both, resulting in a traceback. task-4318265 Forward-Port-Of: odoo/enterprise#83859 Forward-Port-Of: odoo/enterprise#81216
Original PR description
Adding a condition to match contry to CO when looking for NIT latam ID type. therwise, adding another ID type named 'NIT' for a different country causes the search to return both, resulting in a traceback. task-4318265 Forward-Port-Of: odoo/enterprise#83859 Forward-Port-Of: odoo/enterprise#81216
steps to reproduce: - set up ONSS data about the company in Payroll settings / BE L10N (where ONSS number is consisting of special characters - dots or dashes) - go to Payroll / Reporting / DMFA - create a new DMFA and generate an XML report - it should throw error saying expected `int` (since ONSS is a Char field) fix: - while performing the export, filtered the digits only from these fields task-4502689 Forward-Port-Of: odoo/enterprise#80876
Original PR description
steps to reproduce: - set up ONSS data about the company in Payroll settings / BE L10N (where ONSS number is consisting of special characters - dots or dashes) - go to Payroll / Reporting / DMFA - create a new DMFA and generate an XML report - it should throw error saying expected `int` (since ONSS is a Char field) fix: - while performing the export, filtered the digits only from these fields task-4502689 Forward-Port-Of: odoo/enterprise#80876
Currently, the “Unpaid” and “Late” buttons in the sale journal dashboard used the total invoice amount instead of the remaining due amount when account_3way_match was installed. Steps to reproduce: - Install account_3way_match - Create and partially pay an invoice - Go to the dashboard - The displayed amount should reflect the residual, but it shows the full amount This fix restores the expected behavior by using the same logic as the original `_get_open_sale_purchase_query` to compute
Original PR description
Currently, the “Unpaid” and “Late” buttons in the sale journal dashboard used the total invoice amount instead of the remaining due amount when account_3way_match was installed. Steps to reproduce: - Install account_3way_match - Create and partially pay an invoice - Go to the dashboard - The displayed amount should reflect the residual, but it shows the full amount This fix restores the expected behavior by using the same logic as the original `_get_open_sale_purchase_query` to compute `amount_total` and `amount_total_company`. opw-4731478 Forward-Port-Of: odoo/enterprise#83823
This reverts commit cbcff76a94750a6759fd72d9c952d785e603a974. Fix in community was changing all the xml files generated, whereas it should only have had an impact on the invoice report. opw-4661577 Forward-Port-Of: odoo/enterprise#83827 Forward-Port-Of: odoo/enterprise#83783
Original PR description
This reverts commit cbcff76a94750a6759fd72d9c952d785e603a974. Fix in community was changing all the xml files generated, whereas it should only have had an impact on the invoice report. opw-4661577 Forward-Port-Of: odoo/enterprise#83827 Forward-Port-Of: odoo/enterprise#83783
Steps to reproduce: - insert a pivot into a spreadsheet - add the dynamic pivot somewhere with the formula =PIVOT(1) - right click on the values and sort them - open the side panel - update anything (e.g. the domain) => the sorting is dropped. Since commit 93ffeeefe86, measures are identified with the `id` property, not the name. Task: 4746057 opw-4741934 Forward-Port-Of: odoo/enterprise#83903
Original PR description
Steps to reproduce: - insert a pivot into a spreadsheet - add the dynamic pivot somewhere with the formula =PIVOT(1) - right click on the values and sort them - open the side panel - update anything (e.g. the domain) => the sorting is dropped. Since commit 93ffeeefe86, measures are identified with the `id` property, not the name. Task: 4746057 opw-4741934 Forward-Port-Of: odoo/enterprise#83903
**Steps to reproduce:** - Install Accounting - Activate a foreign currency (e.g. EUR) - Make sure there are several rates with today rate different than others - Go to "Accounting / Configuration / Accounting / Chart of Accounts" - Add a default tax to "Expenses" account - Create an invoice: * Customer: [any] * Currency: [EUR] (i.e. the foreign currency) * Invoice Date: [a date in the past where the currency rate is different than today] * Invoice Lines: [any] - Confirm th
Original PR description
**Steps to reproduce:** - Install Accounting - Activate a foreign currency (e.g. EUR) - Make sure there are several rates with today rate different than others - Go to "Accounting / Configuration /…
**Steps to reproduce:** - Install Accounting - Activate a foreign currency (e.g. EUR) - Make sure there are several rates with today rate different than others - Go to "Accounting / Configuration / Accounting / Chart of Accounts" - Add a default tax to "Expenses" account - Create an invoice: * Customer: [any] * Currency: [EUR] (i.e. the foreign currency) * Invoice Date: [a date in the past where the currency rate is different than today] * Invoice Lines: [any] - Confirm the invoice - Go to "Accounting / Reporting / Management / Unrealized Currency Gains/Losses" - Set date filter to "Today" - If there is no adjustement to do, check if the following message is displayed: "You are using custom exchange rates. => Reset to Odoo’s Rate" If it's the case, reset to Odoo's rate (i.e. Today's rate) - Click on "Adjustement Entry" button: * Journal: Miscellaneous Operations * Expense Account: Expenses * Income Account: [any] - Create Entry **Issue:** The values (debit/credit) of the created entry are 0, which is not the case when there is no default tax on the expense account. **Cause:** "_sync_dynamic_lines" is executed on the created entry. If a default tax is set on the expense account, "_sync_tax_lines" is also executed. As only debit and credit values are set on the invoice lines of the entry (neither balance nor amount_currency), the sync method messes up with the value of debit and credit, resetting them to 0 (via multiple recompute). **Solution:** Skip invoice sync. The values computed in "Multicurrency Revaluation Wizard" should be the ones that are used. opw-4664255 Forward-Port-Of: odoo/enterprise#83570
Steps: - duplicate a worksheet template - add a field on the new template - print the original template --> error : field doesn't exist on original worksheet model Current behaviour: Duplicating a worksheet template creates a new model, but the _generate_qweb_report_template method doesn't create a new view for the new template because we copied the original one. It also removes the customizations on the original template's view New behaviour: A new view is created for the dupli
Original PR description
Steps: - duplicate a worksheet template - add a field on the new template - print the original template --> error : field doesn't exist on original worksheet model Current behaviour: Duplicating a worksheet template creates a new model, but the _generate_qweb_report_template method doesn't create a new view for the new template because we copied the original one. It also removes the customizations on the original template's view New behaviour: A new view is created for the duplicated template and remove the duplicate option from the list view, as it is already hidden in form view opw-4664600 opw-4656835 Forward-Port-Of: odoo/enterprise#83529 Forward-Port-Of: odoo/enterprise#83166
The lack of a wait on the pdf's iframe causes a race condition in `sign/static/src/components/sign_request/document_signable.js`, which *can* cause the PDFIframe's `contentDocument` to be reset in the setTimeout(() => this.initializeIframe(), 1); interval as the document ?gets reinitialised?, leading to an error in `initializeIframe`. I assumed it would be necessary to wait for the iframe's `readyState` to be `"complete"`, however after the iframe triggers I was not able to "see" th
Original PR description
The lack of a wait on the pdf's iframe causes a race condition in `sign/static/src/components/sign_request/document_signable.js`, which *can* cause the PDFIframe's `contentDocument` to be reset in the
setTimeout(() => this.initializeIframe(), 1);
interval as the document ?gets reinitialised?, leading to an error in `initializeIframe`.
I assumed it would be necessary to wait for the iframe's `readyState` to be `"complete"`, however after the iframe triggers I was not able to "see" the frame in any other `readyState`, so seems like an unnecessary complexity after all. Hopefully this doesn't come back to bite...
https://runbot.odoo.com/odoo/error/181583
Forward-Port-Of: odoo/enterprise#83937Before this commit: The technical name was not clearly visible in dark mode, making it difficult for users to read. After this commit: The technical name is now clearly visible in dark mode. Task-4680365 Forward-Port-Of: odoo/enterprise#82429
Original PR description
Before this commit: The technical name was not clearly visible in dark mode, making it difficult for users to read. After this commit: The technical name is now clearly visible in dark mode. Task-4680365 Forward-Port-Of: odoo/enterprise#82429
Coming From: https://github.com/odoo/enterprise/pull/69708 Forward-Port-Of: odoo/enterprise#83789
Original PR description
Coming From: https://github.com/odoo/enterprise/pull/69708 Forward-Port-Of: odoo/enterprise#83789
In this PR we add the following wage types: - Complementary LPP - Alimony Deduction - Deduction for prosecution office Forward-Port-Of: odoo/enterprise#83885
Original PR description
In this PR we add the following wage types: - Complementary LPP - Alimony Deduction - Deduction for prosecution office Forward-Port-Of: odoo/enterprise#83885
-- How to reproduce -- Duplicate two or more belgian employees. -- Reason -- The sdworx code check constraint was wrongly single record. -- Fix -- This commit fixes the issue by converting the check to multi records. task-4708324 Forward-Port-Of: odoo/enterprise#83852 Forward-Port-Of: odoo/enterprise#83026
Original PR description
-- How to reproduce -- Duplicate two or more belgian employees. -- Reason -- The sdworx code check constraint was wrongly single record. -- Fix -- This commit fixes the issue by converting the check to multi records. task-4708324 Forward-Port-Of: odoo/enterprise#83852 Forward-Port-Of: odoo/enterprise#83026
### Steps to reproduce: - Accounting > Reporting > Partner Ledger - Select multiple partners - Select "Customer Statements" as report - Click "Send" - Go to the one of the partner in question an dopen the generated PDF - All current companies show in the header and other currencies are present ### Cause: When sending to multiple partners, the action is dispatched with to cron_threads so a new `env` is created. This `env` has a key `companies` containing all companies that exist in the
Original PR description
### Steps to reproduce: - Accounting > Reporting > Partner Ledger - Select multiple partners - Select "Customer Statements" as report - Click "Send" - Go to the one of the partner in question an…
### Steps to reproduce: - Accounting > Reporting > Partner Ledger - Select multiple partners - Select "Customer Statements" as report - Click "Send" - Go to the one of the partner in question an dopen the generated PDF - All current companies show in the header and other currencies are present ### Cause: When sending to multiple partners, the action is dispatched with to cron_threads so a new `env` is created. This `env` has a key `companies` containing all companies that exist in the DB. When the `_init_options_companies` is called for the report it adds `self.env.companies` to the option ([code](https://github.com/odoo/enterprise/blob/4ef74fd9527a28616bf81c9716d6000aa25b839e/account_reports/models/account_report.py#L1276)). So in the end all companies appear on the report. ### Solution: Add 'forced_companies' in the options before calling the `cron`. The format of 'forced_companies' had to be changed to only contain ids because fields cannot be added in `send_and_print_values` as it's a JSON fields. opw-4635283 Forward-Port-Of: odoo/enterprise#82320