Thursday, February 20, 2025
65 changes · saas-18.1
Enhancements to existing features
Self-ordering setup downloads now include SVG versions of each table QR code in addition to PNG files. This makes the QR codes easier to use for production needs such as engraving coasters or other physical table materials.
Original PR description
In the config page of the self order there is an option to download a zip containing all of the table qr codes in png format. In this commit we include also svg variants for each qrcode in the zip file. This is helpful for certain applications, for ex engraving the qr codes on coasters, using laser engraving machines. Task: 4575936 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Self-order demo setups now automatically include the relevant preset data, making demo environments ready to use without extra configuration. This helps teams showcase or test restaurant self-order flows more reliably and with less manual setup.
Original PR description
Before this commit: === - there was preset demo data was not enabled for self order After this commit: === - updated preset demo data to default enabled in pos self order Task: 4501570
Resolved issues and error corrections
The Point of Sale test flow was adjusted so confirmation popups can appear without being blocked by an unnecessary timing delay. This helps prevent false automated test failures and supports more reliable checkout-related behavior.
Original PR description
Following this commit: - Check delay was removed so that confirm popup can be executed default check delay is 200 which is more than already given runbot Error: 111974
Miscellaneous changes
Steps to reproduce: =================== - Open the restaurant registry from 2 devices A and B - From device A, open a table, add a product, go back to floor plan - From device B, choose the same table, click split, choose the product added from device A, and click on pay. Reason: ======= We are trying to delete the same record 'pos.order.line' twice, i.e. we're calling `processDeletedRecords` twice with the same record id [1], so it succeds the first time, and it removes the record from
Original PR description
Steps to reproduce: =================== - Open the restaurant registry from 2 devices A and B - From device A, open a table, add a product, go back to floor plan - From device B, choose the same…
Steps to reproduce: =================== - Open the restaurant registry from 2 devices A and B - From device A, open a table, add a product, go back to floor plan - From device B, choose the same table, click split, choose the product added from device A, and click on pay. Reason: ======= We are trying to delete the same record 'pos.order.line' twice, i.e. we're calling `processDeletedRecords` twice with the same record id [1], so it succeds the first time, and it removes the record from the frontend cache, but when trying to process the deletion the second time, it fails since the record doesn't exist in the cache anymore [2], and hence, the `record` object is `undefined` in the second call to `delete_` with the same record id, causing the traceback [3]. The reason we're calling `processDeletedRecords` twice with the same record id is because `sync_from_ui` is issuing 2 sync events at the same time [4], since it's been passed 2 orders when splitting [5]. Fix: ==== Since it's an urgent bug, this fix just skips deleting the record if it doesn't exist, without "fixing" the root cause of syncing event being issued twice. [1]: https://github.com/odoo/odoo/blob/2d0ed96675541a88d9132bd01d33730f72c79d1d/addons/point_of_sale/static/src/app/store/devices_synchronisation.js#L116 [2]: https://github.com/odoo/odoo/blob/eca835a10d027b936890ff6ccc9e02660edfdfd5/addons/point_of_sale/static/src/app/models/related_models.js#L691 [3]: https://github.com/odoo/odoo/blob/eca835a10d027b936890ff6ccc9e02660edfdfd5/addons/point_of_sale/static/src/app/models/related_models.js#L664-L665 [4]: https://github.com/odoo/odoo/blob/eca835a10d027b936890ff6ccc9e02660edfdfd5/addons/point_of_sale/models/pos_order.py#L1043-L1046 [5]: https://github.com/odoo/odoo/blob/0faf168bbcbc66daeb58999a6222cd2c6d41134c/addons/pos_restaurant/static/src/app/split_bill_screen/split_bill_screen.js#L167 opw-4562134 Forward-Port-Of: odoo/odoo#198477
This fix keeps the form statusbar layered correctly when pages include ribbon elements or rich text editor markers. It prevents visual overlap so users see key status information clearly while working in forms.
Original PR description
This commit avoids the stacking mismatch between the statusbar and elements using a ribbon. It also fixes an issue affecting the left marker in a rich editor field being shown over the statusbar. task-4504282 task-4457597
This update fixes an error affecting certified French point-of-sale receipts by using the correct pricing reference. It helps ensure receipts can be generated reliably and avoids failures in automated checks.
Original PR description
In this commit: =============== taxed_lst_unit_price gives an error as this method got changed by getTaxedlstUnitPrice() so replaced taxed_lst_unit_price by getTaxedlstUnitPrice() Runbot error:110614,110615
The cogwheel dropdown menu is unwanted and only contains the 'Export All' button, which is disabled with an attribute. This commit extends the existing base tree view for this specific use to avoid interfering with other views that use/extend it. Task ID: [4471980](https://www.odoo.com/odoo/project/966/tasks/4471980) Forward-Port-Of: odoo/odoo#195148 Forward-Port-Of: odoo/odoo#193987
Original PR description
The cogwheel dropdown menu is unwanted and only contains the 'Export All' button, which is disabled with an attribute. This commit extends the existing base tree view for this specific use to avoid interfering with other views that use/extend it. Task ID: [4471980](https://www.odoo.com/odoo/project/966/tasks/4471980) Forward-Port-Of: odoo/odoo#195148 Forward-Port-Of: odoo/odoo#193987
- Fix issue where an error occur when trying to open the customer popup on mobile from the ticket screen (while reviewing a paid order). - Now we don't display the `Customer` selection button when we're on the ticket screen (like it was already done for the "actions" button) to avoid this error (like it's done in desktop). Also, it does not make sense to try to change the customer of a paid order. task-id: 4571914 Description of the issue/feature this PR addresses: Current behavior bef
Original PR description
- Fix issue where an error occur when trying to open the customer popup on mobile from the ticket screen (while reviewing a paid order). - Now we don't display the `Customer` selection button when we're on the ticket screen (like it was already done for the "actions" button) to avoid this error (like it's done in desktop). Also, it does not make sense to try to change the customer of a paid order. task-id: 4571914 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#197565
The tour requires the commercial_company_name to be 'yourcompany' which is not the case when demo data is not installed. https://runbot.odoo.com/odoo/runbot.build.error/116103 Forward-Port-Of: odoo/odoo#198303
Original PR description
The tour requires the commercial_company_name to be 'yourcompany' which is not the case when demo data is not installed. https://runbot.odoo.com/odoo/runbot.build.error/116103 Forward-Port-Of: odoo/odoo#198303
**Issue:** When splitting an expense, all products are available to define the split expense categories.  **Expected:** The wizard should only display products related to `Expense Categories` to keep consistency with base expense creation. **Steps to reproduce:** - Activate Expense app; - Create a new expense; - *(opt) Try changing the expense category and see av
Original PR description
**Issue:** When splitting an expense, all products are available to define the split expense categories.  **Expected:** The wizard should only display products related to `Expense Categories` to keep consistency with base expense creation. **Steps to reproduce:** - Activate Expense app; - Create a new expense; - *(opt) Try changing the expense category and see available categories to compare;*  - Save and click `Split Expense`; - In the `Product` column, select a product not listed in `Expense Categories` (cf. optional step); - Split expense and see the new expenses having the normally unavailable product as category.  **Cause:** All products are retrieved by the wizard, unlike the category field of the base `hr_expense`. **Fix:** Add restrictive domain as for base `hr_expense`. https://github.com/odoo/odoo/blob/573cbe3b19e91a134ee65168b3021437a39b6093/addons/hr_expense/models/hr_expense.py#L57 <img width="1439" alt="Capture d’écran 2024-12-16 à 16 32 57" src="https://github.com/user-attachments/assets/c9fa8b43-bd7b-4ab3-8759-b4d6a0e269d6" /> opw-4357521 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197550 Forward-Port-Of: odoo/odoo#190738
…sively The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled. Instead, this commit introduces a new context key: 'no_exchange_difference_no_recursive'. task-id:
Original PR description
…sively The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled. Instead, this commit introduces a new context key: 'no_exchange_difference_no_recursive'. task-id: 4531511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196466 Forward-Port-Of: odoo/odoo#195814
In order to simplify the macro.js API, the action of a step must be a function. The action can then call (Hoot or others) events to interact with the trigger. In any case, it is not useful to have ACTION_HELPERS in macro.js which are only used in very rare cases in the codebase. 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/submi
Original PR description
In order to simplify the macro.js API, the action of a step must be a function. The action can then call (Hoot or others) events to interact with the trigger. In any case, it is not useful to have ACTION_HELPERS in macro.js which are only used in very rare cases in the codebase. 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#198358
When you have multiple payment methods that can work on the kiosk, they would all be shown on the kiosk screen. Steps to reproduce: ------------------- * Setup 2 Stripe payment methods * Create a PoS kiosk * Assign one of the methods to the kiosk * Open the kiosk * Create an order and go to the payment screen > Observation: Both payment methods are shown Why the fix: ------------ The payment methods are now filtered based on the payment methods assigned to the kiosk. opw-457464
Original PR description
When you have multiple payment methods that can work on the kiosk, they would all be shown on the kiosk screen. Steps to reproduce: ------------------- * Setup 2 Stripe payment methods * Create a PoS kiosk * Assign one of the methods to the kiosk * Open the kiosk * Create an order and go to the payment screen > Observation: Both payment methods are shown Why the fix: ------------ The payment methods are now filtered based on the payment methods assigned to the kiosk. opw-4574644 Forward-Port-Of: odoo/odoo#198046
**Current behavior before PR:** It was possible to save a step with step_type "question selection" without any answers. However, this would cause an error when the bot was executed. **Desired behavior after PR is merged:** A constraint has been added to ensure that a "question selection" step cannot be saved without at least one answer. task-id:[4522835](https://www.odoo.com/odoo/my-tasks/4522835) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/su
Original PR description
**Current behavior before PR:** It was possible to save a step with step_type "question selection" without any answers. However, this would cause an error when the bot was executed. **Desired behavior after PR is merged:** A constraint has been added to ensure that a "question selection" step cannot be saved without at least one answer. task-id:[4522835](https://www.odoo.com/odoo/my-tasks/4522835) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197104
Description of the issue/feature this PR addresses: The o_rating_label css is not properly configured, which caused an unintended extra border line to appear on the rating image This commit removes the border explicitly in the CSS file to correct the visual issue. opw-4482430 Related Commit: https://github.com/odoo/odoo/commit/9e8a709f80e3e4620bfa92decb383781b04d64c8#diff-b7f943d7f11d281f92f78810d7da31d5ab33d4e5952d66ce973d0bc24278ebcd Current behavior before PR:  Desired behavior after PR is merged: The border will be invisible and everything else still functional without any influence --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196513
**Problem**: Wrapping links with `feff` chars allows placing the cursor at their inner or outer edge. However, if the parent is `contenteditable=false`, this behavior is unnecessary since navigation outside the link is already blocked. **Example**: `<div contenteditable=false>/ZWS/<a contenteditable=true>` `/ZWS/ab[]c</a></div>` Pressing the left arrow key repeatedly places the cursor at the start of `a`, before `feff`: `<div contenteditable=false>/ZWS/<a contenteditable=true>` `[]/
Original PR description
**Problem**: Wrapping links with `feff` chars allows placing the cursor at their inner or outer edge. However, if the parent is `contenteditable=false`, this behavior is unnecessary since navigation…
**Problem**: Wrapping links with `feff` chars allows placing the cursor at their inner or outer edge. However, if the parent is `contenteditable=false`, this behavior is unnecessary since navigation outside the link is already blocked. **Example**: `<div contenteditable=false>/ZWS/<a contenteditable=true>` `/ZWS/ab[]c</a></div>` Pressing the left arrow key repeatedly places the cursor at the start of `a`, before `feff`: `<div contenteditable=false>/ZWS/<a contenteditable=true>` `[]/ZWS/abc</a></div>` This forces an extra left-arrow press to move past `a`, which is redundant since only the link itself is editable. **Solution**: Wrap links with `feff` only if their parent element is `contenteditable=true`. **Steps to Reproduce**: 1. Add a Form snippet. 2. Focus on the "Submit" button. 3. Press the "Home" button to move the cursor to the start. 4. Press the right arrow key twice. - **Expected**: Cursor moves after the first visible char. - **Issue**: Cursor stops prematurely before the character. opw-4505962 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195704
Description of the issue/feature this PR addresses: - After an internal user (without Live Chat application access) interacted with chatbot from website, he will not be able to click on the Messages icon on the top-right menu anymore:  - Cause: Internal user without Live Chat application access cannot read on model `chatbot.script.step`, so when system calls `mail_channel.chatbot_current_step_id`, securit
Original PR description
Description of the issue/feature this PR addresses: - After an internal user (without Live Chat application access) interacted with chatbot from website, he will not be able to click on the Messages icon on the top-right menu anymore:  - Cause: Internal user without Live Chat application access cannot read on model `chatbot.script.step`, so when system calls `mail_channel.chatbot_current_step_id`, security error occurs. - Solution: Use `sudo` on `mail_channel` variable to avoid security error. 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#196203 Forward-Port-Of: odoo/odoo#174611
**Current behavior:** The `report.stock.quantity` view may attribute and incorrect destination location with a move when building the report: Specifically, it will coalesce a move's `location_dest_id` and `location_final_id` regardless of the state of the move and where the product qty was actually transferred to. **Expected behavior:** If the move is completed, the actual location of where it moved product should be used to fill in the destination location. **Steps to reproduce:*
Original PR description
**Current behavior:** The `report.stock.quantity` view may attribute and incorrect destination location with a move when building the report: Specifically, it will coalesce a move's…
**Current behavior:** The `report.stock.quantity` view may attribute and incorrect destination location with a move when building the report: Specifically, it will coalesce a move's `location_dest_id` and `location_final_id` regardless of the state of the move and where the product qty was actually transferred to. **Expected behavior:** If the move is completed, the actual location of where it moved product should be used to fill in the destination location. **Steps to reproduce:** 1. Enable 2-step delivery 2. Create an in move for some tracked productA -> validate 3. Create a sale order for the same productA, confirm, then validate the first picking in the chain 4. Look at the forecast for productA, observe that it has the positive quantity from the in move furter in the past then it should **Cause of the issue:** When a StockMove was completed, it's `location_final_id` was taken over its `location_dest_id`, which meant the actual location that the move transferred product to was not reflected in the quantity report, meaning you could have a case as described above where the forecast quantity becomes imbalanced because it is not properly counting moves against would-be offsetting ones. **Fix:** Don't prefer `location_final_id` when `move.state == 'done'`. opw-4311583 Forward-Port-Of: odoo/odoo#195212 Forward-Port-Of: odoo/odoo#192440
odoo/odoo#192897 introduced a new bug when trying to access the replenishment view without administrator rights due to a call to `ir.config.parameter` method `get_param` without sudo rights. opw-4583651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198174
Original PR description
odoo/odoo#192897 introduced a new bug when trying to access the replenishment view without administrator rights due to a call to `ir.config.parameter` method `get_param` without sudo rights. opw-4583651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198174
Versions -------- - 17.0+ Steps ----- 1. Have a PNG image with a transparent background; - e.g. https://odoocdn.com/openerp_website/static/src/img/assets/png/odoo_logo.png 3. use it as main image for a product; 4. upload it again as extra image via the website editor; 5. enable click on zoom for the images; 6. click on the images. Issue ----- - The main image gets displayed with a black background. - The extra image gets displayed with a white background. Cause ----- -
Original PR description
Versions
--------
- 17.0+
Steps
-----
1. Have a PNG image with a transparent background;
- e.g. https://odoocdn.com/openerp_website/static/src/img/assets/png/odoo_logo.png
3. use it as main image for a product;
4. upload it again as extra image via the website editor;
5. enable click on zoom for the images;
6. click on the images.
Issue
-----
- The main image gets displayed with a black background.
- The extra image gets displayed with a white background.
Cause
-----
- The `img` element of the main image has the `bg-black` class.
- PNG images uploaded via the `website_sale` editor get converted to WEBP, and then drawn on a white canvas before getting stored.
Solution
--------
- Remove the `bg-black` class from the `img` element.
- When converting to WEBP, use a transparent canvas.
- Do the same for WEBP images uploaded via `ImageField`.
opw-3848324
Forward-Port-Of: odoo/odoo#197603It is possible to have a lead linked to registration from different events by using the merge method on the leads. Currently once they are merged it becomes impossible to update any field that is synced as syncing expects we will only encounter one event. We just default to the first event for the name. Additionally the test revealed that if the lead doesn't have a description and a partner is added, the update mechanism crashes. task-4531433 Forward-Port-Of: odoo/odoo#198380 Forwar
Original PR description
It is possible to have a lead linked to registration from different events by using the merge method on the leads. Currently once they are merged it becomes impossible to update any field that is synced as syncing expects we will only encounter one event. We just default to the first event for the name. Additionally the test revealed that if the lead doesn't have a description and a partner is added, the update mechanism crashes. task-4531433 Forward-Port-Of: odoo/odoo#198380 Forward-Port-Of: odoo/odoo#196848
In the survey stats, the number of votes for a multiple choice answer displayed the label "Votes" without it being translatable. This commit makes it translatable. [task-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/odoo#197157 Forward-Port-Of: odoo/odoo#196704
Original PR description
In the survey stats, the number of votes for a multiple choice answer displayed the label "Votes" without it being translatable. This commit makes it translatable. [task-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/odoo#197157 Forward-Port-Of: odoo/odoo#196704
If discount was appplied to sale order line and user applied global discount, it would have been calculated based on unsdicounted amount resulting in too high global discount as global discount should be calculated based on price after line discount. opw-4349320 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-
Original PR description
If discount was appplied to sale order line and user applied global discount, it would have been calculated based on unsdicounted amount resulting in too high global discount as global discount should be calculated based on price after line discount. opw-4349320 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#191211
This commit fixes two pivot tests failing randomly by ensuring that we wait for the download to be completed before ending the test or asserting the steps. Runbot error-134572 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#198313 Forward-Port-Of: odoo/odoo#198098
Original PR description
This commit fixes two pivot tests failing randomly by ensuring that we wait for the download to be completed before ending the test or asserting the steps. Runbot error-134572 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#198313 Forward-Port-Of: odoo/odoo#198098
In the context of grouping records on a Many2Many field (e.g. tags of tasks) in the list view, it's possible to select the same record multiple times. In such case, when modifying the selected records, there could be duplicated ids in the arguments of the different RPCs (write, unlink, call). Processing the same record multiple times in backend could cause unexpected issues. So in this PR, we filter out the duplicated records ids before each call, to work with a clean recordset in backend.
Original PR description
In the context of grouping records on a Many2Many field (e.g. tags of tasks) in the list view, it's possible to select the same record multiple times. In such case, when modifying the selected records, there could be duplicated ids in the arguments of the different RPCs (write, unlink, call). Processing the same record multiple times in backend could cause unexpected issues. So in this PR, we filter out the duplicated records ids before each call, to work with a clean recordset in backend. version-17.4 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197622 Forward-Port-Of: odoo/odoo#195224
When the chat windows overlap the document action buttons, the buttons are floating on top of the chatwindow. This happens because chat window was lower than document actions, which uses `$zindex-dropdown` (`z-index: 1000`). This commit fixes the issue by putting chat window above `$zindex-dropdown`. before/after:  . This commit fixes the issue by putting chat window above `$zindex-dropdown`. before/after:   --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198362
Consider a recordset of new records, and a loop like ```py for record in records: for line in record.line_ids: line.value ``` The implementation of `record.line_ids` does not actually prefetch all `records`. It actually fetches the field on the records' origin (their corresponding real records), but only assigns the current new record in cache. As the prefetching relies on the cached values of `line_ids`, the prefetching mechanism is actually broken on `line`. The fix cons
Original PR description
Consider a recordset of new records, and a loop like
```py
for record in records:
for line in record.line_ids:
line.value
```
The implementation of `record.line_ids` does not actually prefetch all `records`. It actually fetches the field on the records' origin (their corresponding real records), but only assigns the current new record in cache. As the prefetching relies on the cached values of `line_ids`, the prefetching mechanism is actually broken on `line`.
The fix consists in assigning all the records to prefetch in this case. This does not add unexpected prefetching, since the origin records are prefetched as one batch anyway.
Forward-Port-Of: odoo/odoo#198202
Forward-Port-Of: odoo/odoo#198124**Behavior before PR:** When user edits link and inserts 3 or more digits, link url gets converted to telephone url. This happens because in sanitize.js `deduceURLfromText` method converts url to telephone url if label matches the regex. **Behavior after PR:** Now, inserting 3 or more digits will not convert existing url to telephone url directly. If current link is telephone url or label starts with `"tel:"` prefix then url will get converted to telephone url if label matches the `PHO
Original PR description
**Behavior before PR:** When user edits link and inserts 3 or more digits, link url gets converted to telephone url. This happens because in sanitize.js `deduceURLfromText` method converts url to telephone url if label matches the regex. **Behavior after PR:** Now, inserting 3 or more digits will not convert existing url to telephone url directly. If current link is telephone url or label starts with `"tel:"` prefix then url will get converted to telephone url if label matches the `PHONE_REGEX`. task-4173806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197701 Forward-Port-Of: odoo/odoo#193420
Before this PR, the chat bot would continue even after forwarding an operator to the visitor when the step contained a message. Steps to reproduce: - Create a chat bot script with three steps: "text", "free_input_single", "fw_operator" with a message set. - Start the bot as a visitor, the operator is correctly added to the channel but the input is not available, the conversation is considered as ended. This is due to a race conditions when processing the notifications coming on the
Original PR description
Before this PR, the chat bot would continue even after forwarding an operator to the visitor when the step contained a message. Steps to reproduce: - Create a chat bot script with three steps:…
Before this PR, the chat bot would continue even after forwarding an operator to the visitor when the step contained a message. Steps to reproduce: - Create a chat bot script with three steps: "text", "free_input_single", "fw_operator" with a message set. - Start the bot as a visitor, the operator is correctly added to the channel but the input is not available, the conversation is considered as ended. This is due to a race conditions when processing the notifications coming on the bus. When the message is posted, the operator is not yet added, this information is sent on the bus. When the operator is added, another payload is sent on the bus informing an operator was found. However, the processing of the message notification is delayed and comes after the processing of the newest information, leading to an incorrect state. To solve this issue, ensure insertions are made immediately in the new message handler and send updated data on the bus to ensure the state is correct. This PR also fixes identifying fields issue wiht chat bot steps (step is identified by script step and message not channel. opw-4514479 Forward-Port-Of: odoo/odoo#196584
Steps to reproduce the bug: - Ceate a product - add a new attribute with "variant creation mode" = "Dynamic" - create a BoM for this product - make sure to add an operation in the operational lines of the bom - Click on the BoM smart button then BoM overview smart button Problem: Traceback is raise, because in the BoM overview it creates a BoM report, and it adds the operational lines(operations) to the report, some operations are skipped based on the function `_match_all_variant_v
Original PR description
Steps to reproduce the bug: - Ceate a product - add a new attribute with "variant creation mode" = "Dynamic" - create a BoM for this product - make sure to add an operation in the operational lines…
Steps to reproduce the bug: - Ceate a product - add a new attribute with "variant creation mode" = "Dynamic" - create a BoM for this product - make sure to add an operation in the operational lines of the bom - Click on the BoM smart button then BoM overview smart button Problem: Traceback is raise, because in the BoM overview it creates a BoM report, and it adds the operational lines(operations) to the report, some operations are skipped based on the function `_match_all_variant_values` that checks if the product has all the variant values. This function expects a product to run on, but in case of dynamic attribute a product will only be created if it is included in a sales order, hence the product is empty and the function raise the exception. Since the BoM report is for the product variants, then we can skip the operational line if no product is used in the BoM, and hence the `_match_all_variant_values` won't be called over empty product. opw-4518723 **Possible approaches for the Issue**: 1- Change the product variable in the bom object in the _get_bom_data function to be the product.template instead of the concrete product, this will affect many other functions in the generating of the bom report as **_get_resupply_route_info** function that calls **_get_rules_from_location** which is not a function on the 'product.template' model. Considering that approach requires anticipating the case of having the product.template in the bom in all the sections in the bom report. 2- Keep the porduct in the bom object empty one since we don't have with dynamic attributes. And we just skip operational lines if the porduct is empty so the **_match_all_variant_values** is not called. [**IMPLEMENTED**] (This change doesn't require more changes as everything will be still working with the expected model type 'product.product' but the operations and other data will be empty in the report which make sense because they are variant related ) Current behavior before PR: the app show error whenever a BoM overview smart button is clicked for a BoM of a product with dynamic attribute variants Desired behavior after PR is merged: The BoM overview report should be shown normally with no problems. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196264
This commit will add a protection for the removal of bank and cash accounts. task: 4392444 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197065 Forward-Port-Of: odoo/odoo#190529
Original PR description
This commit will add a protection for the removal of bank and cash accounts. task: 4392444 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197065 Forward-Port-Of: odoo/odoo#190529
Currently, an exception is raised when evaluating multiple records, where some records are complete and correct while others contain errors. error: ```ValueError KeyError(account.move(43,)) while evaluating 'if records:\n action = records.action_l10n_my_edi_send_invoice()' ``` [1]- https://github.com/odoo/odoo/blob/8eacfdcc2b65c62848d7939121c64928b76a80ed/addons/l10n_my_edi_extended/models/account_move.py#L181 [2]- https://github.com/odoo/odoo/blob/8eacfdcc2b65c62848d79391
Original PR description
Currently, an exception is raised when evaluating multiple records, where some records are complete and correct while others contain errors. error: ```ValueError KeyError(account.move(43,)) while evaluating 'if records:\n action = records.action_l10n_my_edi_send_invoice()' ``` [1]- https://github.com/odoo/odoo/blob/8eacfdcc2b65c62848d7939121c64928b76a80ed/addons/l10n_my_edi_extended/models/account_move.py#L181 [2]- https://github.com/odoo/odoo/blob/8eacfdcc2b65c62848d7939121c64928b76a80ed/addons/l10n_my_edi_extended/models/account_move.py#L153 This commit fixes the issue by filtering only those records that have errors during evaluation, and I have added a test for this issue. sentry - 6298401222 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197860
Backport of odoo/odoo#190450 Odoo 18 introduced a new horizon concept for reordering rules, but it lacks persistence and usability. The horizon value resets when navigating away from the replenishment dashboard, affecting both usability and automatic reordering functionality: 1. Users must manually reset the horizon after consulting other views, disrupting workflows. 2. The horizon fails as a replacement for the old `visibility_days` parameter, rendering automatic reordering unreliable.
Original PR description
Backport of odoo/odoo#190450 Odoo 18 introduced a new horizon concept for reordering rules, but it lacks persistence and usability. The horizon value resets when navigating away from the…
Backport of odoo/odoo#190450 Odoo 18 introduced a new horizon concept for reordering rules, but it lacks persistence and usability. The horizon value resets when navigating away from the replenishment dashboard, affecting both usability and automatic reordering functionality: 1. Users must manually reset the horizon after consulting other views, disrupting workflows. 2. The horizon fails as a replacement for the old `visibility_days` parameter, rendering automatic reordering unreliable. This commit reintroduces the `stock.visibility_days` system parameter: - Acts as the default horizon when no custom value is set or after navigating away. - Ensures consistency for automatic reordering rules in the back-end. - Defaults to 0, aligning with prior behavior. This approach prevents arbitrary horizon changes by users from persisting globally, while maintaining a manageable and reliable workflow for all use cases. Task 4346100 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192897
Since the fuzzy search has been removed, it is no longer necessary to exclusively display only exact match results. This commit updates the search functionality to adopt and return all relevant search results, ensuring consistency with the new behavior. opw-4535250 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196990
Original PR description
Since the fuzzy search has been removed, it is no longer necessary to exclusively display only exact match results. This commit updates the search functionality to adopt and return all relevant search results, ensuring consistency with the new behavior. opw-4535250 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196990
Steps to Reproduce: - Open POS restaurant. - Select a table. - Order some food. - Return to the floor plan. - Select the same table again. - Add a kitchen note to a line. - Click Order. - The note update is correctly sent to the preparation display. The "order" button is still displayed and the line with the note is still marked as “changed”. Forward-Port-Of: odoo/odoo#198094
Original PR description
Steps to Reproduce: - Open POS restaurant. - Select a table. - Order some food. - Return to the floor plan. - Select the same table again. - Add a kitchen note to a line. - Click Order. - The note update is correctly sent to the preparation display. The "order" button is still displayed and the line with the note is still marked as “changed”. Forward-Port-Of: odoo/odoo#198094
There is an inconsistency in the product description during 3-step incoming shipments. How to reproduce the issue: - Enable three-step incoming shipments. - Create a product with a description for receipts (e.g., 'receipt') and a different description for internal transfers (e.g., 'transfer'). - Create a receipt with the product, validate it, and open the corresponding picking for the internal transfer. The move_line description_picking is taken from the receipt description instea
Original PR description
There is an inconsistency in the product description during 3-step incoming shipments. How to reproduce the issue: - Enable three-step incoming shipments. - Create a product with a description for receipts (e.g., 'receipt') and a different description for internal transfers (e.g., 'transfer'). - Create a receipt with the product, validate it, and open the corresponding picking for the internal transfer. The move_line description_picking is taken from the receipt description instead of the internal transfer description (it shows 'receipt' instead of 'transfer'). opw-4406582 PR with very similar issue: https://github.com/odoo/enterprise/pull/77283 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197834 Forward-Port-Of: odoo/odoo#193996
When message content is not markup(), it will not render its content as HTML but as text when using t-out. This case was not taken into account when manually processing the content, leading to incorrectly detecting links or other features within purely text content. Those are now properly ignored. From https://github.com/odoo/odoo/pull/190461 Forward-Port-Of: odoo/odoo#198130 Forward-Port-Of: odoo/odoo#197343
Original PR description
When message content is not markup(), it will not render its content as HTML but as text when using t-out. This case was not taken into account when manually processing the content, leading to incorrectly detecting links or other features within purely text content. Those are now properly ignored. From https://github.com/odoo/odoo/pull/190461 Forward-Port-Of: odoo/odoo#198130 Forward-Port-Of: odoo/odoo#197343
In this commit, we simplify the macro API by removing onTimeout() and keeping only onError(). Timeout is ultimately just one type of error that can happen in macro.js. 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#198170
Original PR description
In this commit, we simplify the macro API by removing onTimeout() and keeping only onError(). Timeout is ultimately just one type of error that can happen in macro.js. 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#198170
Issue Before This Commit: ----------------------------------------------- - Purchase tab and checkbox is visible in the product form without installing Purchase. Steps to Produce: ----------------------------------------------- => Purchase checkbox Problem: Purchase checkbox is always visible in the product form which is incorrect. => Purchase tab 1. Install Sales. 2. On Unit and Measure. Problem: Now Purchase tab is visible in the product form without installing Purchase which is
Original PR description
Issue Before This Commit: ----------------------------------------------- - Purchase tab and checkbox is visible in the product form without installing Purchase. Steps to Produce: ----------------------------------------------- => Purchase checkbox Problem: Purchase checkbox is always visible in the product form which is incorrect. => Purchase tab 1. Install Sales. 2. On Unit and Measure. Problem: Now Purchase tab is visible in the product form without installing Purchase which is incorrect. With this commit: ----------------------------------------------- - Purchase tab and checkbox is visible in the product form only after installing Purchase. Task-id: 4391349 Forward-Port-Of: odoo/odoo#190610
## Versions: 18.0+ ## Issue: Clicking on the `Add to Cart` button displays an error message if configured on a product having variants. The issue seems to come from the following PR: https://github.com/odoo/odoo/pull/187556 ## Steps to reproduce: Go to the `Website` app on home page in edit mode; From the `BLOCKS`'s `Inner content` widgets add a `Add to Cart` button anywhere on the page; Select the button to configure it; Select a product with variants as `Product` (e.g. `Acoustic B
Original PR description
## Versions: 18.0+ ## Issue: Clicking on the `Add to Cart` button displays an error message if configured on a product having variants. The issue seems to come from the following PR: https://github.com/odoo/odoo/pull/187556 ## Steps to reproduce: Go to the `Website` app on home page in edit mode; From the `BLOCKS`'s `Inner content` widgets add a `Add to Cart` button anywhere on the page; Select the button to configure it; Select a product with variants as `Product` (e.g. `Acoustic Bloc Screens`); *Optional: choose a variant too;* Save; Click the added `Add to Cart` button. ## Cause: The code tries to access an inexistant form. opw-4573435 opw-4577757 opw-4561122 opw-4548344 opw-4567354 Forward-Port-Of: odoo/odoo#198276
**Current behavior:** Trying to create an MO on mobile which has work orders is not possible. **Expected behavior:** Can create. **Steps to reproduce:** 1. Install `mrp` with demo data 2. Login, in dev tools change viewport size to iPhone SE (a small screen) 3. Open Inventory -> Manufacturings 4. Click `New`, change product to stool (any variant) 5. Try to save -> `ValidationError` **Cause of the issue:** `workcenter_id` and `product_uom_id` have been removed from the k
Original PR description
**Current behavior:** Trying to create an MO on mobile which has work orders is not possible. **Expected behavior:** Can create. **Steps to reproduce:** 1. Install `mrp` with demo data 2. Login, in dev tools change viewport size to iPhone SE (a small screen) 3. Open Inventory -> Manufacturings 4. Click `New`, change product to stool (any variant) 5. Try to save -> `ValidationError` **Cause of the issue:** `workcenter_id` and `product_uom_id` have been removed from the kanban view in commit: b1ceec4c which is used on mobile, meaning that these required fields are not in the save vals returned to the server in the CREATE tuple. **Fix:** Add them back to the kanban view. opw-4440060 Forward-Port-Of: odoo/odoo#197889
When calling preserve_existing_tags_on_taxes(), the module name is passed as argument, cf https://github.com/odoo/odoo/blob/18.0/addons/account/models/chart_template.py#L38. The module name is now l10n_fr_account instead of l10n_fr (account.account.tag are now defined in l10n_fr_account, cf https://github.com/odoo/odoo/blob/18.0/addons/l10n_fr_account/data/account_chart_template_data.xml#L3). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forwar
Original PR description
When calling preserve_existing_tags_on_taxes(), the module name is passed as argument, cf https://github.com/odoo/odoo/blob/18.0/addons/account/models/chart_template.py#L38. The module name is now l10n_fr_account instead of l10n_fr (account.account.tag are now defined in l10n_fr_account, cf https://github.com/odoo/odoo/blob/18.0/addons/l10n_fr_account/data/account_chart_template_data.xml#L3). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198119
Steps to reproduce: - Create a new blank spreadsheet in Documens - Hit the Share button - Open the sharing link in a incognito window => it says "Frozen and copied on ..." even though it's not frozen at all See Enterprise PR Task-4583953 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/odo
Original PR description
Steps to reproduce: - Create a new blank spreadsheet in Documens - Hit the Share button - Open the sharing link in a incognito window => it says "Frozen and copied on ..." even though it's not frozen at all See Enterprise PR Task-4583953 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#198015
**Current behavior:** For `real_time`, `avco` prod: When posting the bill of a reception which originated from a PO with a foreign currency, if a return for the receipt was generated as well as a return for that return, there will be an extraneous SVL created which illogically affects the product's `standard_price` (product value has increased from nowhere). **Expected behavior:** The product cost prior to posting the bill and after posting the bill is equal. **Steps to reproduce:** 1.
Original PR description
**Current behavior:** For `real_time`, `avco` prod: When posting the bill of a reception which originated from a PO with a foreign currency, if a return for the receipt was generated as well as a…
**Current behavior:** For `real_time`, `avco` prod: When posting the bill of a reception which originated from a PO with a foreign currency, if a return for the receipt was generated as well as a return for that return, there will be an extraneous SVL created which illogically affects the product's `standard_price` (product value has increased from nowhere). **Expected behavior:** The product cost prior to posting the bill and after posting the bill is equal. **Steps to reproduce:** 1. Create an `avco` + `real_time` costing/valuated productA 2. Activate 2 additional currencies + give them unique exchange rates 3. Create a purchase order in the first of the two additional currencies, for `N` units of productA at $`price_unit` 4. Confirm the PO -> receive the product 5. Create another purchase order in the second of the two currencies, again `N` units @ $`price_unit` 6. Confirm + receive, then generate a return for this reception 7. Generate a return for the return of step 6 8. Note the current `standar_price` of ProductA 9. For the second purchase order (the one with the returns) create the vendor bill 10. Observe that the `standard_price` of ProductA has increased without any legitimate basis **Cause of the issue:** In `_generate_price_difference_vals`: https://github.com/odoo/odoo/blob/55658e7f43375d7e1af07293e2cd9d1cc4b33883/addons/purchase_stock/models/account_move_line.py#L307-L314 We operate with the assumption that, because we are in a return of a return, any existing pdiff will have already been compensated for- so we take the POL price unit at face value to compare with the AML price unit. But, in case the POL and AML are in different currencies, this will fail to prevent a pdiff SVL from being created. **Fix:** Convert the purchase line's returned price unit to the currency used by the layer for which we are finding the pdiff. opw-4334372 Forward-Port-Of: odoo/odoo#198129 Forward-Port-Of: odoo/odoo#196222
**Problem**: When applying formatting (e.g., Bold) to a selection that includes a link, isZwnbsp characters inside the DOM cause incorrect formatting state detection. isZwnbsp nodes are not formatted, but they are still considered when checking the selection state. **Solution**: Modify `isSelectionFormat` to check only visible text nodes. isZwnbsp characters should be ignored as they do not get formatted. Also when split we remove `FEFF` chars from text node which in case the node has
Original PR description
**Problem**: When applying formatting (e.g., Bold) to a selection that includes a link, isZwnbsp characters inside the DOM cause incorrect formatting state detection. isZwnbsp nodes are not formatted, but they are still considered when checking the selection state. **Solution**: Modify `isSelectionFormat` to check only visible text nodes. isZwnbsp characters should be ignored as they do not get formatted. Also when split we remove `FEFF` chars from text node which in case the node has only one `FEFF` will become an empty node We should exludes those nodes from the check too. **Steps to Reproduce**: 1. Type a link followed by a space. 2. Select all the text. 3. Apply "Bold." 4. The "Bold" button in the toolbar remains inactive incorrectly. opw-4555595 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196828
Currently, a traceback is occurring when the user tries to click the `plans` smart button in the hr department record. To reproduce this issue: 1) Install hr 2) Open any hr department record 3) Click the `Plans` smart button Error:- ``` ValueError: malformed node or string on line 1: <ast.Name object at 0x7333bacc> ``` This error was occurring because of the latest changes from the below commit, https://github.com/odoo/odoo/pull/196430/commits/ec4991330224784571d850fb87ee7940a07
Original PR description
Currently, a traceback is occurring when the user tries to click the `plans` smart button in the hr department record. To reproduce this issue: 1) Install hr 2) Open any hr department record 3) Click…
Currently, a traceback is occurring when the user tries to click the `plans` smart button in the hr department record. To reproduce this issue: 1) Install hr 2) Open any hr department record 3) Click the `Plans` smart button Error:- ``` ValueError: malformed node or string on line 1: <ast.Name object at 0x7333bacc> ``` This error was occurring because of the latest changes from the below commit, https://github.com/odoo/odoo/pull/196430/commits/ec4991330224784571d850fb87ee7940a071080a We used `literal_eval()` from the below line to evaluate the domain in action. Which contains `allowed_company_ids`. This leads to the above error while evaluating in `literal_eval()`. https://github.com/odoo/odoo/blob/b070f9a4aa179799e3412d18b8faba07349bbf7b/addons/hr/models/hr_department.py#L147-L153 The domain in the action was modified from the below commit recently, https://github.com/odoo/odoo/pull/193572/commits/c2243abca397ab6622ec85e6fe6adbfef0d7c47b We can resolve this issue by replacing the `allowed_company_ids` by accessing the value of `allowed_company_ids` from context. sentry-6285774985 Forward-Port-Of: odoo/odoo#197308
Before this commit: When a user in Odoo uses the dialog box to send a message to a WhatsApp number and inserts a line break with "Shift+Enter," it creates a <br> tag. In the WhatsApp module, these tags are stripped, causing the word before and the word after the <br> tag to be joined together without a space or a line break to separate them. How to reproduce: Send a message via the dialog box to a WhatsApp number and insert a line break using Shift+Enter. On the phone, the line break will
Original PR description
Before this commit: When a user in Odoo uses the dialog box to send a message to a WhatsApp number and inserts a line break with "Shift+Enter," it creates a <br> tag. In the WhatsApp module, these tags are stripped, causing the word before and the word after the <br> tag to be joined together without a space or a line break to separate them. How to reproduce: Send a message via the dialog box to a WhatsApp number and insert a line break using Shift+Enter. On the phone, the line break will not be present anymore because the tag <br> is removed with the other tags. After this commit: the line break is there and the words are not join together anymore. OPW-4079729 Forward-Port-Of: odoo/enterprise#78307 Forward-Port-Of: odoo/enterprise#73727
**Steps to reproduce:** - Use the `NL Company`; - Go to `External Identifiers` (via `Settings / Technical / Sequence & Identifiers`): - Remove `l10n_nl.tax_report_rub_3bg_tag` and/or `l10n_nl.tax_report_rub_3bg_tag` identifiers;  - Try to access `EC Sales List` (via `Accounting / Reporting / Statement Reports`). ___ **Issue:** Can't access `EC Sales List` o
Original PR description
**Steps to reproduce:** - Use the `NL Company`; - Go to `External Identifiers` (via `Settings / Technical / Sequence & Identifiers`): - Remove `l10n_nl.tax_report_rub_3bg_tag` and/or…
**Steps to reproduce:**
- Use the `NL Company`;
- Go to `External Identifiers` (via `Settings / Technical / Sequence & Identifiers`):
- Remove `l10n_nl.tax_report_rub_3bg_tag` and/or `l10n_nl.tax_report_rub_3bg_tag` identifiers;
- Try to access `EC Sales List` (via `Accounting / Reporting / Statement Reports`).
___
**Issue:**
Can't access `EC Sales List` of the Dutch company after deleting any or both of the `l10n_nl.tax_report_rub_3bg_tag` and/or `l10n_nl.tax_report_rub_3bg_tag` identifiers.
___
**Expected:**
Users should be able to access `EC Sales List` even when an identifier is deleted as there is a fallback.
___
**Cause:**
The fallback doesn't refer to the good tax options.
https://github.com/odoo/enterprise/blob/b2368558afdf922fdf04bdcfa8a98b4e690ddccd/l10n_nl_intrastat/models/account_sales_report.py#L82-L84
___
**Fix:**
Adapt the fallback references' module for retrieval as done for testing in: https://github.com/odoo/enterprise/blob/b2368558afdf922fdf04bdcfa8a98b4e690ddccd/l10n_nl_intrastat/tests/test_sales_report.py#L22-L24
___
opw-4425376
Forward-Port-Of: odoo/enterprise#78032
Forward-Port-Of: odoo/enterprise#76366… rec widget The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled. Instead, let's use 'no_exchange_difference_no_recursive'. See the test in this commit. task
Original PR description
… rec widget The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled. Instead, let's use 'no_exchange_difference_no_recursive'. See the test in this commit. task-id: 4531511 Forward-Port-Of: odoo/enterprise#78538 Forward-Port-Of: odoo/enterprise#78205
Steps to reproduce the bug: - Create two storable products “P1” and “P2”: - Tracked by Serial Number - Create a quality control point: - Operation: Receipt - Control per: Quantity - Create a receipt: - 10 units of P1 - 10 units of P2 - Mark it as "To Do." - Open the detailed operation of P1: - Assign two SNs: - SN1 - SN2 - Save. - The “Quantity” field of the P1 move is updated to 2. - Mark the move of P1 as "Picked." - Validate the receipt. - The backorde
Original PR description
Steps to reproduce the bug:
- Create two storable products “P1” and “P2”:
- Tracked by Serial Number
- Create a quality control point:
- Operation: Receipt
- Control per: Quantity
- Create a receipt:
- 10 units of P1
- 10 units of P2
- Mark it as "To Do."
- Open the detailed operation of P1:
- Assign two SNs: - SN1 - SN2 - Save.
- The “Quantity” field of the P1 move is updated to 2.
- Mark the move of P1 as "Picked."
- Validate the receipt.
- The backorder wizard is triggered → Validate it.
Problem:
A wizard to process the quality check is triggered, but 12 quality checks (2 for P1 and 10 for P2) are loaded instead of only 2 for P1.
Expected Behavior:
Quality checks should only be triggered for picked moves
opw-4442564
Forward-Port-Of: odoo/enterprise#79066
Forward-Port-Of: odoo/enterprise#76478Different countries have different attendance rules and therefore customizing the attendance entries might be relevant. In order to be able to properly filter we introduce a domain retrieval method which can be properly inherited. Info: @wt-io-it Forward-Port-Of: odoo/enterprise#78402 Forward-Port-Of: odoo/enterprise#78195
Original PR description
Different countries have different attendance rules and therefore customizing the attendance entries might be relevant. In order to be able to properly filter we introduce a domain retrieval method which can be properly inherited. Info: @wt-io-it Forward-Port-Of: odoo/enterprise#78402 Forward-Port-Of: odoo/enterprise#78195
Description of the issue ======================== The initial issue was, when tracked product lines are grouped by product in batch ("Group batch lines" parameter checked in the picking type config), the sublines weren't displayed. This issue was caused by the way we choose to display or not sublines. For a tracked product, we don't display them if reserved lot/serial is hidden (picking type config) and if there is no qty done. That said, that didn't take in consideration the grouping by p
Original PR description
Description of the issue ======================== The initial issue was, when tracked product lines are grouped by product in batch ("Group batch lines" parameter checked in the picking type config),…
Description of the issue
========================
The initial issue was, when tracked product lines are grouped by product in batch ("Group batch lines" parameter checked in the picking type config), the sublines weren't displayed.
This issue was caused by the way we choose to display or not sublines. For a tracked product, we don't display them if reserved lot/serial is hidden (picking type config) and if there is no qty done.
That said, that didn't take in consideration the grouping by product where lines for different pickings are grouped together.
In this case, it's better to show the qty demand anyway to know how many quantity needs to be processed for each picking.
Once this issue is fixed, a second issue appears.
Imagine you have this following case:
- 1 line for lot product (0/4 qty) for receipt 1;
- 1 line for lot product (0/4 qty) for receipt 2.
- In batch, these lines are grouped because they share the same product.
Now, let's say we do the following process:
1. Scan the lot product -> The grouped line is selected;
2. Scan lot01 two times -> receipt 1 line is now 2/4 qty with lot01;
3. Scan lot02 -> receipt 2 line is now 1/4 with lot02.
The point 3. where is the issue happens. Usually, when we scan a lot, we check if the line is completed or not by checking its parent line's quantity. Here, the parent line is the batch grouped line and should not work exactly like that, because by checking this line as the parent of every sublines means we can't know if a particular picking need is fulfilled or not.
How to reproduce
================
- Inventory > Configuration > Operations Types > Barcode App:
- Uncheck "Show reserved lot/SN";
- Check "Group batch lines".
- Create two receipts for the same tracked by lot product;
- Create a batch for this receipt;
- Open the batch in the Barcode app -> You can see there is a line for this product with the total quantity but when clicking on the button to display sublines, the sublines are not shown.
Fix
===
For the first issue, we simply added a condition for `stock.picking.batch` to adapt to this case.
For the second issue, the group by tracked product inside a single picking and the group by product inside a batch are not the same and use a different key.
The first kind of group uses the key `parentLine` and the second one use the key `batchParentLine`. When we want the parent line of a subline, we will always refer to the `parentLine`. But in the interface, if this parent line is itself inside a `batchParentLine`, the `parentLine` won't be displayed, only the batch parent line.
That way, the user still has all lines for a same product grouped together under a single parent line, but to know if a need if fulfilled,
we still check on the parent line limited to a single picking.
[opw-4291149](https://www.odoo.com/odoo/project/49/tasks/4291149)
Forward-Port-Of: odoo/enterprise#79516before this commit: Shipping methods are missing default vlaue of shipping functionalities, which leads to some methods getting filtered out incorrectly. After this commit: Default value of the shipping functionalities are fetched and checked to select the correct shipping method based on user filters. opw-4167675 Forward-Port-Of: odoo/enterprise#79518
Original PR description
before this commit: Shipping methods are missing default vlaue of shipping functionalities, which leads to some methods getting filtered out incorrectly. After this commit: Default value of the shipping functionalities are fetched and checked to select the correct shipping method based on user filters. opw-4167675 Forward-Port-Of: odoo/enterprise#79518
Before this commit, when we clicked on the activity send tax report. It would result by opening the report at the current date instead of the date of the move. After this commit, the expected behaviour was to open the move of the tax closing. task-4583606 Forward-Port-Of: odoo/enterprise#79511
Original PR description
Before this commit, when we clicked on the activity send tax report. It would result by opening the report at the current date instead of the date of the move. After this commit, the expected behaviour was to open the move of the tax closing. task-4583606 Forward-Port-Of: odoo/enterprise#79511
This commit fixes a cohort test failing randomly by ensuring that we wait for the download to be completed before ending the test or asserting the steps. Runbot error-134572 Forward-Port-Of: odoo/enterprise#79680 Forward-Port-Of: odoo/enterprise#79555
Original PR description
This commit fixes a cohort test failing randomly by ensuring that we wait for the download to be completed before ending the test or asserting the steps. Runbot error-134572 Forward-Port-Of: odoo/enterprise#79680 Forward-Port-Of: odoo/enterprise#79555
Since the employees see in their 'My Profile' tab the documents on which they are 'Contact'. We need to set them as contact when generating declaration and not only 'read' access. Forward-Port-Of: odoo/enterprise#79689
Original PR description
Since the employees see in their 'My Profile' tab the documents on which they are 'Contact'. We need to set them as contact when generating declaration and not only 'read' access. Forward-Port-Of: odoo/enterprise#79689
Test that when creating a receipt or internal transfer using the barcode app, the description_picking field of the move_line is not empty. Steps to reproduce the issue: - Create a product with a description for receipts (e.g., 'receipt'). - In the barcode app, create a new receipt and add the product (leave it in draft). - In the inventory app, check the corresponding receipt. - The move_line has no description_picking, even though the product has one. community: https://github.com/o
Original PR description
Test that when creating a receipt or internal transfer using the barcode app, the description_picking field of the move_line is not empty. Steps to reproduce the issue: - Create a product with a description for receipts (e.g., 'receipt'). - In the barcode app, create a new receipt and add the product (leave it in draft). - In the inventory app, check the corresponding receipt. - The move_line has no description_picking, even though the product has one. community: https://github.com/odoo/odoo/pull/193996/files opw-4406582 Forward-Port-Of: odoo/enterprise#79415 Forward-Port-Of: odoo/enterprise#79349
With this commit ================ - Renamed the return value of the getName method to `Inventory Count` for consistency with the Inventory Count button on the main page. - Rephrased toaster message for Inventory Adjustment Validation. - Updated the domain in the product form of Inventory Count to include `storable/inventory tracked` products. Task: [4458119](https://www.odoo.com/odoo/my-tasks/4458119) Forward-Port-Of: odoo/enterprise#79154
Original PR description
With this commit ================ - Renamed the return value of the getName method to `Inventory Count` for consistency with the Inventory Count button on the main page. - Rephrased toaster message for Inventory Adjustment Validation. - Updated the domain in the product form of Inventory Count to include `storable/inventory tracked` products. Task: [4458119](https://www.odoo.com/odoo/my-tasks/4458119) Forward-Port-Of: odoo/enterprise#79154
We use a couple manual SELECT queries in marketing_automation. However these do not flush before querying, meaning the result is potentially wrong if there was a change to the queried tables since the last flush. This is not too noticeable under regular use as only non-store computed fields hold statistics. However it does make the method innacurate in some cases. Notably tests need to flush manually. We now flush properly, as should have been done. As is done for the whatsapp ove
Original PR description
We use a couple manual SELECT queries in marketing_automation. However these do not flush before querying, meaning the result is potentially wrong if there was a change to the queried tables since the last flush. This is not too noticeable under regular use as only non-store computed fields hold statistics. However it does make the method innacurate in some cases. Notably tests need to flush manually. We now flush properly, as should have been done. As is done for the whatsapp override from 18.0 onwards. task-4589525 Forward-Port-Of: odoo/enterprise#79673
Since commit [6f06420e4a9443c52dc0cb427f8f55eb4aecabce](https://github.com/odoo/odoo/commit/6f06420e4a9443c52dc0cb427f8f55eb4aecabce), fields used in expressions in a view are automatically added to the view if not present originally. This allows all fields to be available in the expression editor for modifiers, which this commit is enabling. task-4481934 Forward-Port-Of: odoo/enterprise#79672
Original PR description
Since commit [6f06420e4a9443c52dc0cb427f8f55eb4aecabce](https://github.com/odoo/odoo/commit/6f06420e4a9443c52dc0cb427f8f55eb4aecabce), fields used in expressions in a view are automatically added to the view if not present originally. This allows all fields to be available in the expression editor for modifiers, which this commit is enabling. task-4481934 Forward-Port-Of: odoo/enterprise#79672
An issue may occur where moves are unbalanced when FEC file lines contain a device with an imprecise rounding factor. Steps to reproduce: - Create or use a currency with rounding = 1. - Add rounding to debit or credit in a FEC file, ensuring the rounded unit amount is not equal; for example, two debit lines at 100.5 and one credit line at 201 (see example in test). - In the Idevise column of the file, use the name of the created device. - Attempt to import the file. An error will occur
Original PR description
An issue may occur where moves are unbalanced when FEC file lines contain a device with an imprecise rounding factor. Steps to reproduce: - Create or use a currency with rounding = 1. - Add rounding to debit or credit in a FEC file, ensuring the rounded unit amount is not equal; for example, two debit lines at 100.5 and one credit line at 201 (see example in test). - In the Idevise column of the file, use the name of the created device. - Attempt to import the file. An error will occur: Moves report incorrect balances: Move with name '<name>' has a balance of 1.00. The issue arises because the created device is used to round the amount instead of the company's device, resulting in 100.5 being rounded to 100, hence the two line of 100 no longer balances with 201. opw-4397836 Forward-Port-Of: odoo/enterprise#79698 Forward-Port-Of: odoo/enterprise#76932
Users managing loans can set the flag Skip Until Date to skip the first entries. However skipped loan lines won't create any move and this create issues with assignment of the correct state when load should be closed Steps to reproduce - Create a loans as follows: - Name: any - Amount Borrowed: 20,000.00 - Interests: 107.87 - 01/01/2024 - Duration: 12 months - [Loan Settings] Skip Until: 10/31/2024 - Save, compute sheet and confirm Issues: - Once confirmed it doesn'
Original PR description
Users managing loans can set the flag Skip Until Date to skip the first entries. However skipped loan lines won't create any move and this create issues with assignment of the correct state when load should be closed Steps to reproduce - Create a loans as follows: - Name: any - Amount Borrowed: 20,000.00 - Interests: 107.87 - 01/01/2024 - Duration: 12 months - [Loan Settings] Skip Until: 10/31/2024 - Save, compute sheet and confirm Issues: - Once confirmed it doesn't change state from "draft" - If we click once again "Confirm" we will get a traceback error opw-4476981 Forward-Port-Of: odoo/enterprise#79285
Steps to reproduce: - Create a new blank spreadsheet in Documens - Hit the Share button - Open the sharing link in a incognito window => it says "Frozen and copied on ..." even though it's not frozen at all See Community PR Task-4583953 Forward-Port-Of: odoo/enterprise#79520
Original PR description
Steps to reproduce: - Create a new blank spreadsheet in Documens - Hit the Share button - Open the sharing link in a incognito window => it says "Frozen and copied on ..." even though it's not frozen at all See Community PR Task-4583953 Forward-Port-Of: odoo/enterprise#79520
Currently a `ParseError` is arising when the user installs the `industry_fsm_sale_report` module after deleting `Field Service` product from the products. Steps to reproduce: --- - Install the `industry_fsm_sale` module - Delete `Field Service` from products - Now install `industry_fsm_sale_report` module Traceback: --- ``` Exception: Cannot update missing record 'industry_fsm_sale.field_service_product' ParseError: while parsing /home/odoo/src/enterprise/saas-18.1/industry_fsm_s
Original PR description
Currently a `ParseError` is arising when the user installs the `industry_fsm_sale_report` module after deleting `Field Service` product from the products.
Steps to reproduce:
---
- Install the `industry_fsm_sale` module
- Delete `Field Service` from products
- Now install `industry_fsm_sale_report` module
Traceback:
---
```
Exception: Cannot update missing record 'industry_fsm_sale.field_service_product'
ParseError: while parsing /home/odoo/src/enterprise/saas-18.1/industry_fsm_sale_report/data/product_product_data.xml:4, somewhere inside <record id="industry_fsm_sale.field_service_product" model="product.product">
<field name="worksheet_template_id" ref="industry_fsm_report.fsm_worksheet_template"/>
</record>
```
This commit solves the above issue by using `forcecreate="False"` to bypass record creation if it violates checks.
sentry-5731062091
Forward-Port-Of: odoo/enterprise#78988before this PR: - The income account was solely derived from the product's configuration. After this PR: - If the product’s income account is not set, we fall back to the default account defined on the POS journal. This ensures the Sales Account used in GSTR-1 computations is properly set. See: https://github.com/odoo/odoo/pull/149816 Forward-Port-Of: odoo/enterprise#79661
Original PR description
before this PR: - The income account was solely derived from the product's configuration. After this PR: - If the product’s income account is not set, we fall back to the default account defined on the POS journal. This ensures the Sales Account used in GSTR-1 computations is properly set. See: https://github.com/odoo/odoo/pull/149816 Forward-Port-Of: odoo/enterprise#79661