Friday, June 13, 2025
23 changes · saas-18.1
Miscellaneous changes
Description of the issue this PR addresses: Current behavior before PR: The separator was always inserted before the current block, regardless of its content. Desired behavior after PR is merged: The separator is inserted before the block if it's empty, otherwise it is inserted after the block if it contains text. task-4848276 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212970
Original PR description
Description of the issue this PR addresses: Current behavior before PR: The separator was always inserted before the current block, regardless of its content. Desired behavior after PR is merged: The separator is inserted before the block if it's empty, otherwise it is inserted after the block if it contains text. task-4848276 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212970
If the browser triggers a request just as a tour is finishing up (e.g. navigation to a new page triggering a font fetch), the harness can close the websocket connection while the request is in the `requestPaused` proxy, causing the reply to fail and trigger an error. We can just ignore the error in that case. An alternative would be to enqueue a future into `_responses` when we receive the query, but that would still have a race as depending on scheduling decisions the browser could have alre
Original PR description
If the browser triggers a request just as a tour is finishing up (e.g. navigation to a new page triggering a font fetch), the harness can close the websocket connection while the request is in the `requestPaused` proxy, causing the reply to fail and trigger an error. We can just ignore the error in that case. An alternative would be to enqueue a future into `_responses` when we receive the query, but that would still have a race as depending on scheduling decisions the browser could have already shut down by the time we reach the handler, so we'd need to enqueue a future, check if `ws` is still open, and bail if not. And even then that's still got a hole as there is some time between the `wait(_responses.values())` and the `ws.close()`. https://runbot.odoo.com/odoo/error/186309 Forward-Port-Of: odoo/odoo#213959 Forward-Port-Of: odoo/odoo#213911
Before this commit, some command palette tests failed non- deterministically. The cause was that the values set on debounced functions were too short, compared to the time it took to render the component after each action, PLUS the additional animation frame awaited by each call to 'advanceTime'/'runAllTimers'. All in all, should the CPU be a bit busier than usual, these tests would fail. This commit does 2 things: - the debounce delays have been vastly increased (100 & 200ms -> 500 & 1000
Original PR description
Before this commit, some command palette tests failed non- deterministically. The cause was that the values set on debounced functions were too short, compared to the time it took to render the component after each action, PLUS the additional animation frame awaited by each call to 'advanceTime'/'runAllTimers'. All in all, should the CPU be a bit busier than usual, these tests would fail. This commit does 2 things: - the debounce delays have been vastly increased (100 & 200ms -> 500 & 1000ms); - the awaited actions in the command palette test module have been reduced to a minimum, using Hoot helpers directly instead of the web 'contains' wrapper. runbot [223268](https://runbot.odoo.com/odoo/runbot.build.error/223268) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213840
Have a model that returns a warning onchange during the first call to onchange. On another model that has a many2one to the first model, Create And Edit a record via the many2one field on the form view. Before this commit, there was an endless loop because on dialog was triggering the opening of a second one *during* its willStart lifecycle period, so none of them end up mounted, instead, the formViewDialog was constantly reinstanciated because the dialog container constantly received request
Original PR description
Have a model that returns a warning onchange during the first call to onchange. On another model that has a many2one to the first model, Create And Edit a record via the many2one field on the form view. Before this commit, there was an endless loop because on dialog was triggering the opening of a second one *during* its willStart lifecycle period, so none of them end up mounted, instead, the formViewDialog was constantly reinstanciated because the dialog container constantly received requests to re-render. After this commit, we only open those dialog onMounted of the main component, and this issue doesn't occur anymore. opw-4783459 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#213888 Forward-Port-Of: odoo/odoo#213742
For a document fix, we add a method to the activity button that implements custom behavior when an activity changes. see odoo/enterprise#84128 task-4690165 Forward-Port-Of: odoo/odoo#210988
Original PR description
For a document fix, we add a method to the activity button that implements custom behavior when an activity changes. see odoo/enterprise#84128 task-4690165 Forward-Port-Of: odoo/odoo#210988
## Issue description: - When 'qty_producing' is updated, the new move takes the MO date_deadline. - The MO date_deadline is the minimum date of all the finished moves date_deadline. - When the SO commitment_date is incremented (+1day), the FNS move date_deadline is updated, but not the BP move one. - The MO date_deadline stay the same (because BP move is a finished move, and BP.date_deadline < FNS.date_deadline) - The new FNS move deadline will not be equal to the existing FNS move deadline
Original PR description
## Issue description: - When 'qty_producing' is updated, the new move takes the MO date_deadline. - The MO date_deadline is the minimum date of all the finished moves date_deadline. - When the SO…
## Issue description:
- When 'qty_producing' is updated, the new move takes the MO date_deadline.
- The MO date_deadline is the minimum date of all the finished moves date_deadline.
- When the SO commitment_date is incremented (+1day), the FNS move date_deadline is updated, but not the BP move one.
- The MO date_deadline stay the same (because BP move is a finished move, and BP.date_deadline < FNS.date_deadline)
- The new FNS move deadline will not be equal to the existing FNS move deadline
- The merge is blocked
## How to reproduce:
- Enable By-Products in setting
- Unarchive MTO route
- Create storable products FNS, CMP and BP
- Set FNS route: Manufacture and MTO
- Create BoM:
- Producing: 1 of FNS
- Component: 1 of CMP
- By-Product: 1 of BP
- Create Sale Order for 1 unit of FNS ⇾ Confirm
- Set Delivery Date to 1 day in the future (date must be incremented)
- Go to MO, set quantity producing to 2
- => 2 Finished move for FNS exists; the merge was not done due to a discrepancy in 'date_deadline'
- Click "Produce All"
- !! Singleton Error
## Fix:
On date_deadline change: propagate deadline to sibling FNS moves
OPW-4671555
---
## Test result without fix:
```
2025-06-03 11:54:54,076 37053 ERROR oes_test_17 odoo.addons.sale_mrp.tests.test_sale_mrp_flow: FAIL: TestSaleMrpFlow.test_date_deadline_propagation
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/sale_mrp/tests/test_sale_mrp_flow.py", line 2624, in test_date_deadline_propagation
self.assertEqual(len(fns_move), 1)
AssertionError: 2 != 1
```
## Test result without fix and the asserts on finished moves removed (to reach 'button_mark_done'):
```
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/sale_mrp/tests/test_sale_mrp_flow.py", line 2622, in test_date_deadline_propagation
mo.button_mark_done()
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/mrp/models/mrp_production.py", line 2014, in button_mark_done
productions_not_to_backorder._post_inventory(cancel_backorder=True)
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/mrp/models/mrp_production.py", line 1723, in _post_inventory
order._cal_price(moves_to_do_by_order[order.id])
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/mrp_account/models/mrp_production.py", line 89, in _cal_price
finished_move.ensure_one()
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/odoo/models.py", line 5899, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: stock.move(8252, 8255)
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#213256
Forward-Port-Of: odoo/odoo#212718If a currency not supported by AsiaPay is selected during payment, the system will crash, resulting in a KeyError. In the `const.py` file at [1], we have already defined the `CURRENCY_MAPPING`. Therefore, if a currency is chosen that is not included in the `CURRENCY_MAPPING`, it will cause a crash during the payment process. [1] https://github.com/odoo/odoo/blob/bcaafd941c1b4cae65a71900858894556805762e/addons/payment_asiapay/const.py#L19-L42 **Steps to produce:-** 1. Install `eCommerce`.
Original PR description
If a currency not supported by AsiaPay is selected during payment, the system will crash, resulting in a KeyError. In the `const.py` file at [1], we have already defined the `CURRENCY_MAPPING`.…
If a currency not supported by AsiaPay is selected during payment, the system will crash, resulting in a KeyError. In the `const.py` file at [1], we have already defined the `CURRENCY_MAPPING`. Therefore, if a currency is chosen that is not included in the `CURRENCY_MAPPING`, it will cause a crash during the payment process. [1] https://github.com/odoo/odoo/blob/bcaafd941c1b4cae65a71900858894556805762e/addons/payment_asiapay/const.py#L19-L42 **Steps to produce:-** 1. Install `eCommerce`. 2. Set up the `AsiaPay` payment provider, and in the configuration, set the Currencies as `EGP`. 3. Now, go to `Website > Shop` and add the product to the cart. 4. Try to make the `payment` for the cart using `AsiaPay`. **Error:-** `KeyError: 'EGP'` **Solution:-** - This commit adds a constraint that ensures only currencies defined in `CURRENCY_MAPPING` (from `const.py`) can be selected for the AsiaPay payment provider. If any unsupported currencies are selected, a ValidationError is raised listing the invalid entries. **Sentry - 6665716944** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213496
**Steps to reproduce:** - Install the modules `l10n_sg` and `l10n_sg_ubl_pint`. - Create an invoice. - On the form view of the partner you chose. Under the `Accounting` tab, set `eInvoice format` as PINT singapore. - On the invoice, for `currency_id`, use a currency other than SGD. - Download the invoice in the 'PINT Singapore' format. **Issue:** The invoice is not downloaded and it throws a traceback. **Cause:** The method '_get_additional_document_reference_list' returns a list of
Original PR description
**Steps to reproduce:** - Install the modules `l10n_sg` and `l10n_sg_ubl_pint`. - Create an invoice. - On the form view of the partner you chose. Under the `Accounting` tab, set `eInvoice format` as PINT singapore. - On the invoice, for `currency_id`, use a currency other than SGD. - Download the invoice in the 'PINT Singapore' format. **Issue:** The invoice is not downloaded and it throws a traceback. **Cause:** The method '_get_additional_document_reference_list' returns a list of dictionnaries within another list, while the XML is expecting a list of dictionnaries. **Solution:** Remove the append method. opw-4799363 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212754
The Italian localization defined 'preceding_subtotal' in tax group records using the Italian term "Imponibile" as the default value. This caused the label for untaxed amounts in invoices, sale orders, and purchase orders to always appear in Italian, regardless of the system or partner language. task-4853046 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
Original PR description
The Italian localization defined 'preceding_subtotal' in tax group records using the Italian term "Imponibile" as the default value. This caused the label for untaxed amounts in invoices, sale orders, and purchase orders to always appear in Italian, regardless of the system or partner language. task-4853046 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#213983
If you have 2 invoices and 2 dropship picking linked to 1 Dropship Sale Order, and the two dropship have different SVL cost: The 2nd invoice will have incorrect COGS https://github.com/user-attachments/assets/79f15933-0449-4081-aff0-daa5709889bf ## To reproduce - Create Product P-DROP: * category: AVCO automated * Routes: Buy & Dropship * Purchase Vendors: Azure Interior @ $10 - Create Sale Order for 1 unit of P-Drop ⇾ Confirm - Go to Purchase Order ⇾ ensure unit price is
Original PR description
If you have 2 invoices and 2 dropship picking linked to 1 Dropship Sale Order, and the two dropship have different SVL cost: The 2nd invoice will have incorrect COGS…
If you have 2 invoices and 2 dropship picking linked to 1 Dropship Sale Order, and the two dropship have different SVL cost: The 2nd invoice will have incorrect COGS
https://github.com/user-attachments/assets/79f15933-0449-4081-aff0-daa5709889bf
## To reproduce
- Create Product P-DROP:
* category: AVCO automated
* Routes: Buy & Dropship
* Purchase Vendors: Azure Interior @ $10
- Create Sale Order for 1 unit of P-Drop ⇾ Confirm
- Go to Purchase Order ⇾ ensure unit price is $10 ⇾ Confirm
- Receive products ⇾ ensure **valuation is $10**
- Create Vendor Bill (optional) ⇾ Confirm
- Create Invoice ⇾ Confirm
* **COGS value is $10** (ok)
- In Sale Order, set ordered quantity to 2 units
* New draft PO should have been created
- Go to New Purchase Order ⇾ set price to $20 ⇾ Confirm
- Receive products ⇾ ensure **valuation is $20**
- Create Vendor Bill (optional) ⇾ Confirm
- Create Invoice ⇾ Confirm
* COGS should be $20, but they are actually **$16.67** (KO)
---
## Test result without fix
```
2025-06-11 11:25:32,230 29041 ERROR oes_test_17 odoo.addons.stock_dropshipping.tests.test_stockvaluation: FAIL: TestStockValuation.test_dropship_cogs_multiple_invoices
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/stock_dropshipping/tests/test_stockvaluation.py", line 382, in test_dropship_cogs_multiple_invoices
self.assertEqual(dropship2_cogs_line.balance, -16)
AssertionError: -13.33 != -16
```
OPW-4665635
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#213887
Forward-Port-Of: odoo/odoo#213763Steps to reproduce the issue: 1- install sale_project without demo data 2- as the test is not deterministic, adding step_delay may help reproducing it The project creation tour was intermittently failing at the step that attempts to save the project (.o_form_button_save:enabled). The failure occurred because this step was triggered while a modal (for creating a Sales Order Item) was still visible and overlaid on top of the main form. Add missing steps in the project tour to select a
Original PR description
Steps to reproduce the issue: 1- install sale_project without demo data 2- as the test is not deterministic, adding step_delay may help reproducing it The project creation tour was intermittently failing at the step that attempts to save the project (.o_form_button_save:enabled). The failure occurred because this step was triggered while a modal (for creating a Sales Order Item) was still visible and overlaid on top of the main form. Add missing steps in the project tour to select a product in the Sales Order Item form and save and close the form. build_error-163102 Forward-Port-Of: odoo/odoo#211934
**Current behavior before PR:** Steps to reproduce: - Create a table. - Select some cells, apply background color on them. - Try to remove format using removeFormat button. Trying to remove format from the colored cells leads to traceback `Infinite Loop in removeAllColor()`. The issue happens because after merging commit [1], when applying background-color on cells, text-color will also get applied along with background-color. When trying to remove color using removeFormat button, `ap
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create a table. - Select some cells, apply background color on them. - Try to remove format using removeFormat button. Trying to remove format from the colored cells leads to traceback `Infinite Loop in removeAllColor()`. The issue happens because after merging commit [1], when applying background-color on cells, text-color will also get applied along with background-color. When trying to remove color using removeFormat button, `applyTableColor` method fails to remove text-color from cells despite having color on them, leading to infinite loop error. **Desired behavior after PR:** Now, background-color is removed from cells without any traceback. [1]: https://github.com/odoo/odoo/commit/616413c3272429ec48a6ac238c899b31d0751546 task-4805468 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210803
Users can create a downpayment bill directly from the purchase order or create a bill separately and then associate it with the original purchase order. However, in the latter case, the bill amount won't take into account the currency. Steps to reproduce: - Create a purchase order for a partner in company currency - Create a bill in foreign currency for the same partner - Click "Purchase Matching" smart button - Select PO and BILL > Add to PO > Add Down Payment Issue: Downpayment w
Original PR description
Users can create a downpayment bill directly from the purchase order or create a bill separately and then associate it with the original purchase order. However, in the latter case, the bill amount won't take into account the currency. Steps to reproduce: - Create a purchase order for a partner in company currency - Create a bill in foreign currency for the same partner - Click "Purchase Matching" smart button - Select PO and BILL > Add to PO > Add Down Payment Issue: Downpayment will be added into the PO without taking into account the different currency opw-4716949 Forward-Port-Of: odoo/odoo#212576
### Steps to reproduce: - Install l10n_bg - Install the Bulgarian language - In the Accounting Settings, tick the option "Total amount of invoice in letters" - Change a contact's language to Bulgarian - Create an invoice for this partner, select BGN as the currency - The total should be with a unit in thousands (for example 8500) - The text transcription of the number substracts 1000: Седем Хиляди И Петстотин = 7500 ### Cause: The class `NumberToWords_BG` is a copy of the library num2
Original PR description
### Steps to reproduce: - Install l10n_bg - Install the Bulgarian language - In the Accounting Settings, tick the option "Total amount of invoice in letters" - Change a contact's language to…
### Steps to reproduce: - Install l10n_bg - Install the Bulgarian language - In the Accounting Settings, tick the option "Total amount of invoice in letters" - Change a contact's language to Bulgarian - Create an invoice for this partner, select BGN as the currency - The total should be with a unit in thousands (for example 8500) - The text transcription of the number substracts 1000: Седем Хиляди И Петстотин = 7500 ### Cause: The class `NumberToWords_BG` is a copy of the library num2cyrillic except for the initialization of the variable `_digits` which specifies three arrays with variants of the numbers (1-9). We do it by copying the index 0, which is the default variant, for the non-different spellings. The issue comes from the line `_digits[-1] = [None, 'една', None] + _digits[0][2:]` which have an unneeded `None` which offsets the array by one. So when reading `_digits[-1][8]` we end up with "seven". ### Solution: Remove the `None`. opw-4753418 Forward-Port-Of: odoo/odoo#212914
Setting the opacity to the empty string leads to max opacity but is seen as "/" in the builder because no options corresponds to this value. And the "None" option is not that, which is confusing. Setting a known value for the opacity shows the correct choice for the option Steps to reproduce: - In a database with demo data, go to `/event` - Go to "An unpublished event" - Open editor - Bug: "Filter Intensity" shows "/" Backport of 94cc1cbd2d8ed23fd243515ad215ea91bac46068 task-4367641
Original PR description
Setting the opacity to the empty string leads to max opacity but is seen as "/" in the builder because no options corresponds to this value. And the "None" option is not that, which is confusing. Setting a known value for the opacity shows the correct choice for the option Steps to reproduce: - In a database with demo data, go to `/event` - Go to "An unpublished event" - Open editor - Bug: "Filter Intensity" shows "/" Backport of 94cc1cbd2d8ed23fd243515ad215ea91bac46068 task-4367641 Forward-Port-Of: odoo/odoo#213965 Forward-Port-Of: odoo/odoo#212530
### Issue: Currently, non-system admin users are blocked from checking Envia rates. When initializing the `Envia` class, these users do not have access to the `carrier` fields, leading to an Access Error. ### Solution: Similar to `delivery_bpost` and `delivery_dhl`, we can use a `sudo` when grabbing the `api_key` value from the carrier record. opw-4761196 Forward-Port-Of: odoo/enterprise#85319
Original PR description
### Issue: Currently, non-system admin users are blocked from checking Envia rates. When initializing the `Envia` class, these users do not have access to the `carrier` fields, leading to an Access Error. ### Solution: Similar to `delivery_bpost` and `delivery_dhl`, we can use a `sudo` when grabbing the `api_key` value from the carrier record. opw-4761196 Forward-Port-Of: odoo/enterprise#85319
In uruguayan companies, if the field "Lock Posted Entries with Hash" is checked, the user can not validate electronic invoices in DGI. In this PR we are hiding the field in electronic uruguayan journals to prevent the user to check that field accidentally and generate inconsistencies with electronic invoicing. Forward-Port-Of: odoo/enterprise#85392
Original PR description
In uruguayan companies, if the field "Lock Posted Entries with Hash" is checked, the user can not validate electronic invoices in DGI. In this PR we are hiding the field in electronic uruguayan journals to prevent the user to check that field accidentally and generate inconsistencies with electronic invoicing. Forward-Port-Of: odoo/enterprise#85392
The dynamic payments domain for batch payments has been added in https://github.com/odoo/enterprise/pull/86217 Fix the override for domain payments in the SEPA module. Forward-Port-Of: odoo/enterprise#87481
Original PR description
The dynamic payments domain for batch payments has been added in https://github.com/odoo/enterprise/pull/86217 Fix the override for domain payments in the SEPA module. Forward-Port-Of: odoo/enterprise#87481
When we enable the integer rounding option on this report, a traceback is raised at the report opening. It happens because integer rounding didn't support a groupby when a custom engine is used. opw-4688616 Forward-Port-Of: odoo/enterprise#86452
Original PR description
When we enable the integer rounding option on this report, a traceback is raised at the report opening. It happens because integer rounding didn't support a groupby when a custom engine is used. opw-4688616 Forward-Port-Of: odoo/enterprise#86452
### Steps to reproduce: - Create 2 storable products: Product A, Product B - Create a control point pass/fail control by quantity on receipt and set both products on it. - Create and confirm a receipt with 2 moves: - 2 x Product A - 2 x Product B - Click on the "Quality Check" button and mark one unit of Product A as failed. > This should open the QC for product B. - Close the QC for prodcut B wihtout setting it as failed or passed. - Click on the "Quality Check" button ####
Original PR description
### Steps to reproduce: - Create 2 storable products: Product A, Product B - Create a control point pass/fail control by quantity on receipt and set both products on it. - Create and confirm a…
### Steps to reproduce:
- Create 2 storable products: Product A, Product B
- Create a control point pass/fail control by quantity on receipt and set both products on it.
- Create and confirm a receipt with 2 moves:
- 2 x Product A
- 2 x Product B
- Click on the "Quality Check" button and mark one unit of Product A as failed.
> This should open the QC for product B.
- Close the QC for prodcut B wihtout setting it as failed or passed.
- Click on the "Quality Check" button
#### > Nothing happends
### Expected behavior:
The QC for product B should open.
### Cause of the issue:
When the quality check is marked as failed, the related move is picked: https://github.com/odoo/enterprise/blob/679c81924e05e7544eecfdb960c9ed9611e9cdd5/quality_control/models/quality.py#L438-L451 However, the move for your second porduct is not and hence, its product is not considered to be checkable by the `check_quality` action: https://github.com/odoo/enterprise/blob/679c81924e05e7544eecfdb960c9ed9611e9cdd5/quality_control/models/stock_picking.py#L61-L69
Since these lines were added in c83728f3a7f1504b272f4ef97e4187868338adb3 to not bypass the QC of the unpicked move at validation we should probably only add that filtering condition in that case and continue to consider the unchecked moves as checkable prior to validation.
opw-4765075
Forward-Port-Of: odoo/enterprise#84743Case 1: How to reproduce ================ - Select a record in any folder in Kanban view - Display its chatter - Add an activity from the kanban tile --> the chatter is not updated and needs a refresh Expected behavior ================= Chatter should update instantly Case 2: How to reproduce ================ - Select a record in any folder in Kanban view - Display its chatter - Mark done or cancel one or more activities from Chatter - Click on the activity button of the r
Original PR description
Case 1: How to reproduce ================ - Select a record in any folder in Kanban view - Display its chatter - Add an activity from the kanban tile --> the chatter is not updated and needs a refresh Expected behavior ================= Chatter should update instantly Case 2: How to reproduce ================ - Select a record in any folder in Kanban view - Display its chatter - Mark done or cancel one or more activities from Chatter - Click on the activity button of the related kanban record --> stack trace Expected behavior ================= Corresponding KanbanRecord should update. Note: v. 17.4 raises a missing record exception for the same case task-4690165 Forward-Port-Of: odoo/enterprise#84128
**Before this PR:** - The `Validate` button was always visible, even if the OTP was empty or incorrect. - Users could attempt validation with an invalid or missing OTP. - The OTP delivery message was unclear. **After this PR:** - The `Validate` button proceed done when a valid 6-digit numeric OTP is entered. - A clear error notification is shown if users try to proceed without a valid OTP. - The OTP delivery message now clearly informs that the OTP is sent to the registered mobile n
Original PR description
**Before this PR:** - The `Validate` button was always visible, even if the OTP was empty or incorrect. - Users could attempt validation with an invalid or missing OTP. - The OTP delivery message was unclear. **After this PR:** - The `Validate` button proceed done when a valid 6-digit numeric OTP is entered. - A clear error notification is shown if users try to proceed without a valid OTP. - The OTP delivery message now clearly informs that the OTP is sent to the registered mobile number on the GST portal. These changes improve user guidance and prevent incorrect OTP submissions. Task ID: 4848729 Forward-Port-Of: odoo/enterprise#87199
Currently, an error occurs when a user tries to access `paid consultation` or `paid seats` if the booking fees are deleted by the user. **Steps to Reproduce:** - Install **appointment_account_payment** module without demo data. - Delete **Booking Fees** product`from `invoicing->customer->products` - Click on `Paid Seats` or `Paid Consultation` in the Appointment App. **Error:** `ValueError: No record found for unique ID appointment_account_payment.default_booking_product. It may have b
Original PR description
Currently, an error occurs when a user tries to access `paid consultation` or `paid seats` if the booking fees are deleted by the user. **Steps to Reproduce:** - Install…
Currently, an error occurs when a user tries to access `paid consultation` or `paid seats` if the booking fees are deleted by the user. **Steps to Reproduce:** - Install **appointment_account_payment** module without demo data. - Delete **Booking Fees** product`from `invoicing->customer->products` - Click on `Paid Seats` or `Paid Consultation` in the Appointment App. **Error:** `ValueError: No record found for unique ID appointment_account_payment.default_booking_product. It may have been deleted.` **Root Cause:** After deleting the **Booking Fees**, if user tries to open `Paid Seats` or `Paid Consultation` the system will try to access id of `appointment_account_payment.default_booking_product` at [1] or [2] causing an error. [1]- https://github.com/odoo/enterprise/blob/a4f68967a9826fac981c1141ece1791a0baf647a/appointment_account_payment/models/templates/appointment_type.py#L43 [2]- https://github.com/odoo/enterprise/blob/a4f68967a9826fac981c1141ece1791a0baf647a/appointment_account_payment/models/templates/appointment_type.py#L56 **Solution:** This commit prevents error by restricting user from deleting the `Booking Product`. Sentry-6013528364 Forward-Port-Of: odoo/enterprise#86159