Thursday, March 20, 2025
44 changes · saas-18.2
Enhancements to existing features
Adds ready-made filters that help users quickly find Indian e-invoices that still need to be sent or have errors. It also adds grouping by Indian e-invoice status, making follow-up and compliance monitoring easier for accounting teams.
Original PR description
In this commit, we add the following filters- 1.`Indian E-Invoices To Send` 2.`Indian E-Invoices in error` 3.`Group by Indian E-invoice status` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Unread channel threads in the Discuss sidebar now appear at full visibility in compact mode. This makes new activity easier to notice and keeps the display consistent with other unread conversations.
Original PR description
Before this commit, channel threads that are unread had a 75% opacity in the discuss sidebar when the sidebar is compact. When a sidebar item is neither active and has no unread messages, they are…
Before this commit, channel threads that are unread had a 75% opacity in the discuss sidebar when the sidebar is compact. When a sidebar item is neither active and has no unread messages, they are intended to have 75% opacity, so that the active item is easier to spot and they are less distracting compared to message avatars in the selected conversation. This is specific to discuss compact mode because of avatars next to conversation, but also the compact layout shows less of bg of selected item, so the same bg color is not as visible as in expanded mode. This worked for all items but channel threads before this commit. This happens because the feature to but opacity-100% on unread conversations in discuss sidebar relies on `o-unread` classname, but channel thread had `o-item-unread`. There's no reason to have a different classname, thus this commit fixes the issue by using `o-unread`, which makes them reuse the existing style of all other discuss items that have unread messages. Before / After <img width="64" alt="Screenshot 2025-03-20 at 12 10 29" src="https://github.com/user-attachments/assets/60662d82-da39-404d-b3d5-258e5af6618d" /> <img width="61" alt="Screenshot 2025-03-20 at 12 10 55" src="https://github.com/user-attachments/assets/24d16e87-6702-42cb-8416-bf5ef3174b9d" />
Miscellaneous changes
Some of our new deductible taxes were wrong, this commit fixes them. It also adds a new tax for deductiblility of 35% in the EU (which is more frequent), and one for deductibility of 35% in the case of delivery of goods already in Belgium by a foreign entity. task-none Forward-Port-Of: odoo/odoo#202563 Forward-Port-Of: odoo/odoo#201782
Original PR description
Some of our new deductible taxes were wrong, this commit fixes them. It also adds a new tax for deductiblility of 35% in the EU (which is more frequent), and one for deductibility of 35% in the case of delivery of goods already in Belgium by a foreign entity. task-none Forward-Port-Of: odoo/odoo#202563 Forward-Port-Of: odoo/odoo#201782
Point of Sale orders now correctly clear the customer when a cashier removes them before payment or synchronization. This prevents backend records from keeping an outdated customer, improving order accuracy and reporting.
Original PR description
Steps to reproduce: -------------------------- - Open session in point_of_sale. - Order something with any customer selected. - Now remove the customer and pay. Issue: -------- - The order still have that customer in the backend. Cause: ---------- - When we remove the partner and pay or do any operation which sync order It will have no partner in the order_dict to be written instead of false. So it won't write the partner as the key not found. Fix: ----- - We should have partner_id to be written as false if not there. Task: 4619078
The recruitment app now correctly checks conditions for each applicant when several applicants are processed together. This prevents an error that could interrupt recruitment workflows involving multiple candidates.
Original PR description
As self can contains multiple applicants, it raises an ensure_one error. TASK-ID: 4656015 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website form submissions now keep attached files from being duplicated. This prevents confusion for users and reduces unnecessary duplicate files in the system.
Original PR description
After this commit, the attached files in the form are no longer duplicated. task-4656465 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The appraisal feedback counter now shows the actual number of completed feedback surveys instead of always displaying zero. This helps managers and HR teams quickly see appraisal feedback progress accurately.
Original PR description
In dee57c5a85e26e57159a6eb66de0b2f1f581c64b, which adds prefixes to the states of the model `hr.appraisal`, a search domain on an unrelated model has unfortunately been affected too. This commit fixes the search domain in `_compute_completed_survey_count` which looks at the state of `survey.user_input`, which is not prefixed. Before this commit, the Feedbacks stat button on an appraisal will always show "0 / X", because the filtered state doesn't exist. After this commit, it will show the correct number. Task-id: none
When manually adding a byproduct to a MO, the warehouse is not set because `default_warehouse_id` is missing from the context. This means that the push move from post-prod to stock is never created and the byproduct is stuck in post-production location. This fix adds the context key in the MO form view. Steps: - Activate routes & by-product in the main settings - Activate manufacturing in 3 steps on the warehouse - Create manufacturing order for a product and add a by-product with a positi
Original PR description
When manually adding a byproduct to a MO, the warehouse is not set because `default_warehouse_id` is missing from the context. This means that the push move from post-prod to stock is never created and the byproduct is stuck in post-production location. This fix adds the context key in the MO form view. Steps: - Activate routes & by-product in the main settings - Activate manufacturing in 3 steps on the warehouse - Create manufacturing order for a product and add a by-product with a positive quantity - Confirm manufacturing order - Pick components - Produce & close MO opw-4620008 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202407 Forward-Port-Of: odoo/odoo#201619
The function does not take an `order` parameter. closes odoo/documentation#12557 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202587 Forward-Port-Of: odoo/odoo#202465
Original PR description
The function does not take an `order` parameter. closes odoo/documentation#12557 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202587 Forward-Port-Of: odoo/odoo#202465
Issue Before This Commit: ============================ The system activate inappropriate rules in routes, including those where the rule itself is active but it's destination location is inactive. Steps to Reproduce: ============================ - Install the stock & MRP modules. - Activate multi-step routes and the MTO route. - Notice that 'WH: Stock → Pre-Production (MTO)' rule appears, even when the rule is active but its destination location is inactive. - Go to the warehou
Original PR description
Issue Before This Commit: ============================ The system activate inappropriate rules in routes, including those where the rule itself is active but it's destination location is inactive.…
Issue Before This Commit: ============================ The system activate inappropriate rules in routes, including those where the rule itself is active but it's destination location is inactive. Steps to Reproduce: ============================ - Install the stock & MRP modules. - Activate multi-step routes and the MTO route. - Notice that 'WH: Stock → Pre-Production (MTO)' rule appears, even when the rule is active but its destination location is inactive. - Go to the warehouse, enable the 3-step MRP then switch back to the 1-step MRP. - Go to the MTO route and see that only active rules are now shown. With This Commit: ============================ This commit resolves the issue where the unarchiving route unintentionally restored all associated rules, regardless of their active status. Now, only rules that are active and it's destination location is active are displayed in routes, where inactive ones are filtered out based on the destination location's active status. task - [4577280](https://www.odoo.com/odoo/project.task/4577280) Forward-Port-Of: odoo/odoo#202537 Forward-Port-Of: odoo/odoo#197754
If an action is defined in a step with a string (and therefore is an action that comes from tour_helpers) there is no check on the beforeUnload event that is done. In this commit, we fix this. 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#202291 Forward-Port-Of: odoo/odoo#202093
Original PR description
If an action is defined in a step with a string (and therefore is an action that comes from tour_helpers) there is no check on the beforeUnload event that is done. In this commit, we fix this. 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#202291 Forward-Port-Of: odoo/odoo#202093
Feedbacks given talked about the fact the negative lines were wrong and should be considered as discounts. But that's not the case for every user and is more confusing than anything else. So we remove this logic from Italy. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201414 Forward-Port-Of: odoo/odoo#199100
Original PR description
Feedbacks given talked about the fact the negative lines were wrong and should be considered as discounts. But that's not the case for every user and is more confusing than anything else. So we remove this logic from Italy. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201414 Forward-Port-Of: odoo/odoo#199100
In this commit- We fix the [runbot error](https://runbot.odoo.com/runbot/build/76662614) ```py Please indicate why the always invisible fields are present in the view, or remove the field tag. Addon: 'l10n_in_withholding' View: tds_entry_view_form Fields: <field name="currency_id" column_invisible="True"/> ``` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202390 Forward-Port-Of: odoo/odoo#202
Original PR description
In this commit-
We fix the [runbot error](https://runbot.odoo.com/runbot/build/76662614)
```py
Please indicate why the always invisible fields are present in the view, or remove the field tag.
Addon: 'l10n_in_withholding'
View: tds_entry_view_form
Fields:
<field name="currency_id" column_invisible="True"/>
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#202390
Forward-Port-Of: odoo/odoo#202015The sound effect was too low, to the point that new message notification was more audible than the call invitation, which doesn't make sense as call invitation is a more important alert than new message. This commit increases significantly the call invitation volume to be about the same (or slightly more) than the new message alert. Forward-Port-Of: odoo/odoo#202542
Original PR description
The sound effect was too low, to the point that new message notification was more audible than the call invitation, which doesn't make sense as call invitation is a more important alert than new message. This commit increases significantly the call invitation volume to be about the same (or slightly more) than the new message alert. Forward-Port-Of: odoo/odoo#202542
### Steps to reproduce 1. Create a new group 2. Give the group access to the following models: - `mrp.bom` - `mrp.bom.line` - `mrp.routing.workcenter` - `product.document` 3. Create a new menu using studio to access `mrp.bom` directly 4. Create a new user with the newly created group 5. Sign-in with this user and go on a BoM 6. AccessError ### Before this commit: Users without the `mrp.group_mrp_user` group cannot display bills of material, even if we add the necessary
Original PR description
### Steps to reproduce 1. Create a new group 2. Give the group access to the following models: - `mrp.bom` - `mrp.bom.line` - `mrp.routing.workcenter` - `product.document` 3. Create a new menu using studio to access `mrp.bom` directly 4. Create a new user with the newly created group 5. Sign-in with this user and go on a BoM 6. AccessError ### Before this commit: Users without the `mrp.group_mrp_user` group cannot display bills of material, even if we add the necessary access rights. The record loads without issue, but the chatter displays an error when loading the attachments, due to strict group access on the field `attached_on_mrp`. ### After this commit: Remove the group from the field and move it into the view. This allows easier and more flexible access rights to the BoM without writing any custom code. opw-4538532 Forward-Port-Of: odoo/odoo#199480
Versions -------- - 17.0+ Steps ----- 1. Create an event with an attendee limit of 1; 2. publish the event; 3. add a ticket to you cart; 4. go through checkout until your reach the payment page; 5. open a incognito window or different browser; 6. add same ticket to cart; 7. go to the payment step; 8. click "Pay now" and wait for confirmation; 9. go to previous window, and click "Pay now". Issue ----- The payment gets confirmed, but you land on an internal server error due to
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create an event with an attendee limit of 1; 2. publish the event; 3. add a ticket to you cart; 4. go through checkout until your reach the payment page; 5.…
Versions -------- - 17.0+ Steps ----- 1. Create an event with an attendee limit of 1; 2. publish the event; 3. add a ticket to you cart; 4. go through checkout until your reach the payment page; 5. open a incognito window or different browser; 6. add same ticket to cart; 7. go to the payment step; 8. click "Pay now" and wait for confirmation; 9. go to previous window, and click "Pay now". Issue ----- The payment gets confirmed, but you land on an internal server error due to a lack of available seats for the event. Cause ----- Commit ffc9026361beb added a check before payment to ensure the tickets still had seats available. The event itself however can have a separate seat limit that isn't currently being checked. Solution -------- Add a check on the event's seat availability to `_validate_transaction_for_order`. Also, in case there's a lack of seats, display the correct number of lacking seats for the order instead of `-available_seats`. opw-4453539 Forward-Port-Of: odoo/odoo#202364 Forward-Port-Of: odoo/odoo#200400
On manual sending an invoice email via wizard, if the invoice partner has no email, and another recipient is set as recipient, no mail is sent. This was caused by a check only allowing emails to be sent for invoices with partners having an email. Task: opw-4604810 Forward-Port-Of: odoo/odoo#202007
Original PR description
On manual sending an invoice email via wizard, if the invoice partner has no email, and another recipient is set as recipient, no mail is sent. This was caused by a check only allowing emails to be sent for invoices with partners having an email. Task: opw-4604810 Forward-Port-Of: odoo/odoo#202007
[FIX] account: default_account_id removal from context when reversing analytic distribution When accessing journal items from a report, the context often includes default_account_id. When changing the account of a journal item, new analytic items are created, inheriting an account_id field. If account_id is False, it is automatically populated from default_account_id, which is sourced from account.account instead of account.analytic.account. This mismatch leads to the error: ```The operatio
Original PR description
[FIX] account: default_account_id removal from context when reversing analytic distribution When accessing journal items from a report, the context often includes default_account_id. When changing the account of a journal item, new analytic items are created, inheriting an account_id field. If account_id is False, it is automatically populated from default_account_id, which is sourced from account.account instead of account.analytic.account. This mismatch leads to the error: ```The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead.``` This fix moves when we remove the default_account_id from context to ensure it is removed despite the call stack not including the function _inverse_analytic_distribution opw-4443816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200200
The goal is that we do not need to be more accurate on what we need to update when updating the CoA so I have added force_create to be false if wo do not want to create new accounts, new taxes, new fiscal positions in the Netherlands task-4556250 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/o
Original PR description
The goal is that we do not need to be more accurate on what we need to update when updating the CoA so I have added force_create to be false if wo do not want to create new accounts, new taxes, new fiscal positions in the Netherlands task-4556250 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#198030
Following this commit : - Used color field in product form view that already existed. - Added color field in Edit product view from UI. task-4423837 Forward-Port-Of: odoo/odoo#202500 Forward-Port-Of: odoo/odoo#192319
Original PR description
Following this commit : - Used color field in product form view that already existed. - Added color field in Edit product view from UI. task-4423837 Forward-Port-Of: odoo/odoo#202500 Forward-Port-Of: odoo/odoo#192319
We do not create create caba moves anymore for PoS session closing moves. (See commits 2f62d5c0d78371be70586c79cb2b5931e733b042 and 66e3696b4f06c657ff71af30178f0ac69d552632) But now there are 2 issues when using (only) caba taxes in a PoS session. (1) The closing move does not appear on the tax report. (2) The closing move line do not get the right tax tags (they do not have any). Issue (1) is solved by making pos closing moves `always_tax_exigible`. (In case they did not creat cas
Original PR description
We do not create create caba moves anymore for PoS session closing moves. (See commits 2f62d5c0d78371be70586c79cb2b5931e733b042 and 66e3696b4f06c657ff71af30178f0ac69d552632) But now there are 2 issues when using (only) caba taxes in a PoS session. (1) The closing move does not appear on the tax report. (2) The closing move line do not get the right tax tags (they do not have any). Issue (1) is solved by making pos closing moves `always_tax_exigible`. (In case they did not creat cash basis entries; for backwards compatibility). Issue (2) is solved by telling the tax computation for the lines to include caba taxes (instead of just changing the account to be the "final" account and not the caba transition account). opw-4355124 Forward-Port-Of: odoo/odoo#202479 Forward-Port-Of: odoo/odoo#201812
Before this commit, closing the microphone permission request outside of a call would result in a traceback. Steps to reproduce: 1. Start a call on a channel (observe the browser's microphone permission request pop-up) 2. Quit the call 3. Refuse the microphone permissions -> traceback This happens because the `joinCall` method waits for the permissions before accessing `selfSession` in `_initConnection`, if that happens after the call has ended it produces a traceback as there is no `se
Original PR description
Before this commit, closing the microphone permission request outside of a call would result in a traceback. Steps to reproduce: 1. Start a call on a channel (observe the browser's microphone permission request pop-up) 2. Quit the call 3. Refuse the microphone permissions -> traceback This happens because the `joinCall` method waits for the permissions before accessing `selfSession` in `_initConnection`, if that happens after the call has ended it produces a traceback as there is no `selfSession`. This commit fixes the issue by moving the permission request after the `_initConnection`, thus ensuring that `selfSession` does not get accessed if there is no call. Forward-Port-Of: odoo/odoo#201219
The field `res.config.settings.l10n_ro_edi_client_id` [[1]](https://github.com/odoo/odoo/blob/63e0285ade407074c8e054d6d14a71b633d55f17/addons/l10n_ro_efactura/models/res_config_settings.py#L7C5-L7C26) [[2]](https://github.com/odoo/odoo/blob/63e0285ade407074c8e054d6d14a71b633d55f17/addons/l10n_ro_efactura/models/res_company.py#L18) in module `l10n_ro_efactura` has the same label `Client ID` as the field `res.config.settings.auth_oauth_google_client_id` [[3]](https://github.com/odoo/odoo/blob/63e0
Original PR description
The field `res.config.settings.l10n_ro_edi_client_id`…
The field `res.config.settings.l10n_ro_edi_client_id` [[1]](https://github.com/odoo/odoo/blob/63e0285ade407074c8e054d6d14a71b633d55f17/addons/l10n_ro_efactura/models/res_config_settings.py#L7C5-L7C26) [[2]](https://github.com/odoo/odoo/blob/63e0285ade407074c8e054d6d14a71b633d55f17/addons/l10n_ro_efactura/models/res_company.py#L18) in module `l10n_ro_efactura` has the same label `Client ID` as the field `res.config.settings.auth_oauth_google_client_id` [[3]](https://github.com/odoo/odoo/blob/63e0285ade407074c8e054d6d14a71b633d55f17/addons/auth_oauth/models/res_config_settings.py#L15C5-L15C32) from module `auth_oauth`. Field labels should be unique on the same model so we can change the label and set it in the view where this setting is shown. starting `saas-17.4` the change should be applied to module `l10n_ro_edi` as the efactura was merged in it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202422 Forward-Port-Of: odoo/odoo#201110
Before this PR, the `bus subscription is refreshed when channel is joined` test was sometimes failing. Since [1], opening a thread *always* result in a bus subscription being issued (the channel is added to the bus channels as a string). This is not required: bus subscriptions are based on user's channels (see `ir_websocket@_build_bus_channel_list`). When a new channel is added, the client subscribes again (see `toggleBusSubscription`). Channels should only be added explictly when a channe
Original PR description
Before this PR, the `bus subscription is refreshed when channel is joined` test was sometimes failing. Since [1], opening a thread *always* result in a bus subscription being issued (the channel is…
Before this PR, the `bus subscription is refreshed when channel is joined` test was sometimes failing. Since [1], opening a thread *always* result in a bus subscription being issued (the channel is added to the bus channels as a string). This is not required: bus subscriptions are based on user's channels (see `ir_websocket@_build_bus_channel_list`). When a new channel is added, the client subscribes again (see `toggleBusSubscription`). Channels should only be added explictly when a channel the user is not a member of is opened. This addition causes a race condition between `toggleBusSubscription` and the explicit addition of the channel, resulting in a non deterministic behavior. This PR fixes this issue: channel is only added when required, which is not the case in this test thus solving the issue. fixes runbot-106895 [1]: https://github.com/odoo/odoo/pull/174473 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#202470 Forward-Port-Of: odoo/odoo#202009
That were previously failing since this change https://github.com/odoo/odoo/commit/7aac5cecf198ed07fd6c71a0958f948512c50416#diff-d2dd39541c27864eca6e3d570d14208095c4c5509214e650bdc5bb8d69b5f672R40 making it so that the mail server refuses to connect https://github.com/odoo/odoo/blob/18.0/odoo/addons/base/models/ir_mail_server.py#L374 and later on raises an error as it returns None --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of
Original PR description
That were previously failing since this change https://github.com/odoo/odoo/commit/7aac5cecf198ed07fd6c71a0958f948512c50416#diff-d2dd39541c27864eca6e3d570d14208095c4c5509214e650bdc5bb8d69b5f672R40 making it so that the mail server refuses to connect https://github.com/odoo/odoo/blob/18.0/odoo/addons/base/models/ir_mail_server.py#L374 and later on raises an error as it returns None --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201209
In #195395, the following test suite should first check if the global_result is already stopped --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201800
Original PR description
In #195395, the following test suite should first check if the global_result is already stopped --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201800
Description of the issue/feature this PR addresses: This commit addresses inaccurate calculation of statistics in surveys. The survey fields `answer_score_avg` and `success_ratio` are affected. Current behavior before PR: These are currently using the number of completed surveys as the total number of surveys, but they are gathering data from all surveys, completed or not. This results in broken statistics when there are in progress or incomplete surveys. The values become too high, in
Original PR description
Description of the issue/feature this PR addresses: This commit addresses inaccurate calculation of statistics in surveys. The survey fields `answer_score_avg` and `success_ratio` are affected. Current behavior before PR: These are currently using the number of completed surveys as the total number of surveys, but they are gathering data from all surveys, completed or not. This results in broken statistics when there are in progress or incomplete surveys. The values become too high, including `success_ratio` being above 100%! Desired behavior after PR is merged: The proposed solution is simply to consider all answers to the survey so that the statistics can accurately reflect the scores across all initiated surveys. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197849
_* : website_sale Steps: - Create a combo product with combo items containing unpublished configurable product - on /shop as portal user add the combo product and try to configure any unpublished product Issue: - access error Cause: - The product configurator doesn't sudo the product which is being configured Fix: - if the product for product_configurator is part of published combo product, it will be sudo'ed opw: 4567008 --- I confirm I have signed the CLA and read the PR
Original PR description
_* : website_sale Steps: - Create a combo product with combo items containing unpublished configurable product - on /shop as portal user add the combo product and try to configure any unpublished product Issue: - access error Cause: - The product configurator doesn't sudo the product which is being configured Fix: - if the product for product_configurator is part of published combo product, it will be sudo'ed opw: 4567008 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200106
**Steps to Reproduce:** - Visit the website. - Navigate to the shop (products) page. - Select any product tag to filter products. - No results are displayed, even when products with the selected tag exist. **Issue:** - The domain filter for product tags was incorrectly using `product_variant_ids.all_product_tag_ids`, which did not correctly fetch the tag IDs, resulting in no matching products being displayed. **Fix:** - Updated the domain filter to use `product_variant_ids.all_produc
Original PR description
**Steps to Reproduce:** - Visit the website. - Navigate to the shop (products) page. - Select any product tag to filter products. - No results are displayed, even when products with the selected tag…
**Steps to Reproduce:** - Visit the website. - Navigate to the shop (products) page. - Select any product tag to filter products. - No results are displayed, even when products with the selected tag exist. **Issue:** - The domain filter for product tags was incorrectly using `product_variant_ids.all_product_tag_ids`, which did not correctly fetch the tag IDs, resulting in no matching products being displayed. **Fix:** - Updated the domain filter to use `product_variant_ids.all_product_tag_ids.id`, ensuring the comparison is made against the correct field containing the actual tag IDs. **Explanation:** - The previous implementation used `product_variant_ids.all_product_tag_ids,` which didn't correctly reference tag IDs, causing the filter to return no results. Adding `.id` ensures proper filtering by numeric tag IDs, restoring expected functionality. **Affected Version:** 18.1~master opw-4501022 opw-4576100 opw-4576961 opw-4593530 opw-4584284 opw-4590856 Forward-Port-Of: odoo/odoo#199728
When opening a dropdown inside an `IFrame` or `Shadow DOM`, clicking inside the nested DOM does not trigger auto-close. This happens because the event handler checks whether the clicked element is inside the main document, which is not the case for elements inside an IFrame or Shadow DOM. This commit fixes the issue by ensuring that, in such scenarios, the correct document context (nested DOM) is used for the click detection instead of the clicked element itself. Task-4525603 --- I con
Original PR description
When opening a dropdown inside an `IFrame` or `Shadow DOM`, clicking inside the nested DOM does not trigger auto-close. This happens because the event handler checks whether the clicked element is inside the main document, which is not the case for elements inside an IFrame or Shadow DOM. This commit fixes the issue by ensuring that, in such scenarios, the correct document context (nested DOM) is used for the click detection instead of the clicked element itself. Task-4525603 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196799
Steps: - Install Ecommerce - Add some products to the cart - Remove them using the 'remove' option - Go to my/orders - select any order, then click on Order again - Click on the Add To Cart button - You'll see one confirmation dialog Issue: - By clicking on the add to cart button, that confirmation dialog should not be there as the cart is empty Cause: - Cart quantity does not update when the last product is removed Fix: - While removing the last product, set cart quantity in
Original PR description
Steps: - Install Ecommerce - Add some products to the cart - Remove them using the 'remove' option - Go to my/orders - select any order, then click on Order again - Click on the Add To Cart button - You'll see one confirmation dialog Issue: - By clicking on the add to cart button, that confirmation dialog should not be there as the cart is empty Cause: - Cart quantity does not update when the last product is removed Fix: - While removing the last product, set cart quantity in sessionstorage to ensure that the last removal is recorded affected version-17.0 opw-4566505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202443 Forward-Port-Of: odoo/odoo#199921
Mercado Pago requires the X-platform-id header to be passed in all requests to their platform to keep track of the amount of odoo customers that exist. This key is not secret and perfectly fine to be committed in this repo without worry. task-4628319 Forward-Port-Of: odoo/odoo#200864
Original PR description
Mercado Pago requires the X-platform-id header to be passed in all requests to their platform to keep track of the amount of odoo customers that exist. This key is not secret and perfectly fine to be committed in this repo without worry. task-4628319 Forward-Port-Of: odoo/odoo#200864
**How to reproduce?** 1. Have `l10n_es` installed with `website_sale` and make sure the website with e-commerce belongs to the Spanish company. 2. Create a contact with a Spanish parent company having a VAT number. 3. Add a delivery address to this contact. 4. Create a portal user for this contact. 5. Log in with the portal user on the website, add a product to the cart and try to check out by filling out any remaining delivery address fields and trying to continue. **Observed behavior
Original PR description
**How to reproduce?** 1. Have `l10n_es` installed with `website_sale` and make sure the website with e-commerce belongs to the Spanish company. 2. Create a contact with a Spanish parent company…
**How to reproduce?** 1. Have `l10n_es` installed with `website_sale` and make sure the website with e-commerce belongs to the Spanish company. 2. Create a contact with a Spanish parent company having a VAT number. 3. Add a delivery address to this contact. 4. Create a portal user for this contact. 5. Log in with the portal user on the website, add a product to the cart and try to check out by filling out any remaining delivery address fields and trying to continue. **Observed behavior** An error is raised because it can't find some missing required fields. **Intended behavior** No error should be raised, because the delivery address should not require these fields. The bug was introduced in [this commit]. This fix makes sure that - the fields `vat` and `state` are only required on the invoicing address, - the "display B2B fields" option is automatically enabled for Spanish companies since the `vat` field is required on the invoicing address. [opw-4610111](https://www.odoo.com/odoo/project.task/4610111) [this commit]: https://github.com/odoo/odoo/commit/c63dcc3156235203e9a91a13c44001ecb99a1ffa Forward-Port-Of: odoo/odoo#202040
Steps to reproduce: - Install `sale_subscription` - Create a sub with a discount - Confirm and invoice it - Renew the sub without the discount - Confirm the renewal - Remove the discount on the original sub via the shell since it's locked (simulate first year discount removal) - Cancel the renewal Issue: MRR log is now negative, this is due to how the way `amount_signed` is computed during the churn event creation. Recurring monthly is now greater because we deleted the first year dis
Original PR description
Steps to reproduce: - Install `sale_subscription` - Create a sub with a discount - Confirm and invoice it - Renew the sub without the discount - Confirm the renewal - Remove the discount on the original sub via the shell since it's locked (simulate first year discount removal) - Cancel the renewal Issue: MRR log is now negative, this is due to how the way `amount_signed` is computed during the churn event creation. Recurring monthly is now greater because we deleted the first year discount, which results in negative MRR. https://github.com/odoo/enterprise/blob/5a7b55f9e059c3b54492e184d1e2429779399d08/sale_subscription/models/sale_order_log.py#L174 Solution: Compute `amount_signed` using the sum of the previous logs. Forward-Port-Of: odoo/enterprise#81661 Forward-Port-Of: odoo/enterprise#80872
Issue: - Hovering over the overtime column in the timesheet grid shows the wrong value. when the employee has flexible hours. Steps To Reproduce: - Go to the timesheet grid. - Record time for an employee with flexible hours. - Hover over the weekly overtime column. Solution: - Add the full-time required hours to the overtime calculation when the employee has flexible hours. opw-[4528395](https://www.odoo.com/web#id=4528395&view_type=form&model=project.task) F
Original PR description
Issue:
- Hovering over the overtime column in the timesheet grid shows the wrong value.
when the employee has flexible hours.
Steps To Reproduce:
- Go to the timesheet grid.
- Record time for an employee with flexible hours.
- Hover over the weekly overtime column.
Solution:
- Add the full-time required hours to the overtime calculation when the employee has flexible hours.
opw-[4528395](https://www.odoo.com/web#id=4528395&view_type=form&model=project.task)
Forward-Port-Of: odoo/enterprise#81575
Forward-Port-Of: odoo/enterprise#81057In this commit, we fix the latest step of tour. We can't click on primary or secondary button ... make no sense. As the primary button download the pdf file and there is no test to ensure the file is well downloaded, it make more sense to click on close the modal. With the fix in https://github.com/odoo/odoo/pull/202089 and without the correction, the tour was timeout exceeded. Forward-Port-Of: odoo/enterprise#81672 Forward-Port-Of: odoo/enterprise#81596
Original PR description
In this commit, we fix the latest step of tour. We can't click on primary or secondary button ... make no sense. As the primary button download the pdf file and there is no test to ensure the file is well downloaded, it make more sense to click on close the modal. With the fix in https://github.com/odoo/odoo/pull/202089 and without the correction, the tour was timeout exceeded. Forward-Port-Of: odoo/enterprise#81672 Forward-Port-Of: odoo/enterprise#81596
Problem: The WhatsApp template's attachment is set on the mail message of the related WhatsApp message. If the user deletes the mail message's attachment, the template's attachment also gets deleted. Solution: Instead of directly linking the template attachment, the attachment will be cloned with the appropriate `res_id` and `res_model` before sending. This ensures that the original template attachment remains intact even if the message attachment is removed. Task-4626855 Forward-Po
Original PR description
Problem: The WhatsApp template's attachment is set on the mail message of the related WhatsApp message. If the user deletes the mail message's attachment, the template's attachment also gets deleted. Solution: Instead of directly linking the template attachment, the attachment will be cloned with the appropriate `res_id` and `res_model` before sending. This ensures that the original template attachment remains intact even if the message attachment is removed. Task-4626855 Forward-Port-Of: odoo/enterprise#80760
Steps to reproduce ================== - Install hr_timesheets - Go to Timesheets > All Timesheets - Use the week scale - Scroll to the bottom => Take note of the last record (e.g.: Walter Horton) - Now use a mobile viewport - Make sure the week scale is still applied - Scroll to the bottom => The last record is not the same one as the desktop view Cause of the issue ================== The grid view uses a virtual scroll hook in order to not have to many dom nodes in memory at th
Original PR description
Steps to reproduce ================== - Install hr_timesheets - Go to Timesheets > All Timesheets - Use the week scale - Scroll to the bottom => Take note of the last record (e.g.: Walter Horton) -…
Steps to reproduce ================== - Install hr_timesheets - Go to Timesheets > All Timesheets - Use the week scale - Scroll to the bottom => Take note of the last record (e.g.: Walter Horton) - Now use a mobile viewport - Make sure the week scale is still applied - Scroll to the bottom => The last record is not the same one as the desktop view Cause of the issue ================== The grid view uses a virtual scroll hook in order to not have to many dom nodes in memory at the same time. For this to work, we need a consistent row height. On mobile, when grouping by x amount of fields, they are stacked on top of each other. When grouping by more than 2 fields, there wasn't enough space to display them all.  The `grid-template-rows` was set to auto on mobile in order to accomodate that case. Using auto means we no longer have a consistent row height. Solution ======== We restore the `gridTemplateRows` and allocate extra space when needed.  opw-4208357 Forward-Port-Of: odoo/enterprise#81697 Forward-Port-Of: odoo/enterprise#80476
To reproduce the issue: 1. Confirm a SO with partner P 2. Create/Edit an helpdesk team - Returns: True 3. Create a ticket for P 4. Open its form view 5. Click on return Error: a traceback appears "ValueError: Expected singleton: stock. picking()" The return button loads the wizard `stock.return.picking`. In this model, we try to find a related done picking: https://github.com/odoo/enterprise/blob/7215e4abd904ebdff3bd85c2c2f3002b1f5593b1/helpdesk_stock/wizard/stock_picking_retur
Original PR description
To reproduce the issue: 1. Confirm a SO with partner P 2. Create/Edit an helpdesk team - Returns: True 3. Create a ticket for P 4. Open its form view 5. Click on return Error: a traceback appears…
To reproduce the issue: 1. Confirm a SO with partner P 2. Create/Edit an helpdesk team - Returns: True 3. Create a ticket for P 4. Open its form view 5. Click on return Error: a traceback appears "ValueError: Expected singleton: stock. picking()" The return button loads the wizard `stock.return.picking`. In this model, we try to find a related done picking: https://github.com/odoo/enterprise/blob/7215e4abd904ebdff3bd85c2c2f3002b1f5593b1/helpdesk_stock/wizard/stock_picking_return.py#L24-L31 Which, in the above case, does not exist. Later, we call a method on that picking: https://github.com/odoo/odoo/blob/8f527e93de2d64111904f1fcc5813e8b8ea0e4ba/addons/stock/wizard/stock_picking_return.py#L100-L104 Where `_can_return` is a `ensure_one` method, hence the error. The return button is only displayed in some conditions: https://github.com/odoo/enterprise/blob/3d8bb40fcad00068e12f21b623390c959d3fd19c/helpdesk_stock/views/helpdesk_ticket_views.xml#L35 Here is the problem: `has_partner_picking` can be `True` if we find some related SOL, which is useless, the only thing that matters are the related pickings. OPW-4591280 Forward-Port-Of: odoo/enterprise#81378
In Belgium, certain tax grids (e.g., 81, 82) in the VAT report force negative amounts to 0, as the amounts are carried over to the next period. However, this behavior confuses users, especially VAT experts, as they see 0 instead of the actual negative amount. To improve clarity: - Negative values are now displayed instead of being forced to 0. - The carryover mechanism remains unchanged, and the explanatory infobullet is still displayed. Task-4589150 Forward-Port-Of: odoo/enterprise#797
Original PR description
In Belgium, certain tax grids (e.g., 81, 82) in the VAT report force negative amounts to 0, as the amounts are carried over to the next period. However, this behavior confuses users, especially VAT experts, as they see 0 instead of the actual negative amount. To improve clarity: - Negative values are now displayed instead of being forced to 0. - The carryover mechanism remains unchanged, and the explanatory infobullet is still displayed. Task-4589150 Forward-Port-Of: odoo/enterprise#79793
…bling companies Steps to reproduce: 1. Create a company with two branches. 2. Create an asset model in each branch. 3. Go to the main company's chart of accounts. 4. Select the 'Fixed Asset' account and enable 'Automate Asset'. 5. Assign both branches' asset models to 'Asset Model'. 6. Create a vendor bill in one of the branches using the parent company's 'Fixed Asset' account. Observed behavior: - Two assets are created—one for each model assigned to the 'Fixed Asset' account.
Original PR description
…bling companies Steps to reproduce: 1. Create a company with two branches. 2. Create an asset model in each branch. 3. Go to the main company's chart of accounts. 4. Select the 'Fixed Asset' account and enable 'Automate Asset'. 5. Assign both branches' asset models to 'Asset Model'. 6. Create a vendor bill in one of the branches using the parent company's 'Fixed Asset' account. Observed behavior: - Two assets are created—one for each model assigned to the 'Fixed Asset' account. Expected behavior: - Only one asset should be created, using the asset model corresponding to the branch. - Sibling companies should only access their parent's resources (asset models) and not each other's. This fix ensures that asset models are correctly scoped within their respective branches. opw-4494439 Forward-Port-Of: odoo/enterprise#81589
like the rest of the code in this file, the target model is supposed to be helpdesk.ticket build_error-111888 Forward-Port-Of: odoo/enterprise#81204
Original PR description
like the rest of the code in this file, the target model is supposed to be helpdesk.ticket build_error-111888 Forward-Port-Of: odoo/enterprise#81204
The test ensures that pos moves with caba taxes are also included in the tax report and behave the same as non-caba taxes. This was necessary since the closing moves do not create caba entries anymore. (See the community commit) Forward-Port-Of: odoo/enterprise#81747 Forward-Port-Of: odoo/enterprise#81505
Original PR description
The test ensures that pos moves with caba taxes are also included in the tax report and behave the same as non-caba taxes. This was necessary since the closing moves do not create caba entries anymore. (See the community commit) Forward-Port-Of: odoo/enterprise#81747 Forward-Port-Of: odoo/enterprise#81505
Issue: Validating deliveries of storable products linked to a subscription will not update the delivered_qty untill the subscription has been invoiced and hence wont allow you to invoice it at all if the invoicing is based on delivered qty. ### Steps to reproduce: - Create a recurring product which inventory is tacked by quantity and which invoicing policy is based on delivered quantity. - Put 10 units in stock. - Create a monthly subscription for 1 unit of that product. - Confirm the s
Original PR description
Issue: Validating deliveries of storable products linked to a subscription will not update the delivered_qty untill the subscription has been invoiced and hence wont allow you to invoice it at all if…
Issue: Validating deliveries of storable products linked to a subscription will not update the delivered_qty untill the subscription has been invoiced and hence wont allow you to invoice it at all if the invoicing is based on delivered qty. ### Steps to reproduce: - Create a recurring product which inventory is tacked by quantity and which invoicing policy is based on delivered quantity. - Put 10 units in stock. - Create a monthly subscription for 1 unit of that product. - Confirm the subscription - Validate the associated delivery #### > The qty_delivered of the sol is still at 0 and the subscription can't be invoiced. ### Cause of the issue: Starting from Commit b3ed4416f9b8e37604a9aa38a1f38c3504e22fdf (18.0) we will create the first delivery linked to a subscription rather than waiting for the cron to be triggered. These delivery moves are correctly linked to the related sale order lines of the subscription. However, since future deliveries will also be created and linked to that same sol we need to consider only the outgoing and incoming moves related to the current billing period to determine the qty_delivered. This step is achieved with an override of the `_get_out_going_incoming_moves`: https://github.com/odoo/odoo/blob/a6280b2a5173fad65e62af0ba72cb8721939d709/addons/sale_stock/models/sale_order_line.py#L193-L200 https://github.com/odoo/enterprise/blob/dde492541aa253771f905d0a77650aa35fea0e8c/sale_subscription_stock/models/sale_order_line.py#L27-L34 but this always leads to an empty record set since the order was never invoiced making the`next_invoice_date` and hence the `period_end` coincide with the `start_date` of the order. opw-4628212 Forward-Port-Of: odoo/enterprise#81749