**Steps to Reproduce:**
1. Create a new membership product from the Membership module.
2. Open any partner and go to the Membership page.
3. Click on Buy Membership and select the created product.
4. Click on Invoice Membership.
5. Open the newly created draft invoice.
6. From the invoice line, open the product form (via the internal link).
7. Disable the Can be Purchased option and return to the invoice using breadcrumbs.
8. Add a new line in the invoice and search for the same product by its name.



**Observation:**
1. When Can be Purchased is enabled on the product, the product appears in the invoice line search.
2. When Can be Purchased is disabled, the product no longer appears in the search.



**Issue:**

In the product field domain defined in
https://github.com/odoo/odoo/blob/9ba5b41ef0252f4421ff6cdcd7c047b7c53706f4/addons/account/views/account_move_views.xml#L1022-L1029 the `default_move_type` context is `null`.
As a result, only the condition `[('purchase_ok', '=', True)]` is applied in the `name_search` domain.



**Solution:**

Pass the proper context value in the invoice action, ensuring the domain evaluates correctly and the product remains searchable.




**Note:**

The domain used in the following field
https://github.com/odoo/odoo/blob/9ba5b41ef0252f4421ff6cdcd7c047b7c53706f4/addons/account/views/account_move_views.xml#L1022-L1029

is evaluated by a following JavaScript function
https://github.com/odoo/odoo/blob/9ba5b41ef0252f4421ff6cdcd7c047b7c53706f4/addons/web/static/src/core/py_js/py_interpreter.js#L483-L489

rather than on the Python backend. Because the domain logic depends on dynamic
context evaluation performed client-side, there is no straightforward way to
retrieve or test the domain arguments dynamically within the `name_search`
method on the server. As a result, it is not feasible to write automated test
cases for this specific domain filtering scenario in the backend.



opw-5028789

Forward-Port-Of: odoo/odoo#225230

The system will crash with error when try to create a analytic item.

**Steps to Produce:-**
1. Install the `Accounting` module with demo data.
2. Go to `Settings > enable Analytic Accounting`.
3. Navigate to `Accounting > Customers > Invoices`.
4. Create a new invoice with total amount = 0 and confirm it.
5. Go to Accounting > Accounting > Transactions > Analytic Items.
6. Create a new Analytic Item and:
   - Set a value in the `Project` field.
   - Under the `Accounting` section, select the `Journal Item` linked to the last created 0-amount invoice and save.

**Error:-**
`ZeroDivisionError: float division by zero`

**Cause:-**
- At [1], when `line.balance` is 0.0 (for example, when a journal item is defined with a total of 0.0), the system raises an error.

**Solution:-**
- Added a condition to compute only when line.balance exists; otherwise,set the value to 100.

[1]: https://github.com/odoo/odoo/blob/dff2423ac320fdb97d6bf1f106dc84be1d71cac2/addons/account/models/account_move_line.py#L3248-L3251

**sentry-6844926153**

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

Forward-Port-Of: odoo/odoo#225068

## [FIX] l10n_cz: prevent error with misaligned accounting date and sequence number of demo moves

#### Description of the issue/feature this PR addresses:
Editing CZ Company address while having demo data throws Validation Error

#### Current behavior before PR:
When trying to change address of CZ Company while l10n_cz with demo data is present an error popup is displayed and it's not possible to to save the changes. Steps to reproduce:
 - Install l10n_cz with demo data
 - Open CZ Company in form view
 - Change address (e.g. change city Praha -> Brno)
 - Click Save

#### Desired behavior after PR is merged:
The address changes are saved without any error.

#### Solution:
This change adds `taxable_supply_date` date values for CZ demo moves that are compatible with `invoice_date` values to make sure that accounting date values are the same on each recomputatation and do not lead to new sequence numbers that are not aligned with the previous ones which would cause errors being raised by sequence mixin.

Related to: #226152







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

Forward-Port-Of: odoo/odoo#227847

**Before**
- the active_test context key is part of the main base_automation
  action (base_automation_act), but this context key stays in the
  context further, leading to unwanted filtering in i.e. the
  action_server_ids.resource_ref search view dialog.
- Steps to reproduce:
  - have base_automation installed
  - create an automation rule targeting the res.users model
  - add an Update server action targeting the Partner field
  - in the resource_ref autocomplete, click on Search More...
  - the search view dialogs displays archived records

**After**
- we chose to instead have a default filter in the base_automation_act
  action to include archived records by default. As the context key
  to activate the default filter starts with 'search_default_', it
  is already cleared from the context when opening the form view
  (standard behavior).
- when you reproduce the same steps as before, the archived records
  are no longer displayed in the search view dialog.

**Additional Note**
This fix requires to upgrade the base_automation module.

opw-4886487

Forward-Port-Of: odoo/odoo#225146