Tuesday, February 11, 2025
36 changes · saas-18.1
Resolved issues and error corrections
This fix prevents an error popup from appearing when staff edit a restaurant floor plan and type while adding a new floor or table. It helps keep restaurant point-of-sale setup smooth and avoids interrupting users during layout changes.
Original PR description
Check commit message for description.
Fixed an issue that could make the Discuss app crash while a call was ongoing and the sidebar showed participants. This improves reliability for users joining or viewing calls, especially when some participant details are not fully available.
Original PR description
When people were in a discuss call, the following crash may happen when discuss app is open: ``` Cannot read properties of undefined (reading 'persona') ``` This comes from template reading `channel_member.persona`, which can be undefined. Indeed, some flow may return channel member data without persona data, thus the persona is unknown (= undefined) in JS. This commit fixes the issue by taking into account persona of member that could be missing in the discuss sidebar call participant component. Task-4533395
Fixes an error that occurred when staff canceled the final remaining restaurant order. The system now safely returns users to the floor plan, helping avoid interruptions during restaurant service.
Original PR description
We check that currentOrder exist before accessing its attribute inside the function `showUnbookButton`. This was causing a traceback when canceling the last order in restaurant. After this fix, deleting the last order redirect correctly to the floorplan. Steps to reproduce : - Open "Restaurant" - Go to "Orders" - Delete all orders - For the last one (Direct sale), there is no "Delete" button in the ticket screen if the order is empty, so open it and then delete it with the action button "Cancel order" task-id: 4507062 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
Adding a work order to a manufacturing order without a selected product no longer triggers an error. The change prevents unnecessary calculations when product details are absent, improving stability during manufacturing order setup.
Original PR description
Currently, an error occurs when adding a new work order line in a manufacturing order without specifying a product. Steps to produce: - Install the `mrp` module. - Enable `Unit of measure` and `Work…
Currently, an error occurs when adding a new work order line in a manufacturing order without specifying a product. Steps to produce: - Install the `mrp` module. - Enable `Unit of measure` and `Work Orders` from the settings. - Create a new manufacturing order. - Do not specify a product in the record and attempt to add a work order. - Observe the error. Error: `AssertionError: precision_rounding must be positive, got 0.0` An error occurs when attempting to access `product_uom_id.rounding` - [1]. However, if no product is defined, the `product_uom_id` remains an empty recordset, which generates an error. [1] - https://github.com/odoo/odoo/blob/9922e570acdf695a0101a7a0c28d57a2708ea050/addons/mrp/models/mrp_workorder.py#L159 This commit resolves the issue by ensuring the product is specified, if no product is defined, the method skips the further computation to avoid errors. sentry-6236848517 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores access to the General Information section for bookkeepers viewing bank account-related records. It corrects a display issue that was hiding important details, helping finance users review account information without extra assistance.
Original PR description
The Book keeper was not able to see the General info of bank accounts and so on - The problem was that there was an xpath that overwrite the groups Task-4567218
This fixes a WinBooks import issue caused by a removed partner title field. Imports now correctly handle related contact records, reducing failures when bringing accounting data into Odoo.
Original PR description
…artner` children The `title` field was removed from `res.partner` in [this commit](https://github.com/odoo/odoo/commit/0b8bd891fad1c84607fe147a32d705917341fed7). A [previous fix](https://github.com/odoo/enterprise/commit/81338f4b417399d0636d5dfde47b46dec3a74d97) addressed the issue for the main partner record, but the `title` field was still being referenced for its `child_ids`. This commit ensures that child partners are also handled correctly. no-task
Miscellaneous changes
Steps to Reproduce: -> Drag and Drop the Facebook Snippet. -> Click on the snippet. -> Enter any random text. -> The snippet's content is editable. Solution: By adding the `o_not_editable` class to the Facebook Snippet, it prevent user's input from affecting the snippet. This PR ensures that the Facebook Snippet does not accept any user input. task-4517743 Forward-Port-Of: odoo/odoo#197195 Forward-Port-Of: odoo/odoo#195549
Original PR description
Steps to Reproduce: -> Drag and Drop the Facebook Snippet. -> Click on the snippet. -> Enter any random text. -> The snippet's content is editable. Solution: By adding the `o_not_editable` class to the Facebook Snippet, it prevent user's input from affecting the snippet. This PR ensures that the Facebook Snippet does not accept any user input. task-4517743 Forward-Port-Of: odoo/odoo#197195 Forward-Port-Of: odoo/odoo#195549
Steps to reproduce : -open settings/technical/views -search "product.template.form.inherit" -select the view with external id "point_of_sale.product_template_form_inherit" -A Yellow Warning Message should appear indicating an Access Rights Inconsistency Problem: In the product_view.xml file of the point_of_sale module, in the view named product.template.form.inherit for the field "color", the invisible condition was invisible="true". This caused an accessed right inconsistency because
Original PR description
Steps to reproduce : -open settings/technical/views -search "product.template.form.inherit" -select the view with external id "point_of_sale.product_template_form_inherit" -A Yellow Warning Message should appear indicating an Access Rights Inconsistency Problem: In the product_view.xml file of the point_of_sale module, in the view named product.template.form.inherit for the field "color", the invisible condition was invisible="true". This caused an accessed right inconsistency because the python code did not recognize true as a Boolean but looked for a field named "true" in the product.template model and didn't find any. https://github.com/odoo/odoo/blob/abf0b5f102a0bad3ed0feb8b8e967f5e3c8d2288/addons/point_of_sale/views/product_view.xml#L69 opw-4520474 Forward-Port-Of: odoo/odoo#196807
if they use import export or any automated action that write same journal then it's take new number. here assume that journal_id is only change on draft and if posted then it's raise error but not consider what is same journal_id come to write. 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#19
Original PR description
if they use import export or any automated action that write same journal then it's take new number. here assume that journal_id is only change on draft and if posted then it's raise error but not consider what is same journal_id come to write. 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#197067 Forward-Port-Of: odoo/odoo#196777
## Description of the issue/feature this PR addresses Unable to reach Kiosk mode while in debug mode due to props validation ``` Error: Invalid props for component 'kioskAttendanceApp': unknown key 'token', unknown key 'companyId', unknown key 'companyName', unknown key 'employees', unknown key 'departments', unknown key 'kioskMode', unknown key 'barcodeSource' ``` ### Steps to reproduce - Install `hr_attendance` - Open Kiosk Mode - Enable debug mode => Blank screen ## Current b
Original PR description
## Description of the issue/feature this PR addresses Unable to reach Kiosk mode while in debug mode due to props validation ``` Error: Invalid props for component 'kioskAttendanceApp': unknown key…
## Description of the issue/feature this PR addresses Unable to reach Kiosk mode while in debug mode due to props validation ``` Error: Invalid props for component 'kioskAttendanceApp': unknown key 'token', unknown key 'companyId', unknown key 'companyName', unknown key 'employees', unknown key 'departments', unknown key 'kioskMode', unknown key 'barcodeSource' ``` ### Steps to reproduce - Install `hr_attendance` - Open Kiosk Mode - Enable debug mode => Blank screen ## Current behavior before PR Before this commit, when we were in debug mode, we couldn't access Kiosk mode (white screen with message in console). This was because the props were not fully declared, and, in debug mode, we validated the props here : https://github.com/odoo/odoo/blob/c3e7ee585a58fc07c11d07677d1d64dbd357d6b7/addons/web/static/lib/owl/owl.js#L5715-L5717 As the components are only used in one place each, I've updated the props declaration to match the usage. Forward-Port-Of: odoo/odoo#195831 Forward-Port-Of: odoo/odoo#189412
Fix nondeterministic JS errors of button trying to be clicked while detected as not visible (while being there). HOOT rely on DOM mutation to check if elements visible state change or not. We suspect if the tab load fast enough the button will be considered invisible as the fading didn't started yet. The issue is nondeterministic but fail more consistently by toggling Chrome CPU to 10x, it will then fail 3/4 of the times rb-112019 Forward-Port-Of: odoo/odoo#196980
Original PR description
Fix nondeterministic JS errors of button trying to be clicked while detected as not visible (while being there). HOOT rely on DOM mutation to check if elements visible state change or not. We suspect if the tab load fast enough the button will be considered invisible as the fading didn't started yet. The issue is nondeterministic but fail more consistently by toggling Chrome CPU to 10x, it will then fail 3/4 of the times rb-112019 Forward-Port-Of: odoo/odoo#196980
Versions -------- - 16.0+ Steps ----- 1. Enable Stripe Express Checkout; 2. go to eCommerce as Public User; 3. pay via express checkout for a deliverable item; 4. in Stripe, set shipping address to somewhere in California; 5. finish payment. Issue ----- The new partner is created with its state set to Cadiz instead of California. Cause ----- When searching for a state using its code, it fetches the first matching item. The problem is that unlike country codes, state codes ar
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Enable Stripe Express Checkout; 2. go to eCommerce as Public User; 3. pay via express checkout for a deliverable item; 4. in Stripe, set shipping address to somewhere in California; 5. finish payment. Issue ----- The new partner is created with its state set to Cadiz instead of California. Cause ----- When searching for a state using its code, it fetches the first matching item. The problem is that unlike country codes, state codes aren't unique, e.g. there are 4 states that match the 'CA' code (only one of them being in the United States). Solution -------- Add `country_id` to the search domain to ensure the fetched state belongs to the relevant country. opw-4396024 Forward-Port-Of: odoo/odoo#197073 Forward-Port-Of: odoo/odoo#196428
In this commit, we fix multiple tours on step that can cause non deterministic behaviors by adding additionnal steps to ensure tour is well on the way to taking the right path. 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#197115
Original PR description
In this commit, we fix multiple tours on step that can cause non deterministic behaviors by adding additionnal steps to ensure tour is well on the way to taking the right path. 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#197115
A sales team should be assigned only to sales type moves (invoices, credit notes, ...). Currently, it is possible that some Bills get a sales team assigned. This is not ok as it will distort the reports if users analyze by sales team. It occurs when `_compute_team_id` is called on a recordset containing sales moves and other moves. Even if sales moves are correctly filtered a `self.concat` is used to set the `team_id` and it will return the concatenation of `self` with the arguments, s
Original PR description
A sales team should be assigned only to sales type moves (invoices, credit notes, ...). Currently, it is possible that some Bills get a sales team assigned. This is not ok as it will distort the reports if users analyze by sales team. It occurs when `_compute_team_id` is called on a recordset containing sales moves and other moves. Even if sales moves are correctly filtered a `self.concat` is used to set the `team_id` and it will return the concatenation of `self` with the arguments, so also the non sales moves will have the team assigned opw-4422292 Forward-Port-Of: odoo/odoo#196332 Forward-Port-Of: odoo/odoo#195645
GLN is the default that many people want to use, but that should not be the default for everybody. Instead use the real Peppol Endpoint when it's filled. We only take care of those that the schematron allows and where we know the correspondence. For the others and if the peppol fields are not filled, we still fallback on the VAT opw-4502607 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194551
Original PR description
GLN is the default that many people want to use, but that should not be the default for everybody. Instead use the real Peppol Endpoint when it's filled. We only take care of those that the schematron allows and where we know the correspondence. For the others and if the peppol fields are not filled, we still fallback on the VAT opw-4502607 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194551
The domain on the view overrides the domain on the model. As both domains are correct, this commit moves the partial domain on the view and adds it to the partial domain on the model. task-4514485 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196851
Original PR description
The domain on the view overrides the domain on the model. As both domains are correct, this commit moves the partial domain on the view and adds it to the partial domain on the model. task-4514485 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196851
Forward-Port-Of: odoo/odoo#197193 Forward-Port-Of: odoo/odoo#193528
Original PR description
Forward-Port-Of: odoo/odoo#197193 Forward-Port-Of: odoo/odoo#193528
Issue: In the POS settings, even after disabling the preparation display option, it remains enabled after saving. Steps to reproduce: -In POS configuration -Ensure the Pay after option is set to each order. -Disable self ordering and uncheck the preparation display option, save. Explanation: In res_config_settings.py of pos_self_order, https://github.com/odoo/odoo/commit/8ee8010cf67f20c4eb28a334cc943bfedf2dd0d1 added a check to ensure that the preparation display is enabled if self-orde
Original PR description
Issue: In the POS settings, even after disabling the preparation display option, it remains enabled after saving. Steps to reproduce: -In POS configuration -Ensure the Pay after option is set to each order. -Disable self ordering and uncheck the preparation display option, save. Explanation: In res_config_settings.py of pos_self_order, https://github.com/odoo/odoo/commit/8ee8010cf67f20c4eb28a334cc943bfedf2dd0d1 added a check to ensure that the preparation display is enabled if self-ordering is active. However, it was still automatically enabling the preparation display even when self-ordering was disabled. opw-4225668 (This pr was merged but introduced an error with the test which was fixed in a separate pr: https://github.com/odoo/odoo/pull/186539) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192869 Forward-Port-Of: odoo/odoo#183601
**To reproduce:** 1. Check the field 'Secure Posted Entries with Hash' in a journal with existing entries 2. Immediately return to the Dashboard, before posting new entries 3. An error is raised **Cause:** In odoo/odoo#196748, the secured group usability was changed to only grant access to the new features relating to securing entries if moves from a journal without "Hash on Post" are secured. However, if before any entries are hashed, either by posting a new move in a journal with 'Ha
Original PR description
**To reproduce:** 1. Check the field 'Secure Posted Entries with Hash' in a journal with existing entries 2. Immediately return to the Dashboard, before posting new entries 3. An error is raised…
**To reproduce:** 1. Check the field 'Secure Posted Entries with Hash' in a journal with existing entries 2. Immediately return to the Dashboard, before posting new entries 3. An error is raised **Cause:** In odoo/odoo#196748, the secured group usability was changed to only grant access to the new features relating to securing entries if moves from a journal without "Hash on Post" are secured. However, if before any entries are hashed, either by posting a new move in a journal with 'Hash on Post' or using the 'Secure Entries' wizard, the user returns to the dashboard, an error is raised. This is due to _get_chains_to_hash() being called with early_stop = True, in which case chain_info is an int. **Fix:** The key 'journal_restrict_move', which information on whether the journal is 'Hash on Post' to chain_info, should only be added after the function returns True in case of early_stop. This avoids the item assignment on an int. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197226
This commit make brazilen fields always display in address form even though b2b fields settings disabled from edition because in LATAM country `ID Type` and `ID Number` field are required for billing. Also revert wrong fixed PR https://github.com/odoo/odoo/pull/194110 task-3628329 Forward-Port-Of: odoo/odoo#196965 Forward-Port-Of: odoo/odoo#196182
Original PR description
This commit make brazilen fields always display in address form even though b2b fields settings disabled from edition because in LATAM country `ID Type` and `ID Number` field are required for billing. Also revert wrong fixed PR https://github.com/odoo/odoo/pull/194110 task-3628329 Forward-Port-Of: odoo/odoo#196965 Forward-Port-Of: odoo/odoo#196182
Version: - 17.0 Steps to Reproduce: - Install the Calendar app. - Create an event and enable the "All Day" option. - Duplicate the event. Issue: - When duplicating an All Day event, a traceback error occurs because the start_date and stop_date values are missing. Solution: - The start_date and stop_date are now properly set when duplicating an event resolving the traceback error. task-4353039 Forward-Port-Of: odoo/odoo#196972 Forward-Port-Of: odoo/odoo#188171
Original PR description
Version: - 17.0 Steps to Reproduce: - Install the Calendar app. - Create an event and enable the "All Day" option. - Duplicate the event. Issue: - When duplicating an All Day event, a traceback error occurs because the start_date and stop_date values are missing. Solution: - The start_date and stop_date are now properly set when duplicating an event resolving the traceback error. task-4353039 Forward-Port-Of: odoo/odoo#196972 Forward-Port-Of: odoo/odoo#188171
Versions -------- - 18.0+ Steps ----- 1. Go to eCommerce; 2. add items to cart; 3. go to checkout; 4. pay with Worldline; 5. on Worldline's site, cancel transaction; 6. open order in the backend. Issue ----- Chatter displays: > Error: Worldline: Received invalid transaction status CANCELLED Cause ----- The cancel & declined statuses aren't handled when processing Worldline's response, leading to them being displayed as invalid. Solution -------- Handle the `cancel` an
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Go to eCommerce; 2. add items to cart; 3. go to checkout; 4. pay with Worldline; 5. on Worldline's site, cancel transaction; 6. open order in the backend. Issue ----- Chatter displays: > Error: Worldline: Received invalid transaction status CANCELLED Cause ----- The cancel & declined statuses aren't handled when processing Worldline's response, leading to them being displayed as invalid. Solution -------- Handle the `cancel` and `declined` statuses and display the given error code. Also, when canceled, call `_set_canceled` instead of `_set_error`. opw-4481602 Forward-Port-Of: odoo/odoo#196293
step to reporduce: 1. createdb with sale and inventory in 18.0 and activate product packaging 2. Create product or demo product can be used add the product packaging in inventory tab. 3. if packaging name is have more text then it description data will auto wrap in small portion which don't look good. before fix:  after fix:  after fix:  upg-2452360 opw-4527424 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196779
To reproduce: 1) install localization of any of the below modules. 2) Make branch companies in that localization. 3) install one of the modules below. we get this error:https://github.com/odoo/odoo/blob/17.0/addons/account/models/account_tax.py#L200, `Tax names must be unique`, so only load taxes for root companies. and for tax_group we get this error: ``` The operation cannot be completed: - Create/update: a mandatory field is not set. - Delete: another model requires the recor
Original PR description
To reproduce: 1) install localization of any of the below modules. 2) Make branch companies in that localization. 3) install one of the modules below. we get this error:https://github.com/odoo/odoo/blob/17.0/addons/account/models/account_tax.py#L200, `Tax names must be unique`, so only load taxes for root companies. and for tax_group we get this error: ``` The operation cannot be completed: - Create/update: a mandatory field is not set. - Delete: another model requires the record being deleted. If possible, archive it instead. Model: Tax Group (account.tax.group) Field: Name (name) ``` 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#193013
The nocontent message for inventory counts was still referring to old concepts from before the 17.0 Milk redesign (like the "CREATE" button or the Import action in the Favorites menu). This commit updates the message to correctly reference the new design actions, corrects the English and escapes translations inserted into HTML. [task-4550935](https://www.odoo.com/odoo/project.task/4550935) Forward-Port-Of: odoo/odoo#196908 Forward-Port-Of: odoo/odoo#196835
Original PR description
The nocontent message for inventory counts was still referring to old concepts from before the 17.0 Milk redesign (like the "CREATE" button or the Import action in the Favorites menu). This commit updates the message to correctly reference the new design actions, corrects the English and escapes translations inserted into HTML. [task-4550935](https://www.odoo.com/odoo/project.task/4550935) Forward-Port-Of: odoo/odoo#196908 Forward-Port-Of: odoo/odoo#196835
This PR handles 2 cases of ghost mutations generation: When switching the selection, the hint plugin generated mutations that were not part of a step. They should be ignored. When undoing the insertion of nested embedded components, the post-processing allowing for OWL Component destruction was generating ghost mutations. They should also be ignored. See commits for further details task-4561045 Forward-Port-Of: odoo/odoo#197089
Original PR description
This PR handles 2 cases of ghost mutations generation: When switching the selection, the hint plugin generated mutations that were not part of a step. They should be ignored. When undoing the insertion of nested embedded components, the post-processing allowing for OWL Component destruction was generating ghost mutations. They should also be ignored. See commits for further details task-4561045 Forward-Port-Of: odoo/odoo#197089
Users manually reconciling foreign currency entries sometimes do not perfectly balance the operation. In this case the system needs to collect the amount residual by currency and propose a write-off. Currently the system will raise a traceback when the residual amount is only in foreign currency Steps to reproduce: - Have a foreign currency (EUR) with exchange rate 36.0 - Have a Journal [JNL] in foreign currency - In [JNL] register a Vendor Payment of amount 51,993.01 EUR (1444.25 USD) -
Original PR description
Users manually reconciling foreign currency entries sometimes do not perfectly balance the operation. In this case the system needs to collect the amount residual by currency and propose a write-off.…
Users manually reconciling foreign currency entries sometimes do not perfectly balance the operation. In this case the system needs to collect the amount residual by currency and propose a write-off. Currently the system will raise a traceback when the residual amount is only in foreign currency
Steps to reproduce:
- Have a foreign currency (EUR) with exchange rate 36.0
- Have a Journal [JNL] in foreign currency
- In [JNL] register a Vendor Payment of amount 51,993.01 EUR (1444.25 USD)
- In [JNL] register a new transaction as follows:
- Foreign currency: USD
- Amount in Currency: 1444.25
- Open Journal Items and select:
- The credit entry from the Vendor Payment
- The debit entry from the transaction
- Reconcile
Issue: A traceback will raise
```
File "[...]/account_accountant/wizard/account_reconcile_wizard.py", line 337, in <genexpr>
residual_values[amls.company_currency_id]['residual']
KeyError: res.currency(1,)
```
opw-4514336
Forward-Port-Of: odoo/enterprise#78735### Steps to reproduce: - Create a bom for a product FP: - 1 x COMP (component) - operations: OP1: - instruction: - type: pass/fail, - Create and confirm an MO for 1 unit of FP - Go to the shopfloor, click on the instruction to open a dialog. - Spam the Pass button #### > Traceback: Uncaught Promise: Cannot read properties of undefined (reading 'resId') ### Cause of the issue: Clicking on a footer button of the `MrpQualityCheckConfirmationDialog` will trigger a
Original PR description
### Steps to reproduce: - Create a bom for a product FP: - 1 x COMP (component) - operations: OP1: - instruction: - type: pass/fail, - Create and confirm an MO for 1 unit of FP - Go to the shopfloor,…
### Steps to reproduce:
- Create a bom for a product FP:
- 1 x COMP (component)
- operations: OP1:
- instruction: - type: pass/fail,
- Create and confirm an MO for 1 unit of FP
- Go to the shopfloor, click on the instruction to open a dialog.
- Spam the Pass button
#### > Traceback: Uncaught Promise: Cannot read properties of undefined (reading 'resId')
### Cause of the issue:
Clicking on a footer button of the `MrpQualityCheckConfirmationDialog` will trigger a call of the `doActionAndClose` method: https://github.com/odoo/enterprise/blob/55c6292ff9d59ff09b1d81a61752765cf70d72c0/mrp_workorder/static/src/mrp_display/dialog/mrp_quality_check_confirmation_dialog.js#L93-L113 A the end of this call a `qualityCheckDone` is called to complete the operation which to work properly expects a `lastOpenedQualityCheck` to be set. However, at the end of this call, `displayInstruction` is called to generate a new MRP dialog for the next instuction if even exist. And, during this call if th ecurrent record (instruction) correspond to the `lastOpenedQualityCheck`, the value will be erased: https://github.com/odoo/enterprise/blob/55c6292ff9d59ff09b1d81a61752765cf70d72c0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L337-L340 This causes the error because if you click too fast you will clean the value that you are suppose to use in the next call `qualityCheckDone` which will explode.
### Fix:
We diasble the buttons of the Dialog once a a call of the `doActionAndClose` is triggered. That way, it becomes impossible to spam an action that is already processing the info. This is a backport the part of e4190f1ea2c89439d2cd4afa5137d0fedb06431e related to our issue. In addition to this bacport we apply this change on the `MrpRegisterProductionDialog` extending the `MrpQualityCheckConfirmationDialog` to limit the amount of rpc called performed by validating a registration (prior, you could spam the validate button to encode the exact same value multiple times).
### Note:
By opposition to e4190f1ea2c89439d2cd4afa5137d0fedb06431e we do not disable the buttons during the `openWorksheet` since a priori this action does not close the dialog and we might want to press other buttons on the dialog once this action has been performed.
opw-4352828
Forward-Port-Of: odoo/enterprise#78166
Forward-Port-Of: odoo/enterprise#74795Steps to reproduce: ------------------- 1. create 2 contacts : - one as a company (named parent contact for example) - and one as individual (named child contact) and set its parent company to the (parent contact). 2. create an invoice and set the partner to the (child contact). 3. set the invoice date and due date of the invoice to one month ago. 4. open the parent company (parent contact) -> accounting -> followup. You will see that Follow-up Status = in need of action, but if y
Original PR description
Steps to reproduce: ------------------- 1. create 2 contacts : - one as a company (named parent contact for example) - and one as individual (named child contact) and set its parent company to the (parent contact). 2. create an invoice and set the partner to the (child contact). 3. set the invoice date and due date of the invoice to one month ago. 4. open the parent company (parent contact) -> accounting -> followup. You will see that Follow-up Status = in need of action, but if you clicked the Overdue Invoices, you will not find any invoices. Cause: ----- Since action_open_overdue_entries() introduced in V18.0, the window action filters invoices by partner set on the invoice while the Follow-up Status query checks the move lines which is always set to the parent company of the partner. Fix: --- Use commercial_partner_id instead of partner_id for the domain filter. OPW-4501051 Forward-Port-Of: odoo/enterprise#78737
…on display option Issue: In the POS settings, even after disabling the preparation display option, it remains enabled after saving. Steps to reproduce: -In POS configuration -Ensure the Pay after option is set to each order. -Disable self ordering and uncheck the preparation display option, save. Explanation: In res_config_settings.py of pos_self_order, https://github.com/odoo/odoo/commit/8ee8010cf67f20c4eb28a334cc943bfedf2dd0d1 added a check to ensure that the preparation display is
Original PR description
…on display option Issue: In the POS settings, even after disabling the preparation display option, it remains enabled after saving. Steps to reproduce: -In POS configuration -Ensure the Pay after option is set to each order. -Disable self ordering and uncheck the preparation display option, save. Explanation: In res_config_settings.py of pos_self_order, https://github.com/odoo/odoo/commit/8ee8010cf67f20c4eb28a334cc943bfedf2dd0d1 added a check to ensure that the preparation display is enabled if self-ordering is active. However, it was still automatically enabling the preparation display even when self-ordering was disabled. (forward port of https://github.com/odoo/enterprise/commit/d3606d5a99ba7328cce164c0c16ff594d7639f4a) opw-4225668 X-original-commit: https://github.com/odoo/odoo/commit/2d753a90d0612b35d9d012574915d2e6bb754b1f Forward-Port-Of: odoo/enterprise#76696 Forward-Port-Of: odoo/enterprise#74256
Steps: - enable rental transfers - activate MTO route - create a product with MTO route and 0 stock - create a rental order for that product, validate Issue: The rental order will create 2 pickings that are waiting for each other. This is because the MTO move is using the same rental route with the stock destination, so it ends on the return rental picking. Fix: Force the procurement to use the `route_id` of the `rule_id` of the origin move. This way it will correctly create a new
Original PR description
Steps: - enable rental transfers - activate MTO route - create a product with MTO route and 0 stock - create a rental order for that product, validate Issue: The rental order will create 2 pickings that are waiting for each other. This is because the MTO move is using the same rental route with the stock destination, so it ends on the return rental picking. Fix: Force the procurement to use the `route_id` of the `rule_id` of the origin move. This way it will correctly create a new picking from Vendor to Stock for the product. If the product has a Buy or Manufacture route, it will use those instead. Also found another issue when enabling, then disabling, then re-enabling rental pickings: the stock rule stays archived. It is now fixed and a test has been added. Forward-Port-Of: odoo/enterprise#78648 Forward-Port-Of: odoo/enterprise#76477
Before this commit, if the 'Consumidor Final Anónimo' partner was archived, attempting to open the PoS would lead to an error. This commit shows a clearer error message. opw-4506474 Forward-Port-Of: odoo/enterprise#77903
Original PR description
Before this commit, if the 'Consumidor Final Anónimo' partner was archived, attempting to open the PoS would lead to an error. This commit shows a clearer error message. opw-4506474 Forward-Port-Of: odoo/enterprise#77903
STEP TO REPRODUCE: 1- Install The belgium payroll 2- Go to Payroll 3- Go to reporting > Declaration 274.XX 4- Click on generate xml file Forward-Port-Of: odoo/enterprise#79008
Original PR description
STEP TO REPRODUCE: 1- Install The belgium payroll 2- Go to Payroll 3- Go to reporting > Declaration 274.XX 4- Click on generate xml file Forward-Port-Of: odoo/enterprise#79008
The computation for the cars bik has changed in belgium for 2025. This adds rule parameters and changes the computation to reflect those changes. Task: 4409219 Forward-Port-Of: odoo/enterprise#78978 Forward-Port-Of: odoo/enterprise#77557
Original PR description
The computation for the cars bik has changed in belgium for 2025. This adds rule parameters and changes the computation to reflect those changes. Task: 4409219 Forward-Port-Of: odoo/enterprise#78978 Forward-Port-Of: odoo/enterprise#77557
In this PR: - Replaced the `search` method with `_get` to directly fetch the `gstr1_status` field from `l10n_in.gst.return.period`, improving efficiency and readability. Forward-Port-Of: odoo/enterprise#78575
Original PR description
In this PR: - Replaced the `search` method with `_get` to directly fetch the `gstr1_status` field from `l10n_in.gst.return.period`, improving efficiency and readability. Forward-Port-Of: odoo/enterprise#78575
To reproduce: 1) install localization of any of the below modules. 2) Make branch companies in that localization. 3) install one of the modules below. we get this error:https://github.com/odoo/odoo/blob/17.0/addons/account/models/account_tax.py#L200, `Tax names must be unique`, so only load taxes for root companies. and for tax_group we get this error: ``` The operation cannot be completed: - Create/update: a mandatory field is not set. - Delete: another model requires the record
Original PR description
To reproduce: 1) install localization of any of the below modules. 2) Make branch companies in that localization. 3) install one of the modules below. we get this error:https://github.com/odoo/odoo/blob/17.0/addons/account/models/account_tax.py#L200, `Tax names must be unique`, so only load taxes for root companies. and for tax_group we get this error: ``` The operation cannot be completed: - Create/update: a mandatory field is not set. - Delete: another model requires the record being deleted. If possible, archive it instead. Model: Tax Group (account.tax.group) Field: Name (name) ``` Forward-Port-Of: odoo/enterprise#76792