Wednesday, December 18, 2024
80 changes
Resolved issues and error corrections
The mail sub-channel search panel now stays within the visible browser area more reliably. This prevents automated checks from failing in newer Chrome versions or watch mode, improving confidence in mail interface stability without changing user workflows.
Original PR description
Before this PR, the `test_04_sub_channel_panel_search` test was always failing when chrome version is greater than 123 or in watch mode. This occurs because the sub channel search panel is overflowing, falsing the assertion related to the thread being scrolled to the bottom. The search panel popover is restricted to `Min(100vh, 500px)` which does not take into account the space between the top of the window and the popover. This PR fixes the issue by reducing the vh allowed for the popover in order to keep it visible as much as possible.
This update makes an automated test for collaborative editing more reliable by waiting until the text selection is fully updated before checking it. It helps prevent false test failures, improving confidence in future releases without changing the user experience.
Original PR description
The test introduced in [1] is failing undeterministically. Since the selection update somtimes takes more time than what is expected, we change it waituntil the selection is correct. 109367 [1]: https://github.com/odoo/odoo/pull/179742
This update fixes an accounting test so it works even when only the Accounting app is installed. It reduces false test failures caused by assumptions about optional payment methods from other apps, helping keep releases more reliable.
Original PR description
Don't rely on other modules adding payment methods without an account, it should run with `account` only installed. runbot-106384
Printing receipts from Point of Sale no longer produces an unwanted blank page. This saves paper and reduces confusion for cashiers and customers when issuing receipts.
Original PR description
An extra blank page was being printed when printing the receipt from the POS.
Adding
```
.pos-receipt {
contain: paint;
background-color: transparent;
}
```
to the receipt_screen.scss file fixes the issue.
opw-4292890The emoji button in the Mail text field now appears in the correct place instead of being pushed too far into the form. This prevents overlap with other interface elements and makes emoji use more consistent for users.
Original PR description
The emoji button in the text field was misaligned. Appearing too far in the form view. This led to the emoji being overlapped by other components. The fix consists in : - Added a 'position-absolute' to the button for correct alignement - Updated the parent container to 'position:relative' in the css for correct positioning. This fix addresses a user interface bug and ensures consistent emoji positioning/display. opw-4332574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes Argentine withholding calculations more reliable when registering payments, especially when several payment records are processed together. It also ensures that “today” follows the user’s local date, helping avoid date-related errors in payment workflows.
Original PR description
A few things were wrong: * a compute function needs to take into account multiple records. It can happen even on wizards i.e. in tests because fields are flushed together * `fields.Date.from_string` is deprecated and useless * "Today" needs to take into account the locale of the user runbot-98546
This fixes a redundant validation step when opening the payment registration flow. The same check still happens later as part of preparing the payment wizard, reducing unnecessary failures while preserving existing safeguards.
Original PR description
Remove the check done in `action_force_register_payment` because it will be done anyway when computing the default values for opening the wizard. runbot-105675
Email marketing editors will no longer offer the option to add videos, which are not supported in mass mailing emails. This prevents users from creating campaign content that may not display or work correctly for recipients.
Original PR description
**Problem**: Videos are not supported in email marketing, yet the powerbox allows users to add videos. **Solution**: Disable the option to add videos when editing email templates in mass_mailing. **Steps to reproduce**: 1. Create a new email template. 2. Open the powerbox. 3. Observe that the option to add videos is available. opw-4395333 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The online shop now shows only the tags linked to the selected product variant instead of mixing in tags from other variants. This helps customers see accurate product information and avoids confusion when comparing or choosing variants.
Original PR description
Steps to reproduce: ------------------ - Set a product tags for a specific variant - Go to the shop - All the tags of all product variant are displayed Issue: ----- While displaying the tags the tags does not take into account the current product. This results in the display of all the tags of all variant instead of the tags of the specific one. Fix: ---- task-4357477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects an accounting test so it behaves properly when only the Community Edition is installed. It helps keep automated checks reliable and avoids false failures that could slow down future accounting fixes.
Original PR description
* If only using Odoo CE, this test will fail because action_force_register_payment will raise usererror like 'you can only ...' which will not match the expected out come 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
This fixes a display issue where the email template editor's fullscreen mode could appear hidden behind a pop-up window. Users editing email automation templates can now use fullscreen editing without the workspace being obscured.
Original PR description
Issue: ====== When we toggle the full screen mode it's displayed under the modal. Steps to reproduce the issue: ============================= - Install email automation - Create a new one (commercial prospection) - Click on offer free catalog to open the modal - Click on the internal link on the right of mail template - Toggle full screen mode of the snippets editor - The editing area is under the modal Origin of the issue: ==================== When we toggle the full screen mode we add the class `o_form_fullscreen_ancestor` which will add `z-index:zindex-modal-backdrop + 1` which is bascially putting the iframe under the modal. Solution: ========= Update the `z-index` to put the iframe and the snippets on top of the modal opw-4318011
Code cleanup and technical improvements
This update makes internal web tour testing easier and more reliable by improving how browser windows open during automated tests. It also gives developers quicker access to debugging tools in the browser console, helping them diagnose issues faster.
Original PR description
In this commit, we change two small things to make debugging tours much easier. The first is to use the --start-fullscreen flag instead of --start-maximized because the first one seems to not work properly depending on the chrome versions. The second is to make hoot more easily available in the console so that it can be used more quickly. 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
Miscellaneous changes
The import origin of `json` will be changed to `odoo.tools.safe_eval` for 2 reasons: 1. From 18.0 onwards, it refers to the `json.py` file, not the intended `json` module. This leads to an `AttributeError` when we're calling `json.loads(...)` method. 2. The `json` module from `safe_eval` is, from a security perspective, the intended way to load a json string (rather than the usual `json` from `import json`). follow up of: https://github.com/odoo/odoo/pull/187708 more info: https://git
Original PR description
The import origin of `json` will be changed to `odoo.tools.safe_eval` for 2 reasons: 1. From 18.0 onwards, it refers to the `json.py` file, not the intended `json` module. This leads to an `AttributeError` when we're calling `json.loads(...)` method. 2. The `json` module from `safe_eval` is, from a security perspective, the intended way to load a json string (rather than the usual `json` from `import json`). follow up of: https://github.com/odoo/odoo/pull/187708 more info: https://github.com/odoo/odoo/commit/5ef4c07ada1b47cd08a0fc7a2dd626f92d79b715#diff-6e39afafc5c2078cdfdc27335b7cf8b0867853dc34b5b907a0190f6453949bb2R21 opw-4187186 Forward-Port-Of: odoo/odoo#190955
When using ship later on a settle order, the qty_delivered on the original order would not take into account if the pos order has been delivered or not. Steps to reproduce: ------------------- * Install pos_sale module * Enable ship later * Create an order with any product * Open the PoS and settle the order * Validate the order and use ship later option > Observation: If you go on the sale order the qty_delivered will be 1 but the order has not been delivered yet. Why the fix: --
Original PR description
When using ship later on a settle order, the qty_delivered on the original order would not take into account if the pos order has been delivered or not. Steps to reproduce: ------------------- * Install pos_sale module * Enable ship later * Create an order with any product * Open the PoS and settle the order * Validate the order and use ship later option > Observation: If you go on the sale order the qty_delivered will be 1 but the order has not been delivered yet. Why the fix: ------------ We make sure that if the pos order is linked to a picking, the picking should be completely done to count the qty as delivered. opw-4199142 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189655 Forward-Port-Of: odoo/odoo#185456
Description of the issue this commit addresses: Due to the covid's economical impact, Luxembourg's government decided to apply a 1% diminished rate to some taxes to help companies recover from the crisis. Now that this period is over, those rates aren't right anymore and should be brought back to their original value in the OSS mapping. --- Desired behavior after this commit is merged: Rates that had been diminished by 1% are back to their original value. 16% -> 17% 7% -> 8% ---
Original PR description
Description of the issue this commit addresses: Due to the covid's economical impact, Luxembourg's government decided to apply a 1% diminished rate to some taxes to help companies recover from the crisis. Now that this period is over, those rates aren't right anymore and should be brought back to their original value in the OSS mapping. --- Desired behavior after this commit is merged: Rates that had been diminished by 1% are back to their original value. 16% -> 17% 7% -> 8% --- Enteprise PR: https://github.com/odoo/enterprise/pull/75650 task-[4369658](https://www.odoo.com/odoo/project/967/tasks/4369658) Forward-Port-Of: odoo/odoo#190816 Forward-Port-Of: odoo/odoo#189444
When clicking on a product that is linked to multiple loyalty programs you are prompted to select one of them everytime you add one item via the ui. Steps to reproduce: ------------------- * Create 2 loyalty programs activated when buying a certain product * Open PoS and click on the product > Observation: You will get a prompt everytime you click on the product Why the fix: ------------ The variable `selected_program` is actually only usefull if the program selected is gift card or
Original PR description
When clicking on a product that is linked to multiple loyalty programs you are prompted to select one of them everytime you add one item via the ui. Steps to reproduce: ------------------- * Create 2 loyalty programs activated when buying a certain product * Open PoS and click on the product > Observation: You will get a prompt everytime you click on the product Why the fix: ------------ The variable `selected_program` is actually only usefull if the program selected is gift card or an eWallet program. So we filter it before and only prompt when the output will be usefull. opw-4187037 Forward-Port-Of: odoo/odoo#188435
This pull request appears to update core setup files, including the main configuration and dependency list. Because no specific business issue or feature is described, the expected impact is likely limited to internal maintenance or environment setup.
Original PR description
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
### Steps to reproduce: - In Settings, enable "Multi-Step Routes" - In the Routes, unarchive "Replenish on Order (MTO)" - Create a storable product P with routes: MTO, Buy and a set vendor - Create and confirm a sale order with one line: - 2 x product P > A delivery has been created. - Cancel the SO, set it back to quotation and confirm it once more. > The first delivery has been cancelled and a new one has been created - Decrease the quantity of the SOL from 2 to 1 and save ####
Original PR description
### Steps to reproduce: - In Settings, enable "Multi-Step Routes" - In the Routes, unarchive "Replenish on Order (MTO)" - Create a storable product P with routes: MTO, Buy and a set vendor - Create…
### Steps to reproduce:
- In Settings, enable "Multi-Step Routes"
- In the Routes, unarchive "Replenish on Order (MTO)"
- Create a storable product P with routes: MTO, Buy and a set vendor
- Create and confirm a sale order with one line:
- 2 x product P
> A delivery has been created.
- Cancel the SO, set it back to quotation and confirm it once more.
> The first delivery has been cancelled and a new one has been created
- Decrease the quantity of the SOL from 2 to 1 and save
#### > Issue: The delivery from stock to customer was not updated but an incoming picking was created from customer to stock.
### Cause of the Issue:
When confirming the SO, `_run_pull` will be called and will create an outgoing move SM01 based on our rule. Initially and because of the rule used for its creation, the `procure_method` of this move is `make_to_order`. However, once the SO is cancelled, this move `procure_method` will be updated to be `make_to_stock`: https://github.com/odoo/odoo/blob/ef161136fe2034752c2cc923cb892e933b78d4c0/addons/stock/models/stock_move.py#L1794-L1798 Once the SO is reset to draft and confirmed once more, a new outgoing move SM02 will be created by the `_run_pull` using the same rule as SM01 Then, when the quantity of the SOL is decreased from 2 to 1, a negative outgoing move SM03 will be created by the `_run_pull` and is expected to be absorbed by SM02 during the `_merge_move` of its `action_confirm`: https://github.com/odoo/odoo/blob/ef161136fe2034752c2cc923cb892e933b78d4c0/addons/stock/models/stock_move.py#L1397
However, the merging process will fail for 2 reasons:
1. Negative moves are merged based on a reduced set of comparaison keys: https://github.com/odoo/odoo/blob/ef161136fe2034752c2cc923cb892e933b78d4c0/addons/stock/models/stock_move.py#L1046-L1047 Which is expected to exculde the created sale order lines: https://github.com/odoo/odoo/blob/ef161136fe2034752c2cc923cb892e933b78d4c0/addons/purchase_stock/models/stock_move.py#L28 However, the field name `created_purchase_line_id` has been renamed to `created_purchase_line_id"s"` in 17.0 and this update has been reased by mistake during a forward port: b40bd15c9ce43b60a8993afbe61c56a3bb9f782f
2. While the `procure_method` is a valid comparaison key for negative moves, it is a tricky field to use as the `procure_method` present on the move we want to merge with might not correspond to the `procure_method` set by our rule (`make_to_order` for SM03). The purpose of these lines is therefore to update the `procure_method` of negative moves to match valid merging candidates:
https://github.com/odoo/odoo/blob/ef161136fe2034752c2cc923cb892e933b78d4c0/addons/stock/models/stock_rule.py#L260-L269 However, SM01 is not a valid merging candidtes as it was cancelled and its `procure_method` has changed during its cancellation so that it will wrongly update the `procure_method` of SM03 to `make_to_stock`: https://github.com/odoo/odoo/blob/ef161136fe2034752c2cc923cb892e933b78d4c0/addons/stock/models/stock_rule.py#L267-L268 and will therefore not match its only valid merging candidate: SM02.
opw-4368599
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#190820In odoo/odoo#180856, a new version of the Estonian tax report is added with the xmlid tax_report, in order to not overwrite the tax report for users in stable who didn't update their modules. When upgrading the module, to avoid dropping and recreating the report, we add this upgrade script to rename the xmlid of the tax report. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190718
Original PR description
In odoo/odoo#180856, a new version of the Estonian tax report is added with the xmlid tax_report, in order to not overwrite the tax report for users in stable who didn't update their modules. When upgrading the module, to avoid dropping and recreating the report, we add this upgrade script to rename the xmlid of the tax report. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190718
The logic to calculate pre-work time, working time, and post-work time has been extracted to a new method `_get_pre_post_work_time`. This refactor does not alter the existing logic but makes it reusable and easier to override in custom modules. This makes it easier to customize the calculation for specific use cases, such as only considering overtime hours worked after the scheduled end of the day. This adjustment is necessary to meet client requirements that exclude overtime before the st
Original PR description
The logic to calculate pre-work time, working time, and post-work time has been extracted to a new method `_get_pre_post_work_time`. This refactor does not alter the existing logic but makes it reusable and easier to override in custom modules. This makes it easier to customize the calculation for specific use cases, such as only considering overtime hours worked after the scheduled end of the day. This adjustment is necessary to meet client requirements that exclude overtime before the start of the working day. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189983
## Description When the `product.template.attribute.value` (PTAV) are edited and the respective `product.template.attribute` (PTA) variant creation config is set to `Instantly`, all existing variants for that template are unlinked and all the combinations possible of variants are recreated. This can be slow, specially for templates that already have a lot of variants. ## Patch Main bottleneck is the hot loop in `product.product:unlink`, rewriting it a bit to pre-compute what is possible, be
Original PR description
## Description When the `product.template.attribute.value` (PTAV) are edited and the respective `product.template.attribute` (PTA) variant creation config is set to `Instantly`, all existing variants…
## Description When the `product.template.attribute.value` (PTAV) are edited and the respective `product.template.attribute` (PTA) variant creation config is set to `Instantly`, all existing variants for that template are unlinked and all the combinations possible of variants are recreated. This can be slow, specially for templates that already have a lot of variants. ## Patch Main bottleneck is the hot loop in `product.product:unlink`, rewriting it a bit to pre-compute what is possible, before looping. - Lift `exists` check outside the loop, it does 1 query. - Batch the `search` in the main loop body of `product.product`'s `unlink` with a `_read_group`. - Replace usage of `recordset`'s `union` with `set`'s `add`, due to the loop, complexity goes from `O(n^2)` -> `O(n)` for `n := len(self)`. ## Benchmark On a DB with 1.2M `product.product`, adding a new PTAV to a `product. template` with 39k+ variants takes: | | Before | After | |---------|--------------------|--------| | Timings | timeout (ETC 3h+)* | 2.2min | \* - ETC was calculated by extrapolating the search query in the loop, which was taking ~300ms, times the number of variants to be unlinked which was 39k+ variants. ## Reference opw-4383294 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190739
### [FIX] account_edi_ubl_cii,l10n_ro_edi: Allow NO VAT tax scheme ID Rule [BR-CO-09] enforce the VAT number to start with a country code if the tax scheme id is "VAT". In some countries (RO, HU, non-EU countries, ...) it is perfectly valid to have a VAT that doesn't follow this format. To avoid the rule to raise, we should set the tax scheme ID to something else than "VAT". ### [FIX] account_edi_ubl_cii: only set BIS3 format by default on restricted countries BIS3 is an electronic for
Original PR description
### [FIX] account_edi_ubl_cii,l10n_ro_edi: Allow NO VAT tax scheme ID Rule [BR-CO-09] enforce the VAT number to start with a country code if the tax scheme id is "VAT". In some countries (RO, HU,…
### [FIX] account_edi_ubl_cii,l10n_ro_edi: Allow NO VAT tax scheme ID Rule [BR-CO-09] enforce the VAT number to start with a country code if the tax scheme id is "VAT". In some countries (RO, HU, non-EU countries, ...) it is perfectly valid to have a VAT that doesn't follow this format. To avoid the rule to raise, we should set the tax scheme ID to something else than "VAT". ### [FIX] account_edi_ubl_cii: only set BIS3 format by default on restricted countries BIS3 is an electronic format closely related to Peppol. It therefore only make sense to enable it by default on partners that are in countries where it's actively used or will become mandatory soon. ### [FIX] account_edi_ubl_cii,base_vat,l10n_hu: VAT conversion to EU format Hungary may have different format of VAT number. It is possible to convert their local format (xxxxxxxx-y-zz) to the EU format (HUxxxxxxxx). We should use this converted format when computing the Peppol Endpoint. Enterprise: https://github.com/odoo/enterprise/pull/75671 task-4374458 Forward-Port-Of: odoo/odoo#189421
This commit fixes a bug introduced by [#166482](https://github.com/odoo/odoo/pull/166482), where it attempts to reconcile an account_move_line twice, and fails to do so the second time, which prevents the confirmation of invoices. The fix adds a step to remove already reconciled items from the reconciliation plan. opw-4148669 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186700 Forward-Port-Of: odoo/odoo#180903
Original PR description
This commit fixes a bug introduced by [#166482](https://github.com/odoo/odoo/pull/166482), where it attempts to reconcile an account_move_line twice, and fails to do so the second time, which prevents the confirmation of invoices. The fix adds a step to remove already reconciled items from the reconciliation plan. opw-4148669 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186700 Forward-Port-Of: odoo/odoo#180903
Any computed fields that depend on `customer_rank` or `supplier_rank` were not being recomputed when the ranks changed. This isn't noticeable on standard Odoo code, but downstream modules that use such feature wouldn't work. @moduon MT-8208 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189127
Original PR description
Any computed fields that depend on `customer_rank` or `supplier_rank` were not being recomputed when the ranks changed. This isn't noticeable on standard Odoo code, but downstream modules that use such feature wouldn't work. @moduon MT-8208 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189127
In January 2025, Indonesia is increasing their tax rate from 11% to 12%. This commit adds a new 12% tax as well as the upgrade script to load it into existing databases. task id # 4409300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190748 Forward-Port-Of: odoo/odoo#190693
Original PR description
In January 2025, Indonesia is increasing their tax rate from 11% to 12%. This commit adds a new 12% tax as well as the upgrade script to load it into existing databases. task id # 4409300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190748 Forward-Port-Of: odoo/odoo#190693