Issue
-----
The problem is when a subcontracted product has a component tracked by lots. Creating a receipt for the subcontractor, marking it as Todo then changing the quantity leads to the reception being impossible to validate because the lots for the components cannot be set from the move.

Steps to reproduce
-----
- Create a product (Comp1)
    - Tracked by lots
- Create a product (Prod1)
    - Add a BoM - Subcontracted - Flexible consumption - Set Comp1 as consumable
- Create a receipt for 2 Prod1
- Mark as Todo
- Set Quantity to 3
- Save
- Try to validate the receipt

Situation
-----
Before changing the quantity, the user has 2 buttons ("Record components" and the move's hamburger) which open the "Subcontract" wizard. This wizard is where they can set a lot/serial for the products.

When they change the quantity of the move, the inverse method of quantity is called

https://github.com/odoo/odoo/blob/74a8334558bf86c07c0d68090a9126911867ef42/addons/stock/models/stock_move.py#L170-L171

This method is overridden in the mrp_subcontracting module

https://github.com/odoo/odoo/blob/74a8334558bf86c07c0d68090a9126911867ef42/addons/mrp_subcontracting/models/stock_move.py#L75

The part that's important to our use case is

https://github.com/odoo/odoo/blob/74a8334558bf86c07c0d68090a9126911867ef42/addons/mrp_subcontracting/models/stock_move.py#L81-L82

Recording components leads us to create a backorder production

https://github.com/odoo/odoo/blob/74a8334558bf86c07c0d68090a9126911867ef42/addons/mrp_subcontracting/models/mrp_production.py#L90-L91

In our specific use case, this is problematic because the subcontract wizard loads the form of the last production

https://github.com/odoo/odoo/blob/74a8334558bf86c07c0d68090a9126911867ef42/addons/mrp_subcontracting/models/stock_move.py#L245

The user has no way to access the previous production which lacks lot/serial (other than opening the MO itself). Obviously, we don't want to mess with this flow, but there are 2 things we can do:

1. Avoiding weird cases such as this one by forcing the user to change the quantity through the appropriate wizard
2. Providing a link to the mrp.production once some production has been recorded

For the first point, the stock.move model already has a field we can use

https://github.com/odoo/odoo/blob/8c8449f51d5e327ccd2e4bb7c3c4868d51c6d619/addons/stock/models/stock_move.py#L180

We can just override the compute to fit our use case.

For the second point, there is already a button for this. The problem is that its display condition was changed in 9ca1064 to only show once the move is picked. This fix was a bit of an over correction because we also want to show the button for unpicked moves for which a production has been recorded.

-----
Ticket:
opw-4751896

Forward-Port-Of: odoo/odoo#219268

### Issue
When receiving vendor bills that include bank details, if the partner has archived bank accounts, Odoo may attempt to update them. This leads to a duplicate key violation on `res_partner_bank` when the same account number already exists for the partner.

#### Affected versions
16.0 and later

#### Error example
```bash
2025-07-08 13:36:52,942 204 INFO server-dummy odoo.addons.mail.models.mail_thread: Routing mail from "Client Name" <erp@odoo.com> to "M7- Odoo V17" <purchases@test.odoo.com>,purchases@test.odoo.com with Message-Id <*****.****.*****-****-*****-****.****@******>: direct alias match: ('account.move', 0, {'company_id': 1, 'move_type': 'in_invoice', 'journal_id': 10}, 1, mail.alias(6,))
2025-07-08 13:36:52,946 204 INFO server-dummy odoo.addons.mail.models.mail_thread: Primary email missing on account.move
2025-07-08 13:36:53,576 204 ERROR server-dummy odoo.sql_db: bad query: UPDATE "res_partner_bank" SET "acc_holder_name" = 'M7 GROUP INC.', "company_id" = NULL, "has_iban_warning" = false, "has_money_transfer_warning" = false, "sanitized_acc_number" = '1234567', "write_date" = '2025-07-08T13:36:52.897826'::timestamp, "write_uid" = 1 WHERE id IN (63)
ERROR: duplicate key value violates unique constraint "res_partner_bank_unique_number"
DETAIL:  Key (sanitized_acc_number, partner_id)=(1234567, 3524) already exists.

2025-07-08 13:36:53,576 204 ERROR server-dummy odoo.addons.account.models.account_move: Error importing attachment 'factur-x.xml' as invoice (decoder=_import_invoice_ubl_cii)
Traceback (most recent call last):
  File "/home/odoo/src/odoo/addons/account/models/account_move.py", line 3219, in _extend_with_attachments
    with self.env.cr.savepoint():
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 85, in __exit__
    self.close(rollback=exc_type is not None)
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 89, in close
    self._close(rollback)
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 113, in _close
    self._cr.flush()
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 137, in flush
    self.transaction.flush()
  File "/home/odoo/src/odoo/odoo/api.py", line 879, in flush
    env_to_flush.flush_all()
  File "/home/odoo/src/odoo/odoo/api.py", line 739, in flush_all
    self[model_name].flush_model()
  File "/home/odoo/src/odoo/odoo/models.py", line 6362, in flush_model
    self._flush(fnames)
  File "/home/odoo/src/odoo/odoo/models.py", line 6464, in _flush
    model.browse(ids)._write(vals)
  File "/home/odoo/src/odoo/odoo/models.py", line 4548, in _write
    cr.execute(SQL(
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 332, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "res_partner_bank_unique_number"
DETAIL:  Key (sanitized_acc_number, partner_id)=(1234567, 3524) already exists.
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#224248
Forward-Port-Of: odoo/odoo#223873

When changing `partner_id` on the `account.move.line`s of a duplicated journal entry if this journal entry already had a partner_id, it will stay the same (possible to see from list view) but the move line will be correctly changed.

Step to reproduce:

- Select a journal entry of type PBNK
- Duplicate the journal entry
- Change the partner on the journal items and save
- Go back to the list view, the partner name displayed is from the original journal entry

When clicking on duplicate it will call the function copy and super.copy() will call copy_data from account_move;

This line allow to copy the partner_id (which is needed since invoices revert goes through copy) Since there is no condition on the type of entry, it will also copy the partner_id in our case:
https://github.com/odoo/odoo/blob/22c333d0ed7eba1165f6462e668998d37fcabb73/addons/account/models/account_move.py#L2424-L2426

The introduction of this change introduced our issue, It allow for all duplication to copy the partner_id.
Original fix : https://github.com/odoo/odoo/commit/e1d18960b57b36b8bf69bc787ef6078dcba8c855

opw-4907648

Forward-Port-Of: odoo/odoo#223959
Forward-Port-Of: odoo/odoo#217755

When a payment term with early payment discount is used on invoice the discount date is set on the payment term line based on the actual configuration of the payment term. When the invoice is posted, this date must not change anymore as it usually is what is communicated to the partner in order to apply EPD.

However, if the payment term's delay for discount is modified, the discount date from the move line was not taken into account by the payment register wizard or by the reconciliation widget, as it was instead recalculating a discount limit date, based on the configuration of the payment term at the time the payment is registered on Odoo.

Make sure it is the discount date that is stored on payment terms' account move line that is used to define if an early payment discount has to be applied.

OPW-4895365

Description of the issue/feature this PR addresses:

On runbot, create a new payment term with an early payment discount (eg 10% at 15 days, balance at 30 days).
Create a customer invoice with a invoice line (eg 100 USD) for any customer with this payment term and set the date to 10 days before today. Post the invoice, you can see on the payment term line that the discount is valid until 5 days after today.
Modify the payment term to set 10% at 5 days. If you go back to the invoice, you'll notice the discount date is still 5 days after today which is fine since this is what was communicated to the customer

Current behavior before PR:

Register a payment on this invoice and you'll notice the EPD is not applied because it gets the date from the actual configuration of the payment term instead of the date stored on the invoice's payment term line.

Desired behavior after PR is merged:

Register a payment on this invoice must apply the EPD as it is still valid based on the invoice's payment term line.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#220295
Forward-Port-Of: odoo/odoo#215615

### Steps to reproduce:
	- Go to any task in project module
	- Create a new meeting activity
	- Open Calendar and drag to create a slot
	- Notice the name of the meeting in the pop-up is the same as the task
	- Click on the expand button top-right of the dialog
	- Notice the calendar.event form opened but without a name

### Cause:
When expanding the view using 'More options' button we are keeping the context in the new request.

https://github.com/odoo/odoo/blob/d9c63a85955c2321bae1a705cc09b2554155f826/addons/calendar/static/src/views/attendee_calendar/attendee_calendar_controller.js#L45-L49

But when doing the same through the expand button we don't pass the current context so it will be lost.

https://github.com/odoo/odoo/blob/3dde420665257c63885e891f1ec366568df5007b/addons/web/static/src/views/view_dialogs/form_view_dialog.js#L106-L116

### Fix:
Backporting the commit https://github.com/odoo/odoo/commit/4f71fbbd26b428e57943d974e8441bef295cdef1
to pass the context while expanding the form view

opw-4966486

Forward-Port-Of: odoo/odoo#221422

Versions
--------
- saas-18.2+

Steps
-----
1. Have a product with extra eCommerce images;
2. enable zoom-on-click on the product page;
3. add a recently-sold product carousel to the page;
4. click on an image to zoom in;
5. attempt to use arrow keys to navigate or using esc to exit zoom.

Issue
-----
Keys don't appear to do anything.

Cause
-----
Commit b8d0ab4275b24 set `oe_website_sale` as `snippet_classes` on the `s_dynamic_snippet_products` snippet, in order to enable the `websiteSaleTracking` widget, which uses this class as `selector`.

Issue is this class also gets used as the selector by the `WebsiteSale` widget which adds zoom-on-click event listeners. As there are two elements with the `oe_website_sale` class now, this widget gets called twice, and because the query selector selects all image elements on the sale page, images get duplicate event listeners assigned to them.

Consequently, clicking on an image opens two lightboxes, and the keys only impact the one hidden behind the other, making it appear as if key presses aren't doing anything.

Solution
--------
Instead of querying all images on the sale page in each call of the widget, only query for images in `this.el`.

opw-4908881

Forward-Port-Of: odoo/odoo#223231

> [!Note]
> This PR unreverts fc6b9ed22728 with a minor modification to ensure one `res.currency` record to compare amounts.

**Steps to reproduce**:
1. Install the `sale` module.
2. Enable `Pricelists` under `Settings > Sales > Pricing > Pricelists`.
3. Create two pricelists:
   - Pricelist A with two fixed-price rules: - 0.75 for quantity ≥ 0 - 0.50 for quantity ≥ 1000
   - Pricelist B with a -10% discount applied to Pricelist A.
4. Create a Sales Order using Pricelist B.
5. Add a product to the order line.
6. Increase the quantity to 1000.

**Observed behavior**:
- The unit price does not update according to the pricelist rule for quantity ≥ 1000.
- If you switch the pricelist to another and then back again, the `Update prices` button appears and correctly updates the price.

**Root cause**:
- The price is not recomputed when the quantity changes because the `price_unit` is not updated because it does not match the `technical_price_unit`.
- Since e1b22257a714, `price_unit` is rounded (2 decimals), but `technical_price_unit` is not. This causes a mismatch in comparison logic due to rounding differences.

**Solution**:
- Replace direct float comparison with `currency_id.compare_amounts()` to ensure proper comparison with rounding precision.

opw-4944644

Forward-Port-Of: odoo/odoo#223548

Scenario:

- add a 2 columns content widget
- set the right column text to "On Scroll" animation with "Slide" effect
  and "From Right" direction so the content may be out of the page
- save and reload the page on mobile
- scroll down get in middle of animation with some content out of page
- try to scroll to the right

Result: we can scroll to the right and see the overflowing animated
content outside of the expected page limit.

History:

During an animation, a fix prevent the horizontal scrollbar by setting
"overflow-x: hidden" (or crop depending on version) on a given element:

- in odoo/design-themes@51abb093c77993363b170b12be134c95b3009895
  (14.0: 2021) it was added to $().getScrollingElement()
- in 189a7c96e6e26825dc05c0c6466576fe63aa091e (18.0: 2022) the main page
  scroll was moved from #wrapwrap to html
- in fece9cb85761e6cb3fe3642f947661464402363b (18.0: 2024) the
  "overflow-x: hidden" was moved to the body element

Cause: the "overflow-x: hidden" is ignored by mobile browser on html and
body tags ([example of report]), so in 18.0 and over the possible
horizontal scrollbar caused by an animation is not hidden.

Fix: apply the "overflow-x: clip/hidden" on #wrapwrap element.

[example of report]: https://stackoverflow.com/questions/14270084

opw-4575726

Forward-Port-Of: odoo/odoo#213802

If you have a product template with variant, ex: Telephone case, variant name : Iphone 15 SE, Samsung Galaxy, Nokia 1999
When doing a search with more then 2 letters you will only find the Telephone case, searh exemple: Iphone 15 SE, Galaxy, Samsung.

** Step to reproduce **
- Create a product called "Telephone case" and add a variant named samsung galaxy S24 ultra
- Create a product called "Samsung galaxy"
- Enable both products for point of sale
- Go to the point of sale app and open a shop that sells both of those products.
- Do a search for the product Samsung galaxy
- Issue : Only the product "Telephone case" will appear.

** Cause of the issue **
Doing a search will call getProductsBySearchWord:

https://github.com/odoo/odoo/blob/5a1fff2cc61bd8676049879039defa3fb2a3f13d/addons/point_of_sale/static/src/app/services/pos_store.js#L2401-L2407

During the product.exactMatch(words) we will get a hit since we will have a name of the product variant:

https://github.com/odoo/odoo/blob/5a1fff2cc61bd8676049879039defa3fb2a3f13d/addons/point_of_sale/static/src/app/models/product_template.js#L265-L278

And the call for the function will finish there since the searchword lenght > 2 and we have a hit.

** Origin of the issue **

The variant search was implemented in "exactMatch()" which block more search if it find a result.

https://github.com/odoo/odoo/commit/05abd586d7adcceed3dae0943526e6357b28dbb4

opw-4864976

Forward-Port-Of: odoo/odoo#217484

### Description of the issue/feature this PR addresses:
Nilvera rejects E-Archive invoices if extra fields are present under
`PartyTaxScheme` when no tax office is set. In addition, the
`invoice_edi_format` selection name for TR was incorrect.  

### Current behavior before PR:
When generating E-Archive invoices, Odoo includes extra nodes such as
`registration_address_vals`, `registration_name`, and `company_id`
under the `PartyTaxScheme` element. Nilvera’s validation fails if
these nodes are present while no tax office is configured. At the same
time, the TR value for `invoice_edi_format` was using the wrong name,
which caused inconsistencies. These issues result in blocking
validation errors on Nilvera’s side and prevent the invoices from
being accepted.  

### Desired behavior after PR is merged:
After this fix, the `PartyTaxScheme` is cleaned up only to include the
expected XML structure:

```xml
<cac:PartyTaxScheme>
    <cac:TaxScheme>
        <cbc:Name>TAX OFFICE NAME</cbc:Name>
    </cac:TaxScheme>
</cac:PartyTaxScheme>
```
And the invoice_edi_format selection name for TR will be corrected
to display Türkiye rather than Turkyie.

task-5017223
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#223770

*=website

Target: 17.0 to saas-18.3

Issue: 
This issue applies to any block where multiple backgrounds are present (gradient + image).

Steps to Reproduce:
1. Drop a masonry snippet onto the page.
2. Select a block and change the background color to the gradient.
3. Add background image.
3. Change the image position from "Cover" to "Repeat Pattern."
4. Observe the traceback in the console.

Reason:
The issue occurred due to incorrect parsing of CSS background values when multiple background layers were applied (e.g., a gradient + image). When both are set, the element ends up with multiple background-related properties. Previously, In setValue method, Inside MultiUserValueWidget when value = "100px, 100px", the resulting values array was ['100px,', '100px'], which included an extra comma. This has now been corrected to properly handle such cases.

Other edge cases fixed:
1. Gradient was repeating along with the image.
2. Switching to parallax after repeat-pattern causes gradient to repeat.
3. Removing image kept repeat class, causing gradient to repeat.

Fix Summary:
1. We updated `selectStyle` and _computeWidgetState to correctly handle multi-layer background-size and repeat styles.
In selectStyle, we set the height and width values from options and apply them only to the image layer (not gradient), keeping the gradient layer unchanged.
In `_computeWidgetState`, we fetch the background-size from the target and, if multiple layers are present, return only the first one (image layer), since height and width options apply only to that. Now, setValue receives only single-layer values like
`100px 50px`, ensuring correct behavior.
Set background-size 'cover' to gradient which ensures only the image
repeats while the gradient remains fixed.
2. Remove `o_bg_img_opt_repeat` and reset background-size when
   - Image is removed.
   - Switching to parallax.
   
task-4577864

Forward-Port-Of: odoo/odoo#207757

**Steps to reproduce:**
- With pos_loyalty installed, launch the PoS
- Select a customer and make a purchase
- This needs to create a new loyalty coupon (new customer or program)
- The customer name is not displayed on the receipt

**Problem:**
When a customer is set for an order in pos_loyalty, it should appear on the receipt. Before this commit, sometimes it was not displayed.

**Why the fix:**
The customer was not displayed everytime because it was displayed inside this if statement, https://github.com/odoo/odoo/blob/033c7a63bdf3d10d9d2c5084959fd34f52011bea/addons/pos_loyalty/static/src/app/screens/receipt_screen/order_receipt/order_receipt.xml#L6 So the customer would only be displayed if there was a new coupon being created, and not if we were updating a new one. This behavior was introduced in a REF in 18.3 461359e The behavior does not make sense as it displays the customer for each new coupon we have in this order, so it might be displayed multiple times.
With this commit, we display the customer all the time, as it is weird to only display it if a new coupon is created or if loyalty logic is involved, as said here 879b415

opw-4929076
opw-4976885

As far as I can tell this can occur if the ws connection gets closed while we're in a `recv`: in that case `recv` will mark the connection as closed (`connected=False` and `sock=None`) and raise `WebSocketConnectionClosedException`, then any attempt to `send` will fail with `WebSocketConnectionClosedException`.

Here this likely is an issue because in `_receive` `WebSocketConnectionClosedException` goes through the generic exception handler, which sees that:

- it's not a `ConnectionResetError`
- the result is not set
- and the ws is not connected

So `_receive` just cancels the result and `return`s, and when whatever's waiting on a future finally times out it tries to cleanly shut down and hits a connection that's already closed.

Handle a connection closed in that context more properly:

- unset `ws` so we don't try to clean it up, as we know it's closed
- set the result as being in error
- cancel every future in order to immediately go to the tour failure step rather than wait for timeouts

Note that this will not really *fix* any error per se, because every time this happens it means the browser abruptly closed the WS connection (possibly straight up died), so this should mostly properly attribute the error so we can investigate it.

https://runbot.odoo.com/odoo/error/229793

Forward-Port-Of: odoo/odoo#224023

## Short functional explanation of the error
For Dutch companies, when downloading the NLCIUS file of an invoice, the schemeID of the companyID in the XML isn't correct.

## Reproduction Steps
1. Make sure you use a dutch company: in apps, download the 'l10n_nl' and 'account_edi_ubl_cii' modules. Then, click on your company and select the NL Company.
2. Go to settings and type Peppol. Under Customer Invoices, check the Peppo format. Then, setup a Peppol Endpoint. Hit save.
3. Go to the Accounting app and click on the customers tab, then invoices. Click on new.
4. Select a customer. Make sure that the customer is from the Netherlands, has an email address, and in the accounting tab, an account number. Still in the accounting tab, under Electronic Invoicing, set the format at NLCIUS, set a Peppol e-address and a Peppol Endpoint that is 20 characters long.
5. Add a product, click confirm then Send & Print. Make sure that NLCIUS is well checked and click again Send & Print.
6. In the bottom right corner of the page, just under the Amount Due, there's a paper clip icon. Click on it and you'll see the XML. Download it.

### Expected behavior
As the CompanyID is 20 characters long, the schemeID next to the CompanyID should have the value of 0190.

### Unexpected behavior
If you scroll a bit, you'll see that the SchemeID next to the CompanyID has a number of 0106.

## Origin of the issue
In the code, the SchemeID will have a value of 0190 if the CompanyID is 9 characters long.

__
opw-4943262



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#219771
Forward-Port-Of: odoo/odoo#219424

**Issue**:
* Amounts were exactly doubled in 'Current financial investments' (line 12500) in the Spanish Balance Sheet - SMEs report as account codes 551 and 5525 were incorrectly included in balance_pymes_line_12500_sub_balances formula


**Root Cause**:
* Account codes 551 and 5525 were included in BOTH:
  1. Line 12500 sub_balances (unfiltered account_codes expression)
  2. Line 12500 sub_debits (domain expression with sum_if_pos filter)
* This double-counting within the same line caused financial investment amounts 
  to appear twice in the balance sheet
  
**How to Reproduce**:
1. Create Spanish company with 'es_pymes' chart of accounts
2. Post journal entries to accounts 551 or 5525 (current financial investments)
3. Generate 'Balance Sheet - SMEs (ES)' report
4. Observe amounts in line 'V. Current financial investments' are exactly 
   doubled compared to account balances
5. Click on the doubled amount - shows underlying transactions sum to half the amount

**Fix**:
* Removed account codes 551 and 5525 from balance_pymes_line_12500_sub_balances
* These accounts are properly handled by the  sub_debits expression
* Each account is now counted only once within the line
  
opw-4983300

Currently, an error occurs when creating an expense for an employee that is not linked to a user.

**Steps to reproduce:**

- Install the `hr_expense` module.
- Create a new employee `test` (ensure this employee is not linked to a user).
- Go to Expenses > upload [1] and open it.
- Set the `Employee` to `test` and click `Save` (it may take up to 5 seconds).

(See [2] for Steps to reproduce)

**Error:**
`AttributeError: 'hr.expense' object has no attribute 'uid'`

**Root Cause:**
At [3], the code incorrectly uses `self.uid` instead of `self.env.uid`. Since `hr.expense` records do not have a `uid` field, this leads to an `error`.

**Fix:**
This commit ensures that expenses can be saved correctly, even when the selected employee is not linked to a user.

[1]:
https://drive.google.com/file/d/1Ew2B_zMFCQbw-6nwfKctJPy1W4y2ZaIb/view?usp=sharing

[2]:
https://drive.google.com/file/d/1qP-9L_emaox3l9JyoNVYjqj1Ht8bJSmZ/view?usp=sharing

[3]:
https://github.com/odoo/enterprise/blob/804f263b80cb78884e3f246bcc7fa7ea4e0cf73a/hr_expense_extract/models/hr_expense.py#L90

sentry-6834628909

### Steps to reproduce:
- Install l10n_br_edi, switch to Brazilian company
- Set up Avalara
- Create an invoice with the tax "ICMS Exemption Incl." which is included in price
- Click "Generate taxes" to compute the taxes with Avalara
- In "Journal Items" we can see a line for "ICMS Exemption Incl.", its value appear as excluded

### Cause:
The result from Avalara included a value for this tax:
```
'tax': 1.44,
'taxImpact': {
	'accounting': 'none',
	'impactOnFinalPrice': 'Included',
	'impactOnNetAmount': 'Included',
},
```
But the untaxed amount is computed without this tax. Odoo keeps the untaxed amount from the response and add a line for the tax. As a result the tax is added to the amounts like an excluded tax would.

### Solution:
In the response from Avalara, we don't want to create a line for the tax `icmsDeson` when there is `'accounting': 'none'`.

We also log this tax in the chatter to keep a trace of it.

opw-4964315

Forward-Port-Of: odoo/enterprise#91940

An error occurs when a user attempts to mark a scheduled activity as done after the associated approval rule has been deleted.

**Steps to Reproduce:**
1) Install Sales and Web Studio modules.
2) Log in as Admin and use Studio to add an approval rule to the Sale Order’s Preview button.
>- Set Allowed Group to Access Rights.
>- Set Responsible User to Mitchell Admin.
3) In the Incognito Tab, login as Demo, open the same sale order and click on
   preview to create activity in chatter.
4) Delete the Approval Rule in the original tab.
5) Switch back to Demo and click Mark Done under Planned Activity in chatter.

**Error:**
`SyntaxError: syntax error at or near ')'`
 `LINE 1: SELECT id FROM studio_approval_rule WHERE id IN () FOR UPDAT. ^`

**Root Cause:**
The error occurs because the SQL query at [1] includes an empty tuple of rule IDs `(all_rule_ids)`. An empty `IN ()` clause in SQL results in a syntax error.

[1]- https://github.com/odoo/enterprise/blob/7ea45724e7689a0df11d20ace9c562788f5d19e3/web_studio/models/studio_approval.py#L366

**Solution:**
This commit avoids the error by ensuring that the SQL query only runs when `all_rule_ids` is not empty.

sentry-6306636466

Forward-Port-Of: odoo/enterprise#86982