Monday, March 24, 2025
53 changes · saas-18.2
Resolved issues and error corrections
Automated actions that add or remove followers now receive the correct generated name when using the generic follower action type. This prevents confusing or incorrect labels in automation setup, making it easier for users to identify and manage these actions.
Original PR description
Before this commit the server actions automated naming was not properly working for server actions of type add/remove followers in case of a 'generic' followers action type. This commit fixes this issue (introduced with [1]) [1] https://github.com/odoo/odoo/pull/190709
This fixes an automated test for self-order online payments so it works whether or not demo data is installed. It helps keep the validation pipeline reliable without changing customer-facing behavior.
Original PR description
- Fix test `test_online_payment_self_pay_after_meal_table` that was failling when no demo data was installed. - To fix this issue, we now use a table that exist with or without demo data. - This test was introduced here : https://github.com/odoo/odoo/pull/201294 - runbot error: 161250 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The chat typing indicator now matches the conversation background instead of showing a mismatched grey strip. This improves visual consistency and makes chat windows clearer, especially when using dark mode.
Original PR description
Before this commit, when someone is typing in conversation in a chat window, the "is typing" notification has a `.bg-view`. Problem is that `.bg-view` doesn't match the conversation bg, especially in dark theme where the conversation bg is dark and this is greyish. In chat window this takes the whole width, making it hard to distinguish the rounded rectangle shape of chat window. This commit fixes the issue by replacing the `.bg-view` to `.bg-inherit`, so that the text bg color of "is typing" matches the conversation bg. Before / After  
This fix improves the visual alignment of badges and action buttons in the Discuss sidebar, including both expanded and compact views. Users get a cleaner, more consistent messaging navigation experience with no change to functionality.
Original PR description
Before / After (expanded) <img width="303" alt="Screenshot 2025-03-20 at 12 21 24" src="https://github.com/user-attachments/assets/bc6c0841-aec6-4cf4-8ed8-6cee26b53a9a" /> <img width="301" alt="Screenshot 2025-03-20 at 12 19 22" src="https://github.com/user-attachments/assets/82225946-0b90-4c84-b5c9-77f0c92065a9" /> Before / After (compact) <img width="63" alt="Screenshot 2025-03-20 at 21 48 44" src="https://github.com/user-attachments/assets/2ddff447-d06a-462b-b4b0-0a725e65b100" /> <img width="59" alt="Screenshot 2025-03-20 at 21 47 22" src="https://github.com/user-attachments/assets/c08aa09a-be62-4800-b1d5-4c8b705f098c" />
Appraisal analysis reports now use the same status values as the main appraisal records. This makes grouping by status and filtering by state work correctly in reporting views, helping users analyze appraisal progress reliably.
Original PR description
Issue: cannot groupby status on appraisal analysis neither filter by state in graph view Solve: update the state field values of report to match the original model Task: 4653149
Miscellaneous changes
[FIX] web: save a dirty record without changes - Open a record (e.g., a project task); - Add a tag to a `many2many_tags` field; - Remove the previously added tag; - The record should be dirty (the save icon should be visible); - Click on the save icon/or click to pager next. Before this commit, the UI does nothing. It doesn't save, or it doesn't go to the next record if you click on the pager next. This is because even if the record is considered dirty, because some changes have been
Original PR description
[FIX] web: save a dirty record without changes - Open a record (e.g., a project task); - Add a tag to a `many2many_tags` field; - Remove the previously added tag; - The record should be dirty (the…
[FIX] web: save a dirty record without changes - Open a record (e.g., a project task); - Add a tag to a `many2many_tags` field; - Remove the previously added tag; - The record should be dirty (the save icon should be visible); - Click on the save icon/or click to pager next. Before this commit, the UI does nothing. It doesn't save, or it doesn't go to the next record if you click on the pager next. This is because even if the record is considered dirty, because some changes have been made (adding and removing tags), there are no changes. And a condition prevents to call the `web_save` RPC from being called if there are no changes. If the `web_save` RPC is not called, we do nothing. In this commit, we change this condition so that if the `web_save` RPC is not called, we mark the record as not dirty. When we move to another record (pager next), we do not need to mark the current record as not dirty, but the next record is loaded. X-original-commit: https://github.com/odoo/odoo/commit/43fb8a45ac629c1883ca9521a8879cf19ca7538b ----------------- [FIX] web: wait the main view reload before closing the dialog - On a slow connection; - In a list view (or a form view), click on a button (a view button); - Make some changes and save; - Make some changes in the main view; Because the connection is slow, the main view reloads after the user has made some changes. This causes some issues, for example : the changes may be lost, editable list views may become uneditable, forcing the user to click again. This happens because on the action service, the callback function (`onClose`) is called after the dialog is closed. In the case of a view button, the callback function will reload the main view. This commit changes that order, we will wait for the execution of the callback to complete before closing the dialog. ----------------- [FIX] web: close non-last dialog - Open multiple dialogs; - Close a non-last dialog; - Close all remaining dialogs with `closeAll`. Before this commit, a dialog wasn't closed. This is because when we close a dialog we always remove the last one from the dialog stack. Which in our case is not the right dialog. Conversely, the offset service removes the correct dialog (it uses the id to do this). So we have a dialog on the offset service that is not on the dialog service stack, and a dialog on the dialog service stack that is no longer on the offset service. This commit removes the correct dialog from the dialog stack using the id (as it's done in the offset service). Forward-Port-Of: odoo/odoo#202512
Before this commit: The test `test_rounding_half_up` do un-consistantly fail on the `totalIs("1.20")` check. According to the screenshot, the total value is 1.25 This may be related to a rounding issue, but I suspect that another test product is wrongly selected instead. The test select a product with a name containing `Product Test 1.2` this is expected to select the product with the exact same name. But I do suspect that it can also sometime wrongly select the product `Product Test 1.2
Original PR description
Before this commit:
The test `test_rounding_half_up` do un-consistantly fail on the `totalIs("1.20")` check.
According to the screenshot, the total value is 1.25
This may be related to a rounding issue, but I suspect that another test product is wrongly selected instead.
The test select a product with a name containing `Product Test 1.2` this is expected to select the product with the exact same name. But I do suspect that it can also sometime wrongly select the product `Product Test 1.25` as it starts the same.
After this commit:
The name of the product is modified in the demo data and test to avoid ambiguity with the contains operator
Note: I don't really know why the issue start to happen only now
rb-161265
Forward-Port-Of: odoo/odoo#202865Purpose of this PR: - Check `isSelectionInEditable` before `setSelection` to avoid error when selection is outside the editor. task-4639982 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202215
Original PR description
Purpose of this PR: - Check `isSelectionInEditable` before `setSelection` to avoid error when selection is outside the editor. task-4639982 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202215
Description: ------------ Following commit 4e7b5e44b292dc41217e4c50048b8bb8408246f5, the list view for bills now shows a colored highlight on the bill's reference if there is a potential duplicate, and the matching on the invoice date was relaxed to include potential bills from the same year. This caused a performance regression, as the index on `invoice_date` could no longer be used since the year is now extracted from it. This patch adds a partial 'btree' index on the `ref` field speci
Original PR description
Description: ------------ Following commit 4e7b5e44b292dc41217e4c50048b8bb8408246f5, the list view for bills now shows a colored highlight on the bill's reference if there is a potential duplicate,…
Description: ------------ Following commit 4e7b5e44b292dc41217e4c50048b8bb8408246f5, the list view for bills now shows a colored highlight on the bill's reference if there is a potential duplicate, and the matching on the invoice date was relaxed to include potential bills from the same year. This caused a performance regression, as the index on `invoice_date` could no longer be used since the year is now extracted from it. This patch adds a partial 'btree' index on the `ref` field specifically for bills, as it is the most discriminatory factor when identifying potential duplicates. Benchmark: ---------- On a database with 6M `account_move` records, 230k of which are `'in_invoice'` & `'in_refund'`, `_fetch_duplicate_reference`, triggered when opening the list view of bills, took: | Before | After | Speedup | |--------|-------|---------| | 19.8s | 20ms | 990x | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202999 Forward-Port-Of: odoo/odoo#202923
Since [1], operators now leave live chats instead of just unpinning them. When this happens, the chat is marked as inactive, preventing visitors from sending more messages—giving operators better control over their chats. However, the GC, which unpins old chats after one day of inactivity, was not updated accordingly. As a result, chats were unpinned for operators but remained accessible to visitors. This commit updates the GC process to align with the new behavior, ensuring visitors can n
Original PR description
Since [1], operators now leave live chats instead of just unpinning them. When this happens, the chat is marked as inactive, preventing visitors from sending more messages—giving operators better control over their chats. However, the GC, which unpins old chats after one day of inactivity, was not updated accordingly. As a result, chats were unpinned for operators but remained accessible to visitors. This commit updates the GC process to align with the new behavior, ensuring visitors can no longer send messages after GC. task-4509885 [1]: https://github.com/odoo/odoo/pull/192378 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#203062
The base.group_multi_company group is needed when the test is run without the demo data. Adding this group allows the stock.stock_location_customers location to be added to the stock rule’s search domain. This location is necessary for the stock rule to be found. Runbot error: 161249 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202799
Original PR description
The base.group_multi_company group is needed when the test is run without the demo data. Adding this group allows the stock.stock_location_customers location to be added to the stock rule’s search domain. This location is necessary for the stock rule to be found. Runbot error: 161249 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202799
When creating a partner with an italian VAT number in the backend, the field Codice Fiscale is automatically computed from the Tax ID. However, when a partner is created from the eCommerce of an italian company and the partner's VAT is filled, the Codice Fiscale is not filled in the newly created partner. We extend WebsiteSale to add `computeCodiceFiscale`, which will be triggered when the input field VAT or the select field Country change in the Address form. The function fills the Codice Fi
Original PR description
When creating a partner with an italian VAT number in the backend, the field Codice Fiscale is automatically computed from the Tax ID. However, when a partner is created from the eCommerce of an italian company and the partner's VAT is filled, the Codice Fiscale is not filled in the newly created partner. We extend WebsiteSale to add `computeCodiceFiscale`, which will be triggered when the input field VAT or the select field Country change in the Address form. The function fills the Codice Fiscale if the VAT field is filled, and it starts with 'IT' or the country selected is Italy. Task [link](https://www.odoo.com/odoo/project/967/tasks/4596227) task-4596227 Forward-Port-Of: odoo/odoo#202046 Forward-Port-Of: odoo/odoo#199876
Steps to reproduce the bug: - Create a storage “P1”: - UoM: Kg - Create a storable “Kit 1”: - UoM: unit - BoM: - 1 Kg of P1 - Create a delivery order for 1 unit of Kit 1 - Mark it as to do - Set the quantity of P1 to 1kg - try to print Problem: A traceback is triggered because we try to convert 1kg to unit: ``` odoo.addons.base.models.ir_qweb.QWebException: Error while render the template UserError: L'unité de mesure kg définie sur la ligne de commande
Original PR description
Steps to reproduce the bug:
- Create a storage “P1”:
- UoM: Kg
- Create a storable “Kit 1”:
- UoM: unit
- BoM:
- 1 Kg of P1
- Create a delivery order for 1 unit of Kit 1
- Mark it as to do
- Set the quantity of P1 to 1kg
- try to print
Problem:
A traceback is triggered because we try to convert 1kg to unit:
```
odoo.addons.base.models.ir_qweb.QWebException: Error while render the
template
UserError: L'unité de mesure kg définie sur la ligne de commande
n'appartient pas à la même catégorie que l'unité de mesure unités
définie sur le produit. Veuillez corriger l'unité de mesure définie
sur la ligne de commande ou sur le produit, elles doivent appartenir à
la même catégorie.
Template: stock.stock_report_delivery_has_serial_move_line
```
opw-4619140
Forward-Port-Of: odoo/odoo#201919
Forward-Port-Of: odoo/odoo#201580This commit adds Canary Island CoA from OCA's l10n_es_igic module. The initial migration was done using the script from: `https://github.com/william-andre/transform_coa` Along that, we also applied few more things: - use the english translations in `name` and moved the spanish names in `name@es` - added auto-apply on canary's fiscal position based on zip codes - adapt `-100` taxes on some of the taxes in canary - refactored the template flow From now on, the flow of the template d
Original PR description
This commit adds Canary Island CoA from OCA's l10n_es_igic module.
The initial migration was done using the script from: `https://github.com/william-andre/transform_coa`
Along that, we also applied few more things:
- use the english translations in `name` and moved the spanish names in `name@es`
- added auto-apply on canary's fiscal position based on zip codes
- adapt `-100` taxes on some of the taxes in canary
- refactored the template flow
From now on, the flow of the template dependencies will be like the following:
```
es_canary_common es_common_mainland
| |
(canary-assoc/full/pymes) (assec/full/pymes/coop_pymes)
```
task-id: 3354514
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#202928
Forward-Port-Of: odoo/odoo#195864### Steps to reproduce the issue: (Easier to reproduce with demo data) 1. Create a Fixed Tax and assign it to a Product 2. Open POS session, add Product to Order 3. Add a Coupon Code: "10pc" - This code should give a 10% Discount on the Order 4. The Discount Line includes the Fixed Tax amount and accounts for more than 10% of the Order Total ### Explanation: During the creation of the reward line, the fixed taxes are not excluded from discounts. While it is logical for percen
Original PR description
### Steps to reproduce the issue:
(Easier to reproduce with demo data)
1. Create a Fixed Tax and assign it to a Product
2. Open POS session, add Product to Order
3. Add a Coupon Code: "10pc"
- This code should give a 10% Discount on the Order
4. The Discount Line includes the Fixed Tax amount and accounts for more than 10% of the Order Total
### Explanation:
During the creation of the reward line, the fixed taxes are not excluded from discounts. While it is logical for percentage taxes to be included, as they become part of the discount, fixed taxes are added to the amount.
### Fix reasoning:
The opposite issue was fixed in commit odoo/odoo@534de1e47ab882bfb1cc006bdf1fa00fc877c6c4, adapting the code to javascript.
opw-4506550
Forward-Port-Of: odoo/odoo#202182
Forward-Port-Of: odoo/odoo#200175computed by dedicated method _compute_reference when a single invoice is overdue. Forward-Port-Of: odoo/odoo#202701
Original PR description
computed by dedicated method _compute_reference when a single invoice is overdue. Forward-Port-Of: odoo/odoo#202701
This reference should only be shown in the backend. Forward-Port-Of: odoo/odoo#202862
Original PR description
This reference should only be shown in the backend. Forward-Port-Of: odoo/odoo#202862
In point of sale it is possible to manage several orders at the same time and, whenever an order is paid, all orders will be synchronized with the backend. This causes an issue with loyalty rewards that are granted even for orders not yet completed. Steps to reproduce: - Have a Loyalty Program configured as follows: - Program Type: Loyalty Card - Grant 1 point per $ spent - Create a Loyalty card for [Partner] - Open POS Session - Add a [Partner] as customer - Add product - Leaving
Original PR description
In point of sale it is possible to manage several orders at the same time and, whenever an order is paid, all orders will be synchronized with the backend. This causes an issue with loyalty rewards…
In point of sale it is possible to manage several orders at the same time and, whenever an order is paid, all orders will be synchronized with the backend. This causes an issue with loyalty rewards that are granted even for orders not yet completed. Steps to reproduce: - Have a Loyalty Program configured as follows: - Program Type: Loyalty Card - Grant 1 point per $ spent - Create a Loyalty card for [Partner] - Open POS Session - Add a [Partner] as customer - Add product - Leaving the order as it is, create a new order - Add just a product - Validate & Pay the second order Issue: Loyalty points will be added to [Partner] Card, as if the order was actually paid This occurs because we don't check that the order has been actually paid before processing rewards opw-4538040 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#202588 Forward-Port-Of: odoo/odoo#199108
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#200348 Forward-Port-Of: odoo/odoo#198760
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 Forward-Port-Of: odoo/odoo#200348 Forward-Port-Of: odoo/odoo#198760
Issue ===== When product's code is computed, which is depend of the product's suppliers since each supplier can have a specific code, the first supplier is taken regardless if this supplier info is specific to another product variant which can cause to use the wrong code if there is multiple supplier with the same vendor but for different variants of the same product template. How to reproduce ================ 1. Install Puchase and Barcode; 2. Create a product with at least 2 variants;
Original PR description
Issue ===== When product's code is computed, which is depend of the product's suppliers since each supplier can have a specific code, the first supplier is taken regardless if this supplier info is…
Issue ===== When product's code is computed, which is depend of the product's suppliers since each supplier can have a specific code, the first supplier is taken regardless if this supplier info is specific to another product variant which can cause to use the wrong code if there is multiple supplier with the same vendor but for different variants of the same product template. How to reproduce ================ 1. Install Puchase and Barcode; 2. Create a product with at least 2 variants; 3. In the "Purchase" tab of this product, add two vendor pricelists with the same vendor but each for a different product variant and each with a different code; 4. Go in Purchase, create a new RFQ for this vendor, add a PO line for each variant and confirm the order; 5. Go in Barcode and open the PO's receipt -> You can see both lines have the same vendor's code (from the first pricelist) regardless the pricelist's product variant. Cause of the issue ================== In `_compute_product_code`, it uses the first product (template) supplier info regardless the product variant. Solution ======== In `_compute_product_code`, we skip a supplier info if it concerns another variant, and we break the supplier info loop only if it concerns the current product variant. Miscellaneous ============= The check of the `product.supplierinfo` `read` access right is moved outside of the loop so it is done only one time. [OPW-4589073](https://www.odoo.com/odoo/project/49/tasks/4589073) Forward-Port-Of: odoo/odoo#202592 Forward-Port-Of: odoo/odoo#201753
- Automatically assigns the outstanding account for payment methods using bank journals. task-id: 4600008 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199787
Original PR description
- Automatically assigns the outstanding account for payment methods using bank journals. task-id: 4600008 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199787
Follow-up of https://github.com/odoo/odoo/pull/194593 This PR added test coverage for the fix, but it failed at the last step '.o_menu_brand' to confirm the quotation. The intent is to save to quotation, but it relies on implicit action to quit (and save) the record from the app icon, which acts as a "go to main page of app". This button is not present in tours for some reasons, hence the step failing. This commit fixes it by manually confirming the quotation by clicking on the dedicate
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/194593 This PR added test coverage for the fix, but it failed at the last step '.o_menu_brand' to confirm the quotation. The intent is to save to quotation, but it relies on implicit action to quit (and save) the record from the app icon, which acts as a "go to main page of app". This button is not present in tours for some reasons, hence the step failing. This commit fixes it by manually confirming the quotation by clicking on the dedicated button, which is present in practice and in the tour. runbot-161274 In practice  In tour <img width="558" alt="Screenshot 2025-03-21 at 11 13 11" src="https://github.com/user-attachments/assets/8013a70a-0a0a-4a73-8820-d49678af84a5" /> Forward-Port-Of: odoo/odoo#202857
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#202636
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 Forward-Port-Of: odoo/odoo#202636
The composer should not send the current input on Enter key when being on a mobile device, since it is impossible for them to create a new line with either ctrl-Enter or alt-enter. [FIX] mail: Discuss on Mobile - Enter key behavior The composer should not send the current input on Enter key when being on a mobile device, since it is impossible for them to create a new line with either ctrl-Enter or alt-enter. Task-4209142 Forward-Port-Of: odoo/odoo#202897
Original PR description
The composer should not send the current input on Enter key when being on a mobile device, since it is impossible for them to create a new line with either ctrl-Enter or alt-enter. [FIX] mail: Discuss on Mobile - Enter key behavior The composer should not send the current input on Enter key when being on a mobile device, since it is impossible for them to create a new line with either ctrl-Enter or alt-enter. Task-4209142 Forward-Port-Of: odoo/odoo#202897
This fix aims to improve the user experience on mobile by removing useless tooltips on the chatter. Since the user usually does not have a keyboard on the mobile, we do not show the keybind tooltip when the screen is small task-4633869 Forward-Port-Of: odoo/odoo#201648 Forward-Port-Of: odoo/odoo#200961
Original PR description
This fix aims to improve the user experience on mobile by removing useless tooltips on the chatter. Since the user usually does not have a keyboard on the mobile, we do not show the keybind tooltip when the screen is small task-4633869 Forward-Port-Of: odoo/odoo#201648 Forward-Port-Of: odoo/odoo#200961
The "Lot / SN" column is redundant with the "Pick From" column. When Pick From is displayed, we can hide the "Lot/SN". However, if the user does not have the lot/serial number in a quant, they still need a way to select it, so we allow for a quant creation. In order to not re-introduce the bug fixed by this commit: 60d95aa8304c11698e49336391d98926861e640d , we overwrite the name_create to return False, aka no action is done. --- ## BEFORE https://github.com/user-attachments/assets/7
Original PR description
The "Lot / SN" column is redundant with the "Pick From" column. When Pick From is displayed, we can hide the "Lot/SN". However, if the user does not have the lot/serial number in a quant, they still…
The "Lot / SN" column is redundant with the "Pick From" column. When Pick From is displayed, we can hide the "Lot/SN". However, if the user does not have the lot/serial number in a quant, they still need a way to select it, so we allow for a quant creation. In order to not re-introduce the bug fixed by this commit: 60d95aa8304c11698e49336391d98926861e640d , we overwrite the name_create to return False, aka no action is done. --- ## BEFORE https://github.com/user-attachments/assets/7e6c5a6a-ed86-4564-bcb5-51c94a5a4ae4 - Selecting a SN is very fast - We can easily use an unavailable SN - The unavailable SN is taken from a quant without lot - Lot is displayed twice (pick from & lot/sn) ## AFTER https://github.com/user-attachments/assets/f5bd7cc6-d77e-410c-a1aa-8ad6ba6d0020 - Selecting a SN is a bit harder - Selecting an unavailable SN is even more complicated - The unavailable SN is taken from a quant with its lot OPW-4485159 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202778 Forward-Port-Of: odoo/odoo#199630
### Steps to reproduce: - Create a new draft invoice - In the actions click "PDF without Payment" - In the PDF the name is "Draft Invoice INV/2023/0001" - It should only be "Draft Invoice" ### Cause: "INV/2023/0001" is the placeholders in the XML. It is displayed because the name for draft moves is no longer '/' but null. ### Solution: Change the condition to also check if `o.name` exists. opw-4607518 Forward-Port-Of: odoo/odoo#202676
Original PR description
### Steps to reproduce: - Create a new draft invoice - In the actions click "PDF without Payment" - In the PDF the name is "Draft Invoice INV/2023/0001" - It should only be "Draft Invoice" ### Cause: "INV/2023/0001" is the placeholders in the XML. It is displayed because the name for draft moves is no longer '/' but null. ### Solution: Change the condition to also check if `o.name` exists. opw-4607518 Forward-Port-Of: odoo/odoo#202676
Versions -------- - 18.0+ Steps ----- 1. Create a pricelist with any discount on all products with a minimum quantity of 5; 2. Create a new sale order in mobile view; 3. Create a new sale order line, select any product and set a quantity higher than 5. Issue ----- The price unit isn't discounted as expected. Cause ----- `_compute_price_unit` needs `technical_price_unit` which is missing from the mobile view. Solution -------- Add `technical_price_unit` to mobile sale orde
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a pricelist with any discount on all products with a minimum quantity of 5; 2. Create a new sale order in mobile view; 3. Create a new sale order line, select any product and set a quantity higher than 5. Issue ----- The price unit isn't discounted as expected. Cause ----- `_compute_price_unit` needs `technical_price_unit` which is missing from the mobile view. Solution -------- Add `technical_price_unit` to mobile sale order views. opw-4569731 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#202748
Increase image size from 128 to 256 for combo items in the configurator opw-4630831 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202740
Original PR description
Increase image size from 128 to 256 for combo items in the configurator opw-4630831 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202740
- Implemented support for partial VAT deduction (e.g., 35% reclaimable VAT on EU acquisitions like fuel or electricity). task-4575302 Forward-Port-Of: odoo/odoo#197928
Original PR description
- Implemented support for partial VAT deduction (e.g., 35% reclaimable VAT on EU acquisitions like fuel or electricity). task-4575302 Forward-Port-Of: odoo/odoo#197928
#### This PR addresses 2 issues with the update of Manufacturing Order with kit products in the BoM (and subsequent bugs). Please see commits for details on the issues. Issue 1 ----- When using the "Update BOM" button for a confirmed manufacturing order, quantities for components derived from kit products are incorrectly updated to the kit product's bom instead of the new required quantity. Issue 2 ----- When using the "Update BOM" button for a confirmed manufacturing order, components
Original PR description
#### This PR addresses 2 issues with the update of Manufacturing Order with kit products in the BoM (and subsequent bugs). Please see commits for details on the issues. Issue 1 ----- When using the…
#### This PR addresses 2 issues with the update of Manufacturing Order with kit products in the BoM (and subsequent bugs). Please see commits for details on the issues. Issue 1 ----- When using the "Update BOM" button for a confirmed manufacturing order, quantities for components derived from kit products are incorrectly updated to the kit product's bom instead of the new required quantity. Issue 2 ----- When using the "Update BOM" button for a confirmed manufacturing order, components used to produce a specific variant of a kit product are not added to the MO consumables. Commit breakdown ----- - Commit 1 (handle component quantities - first ticket): - use the correct exploded value for the quantity (divided by the original quantity as the ratio isn't done for the top-level bom) - update test_update_mo_from_bom_with_kit with correct values - extend test_update_mo_from_bom_with_kit for when the kit components' quantities are updated - Commit 2 (handle components for specific variants - second ticket): - adapt the filtering of bom lines to keep them based on the kit's attribute instead of the end product one's - add a new test_update_mo_from_bom_with_kit_vraiants - Commit 3 (handle confusion of multi-variants/UoM kits - additional issues): - change bom_lines_by_id to a defaultdict to consolidate quantity of components - update test_update_mo_from_bom_with_kit to test for multiple UoMs - update test_update_mo_from_bom_with_kit_variants to test for multiple variants ----- Tickets: opw-4473337 opw-4480039 Forward-Port-Of: odoo/odoo#196227
If the target url had duplicate keys in its query params, the redirect url would only contain the key-value pair corresponding to the first occurrence of the key. This is incorrect, as a shop url typically contains multiple attribute values in its query params. The issue was caused by an accidental cast from MultiDict to Dict when handling the query params. opw-4466925 Forward-Port-Of: odoo/odoo#202901 Forward-Port-Of: odoo/odoo#199570
Original PR description
If the target url had duplicate keys in its query params, the redirect url would only contain the key-value pair corresponding to the first occurrence of the key. This is incorrect, as a shop url typically contains multiple attribute values in its query params. The issue was caused by an accidental cast from MultiDict to Dict when handling the query params. opw-4466925 Forward-Port-Of: odoo/odoo#202901 Forward-Port-Of: odoo/odoo#199570
In case of fully flexible working schedules, the leaves must not be computed from the working schedule (as there is none). The test for this bug is in the following related PR: https://github.com/odoo/enterprise/pull/80785 task-4623219 Forward-Port-Of: odoo/odoo#200379
Original PR description
In case of fully flexible working schedules, the leaves must not be computed from the working schedule (as there is none). The test for this bug is in the following related PR: https://github.com/odoo/enterprise/pull/80785 task-4623219 Forward-Port-Of: odoo/odoo#200379
Description of the issue/feature this PR addresses: Odoo Individual Contributor License Agreement Current behavior before PR: Odoo Individual Contributor License Agreement Desired behavior after PR is merged: Odoo Individual Contributor License Agreement --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202642
Original PR description
Description of the issue/feature this PR addresses: Odoo Individual Contributor License Agreement Current behavior before PR: Odoo Individual Contributor License Agreement Desired behavior after PR is merged: Odoo Individual Contributor License Agreement --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202642
Steps to reproduce the bug: - Install accounting - Go to reporting, Invoice analysis - Select Product Quantity, Untaxed Total and Average Price in Measures Traceback is thrown that the field prive_subtotal is used twice for the combination Untaxed total and Average price. Another traceback is thrown that quantity field is used twice for the combination Product Quantity and Average price. This is because the override of the read_group in the account.account_invoice_report in case of ave
Original PR description
Steps to reproduce the bug: - Install accounting - Go to reporting, Invoice analysis - Select Product Quantity, Untaxed Total and Average Price in Measures Traceback is thrown that the field…
Steps to reproduce the bug: - Install accounting - Go to reporting, Invoice analysis - Select Product Quantity, Untaxed Total and Average Price in Measures Traceback is thrown that the field prive_subtotal is used twice for the combination Untaxed total and Average price. Another traceback is thrown that quantity field is used twice for the combination Product Quantity and Average price. This is because the override of the read_group in the account.account_invoice_report in case of average price in the fields it add fields of quantity and price_subtotal. By default the fields are added with the default agg, so they are as <field>:sum. And the Untaxed Total and Poruct Quantity by default add both quantity and prive_subtotal as well. So they are duplicate columns to show on pivot and view crashes. The override of the read_group was introduced in d741788306. opw-4638089 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#201155
When a user tries to access a vendor bill where the vendor is their own company, Odoo displays a warning indicating that the user is trying to invoice themselves. To determine whether to show this warning, we check if the partner has any related `employee_ids`. However, if the user does not have the `"Employees / Officer: Manage all employees"` access rights, they cannot check the `employee_ids`, leading to an access error when opening the vendor bill. Steps to Reproduce: 1. Create a vend
Original PR description
When a user tries to access a vendor bill where the vendor is their own company, Odoo displays a warning indicating that the user is trying to invoice themselves. To determine whether to show this…
When a user tries to access a vendor bill where the vendor is their own company, Odoo displays a warning indicating that the user is trying to invoice themselves. To determine whether to show this warning, we check if the partner has any related `employee_ids`. However, if the user does not have the `"Employees / Officer: Manage all employees"` access rights, they cannot check the `employee_ids`, leading to an access error when opening the vendor bill. Steps to Reproduce: 1. Create a vendor bill where the vendor is set to your own company. 2. Try to access the vendor bill with a user who does not have `"Employees / Officer: Manage all employees"` access rights. Issue: An error occurs because the user lacks permission to check the related `employee_ids` for the vendor. Refer to this [video](https://drive.google.com/file/d/1hIUTbNYhZxT4aOtNq8XE1z7uy7K_HJM1/view) for clearer steps. opw-4539017 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202033
When picking type is changed, the locations on the moves should also be updated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202765 Forward-Port-Of: odoo/odoo#181769
Original PR description
When picking type is changed, the locations on the moves should also be updated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202765 Forward-Port-Of: odoo/odoo#181769
Currently, a traceback is occurs when the user tries to remove the date value, while creating a Bill. To reproduce this issue: 1) Install account 2) Create a Bills record from vendors 3) Change the `Auto-Post` value to `at date` from `other info` 4) Now remove the `Accounting Date` Error:- ``` TypeError: '>' not supported between instances of 'bool' and 'datetime.date' ``` When the user removed the date value, a compute method will be triggered in which a comparison is done
Original PR description
Currently, a traceback is occurs when the user tries to remove the date value, while creating a Bill. To reproduce this issue: 1) Install account 2) Create a Bills record from vendors 3) Change the `Auto-Post` value to `at date` from `other info` 4) Now remove the `Accounting Date` Error:- ``` TypeError: '>' not supported between instances of 'bool' and 'datetime.date' ``` When the user removed the date value, a compute method will be triggered in which a comparison is done between the record date and the today value. However, the user removed the record's date value, which leads to the above traceback from the below line https://github.com/odoo/odoo/blob/2adabe7321f26e67eea9853460948cbd4ac10a4a/addons/account/models/account_move.py#L626-L627 sentry-6402545255 Forward-Port-Of: odoo/odoo#202057
If a list contains multi-line content, only the first line of the content is shown in the spreadsheet cells. This commit fixes this with an `AUTORESIZE_ROWS`, which now works for multi-line formulas. Task: [4609545](https://www.odoo.com/web#id=4609545&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#81929 Forward-Port-Of: odoo/enterprise#81325
Original PR description
If a list contains multi-line content, only the first line of the content is shown in the spreadsheet cells. This commit fixes this with an `AUTORESIZE_ROWS`, which now works for multi-line formulas. Task: [4609545](https://www.odoo.com/web#id=4609545&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#81929 Forward-Port-Of: odoo/enterprise#81325
Versions -------- - 18.0+ Steps ----- 1. Have a second company & select it; 2. create a project w/out `company_id`; 3. set its documents folder to "Projects"; 4. create a service product that creates a project on confirm; 5. set created project as its project template; 6. add service product to a quotation; 7. confirm quotation. Issue ----- Access Error. Cause ----- Commit ac051d00e96c added a constraint on the `website_id` of documents: - OR the document's `company_id` h
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a second company & select it; 2. create a project w/out `company_id`; 3. set its documents folder to "Projects"; 4. create a service product that creates…
Versions -------- - 18.0+ Steps ----- 1. Have a second company & select it; 2. create a project w/out `company_id`; 3. set its documents folder to "Projects"; 4. create a service product that creates a project on confirm; 5. set created project as its project template; 6. add service product to a quotation; 7. confirm quotation. Issue ----- Access Error. Cause ----- Commit ac051d00e96c added a constraint on the `website_id` of documents: - OR the document's `company_id` has to match the website's `company_id`; - OR the website's `company_id` has to be in `self.env.companies`. The Projects folder was created without `website_id`, but was assigned company 1's website by the `_compute_website_id` method. When a document gets created by the sale order, it inherits the `website_id` of the Projects folder. Hence having a shared folder between companies can lead to access errors if the website's `company_id` isn't selected in the company selector. Solution -------- Bypass the constraint when in sudo mode, so you don't have to enable the website's company in the company selector when setting up a sale order. opw-4548619 Forward-Port-Of: odoo/enterprise#81470 Forward-Port-Of: odoo/enterprise#80966
Before this PR the function _compute_unpaid_invoices is using an antipattern of running a search in a for loop. This PR performs a single search and uses a python dictionary for faster lookup in the forloop and fewer queries. Benchmarks: |num res.partner | time before | no. queries| time after | no. queries after| |-----|-----|----|------|----| | 80 | ~18s | 80 | ~0.4s | 1| Forward-Port-Of: odoo/enterprise#81438
Original PR description
Before this PR the function _compute_unpaid_invoices is using an antipattern of running a search in a for loop. This PR performs a single search and uses a python dictionary for faster lookup in the forloop and fewer queries. Benchmarks: |num res.partner | time before | no. queries| time after | no. queries after| |-----|-----|----|------|----| | 80 | ~18s | 80 | ~0.4s | 1| Forward-Port-Of: odoo/enterprise#81438
The customer statement should show the same info as the partner ledger, but in a more condensed way (less columns, same rows). Same for the Follow-up report, but here we should by default filter on sales journals. Ticket - 4606122 Forward-Port-Of: odoo/enterprise#81369
Original PR description
The customer statement should show the same info as the partner ledger, but in a more condensed way (less columns, same rows). Same for the Follow-up report, but here we should by default filter on sales journals. Ticket - 4606122 Forward-Port-Of: odoo/enterprise#81369
Currently on the Frontdesk welcome screen the words "Welcome" and "to" (welcoming visitors to your company) were exported separately, because they weren't in the same parent node. This caused translation issues, since the word "to" is translated differently depending on the context and was not scoped to the module (Javascript translation). This commit puts "Welcome to" together in the same parent node, so the phrase is exported as a whole. [task-4421055](https://www.odoo.com/odoo/project.t
Original PR description
Currently on the Frontdesk welcome screen the words "Welcome" and "to" (welcoming visitors to your company) were exported separately, because they weren't in the same parent node. This caused translation issues, since the word "to" is translated differently depending on the context and was not scoped to the module (Javascript translation). This commit puts "Welcome to" together in the same parent node, so the phrase is exported as a whole. [task-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/enterprise#80851 Forward-Port-Of: odoo/enterprise#78781
Use case: -Create a parent company and a child company. -Create two journals, assigning one to each company. -Connect with a normal user (not an admin, I connected with marc demo) after adding both companies to their allowed companies list. -activate the child company, and attempt to access the General Ledger. --> there is an access right error raised because the user doesn't have access to the parent company. ticket - 4577222 Forward-Port-Of: odoo/enterprise#81452
Original PR description
Use case: -Create a parent company and a child company. -Create two journals, assigning one to each company. -Connect with a normal user (not an admin, I connected with marc demo) after adding both companies to their allowed companies list. -activate the child company, and attempt to access the General Ledger. --> there is an access right error raised because the user doesn't have access to the parent company. ticket - 4577222 Forward-Port-Of: odoo/enterprise#81452
- Removed VAT report banners for warnings but kept rejection banners. task-4575302 Forward-Port-Of: odoo/enterprise#79469
Original PR description
- Removed VAT report banners for warnings but kept rejection banners. task-4575302 Forward-Port-Of: odoo/enterprise#79469
[[FIX] account_batch_payment: show correct amount in reconciled batch payments](https://github.com/odoo/enterprise/pull/80862/commits/d9f837d4bb459a10e74b65c10204e2c31573e7a5) **Issue:** When reconciling a batch payment, its amount is incorrectly displayed as zero in the list view. **Steps to Reproduce:** 1. Install the Accounting app. 2. Navigate to Accounting > Customers > Payments. 3. Create or select two payments, then click Create Batch. 4. Validate the batch payment. 5. Go to Das
Original PR description
[[FIX] account_batch_payment: show correct amount in reconciled batch payments](https://github.com/odoo/enterprise/pull/80862/commits/d9f837d4bb459a10e74b65c10204e2c31573e7a5) **Issue:** When…
[[FIX] account_batch_payment: show correct amount in reconciled batch payments](https://github.com/odoo/enterprise/pull/80862/commits/d9f837d4bb459a10e74b65c10204e2c31573e7a5) **Issue:** When reconciling a batch payment, its amount is incorrectly displayed as zero in the list view. **Steps to Reproduce:** 1. Install the Accounting app. 2. Navigate to Accounting > Customers > Payments. 3. Create or select two payments, then click Create Batch. 4. Validate the batch payment. 5. Go to Dashboard > Transactions. 6. Create a new transaction with the same value as the batch payment. 7. Click on the transaction, select the batch payment, and click Validate to reconcile them. 8. Navigate to Customers > Batch Payments. 9. Observe that the batch payment in the list view shows an amount of zero. Expected Behavior: The list view should display the sum of the payments included in the batch. Actual Behavior: The amount displayed in the list view is always zero after reconciliation. **Root Cause** During reconciliation, when execution reaches line 138 in account_batch_payment.py https://github.com/odoo/enterprise/blob/08084d8423a7d75c1ee2647256e01a464eec0b14/account_batch_payment/models/account_batch_payment.py#L137 , the batch payments are already in the paid state. However, _valid_payment_states() https://github.com/odoo/enterprise/blob/08084d8423a7d75c1ee2647256e01a464eec0b14/account_batch_payment/models/account_batch_payment.py#L69-L70 calls _get_invoice_in_payment_state(), which returns "in_payment". As a result, _valid_payment_states() only returns "in_process", excluding payments in the "paid" state from the computation. Consequently, in _compute_from_payment_ids(), the loop over valid payments is skipped, leaving the amount variable at its initial value of zero. https://github.com/odoo/enterprise/blob/08084d8423a7d75c1ee2647256e01a464eec0b14/account_batch_payment/models/account_batch_payment.py#L132-L162 **Fix** Always compute `amount`. Skip `amount_residual` and `amount_residual_currency` for valid payment states. Opw-4585624 Forward-Port-Of: odoo/enterprise#80862
The bug has been introduced by this commit : https://github.com/odoo/enterprise/commit/4cba2fb58560a95d5ce93eb6e6c1483ef0428ba5 The bug appears when trying to generate batch of payslips with fully flexible working schedules. When the contract linked to the payslip has no working schedule, the check of the timezone is done on the employee linked to the payslip. The fix only consists on taking the employee of each slip instead of taking the employee on self, which was causing a 'singleton expe
Original PR description
The bug has been introduced by this commit : https://github.com/odoo/enterprise/commit/4cba2fb58560a95d5ce93eb6e6c1483ef0428ba5 The bug appears when trying to generate batch of payslips with fully flexible working schedules. When the contract linked to the payslip has no working schedule, the check of the timezone is done on the employee linked to the payslip. The fix only consists on taking the employee of each slip instead of taking the employee on self, which was causing a 'singleton expected' error. This commit also contains a test for the related fix in the following related PR: task-4623219 Forward-Port-Of: odoo/enterprise#80785
Even though it's been commonplace in Odoo for a while, tags (or more precisely facets) with index-0/False color where still shown on Documents kanban cards. This should remain the case functionally as users are not expected to go and change the color of all their tags, nor can we decide for them at upgrade (and it'd be too late for many as well). Task-4645015 Also, cleaning up some test stuff for hoot. See details in individual commits. Task-3861500 Forward-Port-Of: odoo/enterpris
Original PR description
Even though it's been commonplace in Odoo for a while, tags (or more precisely facets) with index-0/False color where still shown on Documents kanban cards. This should remain the case functionally as users are not expected to go and change the color of all their tags, nor can we decide for them at upgrade (and it'd be too late for many as well). Task-4645015 Also, cleaning up some test stuff for hoot. See details in individual commits. Task-3861500 Forward-Port-Of: odoo/enterprise#81867 Forward-Port-Of: odoo/enterprise#76201
**=pos_urban_piper_swiggy Following this commit: ==== - Previously, static values like 'CGST' and 'SGST' were used. However, 'SGST' has been renamed to 'SGST/UTGST'. - To prevent similar issues in the future, tax group names are now fetched dynamically instead of using hardcoded values. - This ensures accurate tax computation and better maintainability. task-4626494 Forward-Port-Of: odoo/enterprise#81858 Forward-Port-Of: odoo/enterprise#80756
Original PR description
**=pos_urban_piper_swiggy Following this commit: ==== - Previously, static values like 'CGST' and 'SGST' were used. However, 'SGST' has been renamed to 'SGST/UTGST'. - To prevent similar issues in the future, tax group names are now fetched dynamically instead of using hardcoded values. - This ensures accurate tax computation and better maintainability. task-4626494 Forward-Port-Of: odoo/enterprise#81858 Forward-Port-Of: odoo/enterprise#80756
Before this PR: - The computation used `start_yearly_period` as the start date. - This caused incorrect depreciation calculations when an asset was disposed of early. - Example: - Prorata Date: 01/01/2025 - Disposal Date: 20/02/2025 - Computed Days: 326 (incorrect, should be 20) After this PR: - `period_start_date` is now set as `max(start_yearly_period, self.paused_prorata_date)`. - Ensures depreciation is calculated only for the valid period before disposal. - Example: - P
Original PR description
Before this PR: - The computation used `start_yearly_period` as the start date. - This caused incorrect depreciation calculations when an asset was disposed of early. - Example: - Prorata Date: 01/01/2025 - Disposal Date: 20/02/2025 - Computed Days: 326 (incorrect, should be 20) After this PR: - `period_start_date` is now set as `max(start_yearly_period, self.paused_prorata_date)`. - Ensures depreciation is calculated only for the valid period before disposal. - Example: - Prorata Date: 01/01/2025 - Disposal Date: 20/02/2025 - Computed Days: 20 (correct). OPW: 4599614 Forward-Port-Of: odoo/enterprise#81888 Forward-Port-Of: odoo/enterprise#80214
Currently an error occurs when the user tries to uninstall `Sales` or `helpdesk_sale_timesheet` after creating a helpdesk ticket. Steps to generate an error: - Create a database without a demo and install helpdesk_sale_timesheet. - Create a helpdesk ticket. - Now try to uninstall sale_management (Sales). Error `KeyError: 'helpdesk.ticket.sale_line_id'` This issue was generated because in the helpdesk ticket we have the `use_helpdesk_sale_timesheet` field (see [1]), which is a depen
Original PR description
Currently an error occurs when the user tries to uninstall `Sales` or `helpdesk_sale_timesheet` after creating a helpdesk ticket. Steps to generate an error: - Create a database without a demo and…
Currently an error occurs when the user tries to uninstall `Sales` or `helpdesk_sale_timesheet` after creating a helpdesk ticket. Steps to generate an error: - Create a database without a demo and install helpdesk_sale_timesheet. - Create a helpdesk ticket. - Now try to uninstall sale_management (Sales). Error `KeyError: 'helpdesk.ticket.sale_line_id'` This issue was generated because in the helpdesk ticket we have the `use_helpdesk_sale_timesheet` field (see [1]), which is a depends field of the `compute_sale_line_id` method, which is the compute method of the field sale_line_id (see [2] and [3]) in the helpdesk ticket. In helpdesk code line [4] tries to update the value of the field `use_helpdesk_sale_timesheet` since this field is related to the helpdesk ticket (see [1]) value of this field also changed in the helpdesk ticket, and the value was changed the compute method trigger because this field depends on the compute method. This commit will solve the above issue by executing an SQL query instead of writing the team field so it doesn't trigger depending on that field. [1]- https://github.com/odoo/enterprise/blob/1619b74b7895108a80d466c57972fc97923c860c/helpdesk_sale_timesheet/models/helpdesk_ticket.py#L27 [2]- https://github.com/odoo/enterprise/blob/1619b74b7895108a80d466c57972fc97923c860c/helpdesk_sale_timesheet/models/helpdesk_ticket.py#L31-L38 [3]- https://github.com/odoo/enterprise/blob/1619b74b7895108a80d466c57972fc97923c860c/helpdesk_sale_timesheet/models/helpdesk_ticket.py#L77-L78 [4]- https://github.com/odoo/enterprise/blob/1619b74b7895108a80d466c57972fc97923c860c/helpdesk/models/ir_module.py#L15 sentry-6308112739 Forward-Port-Of: odoo/enterprise#81008
Before this commit: === - When reloading the POS, the delivery order count in pos_store was lost. After this commit: === - The order count is now properly retained even after a reload. - Ensures that delivery orders persist correctly in pos_store. task-4585831 Forward-Port-Of: odoo/enterprise#79560
Original PR description
Before this commit: === - When reloading the POS, the delivery order count in pos_store was lost. After this commit: === - The order count is now properly retained even after a reload. - Ensures that delivery orders persist correctly in pos_store. task-4585831 Forward-Port-Of: odoo/enterprise#79560
Issue: order.company.partner_id[1] is undefined during the change to use `order` object as props component. in this PR: #189446 Purpose of this PR: use order.company.name if it exists to include into the receipt header. opw-4654437 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202971
Original PR description
Issue: order.company.partner_id[1] is undefined during the change to use `order` object as props component. in this PR: #189446 Purpose of this PR: use order.company.name if it exists to include into the receipt header. opw-4654437 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202971